21854 2013-04-26 21:09:30 +0000 Define MediaKeySession life cycle states and/or events 2013-12-12 23:17:33 +0000 1 1 1 Unclassified HTML WG Encrypted Media Extensions unspecified All All RESOLVED FIXED P2 normal --- 19809 20622 20991 21855 1 ddorwin adrianba adrianba mike public-html-media steele watsonm public-html-bugzilla oldest_to_newest 86889 0 ddorwin 2013-04-26 21:09:30 +0000 There have been several bugs related to communicating various states or exceptions to the "normal" license exchange flow. This bug will track definition of states and/or events to support these use cases. The resolution of this bug should address the following scenarios. The listed bugs contain useful background discussion but will be closed as duplicates of this bug. * Bug 16553: related to not firing needkey if the key is already known * Bug 19208: related to not firing keymessage if the key is already known * Bug 20688: related to the meaning (or elimination) of the keyadded event * Bug 20689: related to indicating successful completion of the key exchange with no message for the server * keymessages may be fired after completion of the initial key exchange (e.g. for renewal scenarios) In addition, the resolution should enable us to address the following: * Bug 20622: SessionID may be assigned asynchronously * Bug 20991: CDM loading should be asynchronous and errors should be reported asynchronously 86891 1 ddorwin 2013-04-26 21:14:39 +0000 *** Bug 20688 has been marked as a duplicate of this bug. *** 86893 2 ddorwin 2013-04-26 21:15:09 +0000 *** Bug 20689 has been marked as a duplicate of this bug. *** 86900 3 ddorwin 2013-04-26 21:54:31 +0000 Bug 21855 to avoid network traffic and duplicate sessions for the same key(s) is likely to be closely related to this issue. (Note: Bug 16553 and bug 19208 mentioned in the original description of this bug were actually closed as duplicates of 21855 instead.) 86901 4 ddorwin 2013-04-26 22:02:28 +0000 Bug 20688 #c4 and #c5 have some useful information about possible states/events from the April 23 f2f. 87337 5 watsonm 2013-05-07 15:33:06 +0000 Updated diagram: http://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgQ0RNIFN0YXRlIFByb2dyZXNzaW9uCgpub3RlIG92ZXIgQ0RNOiBVbmluaXRpYWxpemVkAA8OLCBBcHA6IHRpbWUgcGFzc2VzAC0QSQAwC0NETS0-ACwFa2V5bWVzc2FnZQBdEFdhaXRpbmcKQXBwLT4AegV1cGRhdGUoKQpvcHQAA0BlbgCBMg86IHJlYWR5AIFBFXBsYXliYWNrACRVAFQQAIFmCmNsb3NlKCkAghkVIChrZXkgcmVsZWFzZSkAgxkQQ2xvcwCCJRcAFxNlZAo&s=napkin 87369 6 ddorwin 2013-05-07 19:02:35 +0000 Thanks, Mark. The diagram makes sense. I would put the last keymessage-closing-update() series in an opt box. close() might be implicit, but I'm not sure we need to be explicit about that here. Assuming we roughly agree on what the states are, we need to decide: * If/how to expose (a subset of?) the states. * If/how to document this. (i.e. Is it just informative to help in understanding? If so, does it go in a primer, etc.?) Expanding on a couple things mentioned in the telecon today: * The important question to ask is whether the application needs to know the states or does it have enough information from events to behave correctly without explicit states. (Are there additional events necessary to achieve this?) * The diagram should probably be a state machine. (When specifying implementations, this probably makes the sense. However, the sequence diagram is probably useful as an introduction/primer for someone to understand how a typical flow might look.) 87898 7 steele 2013-05-20 06:23:00 +0000 Having thought about this a bit more now, I am not sure this is needed. I may track the state like this internally in the CDM, but the useful state information (e.g. waiting for a key) can be deduced from the sequence of events as David mentioned. My second thought is that this could be useful to the UA (as opposed to the app) but I think the UA can do the same deduction that the app can since it will see all the events. This would be a good bit of information to put in a primer though. 89479 8 1374 adrianba 2013-06-18 14:43:40 +0000 Created attachment 1374 State transition diagram 89481 9 adrianba 2013-06-18 14:49:05 +0000 Our proposal is to have session state as shown in the attached state transition diagram. A session will start in the CREATED state. A keyerror event might fire taking the session to the ERROR state. Alternatively a keyready event might fire taking the session to the READY state. READY means that the session does not expect to block playback if encrypted content is encountered. During key acquisition, the session moves to the PENDING state when a keymessage event fires. PENDING means that if encrypted content is encountered that needs the key or keys being acquired in this session then playback will stall. Zero or more keymessage events might fire while in the PENDING state. keyready will move the session to the READY state. keyerror to the ERROR state. At any time, for CDM specific reasons, it may be necessary to return from the READY state to the PENDING state. This might occur for some form of key rotation, for example. We propose to add a state attribute to the session and a new keyready event. It is an open question whether we should keep the keyadded event. It's not clear what action someone might take from keyadded but it also doesn't seem cause harm to include it. 89483 10 watsonm 2013-06-18 15:09:32 +0000 LGTM We could add a CLOSED state for when the keys have been destroyed but there may still be state (key release messages, if supported). ...Mark 89487 11 steele 2013-06-18 16:33:57 +0000 Are you proposing a specific "key ready" event or a general "key status" event that indicates a state change? The latter would be more useful IMO and would cover the "closed" case Mark mentioned as well. If you have a general key status event, you can drop the need for an attribute to reflect the status as well. 89488 12 steele 2013-06-18 16:36:39 +0000 Actually I suppose that having "key ready", "key pending" and "key closed" all as separate events would be the way to go. That way if we have multiple sessions on a media element and one session has already requested the key that another session will use as well, the "key pending" event will be sent instead of a "need key" event. 89501 13 adrianba 2013-06-18 19:49:38 +0000 (In reply to comment #12) > Actually I suppose that having "key ready", "key pending" and "key closed" > all as separate events would be the way to go. That way if we have multiple > sessions on a media element and one session has already requested the key > that another session will use as well, the "key pending" event will be sent > instead of a "need key" event. Since needkey fires independently from the key system, we're not proposing to use pending instead of needkey. See bug 21855. 89505 14 steele 2013-06-18 20:52:01 +0000 So if the app wants to display a progress indicator, they will listen for needkey (which always happens) and then listen for keyready (which always happens)? If this is correct I don't understand the use case for the status attribute. It seems like the application knows exactly what the state is based on the messages it has seen. 89508 15 adrianba 2013-06-18 21:19:47 +0000 (In reply to comment #14) > So if the app wants to display a progress indicator, they will listen for > needkey (which always happens) and then listen for keyready (which always > happens)? needkey fires on the media element. Then a session is created and then keyready will eventually fire on the session (usually after keymessage/update exchanges). > If this is correct I don't understand the use case for the status attribute. > It seems like the application knows exactly what the state is based on the > messages it has seen. Yes, you can determine the state by knowing what messages you've seen. We don't have to expose the state but it is a low cost attribute assuming that generally implementations will want to implement as a state machine of some kind and this is a common pattern for APIs that have some kind of progress/state. 91398 16 ddorwin 2013-07-30 00:36:10 +0000 My thoughts: There should be a transition from the READY state to the ERROR state. I think keyadded should be eliminated (replaced by keyready) unless there is a good use case for knowing that a (new?) key was added. Since every transition already has an event, it's unclear what purpose a state attribute would serve. Since it could just restrict or complicate implementations, I do not believe we should expose it unless there are good use cases. Are there other examples of _redundant_ events and state attributes (vs. a single statechange/progress event with a corresponding state attribute)? 91529 17 ddorwin 2013-08-01 23:11:23 +0000 I don't know that it matters, but note that not all events in the state diagram are equal. Specifically, keyerror and keyready are simple events, but keymessage is a custom event type. There is no change from the current events [1]; we've just made them all represent state transitions. https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#event-summary 91690 18 adrianba 2013-08-06 14:47:07 +0000 (In reply to comment #16) > Are there other examples of _redundant_ events and state > attributes (vs. a single statechange/progress event with a corresponding > state attribute)? A few that come to mind: FileReader readyState http://www.w3.org/TR/FileAPI/#dfn-filereader HTMLImageElement complete http://www.w3.org/TR/html5/embedded-content-0.html#the-img-element Document readyState http://www.w3.org/TR/html5/dom.html#dom-document-readystate 93470 19 adrianba 2013-09-17 05:14:38 +0000 I added text describing the internal state of the media key session: https://dvcs.w3.org/hg/html-media/rev/83629aec22e1 Issues still unresolved: 1) I did not remove keyadded. We should decide whether this is now removed. I don't believe it has any purpose. 2) I did not add the state variable as an attribute. If we add this, we need to decide is it a string or integer. 3) I did not add the transition from READY to ERROR. I'm not sure where in the text this transition should be described. 94077 20 adrianba 2013-10-01 14:50:43 +0000 (In reply to Adrian Bateman [MSFT] from comment #19) > Issues still unresolved: > 1) I did not remove keyadded. We should decide whether this is now removed. > I don't believe it has any purpose. I propose that we remove keyadded. It is not needed. > 2) I did not add the state variable as an attribute. If we add this, we need > to decide is it a string or integer. I seem to be the only one arguing for this. It seems like there consensus is "don't care" and I'm happy to leave it out for now. > 3) I did not add the transition from READY to ERROR. I'm not sure where in > the text this transition should be described. I don't think there needs to be a transition from READY to ERROR. I think errors should only occur on the MediaKeySession that are related to in-flight key exchanges either after creating the session or while it is PENDING. If an error occurs in the READY state then this should be thrown against the media element since it presumably is going to cause playback to halt. 94080 21 adrianba 2013-10-01 15:35:09 +0000 Discussed on telcon 2013-10-01: Agreed to issues 1 and 2. Moving issue 3 to be part of bug 21798. 94767 22 adrianba 2013-10-15 14:32:23 +0000 Removed keyadded event. This bug is now resolved. https://dvcs.w3.org/hg/html-media/rev/4b466f3beae3 95489 23 ddorwin 2013-10-28 23:06:14 +0000 (In reply to Adrian Bateman [MSFT] from comment #19) > I added text describing the internal state of the media key session: > https://dvcs.w3.org/hg/html-media/rev/83629aec22e1 This change added the following text to the update() algorithm: > If the session is not in the PENDING state, throw an INVALID_STATE_ERR. I don't think this should be the case. There are probably legitimate reasons for the application to provide a new message without the session requesting it (and thus being in the PENDING state) - in other words, in the READY state. There may even be use cases for calling update() in the CREATED, ERROR, or CLOSED states. This change also included the following text describing the new keyready event: > The media element should not be blocked if encrypted data is encountered associated with the initData used to create the session. I don’t think we can say this. Output protection or other issues could cause the key(s) in the session to be unusable and thus for the media element to be blocked. 96155 24 adrianba 2013-11-12 02:09:22 +0000 (In reply to David Dorwin from comment #23) > This change added the following text to the update() algorithm: > > If the session is not in the PENDING state, throw an INVALID_STATE_ERR. > > I don't think this should be the case. There are probably legitimate reasons > for the application to provide a new message without the session requesting > it (and thus being in the PENDING state) - in other words, in the READY > state. > > There may even be use cases for calling update() in the CREATED, ERROR, or > CLOSED states. update() is intended to provide a message in response to the keymessage payload. I'm not sure we should change the spec unless we know of specific use cases where we don't want to limit it to this. We could wait to see if implementation experience suggests this is actually needed? I think we need to specify what to do if you call update() and it is not expected. Should it be silently ignored or should you get a state error. > This change also included the following text describing the new keyready > event: > > The media element should not be blocked if encrypted data is encountered associated with the initData used to create the session. > > I don’t think we can say this. Output protection or other issues could cause > the key(s) in the session to be unusable and thus for the media element to > be blocked. This is a should rather than a must. The intent is that you move to READY when you don't expect to be blocked waiting for key material. Are you proposing to remove or revise this text? Perhaps we can change it into informative text? 96163 25 ddorwin 2013-11-12 03:58:56 +0000 (In reply to Adrian Bateman [MSFT] from comment #24) > (In reply to David Dorwin from comment #23) > > This change added the following text to the update() algorithm: > > > If the session is not in the PENDING state, throw an INVALID_STATE_ERR. > > > > I don't think this should be the case. There are probably legitimate reasons > > for the application to provide a new message without the session requesting > > it (and thus being in the PENDING state) - in other words, in the READY > > state. > > > > There may even be use cases for calling update() in the CREATED, ERROR, or > > CLOSED states. > > update() is intended to provide a message in response to the keymessage > payload. That's the basic model, but I never assumed it was the only model. > I'm not sure we should change the spec unless we know of specific > use cases where we don't want to limit it to this. We could wait to see if > implementation experience suggests this is actually needed? I think we need > to specify what to do if you call update() and it is not expected. Should it > be silently ignored or should you get a state error. Why do UAs/CDMs need to be "expecting" an update() call? I assumed they would just always process the input and decide what to do? As for use cases, an app could proactively provide a renewal message, a new key, etc. I imagine there might be some more complex uses cases where operations need to be performed on the session as well. > > This change also included the following text describing the new keyready > > event: > > > The media element should not be blocked if encrypted data is encountered associated with the initData used to create the session. > > > > I don’t think we can say this. Output protection or other issues could cause > > the key(s) in the session to be unusable and thus for the media element to > > be blocked. > > This is a should rather than a must. The intent is that you move to READY > when you don't expect to be blocked waiting for key material. Are you > proposing to remove or revise this text? Perhaps we can change it into > informative text? I agree that this is the expected behavior in the happy case and it may be useful in understanding the general flow. The problem I see is that the text implies that playback will not be blocked, but there are expected scenarios when the key/license will be unusable when such media data is encountered (output protection, expired license, etc.) I think we can probably reword the text to provide the helpful information without implying the media element can't be blocked. Maybe we should just say the license/key is ready for use. "Use" may include checking validity. 97546 26 adrianba 2013-12-12 23:12:53 +0000 (In reply to David Dorwin from comment #25) > (In reply to Adrian Bateman [MSFT] from comment #24) > > I'm not sure we should change the spec unless we know of specific > > use cases where we don't want to limit it to this. We could wait to see if > > implementation experience suggests this is actually needed? I think we need > > to specify what to do if you call update() and it is not expected. Should it > > be silently ignored or should you get a state error. > > Why do UAs/CDMs need to be "expecting" an update() call? I assumed they > would just always process the input and decide what to do? > > As for use cases, an app could proactively provide a renewal message, a new > key, etc. I imagine there might be some more complex uses cases where > operations need to be performed on the session as well. I have filed Bug 24081 to track this issue. 97547 27 adrianba 2013-12-12 23:17:33 +0000 (In reply to David Dorwin from comment #25) > I agree that this is the expected behavior in the happy case and it may be > useful in understanding the general flow. The problem I see is that the text > implies that playback will not be blocked, but there are expected scenarios > when the key/license will be unusable when such media data is encountered > (output protection, expired license, etc.) > > I think we can probably reword the text to provide the helpful information > without implying the media element can't be blocked. Maybe we should just > say the license/key is ready for use. "Use" may include checking validity. I have updated the spec with new language to address this case. https://dvcs.w3.org/hg/html-media/rev/d9c9406a821f 1374 2013-06-18 14:43:40 +0000 2013-06-18 14:43:40 +0000 State transition diagram SessionState.svg image/svg+xml 5961 adrianba PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+DQo8 IURPQ1RZUEUgc3ZnIFBVQkxJQyAiLS8vVzNDLy9EVEQgU1ZHIDEuMS8vRU4iICJodHRwOi8vd3d3 LnczLm9yZy9HcmFwaGljcy9TVkcvMS4xL0RURC9zdmcxMS5kdGQiPg0KPCEtLSBHZW5lcmF0ZWQg YnkgTWljcm9zb2Z0IFZpc2lvLCBTVkcgRXhwb3J0IFNlc3Npb25TdGF0ZS5zdmcgUGFnZS0xIC0t Pg0KPHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJo dHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiB4bWxuczpldj0iaHR0cDovL3d3dy53My5vcmcv MjAwMS94bWwtZXZlbnRzIg0KCQl3aWR0aD0iMTFpbiIgaGVpZ2h0PSI4LjVpbiIgdmlld0JveD0i MCAwIDc5MiA2MTIiIHhtbDpzcGFjZT0icHJlc2VydmUiIGNvbG9yLWludGVycG9sYXRpb24tZmls dGVycz0ic1JHQiIgY2xhc3M9InN0MTEiPg0KCTxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+DQoJPCFb Q0RBVEFbDQoJCS5zdDEge3Zpc2liaWxpdHk6dmlzaWJsZX0NCgkJLnN0MiB7ZmlsbDojNWI5YmQ1 O2ZpbGwtb3BhY2l0eTowLjIyO2ZpbHRlcjp1cmwoI2ZpbHRlcl8yKTtzdHJva2U6IzViOWJkNTtz dHJva2Utb3BhY2l0eTowLjIyfQ0KCQkuc3QzIHtmaWxsOiM1YjliZDU7c3Ryb2tlOiNjN2M4Yzg7 c3Ryb2tlLXdpZHRoOjAuMjV9DQoJCS5zdDQge2ZpbGw6I2ZlZmZmZjtmb250LWZhbWlseTpDYWxp YnJpO2ZvbnQtc2l6ZToxLjVlbX0NCgkJLnN0NSB7bWFya2VyLWVuZDp1cmwoI21ya3I0LTI0KTtz dHJva2U6IzViOWJkNTtzdHJva2UtbGluZWNhcDpyb3VuZDtzdHJva2UtbGluZWpvaW46cm91bmQ7 c3Ryb2tlLXdpZHRoOjQuNX0NCgkJLnN0NiB7ZmlsbDojNWI5YmQ1O2ZpbGwtb3BhY2l0eToxO3N0 cm9rZTojNWI5YmQ1O3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLXdpZHRoOjAuNjQxMDI1NjQxMDI1 NjR9DQoJCS5zdDcge2ZpbGw6I2ZmZmZmZjtzdHJva2U6bm9uZTtzdHJva2UtbGluZWNhcDpidXR0 O3N0cm9rZS13aWR0aDo3LjJ9DQoJCS5zdDgge2ZpbGw6IzRmODdiYjtmb250LWZhbWlseTpDYWxp YnJpO2ZvbnQtc2l6ZToxLjVlbX0NCgkJLnN0OSB7bWFya2VyLXN0YXJ0OnVybCgjbXJrcjQtNjYp O3N0cm9rZTojNWI5YmQ1O3N0cm9rZS1saW5lY2FwOnJvdW5kO3N0cm9rZS1saW5lam9pbjpyb3Vu ZDtzdHJva2Utd2lkdGg6NC41fQ0KCQkuc3QxMCB7ZmlsbDojNGY4OGJiO2ZvbnQtZmFtaWx5OkNh bGlicmk7Zm9udC1zaXplOjEuNWVtfQ0KCQkuc3QxMSB7ZmlsbDpub25lO2ZpbGwtcnVsZTpldmVu b2RkO2ZvbnQtc2l6ZToxMnB4O292ZXJmbG93OnZpc2libGU7c3Ryb2tlLWxpbmVjYXA6c3F1YXJl O3N0cm9rZS1taXRlcmxpbWl0OjN9DQoJXV0+DQoJPC9zdHlsZT4NCg0KCTxkZWZzIGlkPSJNYXJr ZXJzIj4NCgkJPGcgaWQ9ImxlbmQ0Ij4NCgkJCTxwYXRoIGQ9Ik0gMiAxIEwgMCAwIEwgMiAtMSBM IDIgMSAiIHN0eWxlPSJzdHJva2U6bm9uZSIvPg0KCQk8L2c+DQoJCTxtYXJrZXIgaWQ9Im1ya3I0 LTI0IiBjbGFzcz0ic3Q2IiByZWZYPSItMy4xMiIgb3JpZW50PSJhdXRvIiBtYXJrZXJVbml0cz0i c3Ryb2tlV2lkdGgiIG92ZXJmbG93PSJ2aXNpYmxlIj4NCgkJCTx1c2UgeGxpbms6aHJlZj0iI2xl bmQ0IiB0cmFuc2Zvcm09InNjYWxlKC0xLjU2LC0xLjU2KSAiLz4NCgkJPC9tYXJrZXI+DQoJCTxt YXJrZXIgaWQ9Im1ya3I0LTY2IiBjbGFzcz0ic3Q2IiByZWZYPSIzLjA0IiBvcmllbnQ9ImF1dG8i IG1hcmtlclVuaXRzPSJzdHJva2VXaWR0aCIgb3ZlcmZsb3c9InZpc2libGUiPg0KCQkJPHVzZSB4 bGluazpocmVmPSIjbGVuZDQiIHRyYW5zZm9ybT0ic2NhbGUoMS41NikgIi8+DQoJCTwvbWFya2Vy Pg0KCTwvZGVmcz4NCgk8ZGVmcyBpZD0iRmlsdGVycyI+DQoJCTxmaWx0ZXIgaWQ9ImZpbHRlcl8y Ij4NCgkJCTxmZUdhdXNzaWFuQmx1ciBzdGREZXZpYXRpb249IjIiLz4NCgkJPC9maWx0ZXI+DQoJ PC9kZWZzPg0KCTxnPg0KCQk8dGl0bGU+UGFnZS0xPC90aXRsZT4NCgkJPGcgaWQ9InNoYXBlMjEt MSIgdHJhbnNmb3JtPSJ0cmFuc2xhdGUoMzI0LC00NjMuNSkiPg0KCQkJPHRpdGxlPlNxdWFyZTwv dGl0bGU+DQoJCQk8ZGVzYz5DUkVBVEVEPC9kZXNjPg0KCQkJPGcgaWQ9InNoYWRvdzIxLTIiIHRy YW5zZm9ybT0ibWF0cml4KDEsMCwwLDEsMC4zNDU1OTgsMS45NzI3OSkiIGNsYXNzPSJzdDEiPg0K CQkJCTxyZWN0IHg9IjAiIHk9IjUwNCIgd2lkdGg9IjEwOCIgaGVpZ2h0PSIxMDgiIGNsYXNzPSJz dDIiLz4NCgkJCTwvZz4NCgkJCTxyZWN0IHg9IjAiIHk9IjUwNCIgd2lkdGg9IjEwOCIgaGVpZ2h0 PSIxMDgiIGNsYXNzPSJzdDMiLz4NCgkJCTx0ZXh0IHg9IjIwLjQiIHk9IjU2My40IiBjbGFzcz0i c3Q0Ij5DUkVBVEVEPC90ZXh0PgkJPC9nPg0KCQk8ZyBpZD0ic2hhcGUyMi03IiB0cmFuc2Zvcm09 InRyYW5zbGF0ZSgzMjQsLTI2MSkiPg0KCQkJPHRpdGxlPlNxdWFyZS4yMjwvdGl0bGU+DQoJCQk8 ZGVzYz5QRU5ESU5HPC9kZXNjPg0KCQkJPGcgaWQ9InNoYWRvdzIyLTgiIHRyYW5zZm9ybT0ibWF0 cml4KDEsMCwwLDEsMC4zNDU1OTgsMS45NzI3OSkiIGNsYXNzPSJzdDEiPg0KCQkJCTxyZWN0IHg9 IjAiIHk9IjUwNCIgd2lkdGg9IjEwOCIgaGVpZ2h0PSIxMDgiIGNsYXNzPSJzdDIiLz4NCgkJCTwv Zz4NCgkJCTxyZWN0IHg9IjAiIHk9IjUwNCIgd2lkdGg9IjEwOCIgaGVpZ2h0PSIxMDgiIGNsYXNz PSJzdDMiLz4NCgkJCTx0ZXh0IHg9IjE5Ljg1IiB5PSI1NjMuNCIgY2xhc3M9InN0NCI+UEVORElO RzwvdGV4dD4JCTwvZz4NCgkJPGcgaWQ9InNoYXBlMjQtMTMiIHRyYW5zZm9ybT0idHJhbnNsYXRl KDMyNCwtNTQpIj4NCgkJCTx0aXRsZT5TcXVhcmUuMjQ8L3RpdGxlPg0KCQkJPGRlc2M+UkVBRFk8 L2Rlc2M+DQoJCQk8ZyBpZD0ic2hhZG93MjQtMTQiIHRyYW5zZm9ybT0ibWF0cml4KDEsMCwwLDEs MC4zNDU1OTgsMS45NzI3OSkiIGNsYXNzPSJzdDEiPg0KCQkJCTxyZWN0IHg9IjAiIHk9IjUwNCIg d2lkdGg9IjEwOCIgaGVpZ2h0PSIxMDgiIGNsYXNzPSJzdDIiLz4NCgkJCTwvZz4NCgkJCTxyZWN0 IHg9IjAiIHk9IjUwNCIgd2lkdGg9IjEwOCIgaGVpZ2h0PSIxMDgiIGNsYXNzPSJzdDMiLz4NCgkJ CTx0ZXh0IHg9IjI5LjU5IiB5PSI1NjMuNCIgY2xhc3M9InN0NCI+UkVBRFk8L3RleHQ+CQk8L2c+ DQoJCTxnIGlkPSJzaGFwZTgtMTkiIHRyYW5zZm9ybT0idHJhbnNsYXRlKDQyMywtNTE3LjUpIj4N CgkJCTx0aXRsZT5EeW5hbWljIGNvbm5lY3RvcjwvdGl0bGU+DQoJCQk8ZGVzYz5LRVlSRUFEWTwv ZGVzYz4NCgkJCTxwYXRoIGQ9Ik05IDYxMiBMMTgwIDYxMiBMMTgwIDEwMjEuNSBMMjMuMDQgMTAy MS41IiBjbGFzcz0ic3Q1Ii8+DQoJCQk8cmVjdCB4PSIxNDIuMTMyIiB5PSI4MDUuOTUiIHdpZHRo PSI3NS43MzU0IiBoZWlnaHQ9IjIxLjU5OTkiIGNsYXNzPSJzdDciLz4NCgkJCTx0ZXh0IHg9IjE0 Mi4xMyIgeT0iODIyLjE1IiBjbGFzcz0ic3Q4Ij5LRVlSRUFEWTwvdGV4dD4JCTwvZz4NCgkJPGcg aWQ9InNoYXBlMTAtMjciIHRyYW5zZm9ybT0idHJhbnNsYXRlKDM2OSwtNDYzLjUpIj4NCgkJCTx0 aXRsZT5EeW5hbWljIGNvbm5lY3Rvci4xMDwvdGl0bGU+DQoJCQk8ZGVzYz5LRVlNRVNTQUdFPC9k ZXNjPg0KCQkJPHBhdGggZD0iTTkgNjEyIEw5IDY5Mi40NiIgY2xhc3M9InN0NSIvPg0KCQkJPHJl Y3QgeD0iLTQwLjA5NTciIHk9IjY0OC40NSIgd2lkdGg9Ijk4LjE5MTQiIGhlaWdodD0iMjEuNTk5 OSIgY2xhc3M9InN0NyIvPg0KCQkJPHRleHQgeD0iLTQwLjEiIHk9IjY2NC42NSIgY2xhc3M9InN0 OCI+S0VZTUVTU0FHRTwvdGV4dD4JCTwvZz4NCgkJPGcgaWQ9InNoYXBlMjMtMzQiIHRyYW5zZm9y bT0idHJhbnNsYXRlKDcyLC0yNjEpIj4NCgkJCTx0aXRsZT5TcXVhcmUuMjM8L3RpdGxlPg0KCQkJ PGRlc2M+RVJST1I8L2Rlc2M+DQoJCQk8ZyBpZD0ic2hhZG93MjMtMzUiIHRyYW5zZm9ybT0ibWF0 cml4KDEsMCwwLDEsMC4zNDU1OTgsMS45NzI3OSkiIGNsYXNzPSJzdDEiPg0KCQkJCTxyZWN0IHg9 IjAiIHk9IjUwNCIgd2lkdGg9IjEwOCIgaGVpZ2h0PSIxMDgiIGNsYXNzPSJzdDIiLz4NCgkJCTwv Zz4NCgkJCTxyZWN0IHg9IjAiIHk9IjUwNCIgd2lkdGg9IjEwOCIgaGVpZ2h0PSIxMDgiIGNsYXNz PSJzdDMiLz4NCgkJCTx0ZXh0IHg9IjI4Ljk5IiB5PSI1NjMuNCIgY2xhc3M9InN0NCI+RVJST1I8 L3RleHQ+CQk8L2c+DQoJCTxnIGlkPSJzaGFwZTEzLTQwIiB0cmFuc2Zvcm09InRyYW5zbGF0ZSgz MjQsLTUxNy41KSI+DQoJCQk8dGl0bGU+RHluYW1pYyBjb25uZWN0b3IuMTM8L3RpdGxlPg0KCQkJ PGRlc2M+S0VZRVJST1I8L2Rlc2M+DQoJCQk8cGF0aCBkPSJNMCA2MTIgTC0xOTggNjEyIEwtMTk4 IDc0Ni40NiIgY2xhc3M9InN0NSIvPg0KCQkJPHJlY3QgeD0iLTIxMS43MiIgeT0iNjAxLjIiIHdp ZHRoPSI3Ni45Mzk1IiBoZWlnaHQ9IjIxLjU5OTkiIGNsYXNzPSJzdDciLz4NCgkJCTx0ZXh0IHg9 Ii0yMTEuNzIiIHk9IjYxNy40IiBjbGFzcz0ic3Q4Ij5LRVlFUlJPUjwvdGV4dD4JCTwvZz4NCgkJ PGcgaWQ9InNoYXBlMTQtNDciIHRyYW5zZm9ybT0idHJhbnNsYXRlKDMyNCwtMzA2KSI+DQoJCQk8 dGl0bGU+RHluYW1pYyBjb25uZWN0b3IuMTQ8L3RpdGxlPg0KCQkJPGRlc2M+S0VZRVJST1I8L2Rl c2M+DQoJCQk8cGF0aCBkPSJNMCA2MDMgTC0xMjkuOTYgNjAzIiBjbGFzcz0ic3Q1Ii8+DQoJCQk8 cmVjdCB4PSItMTEwLjQ3IiB5PSI1OTIuMiIgd2lkdGg9Ijc2LjkzOTUiIGhlaWdodD0iMjEuNTk5 OSIgY2xhc3M9InN0NyIvPg0KCQkJPHRleHQgeD0iLTExMC40NyIgeT0iNjA4LjQiIGNsYXNzPSJz dDgiPktFWUVSUk9SPC90ZXh0PgkJPC9nPg0KCQk8ZyBpZD0ic2hhcGUyOC01NCIgdHJhbnNmb3Jt PSJ0cmFuc2xhdGUoMTAxNywzNTEpIHJvdGF0ZSg5MCkiPg0KCQkJPHRpdGxlPlNoZWV0LjI4PC90 aXRsZT4NCgkJCTxkZXNjPktFWVJFQURZPC9kZXNjPg0KCQkJPHBhdGggZD0iTTAgNjEyIEw4NC45 NiA2MTIiIGNsYXNzPSJzdDUiLz4NCgkJCTxyZWN0IHg9Ii02MzYuMzY4IiB5PSI0Ny43MDAyIiB3 aWR0aD0iNzUuNzM1NCIgaGVpZ2h0PSIyMS41OTk5IiB0cmFuc2Zvcm09InJvdGF0ZSgtOTApIiBj bGFzcz0ic3Q3Ii8+DQoJCQk8dGV4dCB4PSItNjM2LjM3IiB5PSI2My45IiB0cmFuc2Zvcm09InJv dGF0ZSgtOTApIiBjbGFzcz0ic3Q4Ij5LRVlSRUFEWTwvdGV4dD4JCTwvZz4NCgkJPGcgaWQ9InNo YXBlMjktNjEiIHRyYW5zZm9ybT0idHJhbnNsYXRlKDk2MywzNTEpIHJvdGF0ZSg5MCkiPg0KCQkJ PHRpdGxlPlNoZWV0LjI5PC90aXRsZT4NCgkJCTxkZXNjPktFWU1FU1NBR0U8L2Rlc2M+DQoJCQk8 cGF0aCBkPSJNMTMuNjggNjEyIEwxNC4wNCA2MTIgTDk5IDYxMiIgY2xhc3M9InN0OSIvPg0KCQkJ PHJlY3QgeD0iLTY3Ni44NDYiIHk9IjI1LjIwMDIiIHdpZHRoPSI5OC4xOTE0IiBoZWlnaHQ9IjIx LjU5OTkiIHRyYW5zZm9ybT0icm90YXRlKC05MCkiIGNsYXNzPSJzdDciLz4NCgkJCTx0ZXh0IHg9 Ii02NzYuODUiIHk9IjQxLjQiIHRyYW5zZm9ybT0icm90YXRlKC05MCkiIGNsYXNzPSJzdDgiPktF WU1FU1NBR0U8L3RleHQ+CQk8L2c+DQoJCTxnIGlkPSJzaGFwZTMwLTY5IiB0cmFuc2Zvcm09InRy YW5zbGF0ZSg0MjMsLTM1MSkiPg0KCQkJPHRpdGxlPkR5bmFtaWMgY29ubmVjdG9yLjMwPC90aXRs ZT4NCgkJCTxkZXNjPktFWU1FU1NBR0U8L2Rlc2M+DQoJCQk8cGF0aCBkPSJNOSA2MTIgTDY5LjQ4 IDYxMiBMNjkuNDggNjg0IEwyMy4wNCA2ODQiIGNsYXNzPSJzdDUiLz4NCgkJCTxyZWN0IHg9IjIw LjM4NDMiIHk9IjYzNy4yIiB3aWR0aD0iOTguMTkxNCIgaGVpZ2h0PSIyMS41OTk5IiBjbGFzcz0i c3Q3Ii8+DQoJCQk8dGV4dCB4PSIyMC4zOCIgeT0iNjUzLjQiIGNsYXNzPSJzdDEwIj5LRVlNRVNT QUdFPC90ZXh0PgkJPC9nPg0KCTwvZz4NCjwvc3ZnPg0K