idnits 2.17.1 draft-abel-nfc-urn-00.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 28. -- Found old boilerplate from RFC 3978, Section 5.5 on line 330. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 3) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (May 2006) is 6556 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 informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Abel 2 Document: draft-abel-nfc-urn-00.txt NFC Forum 3 Expires: November 2006 May 2006 5 A Uniform Resource Name (URN) Namespace for 6 The Near Field Communication Forum (NFC Forum) 8 Status of this Memo 10 Internet-Drafts are working documents of the Internet Engineering 11 Task Force (IETF), its areas, and its working groups. Note that 12 other groups may also distribute working documents as Internet- 13 Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 22 The list of Internet-Draft Shadow Directories can be accessed at 23 http://www.ietf.org/shadow.html. 25 By submitting this Internet-Draft, each author represents that any 26 applicable patent or other IPR claims of which he or she is aware 27 have been or will be disclosed, and any of which he or she becomes 28 aware will be disclosed, in accordance with Section 6 of BCP 79. 30 Abstract 32 This document describes the Namespace Identifier (NID) for Uniform 33 Resource Namespace (URN) resources published by the Near-Field 34 Communication Forum (NFC Forum). The NFC Forum defines and manages 35 resources that utilize this URN identification model. Management 36 activities for these and other resource types are provided by the NFC 37 Forum Technical Committee. 39 Table of Contents 41 1. Introduction...................................................2 42 2. URN specification for "nfc" NID................................2 43 2.1 Namespace ID:..............................................3 44 2.2 Registration Information:..................................3 45 2.3 Declared registrant of the namespace:......................3 46 2.4 Declaration of syntactic structure:........................3 47 2.5 Relevant ancillary documentation:..........................3 48 2.6 Identifier uniqueness considerations:......................4 49 2.7 Identifier persistence considerations:.....................4 50 2.8 Process of identifier assignment:..........................4 51 2.9 Process for identifier resolution:.........................5 52 2.10 Rules for Lexical Equivalence:............................5 53 2.11 Conformance with URN Syntax:..............................5 54 2.12 Validation mechanism:.....................................5 55 2.13 Scope:....................................................5 56 3. Examples.......................................................5 57 4. Namespace Considerations.......................................5 58 5. Community Considerations.......................................6 59 6. Security Considerations........................................6 60 7. IANA Considerations............................................6 61 8. References.....................................................6 62 8.1 Normative References.......................................6 63 8.2 Informative References.....................................6 64 Acknowledgments...................................................7 65 Author's Addresses................................................7 67 1. 68 Introduction 70 The NFC Forum is a specification development body developing 71 technologies related to near-field communications. This activity is 72 supported by a membership comprised of chip vendors, smart card 73 vendors, equipment vendors, software developers, finance and banking 74 service providers, content providers and other interested companies. 76 Some of the technologies being developed by the NFC Forum need 77 namespaces that are managed so that they are unique and persistent. 78 To assure that the uniqueness is absolute, the registration of a 79 specific NID for use by the NFC Forum was deemed appropriate. 80 Therefore, a full and complete registration will follow the namespace 81 specification process as defined in [RFC3406]. 83 2. 84 URN specification for "nfc" NID 86 2.1 87 Namespace ID: 89 The NID "nfc" is requested. 91 2.2 92 Registration Information: 94 Registration version number: 1 95 Registration date: 2006-05-17 97 2.3 98 Declared registrant of the namespace: 100 Registering organization 101 Name: Near Field Communication Forum, Inc. 102 Address: 401 Edgewater Place, Suite 600 103 Wakefield, MA, 01880 105 Designated contact 106 Role: Technical Program Manager 107 Email: TPM@nfc-forum.org 109 2.4 110 Declaration of syntactic structure: 112 The Namespace Specific String (NSS) of all URNs that use the "nfc" 113 NID will have the following structure: 115 urn:nfc:{NFCresource}:{ResourceSpecificString} 117 Where the "{NFCresource}" is a US-ASCII string that conforms to the 118 URN syntax requirements [RFC2141] and defines a specific class of 119 resource. Each resource class has a specific labeling scheme that is 120 covered by "{ResourceSpecificString}" which also conforms to the 121 naming requirements of [RFC2141]. 123 NFC Forum working groups will manage the assignment of NFC resources 124 and the specific registration values assigned for each resource 125 class. The Technical Committee will coordinate creation of new 126 resource class assignments based on community need. 128 2.5 129 Relevant ancillary documentation: 131 The NFC Forum publishes specifications describing the use of near- 132 field communication for interoperable exchange of information between 133 devices in close proximity. Among these specifications are the 134 designation of new data types, schema, XML elements and attributes, 135 protocols, and other formally named items intended for machine 136 parsing. Interested parties are referred to the NFC Forum web site 137 where these publications will be made available to the community: 139 http://www.nfc-forum.org/ 141 2.6 142 Identifier uniqueness considerations: 144 The NFC Forum working groups and Technical Committee will ensure 145 uniqueness of resource names assigned by the NFC Forum within the 146 resource classes for which they are responsible. 148 When authority and responsibility for assignment of names with a 149 resource class are delegated to an external organization, commitment 150 to adhere to the uniqueness requirements of the assigned resource 151 names will be a pre-condition of such delegation. 153 The structure of the NFC Forum namespace into resource classes will 154 further ensure isolation of names in each class from names in other 155 classes. 157 It is anticipated that some resource classes may be open to self- 158 assignment by any interested individual or organization. To ensure a 159 degree of uniqueness for these self-assigned resource names, fully- 160 qualified domain names will be factored into the name to distinguish 161 the naming authorities. 163 It should be understood that due to the flexibility of the domain 164 names system and the underlying market-based forces that allow for 165 ownership transfer and abandonment of domain names, no guarantee of 166 long-term uniqueness or persistence can be made for this class of 167 resource names beyond that made for the domain names themselves. 169 2.7 170 Identifier persistence considerations: 172 The NFC Forum will not reassign names and will thus guarantee the 173 persistence of names beyond the expected lifetime of the named 174 resource. NFC Forum does not anticipate operating a name resolution 175 service for the assigned names and does not anticipate any other 176 usability issues of the assigned names beyond those for any other 177 naturally aging technology. 179 2.8 180 Process of identifier assignment: 182 The NFC Forum will provide procedures for registration of each class 183 of resource that it maintains. Each such resource may have three 184 types of registration activities: 186 1) Registered names associated with NFC Forum specifications or 187 services; 188 2) Registration of names or resource classes for other entities; 189 3) Name models for use in experimental purposes. 191 2.9 192 Process for identifier resolution: 194 The namespace is not listed with an RDS; this is not relevant. 196 2.10 197 Rules for Lexical Equivalence: 199 No special considerations, the rules for lexical equivalence of 200 [RFC2141] apply. 202 2.11 203 Conformance with URN Syntax: 205 No special considerations. 207 2.12 208 Validation mechanism: 210 None specified. URN assignment and registration will be handled by 211 procedures implemented in support of NFC Forum activities. 213 2.13 214 Scope: 216 Global 218 3. 219 Examples 221 The following examples are representative URNs that could be assigned 222 by the NFC Forum. They may not be the actual strings that would be 223 assigned: 225 urn:nfc:wkt:Uri 226 Defines the well-known type identifier used to identify URI 227 bookmark data objects defined by the NFC Forum and exchanged by 228 NFC devices. 230 urn:nfc:schema:manifest 231 Declares an XML namespace for elements and attributes, used in 232 an XML schema to describe an NFC Forum data transfer manifest. 234 4. 235 Namespace Considerations 237 The NFC Forum is developing a variety of communication protocol and 238 data exchange specifications. Some of these specifications depend 239 upon supporting information (e.g. data descriptions, attributes, 240 schema, etc.) to be fully specified. For proper operation, 241 descriptions of the needed supporting information must exist and be 242 available in a unique, reliable and persistent manner. These 243 dependencies provide the basis of need for namespaces, in one form or 244 another. 246 As type information is relayed across NFC Forum protocols, the need 247 for compact, machine parsed type identification of data and meta- 248 content, with the attributes of uniqueness and reliability mentioned 249 above, becomes imperative for proper interoperation across widely 250 varied implementations. 252 As the NFC Forum work is ongoing and covers many technical areas, the 253 possibility of using various other namespace repositories has been 254 deemed impractical. Each data object, description, or schema as 255 defined in the NFC Forum, could possibly be related to multiple 256 different other namespaces so further conflicts of association might 257 occur. Thus the intent is to utilize the requested URN namespace to 258 manage NFC Forum defined objects, descriptions, and schema. 260 5. 261 Community Considerations 263 The objects and descriptions required for specifications produced and 264 published by the NFC Forum are generally available for use by other 265 organizations. The NFC Forum will provide access and support for 266 name requests by these external organizations. This support can be 267 enabled in timely and responsive fashion as new objects and 268 descriptions are produced. 270 6. 271 Security Considerations 273 There are no additional security considerations other than those 274 normally associated with the use and resolution of URNs in general. 276 7. 277 IANA Considerations 279 The objective of this registration is for the requested NID to be 280 entered into the IANA registry for URN NIDs. This would result in an 281 update to http://www.iana.org/assignments/urn-namespaces and any 282 associated mirrors. 284 8. 285 References 287 8.1 288 Normative References 290 As this registration request is an informative document, there are no 291 normative references. 293 8.2 294 Informative References 296 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 298 [RFC3406] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, 299 "Uniform Resource Names (URN) Namespace Definition 300 Mechanisms", BCP 66, RFC 3406, October 2002. 302 Acknowledgments 304 The author wishes to express thanks to Dwight Smith (Motorola) for 305 his guidance on the urn registration process and for providing, by 306 example, a registration that was worthy of emulation. 308 Author's Addresses 310 Miller Abel 311 Role: Technical Committee Delegate, NFC Forum 312 Address: Microsoft Corporation 313 One Microsoft Way 314 Redmond, WA 98052 316 Email: TPM@nfc-forum.org 318 Copyright (C) The Internet Society (2006). 320 This document is subject to the rights, licenses and restrictions 321 contained in BCP 78, and except as set forth therein, the authors 322 retain all their rights. 324 This document and the information contained herein are provided on an 325 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 326 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 327 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 328 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 329 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.