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

Hi,

I put my comments below.

Sean Lin
Mozilla Taiwan
selin@mozilla.com


On Wed, Sep 16, 2015 at 10:00 AM, 김성혜 <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>
> *보낸 날짜 : *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.
>
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] https://lists.w3.org/Archives/Public/public-tvapi/2015Sep/0012.html


>
>
>
> 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/
>
>
> Sean Lin
>
> Mozilla Taiwan
>
> selin@mozilla.com
>
>
>
>
>
> On Mon, Sep 14, 2015 at 3:35 PM, 김성혜 <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.
>
>
>
> -----------------------
>
>
>