CAN CSA-ISO IEC 21000-4A-2008 Information technology - Multimedia framework (MPEG-21) - Part 4 Intellectual Property Management and Protection Components AMENDMENT 1 IPMP component.pdf

《CAN CSA-ISO IEC 21000-4A-2008 Information technology - Multimedia framework (MPEG-21) - Part 4 Intellectual Property Management and Protection Components AMENDMENT 1 IPMP component.pdf》由会员分享，可在线阅读，更多相关《CAN CSA-ISO IEC 21000-4A-2008 Information technology - Multimedia framework (MPEG-21) - Part 4 Intellectual Property Management and Protection Components AMENDMENT 1 IPMP component.pdf（24页珍藏版）》请在麦多课文档分享上搜索。

1、 Reference numberISO/IEC 21000-4:2006/Amd.1:2007(E)ISO/IEC 2007Information technology Multimedia framework (MPEG-21) Part 4: Intellectual Property Management and Protection Components AMENDMENT 1: IPMP components base profile Technologies de linformation Cadre multimdia (MPEG-21) Partie 4: Composant

2、s de gestion et de protection de proprit intellectuelle AMENDEMENT 1: Profil de base des composants GPPI Amendment 1:2008 toNational Standard of CanadaCAN/CSA-ISO/IEC 21000-4:07Amendment 1:2007 to International Standard ISO/IEC 21000-4:2006 has been adopted without modification(IDT) as Amendment 1:2

3、008 to CSA Standard CAN/CSA-ISO/IEC 21000-4:07. This Amendment wasreviewed by the CSA Technical Committee on Information Technology (TCIT) under the jurisdiction of theStrategic Steering Committee on Information Technology and deemed acceptable for use in Canada.September 2008 International Organiza

4、tion for Standardization (ISO), 2007. All rights reserved. International Electrotechnical Commission (IEC), 2007. All rights reserved. NOT FOR RESALE. ISO/IEC 21000-4:2006/Amd.1:2007(E) PDF disclaimer This PDF file may contain embedded typefaces. In accordance with Adobes licensing policy, this file

5、 may be printed or viewed but shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this file, parties accept therein the responsibility of not infringing Adobes licensing policy. The ISO Central Secretariat a

6、ccepts no liability in this area. Adobe is a trademark of Adobe Systems Incorporated. Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that

7、 the file is suitable for use by ISO member bodies. In the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below. COPYRIGHT PROTECTED DOCUMENT ISO/IEC 2007 All rights reserved. Unless otherwise specified, no part of this publication m

8、ay be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISOs member body in the country of the requester. ISO copyright office Case postale 56 CH-1211 Geneva 20 Tel

9、. + 41 22 749 01 11 Fax + 41 22 749 09 47 E-mail copyrightiso.org Web www.iso.org ii ISO/IEC 2007 All rights reservedISO/IEC 21000-4:2006/Amd.1:2007(E) ISO/IEC 2007 All rights reserved iiiForeword ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Co

10、mmission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity.

11、ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee,

12、ISO/IEC JTC 1. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. The main task of the joint technical committee is to prepare International Standards. Draft International Standards adopted by the joint technical committee are circulated to nati

13、onal bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible f

14、or identifying any or all such patent rights. Amendment 1 to ISO/IEC 21000-4:2006 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 29, Coding of audio, picture, multimedia and hypermedia information. ISO/IEC 21000-4:2006/Amd.1:2007(E) ISO/IEC 2007 All

15、rights reserved 1Information technology Multimedia framework (MPEG-21) Part 4: Intellectual Property Management and Protection Components AMENDMENT 1: IPMP components base profile Add Clause 9: 9 Base Profile 9.2 Introduction ISO/IEC 21000-4 Intellectual Property Management and Protection (IPMP) Com

16、ponents addresses the need for effective management and protection of intellectual property in the ISO/IEC 21000 MPEG-21 multimedia framework over heterogeneous access and delivery infrastructures. It represents a flexible and extensible framework for applying protection mechanisms to a Digital Item

17、 (DI). It purposely does not specify protection measures, keys, key management, trust management, encryption algorithms, certification infrastructures or other components. In its current form, the specification is designed to be applicable to a wide range of application areas 1415. Similarly to prev

18、iously developed MPEG standards, we believe the utility of this part of ISO/IEC 21000 can be enhanced by the careful identification and development of specific profiles supporting functionality relevant to various user communities. Base Profile specifically aims at supporting use cases in widespread

19、 use in the area of commercial content distribution. Base Profile purposely provides a limited scope in order to facilitate the easier and lighter implementation in devices with limited computational/storage capabilities. 9.2 Application Areas Base Profile provides sufficient functionality to suppor

20、t current and emerging practices for distribution of commercial content, with a special focus on entertainment content such as movies and music, while reducing the requirements on end devices (e.g. footprint, memory usage, computational power, storage). To this end, Base Profile will provide suitabl

21、e protection capability for the simple applications such as music player application, video player, music player with karaoke capability, etc. 9.3 List of Tools 9.3.1 Requirements Based on use-cases listed in Annex M and the capabilities in the MPEG-21 IPMP Components, the following is a list of det

22、ail required capabilities that shall be supported in Base Profile. These requirements later can be translated into some guidelines of rationale when selecting supported elements out of the complete set of MPEG-21 IPMP Components elements. ISO/IEC 21000-4:2006/Amd.1:2007(E) 2 ISO/IEC 2007 All rights

23、reservedOne important corollary derived from the use cases is that typically protection mechanisms are not applied independently, but rather a single mechanism (most likely incorporating several techniques, such as encryption, key management, digital signatures and/or watermarking, and with associat

24、ed non-technical compliance enforcement methods) is used as an indivisible component. With this in mind, Base Profile can be greatly simplified by assuming that a single Tool will be used for any given DI. Nonetheless, Base Profile should allow for the same Tool to be applied multiple times within t

25、he same DI (e.g. to protect different resources) and for different Licenses to be applied to different elements. Another important result from the use cases is that it is not necessary to support multiple levels of Signature. The use cases show that the user who assembles the DI also applies the pro

26、tection. Therefore, digital signature on a parent element in the DI is sufficient to ensure integrity of its children. A related result is that the type of protection that is most likely to be applied to a License is a digital signature to ensure the integrity of the License, i.e. that it has not be

27、en tampered with. Therefore, it is not necessary in Base Profile to be able to signal governance of a License, beyond the capability of signing the parent element. Note that MPEG-21 IPMP Components is capable of supporting more flexible configurations, e.g. where the License is signed (or otherwise

28、“governed”) by one party, the Tool is signed by another party and the DI is assembled by yet another party, which is not in scope for Base Profile. Finally, in order to facilitate processing of these Digital Items in resource-constrained terminals (such as portable devices with limited memory, proce

29、ssing power, connectivity and power consumption), Base Profile limits the ability to specify Tools to either an ID or a reference to the location where the Tool can be downloaded. (Note that this excludes the ability to specify Tools inline, which is consistent with the assumptions that, in general,

30、 Tools will be relatively complex.) An ID can be used by the terminal to determine if that capability is already supported. Loading of Tools specified through a reference is assumed to be through an out-of-band mechanism. 9.3.2 Selection Rationale Base Profile restricts the occurrence of some elemen

31、ts from the complete MPEG-21 IPMP Components elements. The guidelines for the restrictions are as follow: 1. Base Profile is designed to maintain the capability to express the protected Digital Item. 2. Base Profile is designed to reduce the requirement on end devices (e.g. device footprint, memory

32、usage, computational power, storage); thus, the following properties are restricted: a. Base Profile is designed to carry one protection tool in one document. b. Base Profile is designed to have no recursion. Recursion may consume more memory and computing power. Having recursion capability while ca

33、rrying only one tool is redundant as protecting a single resource with same tool many times gives no additional protection effect. c. Base Profile is designed to have no duplication of elements in many locations. For elements that can be inserted in different locations, a suitable place among the cu

34、rrent existing ones should be chosen to ease the implementation while not sacrificing the feature(s) offered by that element. 3. For simplicity, tool is assumed to be ready for use in the terminal. The procedure to acquire and/or install the tool in the terminal is out of scope of Base Profile. 4. B

35、ase Profile is designed to be simple for transfer. This requires the XML instance of Base Profile should be as small and compact as possible. For example, rather than being able to carry the tool binary representation in the XML document (with base64 encoding format), it is better to just carry refe

36、rence to it. 9.3.3 IPMP DIDL Base Profile maintains the full capability to express the protected DI (guideline no. 1); therefore, it shall include all the elements in the IPMP Digital Item Declaration Language (DIDL) schema. These elements taken together are a Representation of the Digital Item Decl

37、aration (DID) model that allows for inclusion of governance information (per guideline 1 in subclause 9.3.2). ISO/IEC 21000-4:2006/Amd.1:2007(E) ISO/IEC 2007 All rights reserved 39.3.4 IPMP General Information Descriptor Base Profile shall include the root element IPMPGeneralInfoDescriptor as define

38、d in Clause 8. It shall: Include ToolList element Optionally include LicenseCollection element. It may contain any number of RightsDescriptor elements (in case there are multiple assets in the digital item), although in most instances a single RightsDescriptor element is likely to be used. The Right

39、sDescriptor in Base Profile excludes the possibility of having an IPMPInfoDescriptor child (per guideline 2.b) Optionally include Signature element. If present, it is sufficient to ensure the integrity of the children elements. The ToolList element shall: Include at most one instance of ToolDescript

40、ion (per guideline 2.a). Note that Tools to be used in IPMPInfoDescriptor can only reference elements in ToolList; this ensures that only a single Tool can be defined for any given DI. Provide no support for Signature (per guideline 2.c). The ToolDescription element shall: Include IPMPToolID element

41、 Optionally include Remote element but without Signature element (per guideline 2.c) Provide no support of MemberOf element and its children (per guideline 2.a) Provide no support for Inline tool definition (per guideline 4) Provide no support for ConfigurationSettings (per guideline 3) Provide no s

42、upport for RightsDescriptor. RightsDescriptor elements are carried all together under the LicenseCollection element (per guideline 2.c) Provide no support for Signature (per guideline 2.c) 9.3.5 IPMP Information Descriptor Base Profile shall include the root element IPMPInfoDescriptor but with the f

43、ollowing constraints: Support for (at most) a single Tool No support for RightsDescriptor (no need to specify governance over the Tool itself). The RightsDescriptor elements are collected and expressed under the LicenseCollection element (per guideline 2.c) The element dsig:Signature remains optiona

44、l. The Tool element shall have the following constraint: No attributes are needed. Since there is at most one Tool, order is no longer relevant (per guideline 2b). No support for ToolBaseDescription. All tool definition is carried in the ToolList while the Tool element will only refer to it (per gui

45、deline 2.c) ISO/IEC 21000-4:2006/Amd.1:2007(E) 4 ISO/IEC 2007 All rights reserved Include a ToolRef element (per guideline 2.c) Optionally support the InitializationSettings element. However, there will be no support for ToolBaseDescription (no recursion per guideline 2.b). The only supported child

46、element shall be InitializationData. No support for RightsDescriptor (per guideline 2.c) No support for Signature (per guideline 2.c) 9.4 Profile Definition 9.4.1 Namespaces Throughout this document, Qualified Names are written with a namespace prefix followed by a colon followed by the local part o

47、f the Qualified Name. For clarity, throughout this document, consistent namespace prefixes are used. Table 2 gives these prefixes and the corresponding namespace. Table 2 Mapping of prefixes to namespaces in examples and text Prefix Name Corresponding namespace ipmpdidl IPMP DIDL urn:mpeg:mpeg21:200

48、4:01-IPMPDIDL-NS ipmpinfo IPMP Information urn:mpeg:mpeg21:2004:01-IPMPINFO-NS didl DIDL urn:mpeg:mpeg21:2002:02-DIDL-NS didmodel DIDL Model urn:mpeg:mpeg21:2002:02-DIDMODEL-NS dii Digital ItemIdentifier (DII) urn:mpeg:mpeg21:2002:01-DII-NS r Rights Expression Language (REL) Core urn:mpeg:mpeg21:200

49、3:01-REL-R-NS xsd XMLSchema http:/www.w3.org/2001/XMLSchema xsi XMLSchema Instance http:/www.w3.org/2001/XMLSchema-instance dsig XML digital signature core http:/www.w3.org/2000/09/xmldsig# 9.4.2 IPMP DIDL IPMP DIDL is included as specified in clause 6 without any restrictions. 9.4.3 IPMP General Information Descriptor Representation The subset of elements of the IPMP General Information Descriptor schema (see clause 8) and any restrictions are listed in subclause 9.3.2. Table 3 list the ele