Internet DRAFT - draft-greifenberg-mmusic-img-urn
draft-greifenberg-mmusic-img-urn
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]
