OMADRM2学习笔记DCF-v2规范定义

http://zeroliu.blogdriver.com/zeroliu/1266005.html

【虎.无名】OMA-DRM-2学习笔记：OMA-TS-DRM-DCF-V2_0-20060303-A.pdf
4, introduction
The DRM Content Format is closely related to the Rights Expression Language specification [DRMREL-v2], which defines the syntax and semantics for the Rights Objects.
The file format is extensible, so additional features may be added in the future while maintaining compatibility with the older versions.
Compatibility with the version 1 Content Format [DRMCF-v1] is not maintained by this specification, therefore a different MIME type is used.
注：从上看出DRMCF-v2与DRMCF-v1格式不兼容，并使用了独立的MIME类型；
There are two profiles of the DRM Content Format. One is used for Discrete Media (such as still images) and one for Continuous Media (such as music or video).
注：新的DRMREL-v2分别针对Discrete Media和Continuous Media定义了两种配置格式；
The Content Issuer can decide which profile to use for their content, but in general, the profile for Continuous Media should be used for Continuous Media content, in order to create a harmonious user experience. The Discrete Media profile should be used for other types of content.
To a User, the difference is that a file conforming to the Discrete Media profile looks like a DRM protected file, whereas a file conforming to the Continuous Media profile looks and functions like a media file to the outside.
注：如何决定采用哪种格式。。。
5. DRM Content Format
There are two DRM Content Format profiles: DCF,PDCF...
DCF：This specification defines the Discrete Media format based on the types of the ISO base media file format [ISO14496-12], instead of WSP types [WSP] used in Version 1 [DRMCF-v1]. By using the ISO principles, the DCF format maintains the extensible nature of the ISO format, while keeping overhead minimal.
PDCF(Packetized DCF)：Continuous media is protected in a separate profile because it is packetized and thus the profile is called the Packetized DCF (PDCF). Applications that read and parse Continuous Media are meant to work on the file on a packet-by-packet basis. An OMA DRM compliant streaming server MUST be able to understand the Content Format’s structure in order to break the content into headers and packets that can be delivered to a client that understands the Content Format.
注：DCF基于ISO14496-12来定义，而不是象DRMCF-v1一样基于WSP类型。
5.1.1 ISO File structure
The ISO base media file format is structured around an object-oriented design of boxes.
A basic box has two mandatory fields, size and type. The type identifier is used to dynamically bind a box to a statically defined type and the size is an offset from start to the end of the box. A Box type identifier is a Unique Identifier Number. List of reserved numbers can be found in Appendix B. The identifier is constructed from four bytes, each representing a human-readable character, thus the name Four Character Code (4CC).
The ISO base format uses a language called Syntax Description Language (SDL) for defining data structures.
注：采用面向对象的SDL来描述DCF-v2/ISO的结构。基本结构有size和type两个字段，既可视为int(32)整数，也可视为4个ASCII字节(4CC)格式；
aligned(8) class Box (unsigned int(32) boxtype, optional unsigned int(8)[16] extended_type) {
 unsigned int(32) size;
 unsigned int(32) type = boxtype;
 //条件扩充（略）
}
aligned(8) class FullBox(unsigned int(32) type, unsigned int(8) v, bit(24) f) extends Box(type) {
 unsigned int(8)  version = v;
 unsigned int(24) flags = f; //bit(24)=unsigned int(24)
}
注：那么FullBox将有一下几个字段；
Size  unsigned int(32)  Offset to the end of the box
Type  unsigned int(32)  Box type 4CC
Version unsigned int(8)  Version field
Flags  unsigned int(24) Additional flags
The numeric fields in the ISO format are in network byte order.
注：以上结构采用aligned(8)字节对齐（即按字节对齐，而不是缺省的int32对齐，无填充），以及网络字节顺序。
5.2.1 Common Headers Box
aligned(8) class OMADRMCommonHeaders extends FullBox('ohdr', version, 0) {
 unsigned int(8)  EncryptionMethod; // Encryption method
 unsigned int(8)  PaddingScheme; // Padding type
 unsigned int(64)  PlaintextLength; // Plaintext content length in bytes
 unsigned int(16)  ContentIDLength; // Length of ContentID field in bytes
 unsigned int(16)  RightsIssuerURLLength; // Rights Issuer URL field length in bytes
 unsigned int(16)  TextualHeadersLength; // Length of the TextualHeaders array in bytes
 char  ContentID[];   // Content ID string
 char  RightsIssuerURL[]; // Rights Issuer URL string
 string TextualHeaders[]; // Additional headers as Name:Value pairs
 Box ExtendedHeaders[];  // Extended headers boxes
}
This box MUST appear in both DCF and PDCF.
疑问：如何确定ExtendedHeaders的长度，由PlaintextLength来决定？报文体用ExtendedHeaders来包装？允许多个Box？
5.2.1.1 Common Headers Version
The version field of the FullBox defines which version of DRM Content Format specification was used by the author of the Content Object.
The value for version MUST be 0 for objects conforming to this specification.
注：填充0
5.2.1.2 EncryptionMethod Field：NULL、AES_128_CBC、AES_128_CTR
Rights Issuers should take care in using NULL EncryptionMethod because, given a null-encrypted Media Object within a DCF or PDCF, the following statements hold true:
－Null-encrypted Media Objects do not have any Confidentiality protection.
－Null-encrypted Media Objects can always be used without an associated Rights Object.
－Null-encrypted Media Objects may not have any integrity protection.
注：不推荐用Null-encrypted方式，无需权限对象就可使用。
5.2.1.4 PlaintextLength Field
The PlaintextLength field defines the length of the original plaintext. If the content is encrypted, it MUST have a PlaintextLength value set.
If the extracted content length does not match the PlaintextLength field value, it is an error and the Content Object MUST be discarded.
注：如加密，则填写加密后的长度。
5.2.1.5 ContentIDLength Field
The ContentIDLength field defines the number of bytes occupied by the ContentID field. The value MUST be greater than zero.
A Device MUST support ContentIDs of at least 256 bytes. For best interoperability, content author should not use a ContentID larger than 256 bytes.
注：ContentIDLength和RightsIssuerURLLength，长度应在(0..256]的范围内；
5.2.1.7 TextualHeadersLength Field
Thus, conforming tools MUST use the TextualHeadersLength field. A Device MUST support textual headers of at least 2048 bytes total length.
注：设备至少支持2048的TextualHeadersLength长度。
5.2.1.8 ContentID Field
The ContentID field MUST contain a globally unique identifier for this Content Object. Note that even if two or more Content Objects contain the same Media Object, the Content Objects will each have a different (and globally unique) ContentID.
The value MUST be encoded using US-ASCII encoding.
The value MUST be a unique URI according to [RFC2396].
If the Content Object is referenced from a DRM Rights Object, the value of the ContentID field MUST match the value of the referencing element of the Rights Object as defined in [DRMREL-v2]. The ContentID MUST be in the ‘cid-url’ format of [RFC2392].
注：必须按US-ASCII编码，必须符合URI规范。对于OMA-DRM-2还必须按照cid-url格式。
5.2.1.9 RightsIssuerURL Field
The value of the RightsIssuerURL MUST be a URL according to [RFC2396], and MUST be an absolute identifier. The RightsIssuerURL MAY be empty e.g. if the Content Object is not encrypted.
注：当Null-encrypted时，改字段允许为null。
5.2.2 Textual Headers
注：范例 Silent:on-demand;http://myissuer.com/silent?cid=428\0Preview:instant;cid:[e-mail]\0
Each supported header is defined using augmented Backus-Naur Form (BNF) [RFC2234].
The textual headers are encoded using UTF-8 encoding.
Ordering of headers is significant, and the headers MUST be in the order of priority, from highest to lowest. This means that e.g. if the textual headers include both Silent and Preview headers, whichever appears first in the field is considered to have priority over the second.
注：所支持的头信息由BNF[RFC2234]来定义。按UTF-8编码。多个头信息按优先级从高到低来排列。
5.2.2.1 Silent header
格式：Silent:on-demand;silent-rights-url或者Silent:in-advance;silent-rights-url
The parameter silent-rights-url MUST be a URL according to [RFC2396] and a successful request to the URL MUST return a ROAP Trigger, a Download Descriptor or a bundled Download Descriptor and ROAP Trigger as defined in [DRMv2].
注：为URL格式，返回ROAP触发器、DD描述、或者DD+ROAP
If silent-rights-url is a HTTP URL and the request fails with error code 404 Not Found [RFC2616], the Device SHOULD NOT make further requests to the URL. If the request fails with some other error, the Device MAY retry the request at a later time.
注：如果返回404错误，不再请求；否则，可以重试改URL。
The parameter silent-rights-url MUST be specified on the Silent header. The device MUST use this silent-rightsurl to obtain rights silently and automatically according to [DRM-v2].
注：设备自动按照DRM-v2通过silent-rights-url来获取权限。
5.2.2.2 Preview header
The Preview header contains an indication to the client that it is possible to provide a preview for this DRM Content.
5.2.2.3 ContentURL header
The ContentURL header is used to indicate a location for acquiring the DCF or PDCF.
注：用于不支持当前dcf包装的媒体文件时，下载同一个内容的其他版本。

5.2.2.6 Custom headers
Content author MAY insert additional Custom headers to the TextualHeaders field. Custom headers MUST follow the generic syntax defined below, encoded using UTF-8 encoding.
Consuming Devices MUST ignore the headers that they do not recognize.
注：用户自定义header信息，必须用UTF-8编码，设备必须能忽略不识别的头信息。
5.2.3 Extended Headers
The ExtendedHeaders field MAY include zero or more nested boxes that add functionalities to the common headers. The ExtendedHeaders field continues until the end of the parent box is reached.
注：允许0个或者多个nested的Box
5.2.3.1 Group ID
The ExtendedHeaders field MAY include one instance of the OMADRMGroupID Box:
aligned (8) class OMADRMGroupID extends FullBox('grpi', version, 0) {
 unsigned int(16) GroupIDLength; // length of the Group ID URI
 unsigned int(8) GKEncryptionMethod; // Group Key encryption algorithm
 unsigned int(16) GKLength; // length of the encrypted Group Key
 char GroupID[GroupIDLength]; // Group ID URI
 byte GroupKey[GKLength]; // Encrypted Group Key and encryption information
}
注：可以包含1个OMADRMGroupID实例。type定义为'grpi'。
The GroupID value identifies this DCF as part of a group of DCF's whose Rights can be defined in a common group Rights Object instead of (or in addition to) in separate content-specific Rights Objects.
The value of GroupID MUST be a URI according to [RFC2396] and MUST contain a globally unique identifier. The value MUST be encoded using US-ASCII encoding.
注：GroupID表示该DCF是一组DCF的一部分，使用公共的组权限对象RO。GroupID按URI格式来定义，使用US-ASCII编码。
Generally each content item in a group will be encrypted with a different content item encryption key.
A single additional key (used for the whole group) is used to encrypt each content item encryption key for storage in the GroupKey field.
注：一般每个内容项将使用不同的CEK加密。而额外的组密钥GEK，用来加密各个CEK。
Note that since the Group ID box is part of the OMA DRM container box, it is possible for different content items in a multipart DCF to belong to different groups
注：（没明白）
The NULL EncryptionMethod MUST NOT be used as a GKEncryptionMethod.
注：EncryptionMethod不允许使用NULL
5.2.4 Mutable DRM Information Box
A Device MAY modify, extend, truncate, delete or add the MutableDRMInformation box.
The contents of the box MUST be interpreted as an array of Boxes, continuing until the end of the parent box.
注：把内容解析为Box数组，从父Box的结束处开始。
aligned(8) MutableDRMInformation extends Box(‘mdri’) {
 Box data[]; // array of any boxes and free space
}
5.2.4.1 Transaction Tracking Box
The OMA DRM Transaction Tracking Box enables transaction tracking as defined in [DRM-v2] section 12.3.
The OMADRMTransactionTracking box MUST include a single TransactionID value as defined below. It MAY appear in both DCF and PDCF.
注：用于跟踪会话，在DCF/PDCF中都可能出现。
aligned(8) class OMADRMTransactionTracking extends FullBox('odtt', 0, 0) {
 char TransactionID[16]; // value to enable transaction tracking
}
The Rights Issuer MAY provide any value as a TransactionID to the DRM Agent during the Rights acquisition process and the TransactionID included in the DRM Container may be changed by the DRM Agent as defined in [DRM-v2]. When packaging content, the TransactionID MAY be set to an arbitrary value.
注：TransactionID可以使用任意值填充，DRM Agent有可能修改该值。（Why？）
5.2.4.2 Rights Object Box
The rights object box MAY be used to insert a Protected Rights Object, defined in [DRM-v2] section 5.3.8, into a DCF or PDCF.
A MutableDRMInformation box MAY include zero or more Rights Object boxes.
The Rights Object is treated as binary data and a Device MAY add or delete Rights Object boxes in the MutableDRMInformation box.
aligned(8) class OMADRMRightsObject extends FullBox('odrb', 0, 0) {
 byte Data[]; // binary Rights Object
}
注：MutableDRMInformation可能包含0个或多个OMADRMRightsObject。设备在处理过程中可能会添加或删除OMADRMRightsObject信息。
5.3 DCF Hash Calculation
Content Objects MAY be protected for integrity by including a DCF hash into a Rights Object or ROAP request.  Since (P)DCF MAY include structures editable by the Device, these structures are excluded from hash calculation.  The DCF hash MUST be calculated from the beginning of the DCF to the end of the last OMADRMContainer, ignoring the MutableDRMInformation box.  PDCF hash MUST be calculated from the beginning of the PDCF, skipping the MutableDRMInformation box after the movie box, or end of file in case there is no MutableDRMInformation box present.
注：内容的hash可能会用在Rights Object或者ROAP request中。考虑到DCF/PDCF可能被设备修改，计算hash时候需要特别注意，需要忽略MutableDRMInformation部分。
6. Discrete Media Profile (DCF)
6.1 DCF MIME Type
注：MIME类型必须是application/vnd.oma.drm.dcf，文件后缀名“.odf”.