SMPTE RP 2079-2013 Digital Object Identifier (DOI) Name and Entertainment ID Registry (EIDR) Identifier Representations.pdf

1、 Copyright 2013 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved November 7, 2013 Table of Contents Page Foreword . 2 Intellectual Property 2 Introduction 2 1 Scope . 3 2 Conformance Notation . 3 3 Normative References . 3 4 Ca

2、nonical DOI Name . 4 5 Canonical EIDR Identifier . 4 6 Canonical DOI Name Type 4 7 Canonical EIDR Identifier Type 5 8 Canonical DOI Name Element . 6 9 Canonical EIDR IdentifierElement . 7 10 URI Representation of Canonical DOI Name andCanonical EIDR Identifier . 7 11 Binary Representations of Canoni

3、cal EIDR Identifier 7 Annex A Bibliography (Informative) . 9 Page 1 of 9 pages SMPTE RP 2079:2013 SMPTE RECOMMENDED PRACTICE Digital Object Identifier (DOI) Name and Entertainment ID Registry (EIDR) Identifier Representations SMPTE ST 2079:2013 Page 2 of 9 pages Foreword SMPTE (the Society of Motion

4、 Picture and Television Engineers) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTEs Engineering Documents, including Standards, Recommended Practices, a

5、nd Engineering Guidelines, are prepared by SMPTEs Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are draft

6、ed in accordance with the rules given in Part XIII of its Operations Manual. SMPTE RP 2079 was prepared by Technology Committee 30MR. Intellectual Property At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implementation of this Engineering Docum

7、ent. However, attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights. Introduction This section is entirely informative and does not form an integral part

8、of this Engineering Document. The digital object identifier (DOI) system specified in ISO/IEC 26324 provides an infrastructure for persistent unique identification of objects in the form of a DOI name. An Entertainment ID Registry (EIDR) Identifier is a particular kind of a DOI name used for global

9、unique identification of movie and TV content. It is desirable to facilitate interchange of DOI names and EIDR Identifiers in MXF and other SMPTE engineering documents by unambiguously specifying their representation. SMPTE ST 2079:2013 Page 3 of 9 pages 1 Scope To facilitate interchange, this speci

10、fication defines specific text and binary representations for digital object identifier (DOI) names and Entertainment ID Registry (EIDR) Identifiers. It also defines dictionary entries, e.g. types and elements, for use in MXF and other KLV-based applications. 2 Conformance Notation Normative text is

11、 text that describes elements of the design that are indispensable or contains the conformance language keywords: “shall“, “should“, or “may“. Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting

12、interoperability. Informative text does not contain any conformance keywords. All text in this document is, by default, normative, except: the Introduction, any section explicitly labeled as “Informative“ or individual paragraphs that start with “Note:” The keywords “shall“ and “shall not“ indicate

13、requirements strictly to be followed in order to conform to the document and from which no deviation is permitted. The keywords, “should“ and “should not“ indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certai

14、n course of action is preferred but not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited. The keywords “may“ and “need not“ indicate courses of action permissible within the limits of the document. The keyword “reserved”

15、indicates a provision that is not defined at this time, shall not be used, and may be defined in the future. The keyword “forbidden” indicates “reserved” and in addition indicates that the provision will never be defined in the future. A conformant implementation according to this document is one th

16、at includes all mandatory provisions (“shall“) and, if implemented, all recommended provisions (“should“) as described. A conformant implementation need not implement optional provisions (“may“) and need not implement them as described. Unless otherwise specified, the order of precedence of the type

17、s of normative information in this document shall be as follows: Normative prose shall be the authoritative definition; Tables shall be next; followed by formal languages; then figures; and then any other language forms. 3 Normative References The following standards contain provisions that, through

18、 reference in this text, constitute provisions of this recommended practice. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this recommended practice are encouraged to investigate the possibility of applying th

19、e most recent edition of the standards indicated below. ISO/IEC 7064:2003 Information Technology Security Techniques Check Character Systems ISO/IEC 26324:2012, Information and Documentation Digital Object Identifier System SMPTE ST 335:2012, Metadata Element Dictionary Structure SMPTE ST 2003:2012,

20、 Types Dictionary Structure SMPTE ST 2079:2013 Page 4 of 9 pages Internet Engineering Task Force (IETF) (April 2006). RFC 4452, The “info“ URI Scheme for Information Assets with Identifiers in Public Namespaces Internet Engineering Task Force (IETF) (January 2008). RFC 5234, Augmented BNF for Syntax

21、 Specifications: ABNF 4 Canonical DOI Name A Canonical DOI Name is defined as a DOI name string as specified in Section 4.1 of ISO/IEC 26324. Example: 10.1000/123456 is a Canonical DOI Name with the DOI prefix 10.1000 and the DOI suffix 123456. Note: A DOI name can be resolved at http:/www.dx.doi.or

22、g/ . 5 Canonical EIDR Identifier A Canonical EIDR Identifier shall be a DOI name string as specified in ISO/IEC 26324, conforming to the EIDR_IDENTIFIER syntax specified below (using ABNF as specified in IETF RFC 5234): EIDR_IDENTIFIER = EIDR_PREFIX “/“ EIDR_SUFFIX EIDR_PREFIX = “10.5240“ EIDR_SUFFI

23、X = 5*5(4*4HEXDIG “-“) CHECK DIGIT = %x30-39 ; 0-9 HEXDIG = DIGIT / “A“ / “B“ / “C“ / “D“ / “E“ / “F“ ALPHA = %x41-5A / %x61-7A ; A-Z / a-z CHECK = DIGIT / ALPHA CHECK shall be the Mod 37,36 check character as specified in ISO/IEC 7064, computed over the 20 hexadecimal digits HEXDIG of EIDR_SUFFIX.

24、EIDR Identifiers shall be case insensitive. Example: 10.5240/5FD4-FEE1-22F5-583E-FECC-O and 10.5240/5fd4-FEE1-22F5-583E-fecc-o correspond to the same EIDR Identifier. Note: The check character is computed over the DOI suffix alone: if the prefix is not 10.5240, the DOI name is not an EIDR Identifier

25、. 6 Canonical DOI Name Type The Canonical DOI Name Type registry entry, as defined in SMPTE ST 2003, shall be as specified in Table 1. An instance of the Canonical DOI Name Type shall be a Canonical DOI Name as specified in Section 4. SMPTE ST 2079:2013 Page 5 of 9 pages Table 1 DOI Name Type Defini

26、tion Name Canonical DOI Name Type Symbol CanonicalDOINameType Designator Bytes 1-7: Types Byte 8: 0x01 Byte 9-10: RenamedCharacterTypes Byte 11: 0x07 Byte 12-16: 0x00 Definition DOI name as specified in Section 4.1 of ISO/IEC 26324 Type Kind Basic Type Size variable Base Type UTF16String Type Qualif

27、iers n/a Facets n/a Defining Document SMPTE RP 2079 Context Abstract 7 Canonical EIDR Identifier Type The Canonical EIDR Identifier Type registry entry, as defined in SMPTE ST 2003, shall be as specified in Table 2. An instance of the Canonical EIDR Identifier Type shall be a Canonical EIDR Identifi

28、er as specified in Section 5. SMPTE ST 2079:2013 Page 6 of 9 pages Table 2 EIDR Identifier Type Definition Name Canonical EIDR Identifier Type Symbol CanonicalEIDRIdentifierType Designator Bytes 1-7: Types Byte 8: 0x01 Bytes 9-10: RenamedCharacterTypes Byte 11: 0x08 Byte 12-16: 0x00 Definition Canon

29、ical EIDR Identifier Type Kind Basic Type Size variable Base Type CanonicalDOINameType Type Qualifiers n/a Facets n/a Defining Document SMPTE RP 2079 Context Abstract 8 Canonical DOI Name Element The Canonical DOI Name element registry entry, as defined in SMPTE ST 335, shall be as specified in Tabl

30、e 3. Table 3 DOI Name Element Definition Name Canonical DOI Name Symbol CanonicalDOIName Designator Bytes 1-7: Elements Byte 8: 0x0E Bytes 9-11: InternationalStandardIdentifiers Byte 12: 0x0C Definition Identifier of type CanonicalDOINameType Type CanonicalDOINameType Defining Document SMPTE RP 2079

31、 Context Scope Abstract Note: This element is distinct from the DOI element (urn:smpte:ul:06.0E.2B.34.01.01.01.01.01.01.15.01.00.00.00.00), which does not specify a specific representation of the DOI Name or a data type. SMPTE ST 2079:2013 Page 7 of 9 pages 9 Canonical EIDR IdentifierElement The Can

32、onical EIDR Identifier element registry entry, as defined in SMPTE ST 335, shall be as specified in Table 4. Table 4 EIDR Identifier Element Definition Name Canonical EIDR Identifier Symbol CanonicalEIDRIdentifier Designator Bytes 1-7: Elements Byte 8: 0x0E Bytes 9-11: InternationalStandardIdentifie

33、rs Byte 12: 0x0D Definition Identifier of type CanonicalEIDRIdentifierType Type CanonicalEIDRIdentifierType Defining Document SMPTE RP 2079 Context Abstract 10 URI Representation of Canonical DOI Name and Canonical EIDR Identifier Note: ISO/IEC 26324 specifies multiple possible URI representations f

34、or Canonical DOI Names. To facilitate interchange, the URI representation of a Canonical DOI Name or a Canonical EIDR Identifier should conform to IETF RFC 4452 using the doi namespace. Example: The URI representation of the Canonical EIDR Identifier 10.5240/5FD4-FEE1-22F5-583E-FECC-O is info:doi:10

35、.5240/5FD4-FEE1-22F5-583E-FECC-O according to IETF RFC 4452. 11 Binary Representations of Canonical EIDR Identifier 11.1 Full Binary Representation The full binary representation of a Canonical EIDR Identifier shall be a 152-bit binary word ordered most significant byte first, and shall consist of t

36、he concatenation of the following: a 64-bit word equal to 0x31302e353234302f (US-ASCII encoding of the string “10.5240/“); 20 4-bit nibbles, each equal to the value of a single hexadecimal digit HEXDIG of EIDR_SUFFIX, starting from the leftmost one; and an 8bit word containing the ASCII-encoded valu

37、e of either the lowercase or uppercase representation of the CHECK character. Example: The full binary representation of the Canonical EIDR Identifier 10.5240/5FD4-FEE1-22F5-583E-FECC-O is 0x31302E353234302F5FD4FEE122F5583EFECC4F SMPTE ST 2079:2013 Page 8 of 9 pages 11.2 Compact Binary Representatio

38、n The compact binary representation of a Canonical EIDR Identifier shall be a 96-bit binary word ordered most significant byte first, and consist of the concatenation of the following: a 16-bit word equal to 0x1478 (5240 in decimal); and 20 4-bit nibbles, each equal to the value of a single hexadeci

39、mal digit HEXDIG of EIDR_SUFFIX, starting from the leftmost one. Note: When generating a Canonical EIDR Identifier from a compact EIDR Identifier, the CHECK character will need to be computed. Example: The compact binary representation of the Canonical EIDR Identifier 10.5240/5FD4-FEE1-22F5-583E-FECC-O is 0x14785FD4FEE122F5583EFECC SMPTE ST 2079:2013 Page 9 of 9 pages Annex A Bibliography (Informative) Entertainment Identifier Registry (30 January 2012). EIDR: ID Format Ver. 1.02 (http:/eidr.org/documents/EIDR_ID_Format_v1.02_Jan2012.pdf