RFC 5119

A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE)

๐Ÿ“… published February 2008, from ietf

RFC 5119: A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE) ๐ŸŽ€

Okay bestie, the title block first. This is from the Network Working Group and it's by T. Edwards from FOX ๐Ÿ’…. It's dated February 2008, and it's Informational ๐Ÿ“š, which means it's just here to inform the Internet community. It's not a standard. The header doesn't list any RFCs it obsoletes or updates, so it's a clean slate ๐Ÿงš.


Status of This Memo ๐Ÿ“œ

This memo is here to give information to the Internet community. It doesn't specify an Internet standard of any kind ๐Ÿ™ˆ. Distribution is unlimited, so share it with everyone ๐Ÿซถ.

Abstract ๐Ÿ’…

So this doc describes a Uniform Resource Name (URN) namespace for the Society of Motion Picture and Television Engineers (SMPTE). The point is naming persistent resources that SMPTE produces or manages ๐ŸŽฌ. It also specifically describes a subnamespace for Universal Labels โœจ.

Table of Contents ๐Ÿงš

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  URN Namespace Definition Template  . . . . . . . . . . . . . .  2
3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
5.  Namespace Considerations and Community Considerations  . . . .  6
6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
7.  SMPTE Registration Authority (Informative) . . . . . . . . . .  7
8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
  8.1.  Normative References . . . . . . . . . . . . . . . . . . .  7
  8.2.  Informative References . . . . . . . . . . . . . . . . . .  7

1. Introduction โœจ

SMPTE is the Society of Motion Picture and Television Engineers, and it's an internationally-recognized standards-developing organization ๐ŸŒ. It's headquartered and incorporated in the United States of America, and it has members in over 80 countries on six continents ๐ŸŒ. SMPTE's Engineering Documents include Standards, Recommended Practices, and Engineering Guidelines. The Technology Committees prepare them ๐Ÿ› ๏ธ. Anyone with a bona fide interest in a committee's work can join, so it's giving open doors ๐Ÿšช. SMPTE works closely with other standards-developing organizations too, including ISO, the IEC, and the ITU ๐Ÿค. The SMPTE Registration Authority also keeps a registry of Universal Labels (ULs). Those ULs identify the type and encoding of data inside data streams tied to audio-visual material ๐ŸŽž๏ธ.

SMPTE would love to assign unique, permanent, and location-independent names using URNs for the resources it produces or manages ๐Ÿฆ‹.

This namespace spec is for a formal namespace, so it's serious business ๐Ÿ’ผ.

2. URN Namespace Definition Template ๐ŸŽ€

This template follows [RFC3406], so the structure is all there.

Namespace ID: smpte

Registration Information:

  • Version: 2
  • Date: 2007-07-08

Declared registrant of the namespace:

  • Registering Organization: Society of Motion Picture and Television Engineers
  • Address:
3 Barker Avenue - 5th Floor
White Plains, NY 10601 USA
  • Designated Contact Person: Director of Engineering
  • Phone: +1 (914) 761-1100
  • Email: standards@smpte.org

Declaration of structure:

Okay so the Namespace Specific String (NSS) of every URN that uses the smpte NID shall be conformant to the URN syntax requirements defined in [RFC2141] ๐Ÿ“. URNs for the urn:smpte namespace shall follow the structure defined in [SMPTE2029] ๐Ÿงฉ.

SMPTE (or it successor) may add more subnamespaces in the future ๐Ÿ”ฎ. Any system that deals with URNs for the urn:smpte namespace should be written with the awareness that this could happen at any time ๐Ÿ‘€.

For informative purposes, here's the identifier structure written in ABNF (according to [RFC4234]) ๐Ÿค“:

;start ABNF notation

URN = "urn:" NID NSS

NID = "smpte:"

NSS = UL-NSS / other-NSS

UL-NSS = "ul:" UL

UL = QUADBYTE *(DOT QUADBYTE)

DOT = %x2E ; period

QUADBYTE = 4BYTE

BYTE = 2HEXDIG

other-NSS = 1*(DIGIT / ALPHA / "-"/":")

; other-NSS that conforms with [RFC2141] for future
expansion

;end ABNF notation

Relevant ancillary documentation:

The structure for URNs in the urn:smpte namespace is defined in [SMPTE2029] ๐Ÿ“–. Values of ULs in the urn:smpte:ul subnamespace shall be constrained as defined in [SMPTE298M] ๐Ÿ”’. Details about using ULs as keys in key-length-value (KLV) coding are in [SMPTE336M], and that includes how to figure out which SMPTE registry a SMPTE-administered UL lives in ๐Ÿ—‚๏ธ.

Identifier uniqueness considerations:

[SMPTE2029] says this, and it's a big deal ๐Ÿšจ:

"All URNs in the SMPTE namespace shall conform to IETF RFC 3406. In particular, URNs in the SMPTE namespace shall not be re-assigned, and URNs shall continue to be valid, even if the owners or registrants of the SMPTE resources identified by the URNs are no longer members or customers of SMPTE. There need not be resolution of such URNs, but they shall not resolve to false or stale information."

Also, the rules for assigning SMPTE-administered ULs say each UL has to be unique to the UL space and can't be reassigned or reused ๐Ÿ”.

Here's a note from [SMPTE298M]: it says "A universal label shall be an 'object identifier' as specified by ISO/IEC 8824-1," ([ISO8824-1]). The SMPTE Universal Label is a specialized version, though, and it carries extra semantics over the OID representation of a URN OID ([RFC3061]) ๐Ÿง .

SMPTE will work to make sure all current and future urn:smpte subnamespaces have unique identifiers ๐Ÿ’ฏ.

Identifier persistence considerations:

SMPTE-administered ULs may sometimes be deleted through SMPTE procedures. Even so, once a UL is deleted it won't get reused ๐Ÿชฆ. Revisions to ULs make a new UL and delete the old one ๐Ÿ”„.

The persistence of URNs in future urn:smpte subnamespaces will be defined by SMPTE Standards ๐Ÿ“˜.

Process of identifier assignment:

Assigning URNs in the SMPTE NID is limited to SMPTE and the authorities SMPTE specifically designates ๐Ÿ”‘. SMPTE may designate parts of its namespace for assignment by other parties ๐Ÿง‘โ€๐Ÿคโ€๐Ÿง‘.

Committees follow due process when they develop SMPTE documents โš–๏ธ. Some Universal Label registrations and other registrations may require a fee paid to SMPTE ๐Ÿ’ธ.

Every class of SMPTE-administered UL requires the applicant's name and address for registration ๐Ÿ“ฌ. Some classes of labels also need supporting technical documentation, and they may need a due process evaluation through the SMPTE Engineering Committee process ๐Ÿ“.

Process for identifier resolution:

SMPTE-administered ULs are resolved through publications of the SMPTE Registration Authority ๐Ÿ”Ž. Right now, those publications come through a Metadata Dictionary as specified in [RP210], and through the SMPTE Labels Registry as specified in [RP224]. Both are available online at http://www.smpte-ra.org/mdd/ ๐Ÿ’ป.

SMPTE expects to develop and maintain "URN catalogs" that map all future assigned URNs in the urn:smpte namespace to Uniform Resource Locators (URLs). That should make Web-based resolution of named resources possible ๐ŸŒโœจ.

Rules for Lexical Equivalence:

Lexical equivalence of URNs in the urn:smpte:ul subnamespace is defined by a case-insensitive string match ๐Ÿ”ค.

SMPTE will specify lexical equivalence of URNs in any additional subnamespaces of urn:smpte: in the defining document. If there's no such specification, then lexical equivalence of URNs in the urn:smpte: namespace outside the urn:smpte:ul subnamespace is defined by an exact string match, according to [RFC2141] ๐ŸŽฏ.

Conformance with URN Syntax:

There are no special considerations beyond the syntax described here ๐Ÿ“.

Validation mechanism:

None ๐Ÿ™…โ€โ™€๏ธ.

Scope:

Global ๐ŸŒŽ.


Part 1 of 2 is done, and part 2 is coming with the examples, security stuff, namespace considerations, IANA, and references ๐Ÿฆ‹ to be continued ๐Ÿงš

8.1. Normative References ๐ŸŽ€

okay so the normative refs are the ones you NEED to read to actually implement this stuff, no cap ๐Ÿ“š

  • [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. ๐Ÿ’…
  • [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. ๐Ÿฆ‹
  • [SMPTE2029] Society of Motion Picture and Television Engineers, "Uniform Resource Names for SMPTE Resources", SMPTE 2029-2007, <http://www.smpte.org>. ๐ŸŒธ

8.2. Informative References ๐Ÿงš

these ones are more like bonus reading, lowkey helpful for context but you don't HAVE to read them to get the core idea ๐Ÿซถ

  • [ISO8824-1] International Organization for Standardization, "Information Processing - Open System Interconnection - Specification of Abstract Syntax Notation One (ASN.1)", ISO Standard 8824-1:1995, 1995. ๐Ÿ’œ
  • [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", RFC 3061, February 2001. ๐ŸŒˆ
  • [RFC4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. ๐Ÿ“
  • [RP210] Society of Motion Picture and Television Engineers, "Metadata Dictionary Registry of Metadata Element Descriptions", SMPTE RP210, <http://www.smpte.org>. โœจ
  • [RP224] Society of Motion Picture and Television Engineers, "Registry of SMPTE Universal Labels", SMPTE RP224, <http://www.smpte.org>. ๐Ÿ‘‘
  • [SMPTE298M] Society of Motion Picture and Television Engineers, "Universal Labels for Unique Identification of Digital Data", ANSI / SMPTE 298M-1997, <http://www.smpte.org>. ๐Ÿ”ฅ
  • [SMPTE336M] Society of Motion Picture and Television Engineers, "Data Encoding Protocol using Key-Length-Value", SMPTE 336M-2001, <http://www.smpte.org>. ๐Ÿ™ˆ

Author's Address ๐Ÿ’Œ

Thomas G. Edwards FOX 10201 West Pico Boulevard Los Angeles, CA 90035 US

Phone: +1 310 369 7093 Email: thomas.edwards@fox.com URI: http://www.fox.com


Copyright (C) The IETF Trust (2008).

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. ๐Ÿ’–

๐Ÿ“ฆ where this page comes from