MMUSIC J. Greifenberg
Internet-Draft Dampsoft GmbH
Expires: June 18, 2006 December 15, 2005
Identifiers for Internet Media Guides (IMG)
draft-greifenberg-mmusic-img-urn-01
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 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
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 18, 2006 [Page 1]
Internet-Draft img-urn December 2005
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
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Greifenberg Expires June 18, 2006 [Page 2]
Internet-Draft img-urn December 2005
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 [8] and IMG framework [9]
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
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations.
IMG specific terminology is defined [9]. 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 18, 2006 [Page 3]
Internet-Draft img-urn December 2005
Namespace ID:
"img" requested
Registration information:
TBD
Declared registrant of the namespace:
Contact: Janico Greifenberg
jgre@jgre.org
Declaration of syntactic structure:
The Namespace Specific String (NSS) has the following ABNF [7]
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 = 4(DIGIT)
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 the first day (starting 00:00 UTC) the organization
allocating the URN owned the domain name specified in the
ProviderId.
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
Greifenberg Expires June 18, 2006 [Page 4]
Internet-Draft img-urn December 2005
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.
IMG senders MAY provide URN resolution using the Dynamic
Delegation Discovery System (DDDS) (see [3], [4], [5], and [6]).
Greifenberg Expires June 18, 2006 [Page 5]
Internet-Draft img-urn December 2005
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
a simple mapping that does not require any additional round-trips.
This allows applications to use the mechanism best suited for their
needs.
Greifenberg Expires June 18, 2006 [Page 6]
Internet-Draft img-urn December 2005
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
[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] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", RFC 3401, October 2002.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Two: The Algorithm", RFC 3402, October 2002.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002.
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The Uniform Resource Identifiers (URI)", RFC 3404,
October 2002.
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[8] Nomura, Y., Walsh, R., Luoma, J., Ott, J., and H. Schulzrinne,
"Requirements for Internet Media Guides",
draft-ietf-mmusic-img-req-07 (work in progress), June 2004.
[9] Walsh, R., Luoma, J., Asaeda, H., Schulzrinne, H., and Y.
Nomura, "A Framework for the Usage of Internet Media Guides",
Greifenberg Expires June 18, 2006 [Page 7]
Internet-Draft img-urn December 2005
draft-ietf-mmusic-img-framework-08 (work in progress),
July 2004.
[10] Walsh, R., "The IMG Envelope",
draft-walsh-mmusic-img-envelope-03 (work in progress),
June 2005.
Greifenberg Expires June 18, 2006 [Page 8]
Internet-Draft img-urn December 2005
Author's Address
Janico Greifenberg
Dampsoft GmbH
Vogelsang 1
Damp D-24351
Germany
Email: jgre@jgre.org
Greifenberg Expires June 18, 2006 [Page 9]
Internet-Draft img-urn December 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Greifenberg Expires June 18, 2006 [Page 10]