- From: Sean Lin <selin@mozilla.com>
- Date: Tue, 15 Sep 2015 14:50:22 +0800
- To: 김성혜 <shkim@etri.re.kr>
- Cc: "HU, BIN" <bh526r@att.com>, Paul Higgs <paul.higgs@ericsson.com>, TV Control API Community Group <public-tvapi@w3.org>
- Message-ID: <CAO=Rbvm9NzQRt3LObjDnNo+R4nuMpsq5PXBkAQD8z6-tP5NwVg@mail.gmail.com>
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.
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.
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.
4. TVCICardState appears to have only two states {inserted, removed}. Can
we simplify it to be just a boolean attribute like isPlugged?
5. The dictionary (TVCICardInformation) doesn't appear allowed to have
read-only members in WEBIDL [1]. So it may need to be an interface.
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*
>
> 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;
>
> };
>
> 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, c**onnected, error in the
> future.*
>
> enum TVCICardState {
> "CIcard-inserted",
> "CIcard-removed',
> };
>
> Enumeration description
> CIcard-inserted : The state that CI Card is inserted
> CIcard-removed : The state that CI Card is removed
> -----------------------
>
>
>
>
> ------------------------------
> *보낸 사람 : *"HU, BIN" <bh526r@att.com>
> *보낸 날짜 : *2015-09-12 01:50:22 ( +09:00 )
> *받는 사람 : *Paul Higgs <paul.higgs@ericsson.com>, 김성혜 <shkim@etri.re.kr>
> *참조 : *TV Control API Community Group <public-tvapi@w3.org>
> *제목 : *RE: tvapi-ACTION-38: Propose an api spec for conditional access
> systems
>
> Thank you Paul and Sung Hei for the great work and discussion.
>
>
>
> Have we had an agreement here?
>
>
>
> Thank you and have a great weekend
>
>
>
> Bin
>
>
>
> *From:* Paul Higgs [mailto:paul.higgs@ericsson.com]
> *Sent:* Thursday, September 03, 2015 5:45 AM
> *To:* 김성혜
> *Cc:* TV Control API Community Group
> *Subject:* RE: tvapi-ACTION-38: Propose an api spec for conditional
> access systems
>
>
>
> Hi Sung Hei
>
>
>
> I could not see that a TVChannel needed more than just a single attribute
> indicating with CA system is in use (essentially the tuner can copy this
> from the received TS).
>
>
>
> The caCardInUse for a channel is an index to the sequence of installed
> cards. It is an easy way for the WebApp to determine what CI card the STB
> has assigned to the channel. This could be useful when there are multiple
> CI cards in an STB
>
>
>
> Paul
>
>
>
> *From:* 김성혜[mailto:shkim@etri.re.kr <shkim@etri.re.kr>]
> *Sent:* Thursday, September 03, 2015 8:18 AM
> *To:* Paul Higgs
> *Cc:* TV Control API Community Group
> *Subject:* Re: tvapi-ACTION-38: Propose an api spec for conditional
> access systems
>
>
>
> I have used "TVCICardInformation dictionary" to consider extension for
> future version.
>
> Anyway, it would much simplier to add “CA_system_ID” as an attribute.
>
> I am OK with whatever type of API is used.
>
>
>
>
>
> What is "caCardInUse"? Is it the index of the slot?
>
> I do not know exactly how the STB know which card to use for decryption.
>
> I am thinking (in common sense), STB is preconfigured with the CA card
> used for TV source.
>
> For example, when STB is set to the DVB cable mode, it use CA Card only
> from slot n.
>
> I think this should be checked anyway.
>
>
>
> Regards,
>
> Sung Hei Kim
>
>
>
>
>
> 2015. 9. 2., 오후 7:19, Paul Higgs <paul.higgs@ericsson.com> 작성:
>
>
>
> Hi Sung Hei
>
>
>
> I agree that the CA_PID *could* be used by some WebApp based “protocol
> analyzer” but this is just one piece of information that such a WebApp
> would need.
>
> My recommendation would be to add a CA_system_ID attribute to the
> TVChannel interface which denotes what CA system is currently needed/inuse
> to decrypt the channel. We could also add a CACard to the TVChannel to
> indicate which CA Card is currently being used to decrypt the channel (this
> CACard would be the index into the array of CACards in the system), however
> it may not provide anything useful – I think Kaz mentioned that in Japan
> some devices have 8 CA Card slots, but I don’t know if each card has a
> different CA_system_ID or not.
>
> interface TVChannel : EventTarget {
>
> Promise<sequence<TVProgram
> <http://w3c.github.io/tvapi/spec/#idl-def-TVProgram>>> getPrograms
> <http://w3c.github.io/tvapi/spec/#widl-TVChannel-getPrograms-Promise-sequence-TVProgram---TVGetProgramsOptions-options>
> (optional TVGetProgramsOptions
> <http://w3c.github.io/tvapi/spec/#idl-def-TVGetProgramsOptions> options);
>
> Promise<TVProgram <http://w3c.github.io/tvapi/spec/#idl-def-TVProgram>
> > getCurrentProgram
> <http://w3c.github.io/tvapi/spec/#widl-TVChannel-getCurrentProgram-Promise-TVProgram>
> ();
>
> readonly attribute DOMString networkId
> <http://w3c.github.io/tvapi/spec/#widl-TVChannel-networkId>;
>
> readonly attribute DOMString transportStreamId
> <http://w3c.github.io/tvapi/spec/#widl-TVChannel-transportStreamId>;
>
> readonly attribute DOMString serviceId
> <http://w3c.github.io/tvapi/spec/#widl-TVChannel-serviceId>;
>
> readonly attribute TVSource
> <http://w3c.github.io/tvapi/spec/#idl-def-TVSource> source
> <http://w3c.github.io/tvapi/spec/#widl-TVChannel-source>;
>
> readonly attribute TVChannelType
> <http://w3c.github.io/tvapi/spec/#idl-def-TVChannelType> type
> <http://w3c.github.io/tvapi/spec/#widl-TVChannel-type>;
>
> readonly attribute DOMString name
> <http://w3c.github.io/tvapi/spec/#widl-TVChannel-name>;
>
> readonly attribute DOMString number
> <http://w3c.github.io/tvapi/spec/#widl-TVChannel-number>;
>
> readonly attribute boolean isEmergency
> <http://w3c.github.io/tvapi/spec/#widl-TVChannel-isEmergency>;
>
> readonly attribute boolean isFree
> <http://w3c.github.io/tvapi/spec/#widl-TVChannel-isFree>;
>
> readonly attribute unsigned short CA_system_ID;
>
> readonly attribute unsigned short caCardInUse;
>
> };
>
>
>
> You are correct that we do not have a formal requirement for Events when
> the content stream changes from unscrambled -> scrambled etc.. The UA can
> certainly implement some specific “banner screen” for this – I presume the
> MediaSource output from the TVTuner can do this.
>
> I leave it to the editor to determine if we should have such an event and
> allow the WebApp to inform the user.
>
>
>
> Paul
>
>
>
>
>
> *From:* 김성혜 [mailto:shkim@etri.re.kr <shkim@etri.re.kr>]
> *Sent:* Wednesday, September 02, 2015 4:07 AM
> *To:* Paul Higgs; TV Control API Community Group
> *Subject:* RE: tvapi-ACTION-38: Propose an api spec for conditional
> access systems
>
>
>
>
>
>
> Thank you Paul for your comments.
>
>
> I have made comments inline.
>
>
>
> Also, I have made changes to the CAS APIs based on the meeting results and
> comment from Paul, which follows the in-line comments.
> Please see the changes.
>
>
>
> Regards,
> Sung Hei Kim
>
>
>
>
>
> ------------------------------
>
> *보낸 사람 : *"Paul Higgs" <paul.higgs@ericsson.com>
> *보낸 날짜 : *2015-09-02 02:58:44 ( +09:00 )
> *받는 사람 : *김성혜 <shkim@etri.re.kr>, TV Control API Community Group <
> public-tvapi@w3.org>
> *참조 : *구한승 <koohs@etri.re.kr>, 박주영 <jypark@etri.re.kr>
> *제목 : *RE: tvapi-ACTION-38: Propose an api spec for conditional access
> systems
>
> Hello Sunk Hei
>
>
>
> I’ve had a chance to look at this again after your explanation during
> todays call, and would like to make the following points.
>
>
>
> · The CA_system_ID is sufficient on its own to indicate which
> conditional access system is used by the content/channel and which is
> supported by a CI card. I don’t believe the CA_PID (from ISO 13818-1
> definition of the conditional access descriptor) needs to be exposed to the
> WebApp.
>
>
>
> Sung Hei >> CA_PID can be used for analyzing protocols of MPEG
> streams. CA_PID can be used in WebApps for MPEG protocol analyzer for
> debugging STB system.
>
> However, I think maybe it is too specific information for the 1st version,
> and we maybe consider it for the next version.
>
>
>
> o As you said in the call, there is already an isFree
> <http://w3c.github.io/tvapi/spec/#widl-TVChannel-isFree> attribute in the
> TVChannel <http://w3c.github.io/tvapi/spec/#tvchannel-interface>. This is
> a Boolean defined as “*MUST* indicate whether the TV channel is free to
> watch.” however it may be best defined as “*MUST* indicate whether the TV
> channel is currently free to watch.” It could be that a channel shows
> some free promotional material prior to paid/scrambled content being
> presented.
>
>
>
> Sung Hei >> Although isFree is not defined by this CAS proposal, I think
> it needs to be changed.
>
>
>
>
> · Knowing what CA Systems are supported by installed CA cards is
> useful (also helps to know some state information for each CA card).
>
> o Perhaps your definition of getCICard is intended to do this, in which case I would suggest it being defined as Promise<sequence<TVCICard>> getCICards ();
>
> o There would be as many elements in the sequence as there are CI card
> “slots” in the system
>
>
>
> Sung Hei >> I will accept your proposal and change it.However, the CICard
> in TVManager can be defined as sequence, but in TVChannel only a single CI
> Card is used, it this correct?
>
>
>
>
>
> o The TVCICard interface (at a system level) should include the
> following (these things are good for user level debugging/troubleshooting –
> see attached screen shots from my US CableCard based STB)
>
> § CA_system_ID : as presently defined/used
>
> § Card_State : one of { inserted, accepted, connected, removed, error }
>
> § Num_Sessions : the number of concurrent sessions supported by the card
>
> § System_Name : human readable string for the CA card
>
> § Software_Version : human readable string of the software version on
> the CA card
>
> § Region : string representing the country or region the CA is
> configured for.
>
> § Pairing_State : one of { unknown, none, in-progress, ok, bad }
>
> § There is a lot of other “diagnostic” information that the CA Card
> could supply to the content source (again see those screen shots). So an
> opaque JSONified string may be useful to carry it all to the provider (the
> WebApp need not decipher this)
>
>
>
> Sung Hei >> Since I was focus on CI card for each TV channel, I did not
> consider information that is provided by the device (i.e. STB). But, I am
> not sure if every STB provides same type of information with same format.
> We may need to look into this.
> I think middleware standard for STB such as OCAP, ACAP, MHP, can provide
> such information. But we need to study them.
> For now, maybe information such as CA_system_ID and Card_State can be
> consider for our current requirements. For other information, I do not find
> any use. As you’ve mentioned it can be used for debugging/troubleshooting,
> but, I think maybe it is too detailed for the first version, unless the
> group think otherwise?
>
>
>
> · Informing the WebApp that the scrambling state of a channel has
> changed is certainly important, and I presume that is what your [Proposal
> 2] aroundonCIcardchanged;is for.
>
> o On a channel level there are two types of events that should be
> reported to the WebApp
>
> § The content in the channel has transitioned from unscrambled to
> scrambled and the terminal has no permission to unscramble it
>
> § The content in the channel has transitioned from unscrambled to
> scrambled and the terminal has no resource to unscramble it
>
>
>
> Sung Hei >> Yes. Maybe we need this, however, it is not in the requirement.
> During the last meeting (Aug.4th), I have suggested to add a new
> requirement to notify the webapps of the event regarding entitlement
> changes, such as availability of entitlement, service not subscribed,
> security not supported, resource not available, etc. However, it is not in
> our requirement, and I did not propose any APIs for this.
> Maybe we can consider this in the next version?
>
>
>
> o You may optionally want to inform the WebApp that the content has
> transitioned from scrambled (whether you have permission/resource to
> descramble or not) to unscrambled. I say optionally because there would be
> no user impact of this transition and no WebApp action to be taken.
>
>
>
> ㅓ Sung Hei >> Same as previous comments
>
>
>
> Paul
>
>
>
>
>
>
>
>
>
>
>
> >>>>>>>> CAS APIs <<<<<<<<<<<<<<
>
>
>
> *[Changed summary]*
>
> 1. Removed applyCICard() defined for [cas.descrypt] requirement.
>
> àPlease note, [cas.descrypt] should be removed from the TV Control API
> Technical Requirements (TV Control API Technical Requirements)
>
> 2. Removed casPId in the TVCICardInformation.
>
> 3. Add [cas] requirements to the TVmanager with getCICards method
>
> 4. Changed getCICard method to getChannelCICard method from TVChannel.
>
> 5. Add state (inserted, accepted, connected, removed, error) to the
> TVCICardInformation and updated TVCICardState to support (inserted,
> accepted, connected, removed, error)
>
>
>
> *{Question}*
>
> I’m still not sure if we need to define a WebIDL interface for CI Card.
>
> Currently, I’ve just defined it in form of a WebIDL dictionary, because,
> from our current requirements I do not see the need of defining separate
> WebIDL interface (class) for CI Card.
>
> Any comments on this matter??
>
>
>
> *Please see the changes.*
>
>
>
> [TVCICardInformation dictionary]
>
> The TVCICardInformation dictionary contains the information on the CI Card
> used to decrypt the encrypted TV channel.
>
> dictionary TVCICardInformation {
>
> readonly attribute Boolean isScrambled;
>
> readonly attribute TVCICardState state;
>
> readonly attribute DOMString? casSystemId;
>
> };
>
>
>
> isScrambled of type Boolean, readonly
>
> MUST indicate whether the stream from this TV channel is currently
> encrypted(or scrambled).
>
> 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.
>
>
>
> Note) isScambled is related to the isFree attribute in the TVchannel.
>
>
>
>
>
> [Changes to the TVManager]
>
> Interface TVManager EventTarget {
>
> :
>
> Promise<sequence< TVCICardInformation>> getCICards ();
>
> attribute EventHandler onCIcardchanged;
>
> :
>
> }
>
>
>
> getCICards
>
> returns sequence of TVCICardInformation dictionary which provides meta
> information of the CI cards available in the system.
>
> No parameters
>
> Return type: sequence <TVCICardInformation>
>
>
>
>
>
> [Changes to the TVChannel]
>
> Interface TVChannel: EventTarget {
>
> :
>
> TVCICardInformation getChannelCICard();
>
> attribute EventHandler onCIcardchanged;
>
> :
>
> }
>
>
>
> getChannelCICard
>
> returns a TVCICardInformation dictionary which provides meta information
> of the CI cards used in decrypting encrypted TV channel as long as the
> information are available.
>
> No parameters
>
> Return type: TVCICardInformation
>
>
>
>
>
> [New Event]
>
> Event Handler: onCIcardchanged
>
> Event name: CI_CHANGE
>
> Event type: TVCICardChangedEvent
>
> Description: Handles the information for the dynamically added/removed
> common interface (CI) cards.
>
>
>
>
>
> XX. TVCICardChangedEvent Interface
>
> The TVCICardChangedEvent interface represents the events related to the
> changes in the state of the CI cards.
>
>
>
> Interface TVCICardChangedEvent : Event {
>
> readonly attribute TVCICardState state;
>
> readonly attribute DOMString? casSystemId;
>
> }
>
>
>
> Enum TVCICardState {
>
> “CIcard-inserted”,
>
> “CIcard-accepted”,
>
> “CIcard-connected”,
>
> “CIcard-removed”,
>
> “CIcard-error”
>
> };
>
>
>
>
>
> >>>>>>>> End of CAS APIs <<<<<<<<<<<<<<
>
>
>
>
>
>
>
> *From:* 김성혜 [mailto:shkim@etri.re.kr <shkim@etri.re.kr>]
> *Sent:* Tuesday, September 01, 2015 6:41 AM
> *To:* TV Control API Community Group
> *Cc:* 구한승; 박주영
> *Subject:* RE: tvapi-ACTION-38: Propose an api spec for conditional
> access systems
>
>
>
>
>
> Dear All,
>
>
>
> [Background]
>
> I have studied the CAS requirements.
>
> I have looked at two references, i.e., ATSC CAS for terrestrial broadcast,
> ISO 13818-1.
>
> ATSC[1] from 4.1.3.5.1 (page 10) defines ATSC_CA_descriptor () as follows:
>
> ATSC_CA_descriptor() {
>
> descriptor_tag (8bits, value= 0x88)
>
> descriptor_length (8bits, uimsbf)
>
> CA_System_ID (16bits, uimsbf)
>
> for ( i = 0 ; i < descriptor_length - 2 ; i++ ) {
>
> private_data_byte 8 bslbf
>
> }
>
> }
>
> The CA_System_ID is defined as This 16-bit unsigned integer indicates the
> type of CA system applicable for the information conveyed in this
> descriptor.
>
> So “meta information” regarding CAS is CA_System_ID, which is usually
> identifies vendor of the CAS system which is used for encrypting/decrypting
> channels.
>
>
>
> ISO[2] from 2.6.16 (page 69) defines Conditional access descriptor as
> follows:
>
> CA_descriptor() {
>
> descriptor_tag (8bits, uimsbf)
>
> descriptor_length (8bits, uimsbf)
>
> CA_system_ID (16bits, uimsbf)
>
> reserved (3bits, bslbf)
>
> CA_PID 13 uimsbf
>
> for (i = 0; i < N; i++) {
>
> private_data_byte (8bits, uimsbf)
>
> }
>
> }
>
>
>
> CA_system_ID – This is a 16-bit field indicating the type of CA system
> applicable for either the associated ECM and/or EMM streams. The coding of
> this is privately defined and is not specified by ITU-T | ISO/IEC.
>
> CA_PID – This is a 13-bit field indicating the PID of the Transport Stream
> packets which shall contain either ECM or EMM information for the CA
> systems as specified with the associated CA_system_ID. The contents (ECM or
> EMM) of the packets indicated by the CA_PID is determined from the context
> in which the CA_PID is found, i.e. a TS_program_map_section or the CA table
> in the Transport Stream, or the stream_id field in the Program Stream.
>
>
>
> So “meta information” regarding CAS is can be CA_System_ID and CA_PID.
>
>
>
> Also there is an important CAS related meta-information in the field of
> PES (Packetized Elementary Stream) which is called PES_scrambling_control
> (indicate the scrambling mode of the PES packet payload).
>
> If “ PES_scrambling_control = 0x00 “ indicated not scrambled. Other value
> are user-defined which means the packet is scrambled.
>
>
>
> [Reference]
>
> [ATSC] ATSC Standard: Conditional Access System for Terrestrial Broadcast
> (A/70 Part 1:2010)
>
> [ISO] ISO 13818-1, Information technology — Generic coding of moving
> pictures and associated audio information: Systems, 2000
>
>
>
> Through this analysis, it is possible to define the APIs for CAS
> requirements.
>
> The followings are the proposals for the APIs.
>
>
>
> [Proposal 1] Meta information for CI Card
>
> Proposal for “Meta information” for CAS CI card is as follows.
>
> The TVCICardInformation dictionary contains the information on the CI Card
> used to decrypt the encrypted TV channel.
>
> dictionary TVCICardInformation {
>
> readonly attribute Boolean isScrambled;
>
> readonly attribute DOMString? casSystemId;
>
> readonly attribute DOMString? casPId;
>
> };
>
>
>
> isScrambled of type Boolean, readonly
>
> MUST indicate whether the stream from this TV channel is encrypted(or
> scrambled).
>
> 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.
>
> casPID of type DOMString, readonly, nullable
>
> MUST return the CAS PID of ECM or EMM information for CA System. Note, the
> value is null, if the value of isScrambled is false or if the system does
> not support casPID.
>
>
>
> Note) isScambled is equivalent to the isFree attribute in the TVchannel.
>
>
>
>
>
> [Proposal 2] APIs for CAS Requirements
>
> To support [cas], [cas.descrypt] [cas.notifications.change] requirements,
> it can be defined under TVChannel Interface, since CAS are applied for each
> TV channel.
>
> But we need to discuss where the methods to support CAS requirements
> should be defined under TVSource interface or TVChannel interface.
>
> Anyway, proposed methods are as follows.
>
> Interface TVChannel: EventTarget {
>
> :
>
> TVCICardInformation getCICard();
>
> void applyCICard (TVCICardInformation card);
>
> attribute EventHandler onCIcardchanged;
>
> :
>
> }
>
>
>
> [New Methods]
>
> getCICard
>
> returns a dictionary of TVCICardInformation which provides meta
> information of the CI cards used in decrypting encrypted TV channel as long
> as the information are available.
>
> No parameters
>
> Return type: TVCICardInformation
>
>
>
> applyCICard
>
> request the tuner to apply CI card with the card parameter.
>
> Parameter (card)
>
> Type: TVCICardInformation, Nullable(X), Optional(X)
>
> Description: Specifies information of CI Card to be applied to the
> encrypted TV channel.
>
> Return type: void
>
>
>
> [Memo from Sung Hei Kim] I am not sure if the system (settop) can
> use(apply) the specified CI card from the webapp. Normally, CI card that
> can be used for decryption are already included in the TV stream.
>
>
>
> [New Event]
>
> Event Handler: onCIcardchanged
>
> Event name: CI_CHANGE
>
> Event type: TVCICardChangedEvent
>
> Description: Handles the information for the dynamically added/removed
> common interface (CI) cards.
>
>
>
>
>
> XX. TVCICardChangedEvent Interface
>
> The TVCICardChangedEvent interface represents the event related to the
> changes to the CI cards, which can be occur with the add or removal of the
> CI cards.
>
>
>
> Interface TVCICardChangedEvent : Event {
>
> readonly attribute TVCICardState state;
>
> readonly attribute DOMString? casSystemId;
>
> }
>
>
>
> 23. Enumerations
>
> Enum TVCICardState {
>
> “CIcard-added”,
>
> “CIcard-removed”
>
> };
>
>
>
> Regards,
>
> Sung Hei Kim (ETRI)
>
>
>
>
>
> [Note Requirements]
>
> [cas] This API SHALL be able to provide the webapps with the meta
> information of the CI cards as long as those meta information is available.
> For example, the CAS standards such as DVB-CI, ARIB-CAS... etc.
>
> [cas.decrypt] This API SHALL be able to enable the webapps to apply the CI
> cards to decrypt the encrypted channel.
>
> [cas.notifications] This API SHALL be able to notify the webapps of the
> dynamically added/removed Common Interface (CI) cards.
>
> The following event SHALL be supported
>
> [cas.notifications.change] CI_CHANGE
>
>
> ------------------------------
>
> *보낸* *사람* *: *"TV Control API Community Group Issue Tracker" <
> sysbot+tracker@w3.org>
> *보낸* *날짜* *: *2015-07-07 22:54:12 ( +09:00 )
> *받는* *사람* *: *public-tvapi@w3.org <public-tvapi@w3.org>
> *참조* *: *
> *제목* *: *tvapi-ACTION-38: Propose an api spec for conditional access
> systems
>
> tvapi-ACTION-38: Propose an api spec for conditional access systems
>
> http://www.w3.org/community/tvapi/track/actions/38
>
> Assigned to: Sung Hei Kim
>
>
>
Received on Tuesday, 15 September 2015 06:50:56 UTC