MMUSIC J. Greifenberg Internet-Draft Dampsoft GmbH Expires: June 21, 2007 December 18, 2006 Identifiers for Internet Media Guides (IMG) draft-greifenberg-mmusic-img-urn-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 21, 2007. Copyright Notice Copyright (C) The IETF Trust (2006). Abstract This document defines a Uniform Resource Name (URN) namespace for identifying Internet Media Guides (IMGs). IMG metadata describes files, resources and multimedia programs available for streaming or downloading via multicast or unicast. Greifenberg Expires June 21, 2007 [Page 1] Internet-Draft img-urn December 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Specification Template . . . . . . . . . . . . . . . . . . . . 3 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Namespace Considerations . . . . . . . . . . . . . . . . . . . 6 6. Community Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Greifenberg Expires June 21, 2007 [Page 2] Internet-Draft img-urn December 2006 1. Introduction Internet Media Guides (IMGs) are used to encapsulate and communicate metadata about (ephemeral) contents available via arbitrary networks, e.g., TV and multimedia streams, downloadable contents, or other services. The scope and background of the work on Internet Media Guides have been described in the IMG requirements [9] and IMG framework [8] specifications. Furthermore, [10] specifies a common encapsulation format for metadata transport. Identification of IMG metadata is needed by receivers to be able to handle incoming metadata; it is important to know, if newly received metadata is something completely new or if it updates metadata that is already known. Therefore an identifier is included in the IMG transport envelope. This identifier must be persistent and location-independent in order to allow metadata to be moved or cached by different entities and still be recognizable as the same metadata. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. IMG specific terminology is defined [8]. In addition, the following term is defined: IMG resource: A common name for a full or delta IMG, for an IMG fragment, or an IMG pointer encoded in some specific metadata format. The IMG resource does not include a possible IMG envelope used for encapsulation. An IMG resource is identified by an IMG URN using the namespace defined in this document and may be stored in one or more locations. 3. Specification Template Greifenberg Expires June 21, 2007 [Page 3] Internet-Draft img-urn December 2006 Namespace ID: "img" requested Registration information: Registration version: 1; registration date: 2006-11-06 Declared registrant of the namespace: Contact: Janico Greifenberg jgre@jgre.org Declaration of syntactic structure: The Namespace Specific String (NSS) has the following ABNF [3] specification: NSS = ProviderId ":" DateId ":" IMGRootId [":" FragmentId] ProviderId = 1*(label ".") toplabel DateId = CCYY MM DD IMGRootId = 1*(alphanum / symbol / ("%" HEXDIG HEXDIG )) FragmentId = 1*(alphanum / symbol / ":" / ("%" HEXDIG HEXDIG )) label = alphanum / (alphanum *( alphanum / "-" ) alphanum) toplabel = ALPHA / (ALPHA *( alphanum / "-" ) alphanum) CCYY = 4DIGIT MM = ( "0" DIGIT ) / ( "1" ( "0" / "1" / "2" ) ) DD = ( "0" DIGIT ) / ( ( "1" / "2" ) DIGIT ) / "30" / "31" alphanum = ALPHA / DIGIT symbol = "(" / ")" / "+" / "," / "-" / "." / "=" / "@" / ";" / "$" / "_" / "!" / "*" / "'" ProviderId is the IMG sender's or IMG transceiver's identifier. ProviderId MUST be an Internet domain name, and MUST be owned by the organization creating the IMG resource and allocating the URN to the resource, at the date identified by the DateId. DateId is a date in ISO 8601 Basic Format (CCYYMMDD), and MUST correspond to a day (starting 00:00 UTC) the organization allocating the URN owned the domain name specified in the ProviderId. The organization MUST use the same date for all URNs it allocates. Greifenberg Expires June 21, 2007 [Page 4] Internet-Draft img-urn December 2006 IMGRootId MUST be unique among all IMGRootIds emanating from the IMG sender or IMG transceiver identified by ProviderId and DateId. This identifier refers to a top-level entity in the data model used for IMG resources published by the organization identified by the ProviderID and DateID. The data model and its semantics are defined by the organization. If an IMG sender assigns an identifier to a subset of metadata identified by an IMGRootId, it uses the same IMGRootId and a FragmentId. The FragmentId MAY be an identifier corresponding to the structure of the metadata. The sender or transceiver MUST assign FragmentIds that are unique among the FragmentIds with the same IMGRootId. Relevant ancillary documentation: None Identifier Uniqueness considerations: The combination of ProviderId and DateId serves to uniquely identify the organization providing the IMG sender or IMG transceiver allocating the URN. That organization is responsible for ensuring the uniqueness of the IMGRootId and the FragmentId. Identifier Persistence considerations: URNs of this namespace may only be allocated by an organization that owns an Internet domain name. The URN identifies a date on which the organization owned that domain name. The combination of domain name and date will serve to unambiguously and persistently identify that organization. Process of identifier assignment: The organization identified by the ProviderId/DateId combination is responsible for assigning an IMGRootId that is unique among all IMGRootId it allocates. Process for identifier resolution: IMG identifiers can be resolved using either data included in the IMG envelope or an external RDS. The IMG transfer envelope includes the identifies of the metadata the envelope is associated with. Furthermore, the envelope can include URLs that can be used to access the metadata the envelope refers to. IMG receivers MAY use this information to resolve the URN. Receivers should, however, be aware the the URLs may be outdated and do not point to the sought metadata. Greifenberg Expires June 21, 2007 [Page 5] Internet-Draft img-urn December 2006 IMG senders MAY provide URN resolution using the Dynamic Delegation Discovery System (DDDS) (see [4], [5], [6], and [7]). If this mechanism is available, receivers can locate an authoritative server for information about the sender of the IMG identified by a given URN using the process specified in [7]. Rules for Lexical Equivalence: The ProviderId is case-insensitive. The remainder of the NSS shall be considered case-sensitive. Otherwise the rules defined in [2] apply. Conformance with URN syntax: When using format-specific syntaxes for identifying fragments in the FragmentId portion of the URN, senders MUST translate any character that is outside the URN character set using the rules defined in [2]. Validation mechanism: None additional to resolution specified. Scope: Global. 4. Examples The following examples are representative of URNs in this namespace, but may not refer to actual IMG resources. urn:img:example.org:20051021:my-img-root urn:img:example.org:20051021:my-img-root:subset 5. Namespace Considerations The IMG namespace allows names to be assigned in a distributed manner without central authority. IMG senders can choose the identifier structure that best suits the needs of their application context. Furthermore, format-specific or application-specific fragment identifiers can be included in IMG URNs to allow subsets of metadata to be identified. Resolution can be done using either a distributed discovery system or Greifenberg Expires June 21, 2007 [Page 6] Internet-Draft img-urn December 2006 a simple mapping that does not require any additional round-trips. This allows applications to use the mechanism best suited for their needs. 6. Community Considerations The ability to assign unique identifiers for IMGs in a flexible manner without a central authority, allows IMG senders and IMG transceivers to be set up easily. 7. IANA Considerations This document includes a URN NID registration that is to be entered into the IANA registry of URN NIDs. 8. Security Considerations There are no additional security considerations other than those normally associated with the use and resolution of URNs in general. 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Moats, R., "URN Syntax", RFC 2141, May 1997. [3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. 9.2. Informative References [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002. [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. Greifenberg Expires June 21, 2007 [Page 7] Internet-Draft img-urn December 2006 [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [8] Nomura, Y., Walsh, R., Luoma, J-P., Asaeda, H., and H. Schulzrinne, "A Framework for the Usage of Internet Media Guides (IMGs)", RFC 4435, April 2006. [9] Nomura, Y., Walsh, R., Luoma, J-P., Ott, J., and H. Schulzrinne, "Requirements for Internet Media Guides (IMGs)", RFC 4473, May 2006. [10] Walsh, R., "The IMG Envelope", draft-walsh-mmusic-img-envelope-05 (work in progress), June 2006. Author's Address Janico Greifenberg Dampsoft GmbH Vogelsang 1 Damp D-24351 Germany Email: jgre@jgre.org Greifenberg Expires June 21, 2007 [Page 8] Internet-Draft img-urn December 2006 Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Greifenberg Expires June 21, 2007 [Page 9]