RE: tvapi-ACTION-38: Propose an api spec for conditional access systems -> for requirement [cas]

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>
보낸 날짜 : 2015-09-15 20:06:01 ( +09:00 )
받는 사람 : Sean Lin <selin@mozilla.com>, 김성혜 <shkim@etri.re.kr>
참조 : 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 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]
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.

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.


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.


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”
};



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/


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.

-----------------------