idnits 2.17.1 draft-edwards-urn-smpte-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 415. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 8, 2007) is 6160 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) -- Possible downref: Non-RFC (?) normative reference: ref. 'SMPTE2029' -- Obsolete informational reference (is this intentional?): RFC 4234 (Obsoleted by RFC 5234) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Edwards 3 Internet-Draft PBS 4 Expires: December 10, 2007 June 8, 2007 6 A Uniform Resource Name (URN) Namespace for the Society of Motion 7 Picture and Television Engineers (SMPTE) 8 draft-edwards-urn-smpte-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 10, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes a Uniform Resource Name (URN) namespace for 42 the Society of Motion Picture and Television Engineers (SMPTE) for 43 naming persistent resources that SMPTE produces or manages. A 44 subnamespace for Universal Labels is specifically described. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. URN Namespace Definition Template . . . . . . . . . . . . . . 3 50 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 51 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 52 5. Namespace Considerations and Community Considerations . . . . 7 53 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 54 7. SMPTE Registration Authority (Informative) . . . . . . . . . . 8 55 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 57 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 Intellectual Property and Copyright Statements . . . . . . . . . . 10 61 1. Introduction 63 SMPTE (the Society of Motion Picture and Television Engineers) is an 64 internationally-recognized standards developing organization. 65 Headquartered and incorporated in the United States of America, SMPTE 66 has members in over 80 countries on six continents. SMPTE's 67 Engineering Documents, including Standards, Recommended Practices and 68 Engineering Guidelines, are prepared by SMPTE's Technology 69 Committees. Participation in these Committees is open to all with a 70 bona fide interest in a committee's work. SMPTE cooperates closely 71 with other standards-developing organizations, including ISO, IEC and 72 ITU. Also, the SMPTE Registration Authority maintains a registry of 73 Universal Labels (ULs) used in identifying the type and encoding of 74 data within data streams associated with audio-visual material. 76 SMPTE would like to assign unique, permanent, and location- 77 independent names using URNs for resources that SMPTE produces or 78 manages. 80 This namespace specification is for a formal namespace. 82 2. URN Namespace Definition Template 84 The following template is provided in accordance with [RFC3406]. 86 Namespace ID: 88 smpte 90 Registration Information: 92 Version: 2 94 Date: 2007-07-08 96 Declared registrant of the namespace: 98 Registering Organization: Society of Motion Picture and 99 Television Engineers 101 Address: 3 Barker Avenue - 5th Floor 103 White Plains, NY 10601 USA 105 Designated Contact Person: Director of Engineering 107 Phone: +1 (914) 761-1100 109 Email: standards@smpte.org 111 Declaration of structure: 113 The Namespace Specific String (NSS) of all URNs that use the 114 "smpte" NID shall be conformant to the URN syntax requirements 115 defined in [RFC2141]. 117 URNs for the "urn:smpte" namespace shall follow the structure 118 defined in [SMPTE2029]. 120 SMPTE (or it successor) may add additional subnamespaces in the 121 future. Any system which deals with URNs for the "urn:smpte" 122 namespace should be written with the awareness that this could 123 occur at any time. 125 For informative purposes, the identifier structure described 126 using ABNF (according to [RFC4234]) is as follows: 128 ;start ABNF notation 130 URN = "urn:" NID NSS 132 NID = "smpte:" 134 NSS = UL-NSS / other-NSS 136 UL-NSS = "ul:" UL 138 UL = QUADBYTE *(DOT QUADBYTE) 140 DOT = %x2E ; period 142 QUADBYTE = 4BYTE 144 BYTE = 2HEXDIG 146 other-NSS = 1*(DIGIT / ALPHA / "-"/":") 148 ; other-NSS which conforms with [RFC2141] for future 149 expansion 150 ;end ABNF notation 152 Relevant ancillary documentation: 154 The structure for URNs in the "urn:smpte" namespace are defined 155 in [SMPTE2029]. 157 The values of ULs in the "urn:smpte:ul" subnamespace shall be 158 constrained as defined in [SMPTE298M]. Details regarding the 159 use of ULs as keys in key-length-value (KLV) coding including 160 how to determine in which SMPTE registry a SMPTE-administered 161 UL may be found are described in [SMPTE336M]. 163 Identifier uniqueness considerations: 165 [SMPTE2029] states that "All URNs in the SMPTE namespace shall 166 conform to IETF RFC 3406. In particular, URNs in the SMPTE 167 namespace shall not be re-assigned, and URNs shall continue to 168 be valid, even if the owners or registrants of the SMPTE 169 resources identified by the URNs are no longer members or 170 customers of SMPTE. There need not be resolution of such URNs, 171 but they shall not resolve to false or stale information." 173 Additionally, the rules for assignment of SMPTE-administered 174 ULs requires that each UL be unique to the UL space and that it 175 cannot be reassigned or reused. 177 It should be noted that [SMPTE298M] states that "A universal 178 label shall be an 'object identifier' as specified by ISO/IEC 179 8824-1," ([ISO8824-1]) although the SMPTE Universal Label 180 representation is a specialized one that carries additional 181 semantics over the OID representation of URN OID ([RFC3061]). 183 SMPTE will work to ensure that all current and future 184 "urn:smpte" subnamespaces contain unique identifiers. 186 Identifier persistence considerations: 188 SMPTE-administered ULs may occasionally be deleted through 189 SMPTE procedures. Regardless, even after a UL has been 190 deleted, it will not be reused. Revisions to ULs will result 191 in the creation of a new UL, and the deletion of the old one. 193 The persistence of URNs in future "urn:smpte" subnamespaces 194 will be defined by SMPTE Standards. 196 Process of identifier assignment: 198 Assignment of URNs in the SMPTE NID is limited to SMPTE and 199 those authorities that are specifically designated by SMPTE. 200 SMPTE may designate portions of its namespace for assignment by 201 other parties. 203 Due process is followed by committees in the development of 204 SMPTE documents. Some types of Universal Label registrations, 205 and other registrations may require a fee to be paid to SMPTE. 207 All classes of SMPTE-administered ULs require for registration 208 the name and address of the applicant. Some classes of labels 209 also require the submission of supporting technical 210 documentation for the label and may require a due process 211 evaluation through the SMPTE Engineering Committee process. 213 Process for identifier resolution: 215 SMPTE-administered ULs are resolved through publications of the 216 SMPTE Registration Authority. Currently, publication of SMPTE- 217 administered ULs are made through a Metadata Dictionary as 218 specified in [RP210] and through the SMPTE Labels Registry as 219 specified in [RP224], both of which are currently available 220 online at http://www.smpte-ra.org/mdd/. 222 SMPTE expects to develop and maintain "URN catalogs" that map 223 all future assigned URNs in the "urn:smpte" namespace to 224 Uniform Resource Locators (URLs) to enable Web-based resolution 225 of named resources. 227 Rules for Lexical Equivalence: 229 Lexical equivalence of URNs in the "urn:smpte:ul" subnamespace 230 is defined by case-insensitive string match. 232 Lexical equivalence of URNs in additional subnamespaces of 233 "urn:smpte:" will be specified by SMPTE in the defining 234 document; in the absense of such specification, lexical 235 equivalence of URNs in the "urn:smpte:" namespace outside of 236 the "urn:smpte:ul" subnamespace is defined by exact string 237 match, according to [RFC2141]. 239 Conformance with URN Syntax: 241 No special considerations beyond the syntax herein described. 243 Validation mechanism: 245 None. 247 Scope: Global. 249 3. Examples 251 Currently only a "urn:smpte:ul" subnamespace is defined. This is the 252 subnamespace for SMPTE Universal Labels [SMPTE298M]. SMPTE may add 253 additional subnamespaces in the future. 255 The following examples are not guaranteed to be real, and are 256 provided for illustrative purposes only. 258 urn:smpte:ul:060E2B34.04010103.04010202.01011100 260 urn:smpte:newnss:future-urn-2105 262 4. Security Considerations 264 The SMPTE URN Namespace ID shares the security considerations 265 outlined in [RFC3406], but has no other known security 266 considerations. 268 5. Namespace Considerations and Community Considerations 270 SMPTE is an internationally-recognized standards developing 271 organization. As part of this effort, SMPTE also registers items 272 such as Universal Labels through the SMPTE Registration Authority. 273 The SMPTE namespace provides a uniform, unique, and effective way to 274 communicate resource names for these items, which can be used by the 275 motion imaging industry community. This namespace is also intended 276 to be a useful mechanism to provide both human and automated access 277 to these resources through online systems. 279 The individual URNs in the namespace shall be assigned through the 280 process of development of documents by SMPTE, through definition by 281 SMPTE standards, or through the registration of Universal Labels or 282 other items by the SMPTE Registration Authority. 284 RFC 3406 states that a URN registration RFC must include a 'Namespace 285 Considerations' section, which outlines the perceived need for a new 286 namespace. There are four areas where existing URN namespaces fall 287 short of the requirements for a SMPTE URN namespace. 289 URN assignment procedures: URNs for resources defined by SMPTE 290 standards must be assigned exclusively by SMPTE or its delegates 291 to ensure the integrity of the standards process. No other 292 existing URN namespace has URNs assigned and managed by SMPTE. 294 URN resolution: URNs assigned by SMPTE standards must be resolved 295 by SMPTE mechanisms such as the SMPTE Registration Authority to 296 ensure the integrity of the standards process. This resolution 297 may require the reference of databases only maintained by SMPTE. 299 Types of resources to be identified: Many resources defined by 300 SMPTE standards (such as Universal Labels) have no adequate 301 existing URN representation. 303 Types of services to be supported: SMPTE expects to establish web 304 services for the automated resolution of resources defined by 305 SMPTE standards utilizing the SMPTE URN namespace. 307 6. IANA Considerations 309 This document defines a URN NID registration that is to be entered 310 into the IANA registry of URN NIDs. It specifically requests the 311 NID, "smpte". 313 7. SMPTE Registration Authority (Informative) 315 The URL of the SMPTE Registration Authority is 316 http://www.smpte-ra.org. 318 8. References 320 8.1. Normative References 322 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 324 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 325 "Uniform Resource Names (URN) Namespace Definition 326 Mechanisms", BCP 66, RFC 3406, October 2002. 328 [SMPTE2029] 329 Society of Motion Picture and Television Engineers, 330 "Uniform Resource Names for SMPTE Resources", SMPTE 2029, 331 (to be published). 333 8.2. Informative References 335 [ISO8824-1] 336 International Organization for Standardization, 337 "Information Processing - Open System Interconnection - 338 Specification of Abstract Syntax Notation One (ASN.1)", 339 ISO Standard 8824-1:1995, 1995. 341 [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", 342 RFC 3061, February 2001. 344 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 345 Specifications: ABNF", RFC 4234, October 2005. 347 [RP210] Society of Motion Picture and Television Engineers, 348 "Metadata Dictionary Registry of Metadata Element 349 Descriptions", SMPTE RP210, . 351 [RP224] Society of Motion Picture and Television Engineers, 352 "Registry of SMPTE Universal Labels", SMPTE RP224, 353 . 355 [SMPTE298M] 356 Society of Motion Picture and Television Engineers, 357 "Universal Labels for Unique Identification of Digital 358 Data", ANSI / SMPTE 298M-1997, . 360 [SMPTE336M] 361 Society of Motion Picture and Television Engineers, "Data 362 Encoding Protocol using Key-Length-Value", SMPTE 336M- 363 2001, . 365 Author's Address 367 Thomas G. Edwards 368 PBS 369 6453 Stephenson Way 370 Alexandria, VA 22312 371 US 373 Phone: +1 703 739 5000 374 Email: tedwards@pbs.org 375 URI: http://www.pbs.org 377 Full Copyright Statement 379 Copyright (C) The IETF Trust (2007). 381 This document is subject to the rights, licenses and restrictions 382 contained in BCP 78, and except as set forth therein, the authors 383 retain all their rights. 385 This document and the information contained herein are provided on an 386 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 387 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 388 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 389 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 390 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 391 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 393 Intellectual Property 395 The IETF takes no position regarding the validity or scope of any 396 Intellectual Property Rights or other rights that might be claimed to 397 pertain to the implementation or use of the technology described in 398 this document or the extent to which any license under such rights 399 might or might not be available; nor does it represent that it has 400 made any independent effort to identify any such rights. Information 401 on the procedures with respect to rights in RFC documents can be 402 found in BCP 78 and BCP 79. 404 Copies of IPR disclosures made to the IETF Secretariat and any 405 assurances of licenses to be made available, or the result of an 406 attempt made to obtain a general license or permission for the use of 407 such proprietary rights by implementers or users of this 408 specification can be obtained from the IETF on-line IPR repository at 409 http://www.ietf.org/ipr. 411 The IETF invites any interested party to bring to its attention any 412 copyrights, patents or patent applications, or other proprietary 413 rights that may cover technology that may be required to implement 414 this standard. Please address the information to the IETF at 415 ietf-ipr@ietf.org. 417 Acknowledgment 419 Funding for the RFC Editor function is provided by the IETF 420 Administrative Support Activity (IASA).