- From: 김성혜 <shkim@etri.re.kr>
- Date: Thu, 17 Sep 2015 06:54:58 +0000
- To: Sean Lin <selin@mozilla.com>
- CC: Paul Higgs <paul.higgs@ericsson.com>, "HU, BIN" <bh526r@att.com>, TV Control API Community Group <public-tvapi@w3.org>
- Message-ID: <609FE8B8E7BD1248A27BD3B8BC699ABD1D76F114@SMTP1.etri.info>
From Sean's comment, I have made changes as below.
I am not sure if I got it right, please check.
I've changed CA_system_ID in TVChannel to casSystemId, since it is equivalent.
Also, I've changed "TVCICardInformation dictionary" to "TVCICard Interface".
Since, it is not dictionary, I thought it is appropriate to remove the term 'Information'.
Please see the changes.Any comments?
Regards,
Sung Hei Kim
----------------------- Changes to TVChannel
interface TVChannel : EventTarget {
:
attribute EventHandler onCIcardchanged; -> details in https://lists.w3.org/Archives/Public/public-tvapi/2015Sep/0012.html
readonly attribute unsigned short casSystemId;
readonly attribute unsigned short caCardInUse;
};
----------------------- Changes to TVManager
Interface TVManager EventTarget {
:
Promise<sequence< TVCICard>> getCICards ();
readonly attribute unsigned short caCardInUse;
attribute EventHandler onCIcardchanged; -> details in https://lists.w3.org/Archives/Public/public-tvapi/2015Sep/0012.htm
}
getCICards
returns sequence of TVCICard interface which provides meta information of the CI cards available in the system.
No parameters
Return type: sequence <TVCICard>
[TVCICard Interface] -> Changed from TVCICardInformation dictionary to TVCICard Interface
The TVCICard interface represents properties related to CI Card which is used to decrypt encrypted TV channel.
interface TVCICard : EventTarget {
readonly attribute TVCICardState ciCardState;
readonly attribute DOMString? casSystemId;
readonly attribute Boolean isInUse;
readonly attribute unsigned short caCardInUse;
};
casSystemId of type DOMString, readonly, nullable
MUST return the CAS system ID used to decrypt stream from the encrypted TV channel. Note, the value is null, if the value of isScrambled is false.
ciCardState of type TVCICardState, readonly, nullable
MUST return the type of CI Card State
isInUse of type Boolean, readonly, nullable
MUST indicate whether the CI Card is in use to decrypt TV channel(s)
enum TVCICardState {
"CIcard-inserted",
“CIcard-accepted”,
"CIcard-removed',
“CIcard-error”
};
Enumeration description
CIcard-inserted : The state that CI Card is inserted
CIcard-accepted : The state that CI Card has been accepted
CIcard-removed : The state that CI Card is removed
CIcard-error: The state that CI Card has error.
________________________________
보낸 사람 : "Sean Lin" <selin@mozilla.com>
보낸 날짜 : 2015-09-16 15:34:35 ( +09:00 )
받는 사람 : 김성혜 <shkim@etri.re.kr>
참조 : Paul Higgs <paul.higgs@ericsson.com>, HU, BIN <bh526r@att.com>, TV Control API Community Group <public-tvapi@w3.org>
제목 : Re: tvapi-ACTION-38: Propose an api spec for conditional access systems -> for requirement [cas]
Hi,
I put my comments below.
clear="all">
Sean Lin
Mozilla Taiwan
selin@mozilla.com<mailto:selin@mozilla.com>
On Wed, Sep 16, 2015 at 10:00 AM, 김성혜 <shkim@etri.re.kr<mailto:shkim@etri.re.kr>> wrote:
Hi!
I was not sure of the agreed item, so I had to divide to e-mail into 3 part.
Anyway, I have my comments in-line with "shk>" in blue.
Also, I provided changes to TVManager parts, please see them.
Question: Do we have agreement with removal of requirement [cas.decrypt]?
If we do, I can remove them from our wiki, if no one volunteers.
Regards,
Sung Hei Kim
________________________________
보낸 사람 : "Paul Higgs" <paul.higgs@ericsson.com<mailto:paul.higgs@ericsson.com>>
보낸 날짜 : 2015-09-15 20:06:01 ( +09:00 )
받는 사람 : Sean Lin <selin@mozilla.com<mailto:selin@mozilla.com>>, 김성혜 <shkim@etri.re.kr<mailto:shkim@etri.re.kr>>
참조 : HU, BIN <bh526r@att.com<mailto:bh526r@att.com>>, TV Control API Community Group <public-tvapi@w3.org<mailto:public-tvapi@w3.org>>
제목 : RE: tvapi-ACTION-38: Propose an api spec for conditional access systems -> for requirement [cas]
Hi Sean.. My comments are inserted below – although its getting hard to follow and extract the agreed items from this e-mail thread!
From: Sean Lin [mailto:selin@mozilla.com<mailto:selin@mozilla.com>]
Sent: Tuesday, September 15, 2015 2:50 AM
To: 김성혜
Cc: HU, BIN; Paul Higgs; TV Control API Community Group
Subject: Re: tvapi-ACTION-38: Propose an api spec for conditional access systems -> for requirement [cas]
Hi Sung Hei,
The current proposal looks good to me too. Just share my two cents about something that we might tweak a little. FYI. :)
1. We may consider to remove the caCardInUse attribute (or move it to TVCICardInformation, which can be retrieved from getCICards() in TVManager). Then TVChannel would have the 'less changeable' attributes like CA_system_ID about its intrinsic characteristics; whereas TVManager would have something more relevant to the actual use or configuration, like getCICards() and TVCICardInformation. And since CA cards appear to be hot-pluggable, there seem some gray areas and introduced overhead to maintain the consistency of the indexes (caCardInUse) of Card array. (Ex. A series of actions may be: Card A gets removed from slot 1; Card B gets inserted to slot 1, Card A gets inserted to slot 2. getCICards() can be called between each action and the index of Card A is not guaranteed to be the same.) On the other hand, it might be possible to have a card ID,which can distinguish multiple cards even if they have the same CA_system_ID, in TVChannel. But when the applied card changes, we may still need to notify all the affected TVChannels.
PH> I proposed the caCardInUse to the TVChannel so that a WebApp could determine which card (from the array of cards in the TVCICardInformation) is currently being used.
SHK> I agree with Paul's comment on the use of caCardInUse for TVchannel.
I think it is possible to add caCardInUse to the TVCICardInformation, so that WebApps will know which CA_system_ID is in which slot.
About card ID, I do not think the CI Cards have any unique ID in global terms.
I agree with the use of caCardInUse. My concern was the consistency of caCardInUse in TVChannel if it's accessed as the index of the array. [Scenario 1] stated below is an example where my concern was originated. That's why the idea to move caCardInUse to TVCICardInformation came out.
Yet it's also fine if you decide to keep caCardInUse in TVChannel. (Your call :) ) But please address in spec that the UA needs to pay some efforts to keep caCardInUse in TVChannel update-to-date. (At least I didn't see it being addressed in previous discussion, so I brought out my concern.)
[Scenario 1] The application accesses and holds a TVChannel object "C1", and it uses card "CA1", which occupies the first slot, so "caCardInUse" in "C1" might be "0" (the current index of the CA card array.) Then card "CA1" gets removed, "caCardInUse" in "C1" needs to be updated to a proper value indicating that no card with CA_system_ID as "ID1" is in use. And if card "CA1" gets inserted back to another slot (the original first slot might be occupied by another card), then "caCardInUse" in "C1" might be updated to "1" or another reasonable value.
2. Some devices have multiple card slots, and I'm not sure if each card needs to have different CA_system_ID either. Then we may consider to have a boolean attribute like isInUse in TVCICardInformation to allow the application to set and indicate this card is currently in use for the channels with the same CA_system_ID. So in case there are multiple cards with the same CA_system_ID, at most one of them can be set with isInUse. Thus the UA should know which card would be used for which CA_system_ID.
PH> I do not believe there is any requirement that each card has a different CA_system_ID. If there is/was then we would not need the caCardInUse attribute on the channel (as there would only be one card that could be used with the CA system ID of the channel)
SHK> I have heard that CA_system_ID is not unique. A single company can use same CA_system_ID for CI Card to descript contents from difference source from (DVB, DMB, etc.). As you know, in Korea, we have single CI Card for STB, so it does not matter if a company use same CA_system_ID for different CI Card.
I think adding caCardInUse to the TVCICardInformation cam solve the problem not knowing which card is being used.
Well, my original point is "it's also possible that multiple inserted cards have the same CA_system_ID when they are inserted on the same device, which supports multiple cards." So if there becomes no "caCardInUse" in TVChannel (to save the overhead of updating caCardInUse in TVChannel objects), the alternate could be adding a boolean "isInUse", _not_ read-only so configurable by apps, to TVCICardInformation. And the constraint should apply: for a given CA_system_ID, at most one card with that CA_system_ID could be set with isInUse = true. [Scenario 2] is an example of what I tried to convey.
[Scenario 2]
UA would know Channel1 should use Card3 instead of Card1, and Channel2 should use Card2 by looking up .
TVCICardInformation
CA_system_ID
isInUse
(configurable by apps)
Card1
ID1
false
Card2
ID2
true
Card3
ID1
true
TVChannel
CA_system_ID
Channel1
ID1
Channel2
ID2
3. Can we move "oncicardchanged" event handler from TVChannel to TVManager? Since there may be a bunch of TVChannel objects, but usually only one TVManager, it might reduce the overhead in the UA to trigger this event. And if we only keep the less changeable CA_system_ID in TVChannel, "oncicardchanged" event handler becomes more TVManager related.
PH> It seems to already be defined in TVManager!
SHK> This is part of the e-mail with " -> for [cas.notifications] requirement ".
I wanted to differentiate proposals for different requirements.
As far as I know from the top of [1], I see it also defined in TVChannel.
Interface TVChannel: EventTarget {
:
attribute EventHandler onCIcardchanged;
:
}
But after diving info the previous thread, I found the handler also defined in TVManager. Maybe I was confused. Anyway, it looks good to me as long as TVManager has it.
[1]
4. TVCICardState appears to have only two states {inserted, removed}. Can we simplify it to be just a boolean attribute like isPlugged?
PH> That is Sung Hei’s original proposal – I have suggested that additional states are required (once the card is installed it may need to “pair” with other resources, it may “fail” in its initiation and give an error state, etc)
SHK> With Pauls' proposal of adding state { inserted, accepted, connected, removed, error}, I thought eventually, we will be needing those 5 states in the future.
But, I was not sure every STB provides those same 5 states. Also, since our requirement [cas.notifications] only mentions card insertion and removal, I thought for now use of one two states { inserted, removed} would be OK.
However, if there is a need for new state {accepted(paired?), error}, it is OK for me.
Enum TVCICardState {
“CIcard-inserted”,
“CIcard-accepted”,
“CIcard-removed”,
“CIcard-error”
};
Looks good to me too. Thank you.
5. The dictionary (TVCICardInformation) doesn't appear allowed to have read-only members in WEBIDL [1]. So it may need to be an interface.
SHK> I am not a WEBIDL expert, so I was not sure how to define TVCICardInformation as dictionary or interface.
I though WebApps will not be manipulating(changing values) the TVCICardInformation, I thought I would be simplier to define it as a dictionary.
Anyway, it does not matter.
Any thoughts?!
[1] http://www.w3.org/TR/WebIDL/
clear="all">
Sean Lin
Mozilla Taiwan
selin@mozilla.com<mailto:selin@mozilla.com>
On Mon, Sep 14, 2015 at 3:35 PM, 김성혜 <shkim@etri.re.kr<mailto:shkim@etri.re.kr>> wrote:
I do not have any disagreement with Paul's proposal for requirement [cas] on TV channel.
interface TVChannel : EventTarget {
Promise<sequence<TVProgram>> getPrograms (optional TVGetProgramsOptions options);
Promise<TVProgram> getCurrentProgram ();
readonly attribute DOMString networkId;
readonly attribute DOMString transportStreamId;
readonly attribute DOMString serviceId;
readonly attribute TVSource source;
readonly attribute TVChannelType type;
readonly attribute DOMString name;
readonly attribute DOMString number;
readonly attribute boolean isEmergency;
readonly attribute boolean isFree;
readonly attribute unsigned short CA_system_ID;
readonly attribute unsigned short caCardInUse;
};
But, I do like to hear from Sean about his thoughts.
Also, can anyone comment on the changes to the TVManager to support requirement [cas] on TV Settop?
The webapps may want to know the installation status of the CI cards to a settop box.
In order to support this, TVManager will need to provide information of the CI cards installed.
----------------------- Changes to TVManager
[Changes to TVManager] -> used sequence to support multiple CI cards
Interface TVManager EventTarget {
:
Promise<sequence< TVCICardInformation>> getCICards ();
:
}
getCICards
returns sequence of TVCICardInformation dictionary which provides meta information of the CI cards available in the system.
No parameters
Return type: sequence <TVCICardInformation>
[Defintion of TVCICardInformation dictionary] -> define CI Card State to inform the webapps of the CI card installation status
changes (Sept.16) -> add "caCardInUse" from comment 1 and from comment 2.
The TVCICardInformation dictionary contains the information on the CI Card used to decrypt the encrypted TV channel.
dictionary TVCICardInformation {
readonly attribute TVCICardState ciCardState;
readonly attribute DOMString? casSystemId;
readonly attribute unsigned short caCardInUse;
};
casSystemId of type DOMString, readonly, nullable
MUST return the CAS system ID used to decrypt stream from the encrypted TV channel. Note, the value is null, if the value of isScrambled is false.
ciCardState of type TVCICardState, readonly, nullable
MUST return the type of CI Card State
[Defintion of TVCICardState] -> define enum TVCICardState for futher extention of other states such as, accepted, connected, error in the future.
changes (Sept.16) -> add "CIcard-accepted", "CIcard-error" from comment 4.
enum TVCICardState {
"CIcard-inserted",
“CIcard-accepted”,
"CIcard-removed',
“CIcard-error”
};
Enumeration description
CIcard-inserted : The state that CI Card is inserted
CIcard-accepted : The state that CI Card has been accepted
CIcard-removed : The state that CI Card is removed
CIcard-error: The state that CI Card has error.
-----------------------
Received on Thursday, 17 September 2015 06:55:57 UTC