From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4729.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc4729.txt (limited to 'doc/rfc/rfc4729.txt') diff --git a/doc/rfc/rfc4729.txt b/doc/rfc/rfc4729.txt new file mode 100644 index 0000000..8e06780 --- /dev/null +++ b/doc/rfc/rfc4729.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group M. Abel +Request for Comments: 4729 NFC Forum +Category: Informational November 2006 + + + A Uniform Resource Name (URN) Namespace for + the Near Field Communication (NFC) Forum + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2006). + +Abstract + + This document describes the Namespace Identifier (NID) for Uniform + Resource Name (URN) resources published by the Near Field + Communication (NFC) Forum. The NFC Forum defines and manages + resources that utilize this URN identification model. Management + activities for these and other resource types are provided by the NFC + Forum Technical Committee. + +Table of Contents + + 1. Introduction ....................................................2 + 2. URN Specification for "nfc" NID .................................2 + 3. Examples ........................................................5 + 4. Namespace Considerations ........................................5 + 5. Community Considerations ........................................5 + 6. Security Considerations .........................................6 + 7. IANA Considerations .............................................6 + 8. Informative References ..........................................6 + Acknowledgments ....................................................6 + + + + + + + + + + + + + +Abel Informational [Page 1] + +RFC 4729 URN Namespace for the NFC Forum November 2006 + + +1. Introduction + + The NFC Forum is a specification development body developing + technologies related to near-field communications. This activity is + supported by a membership comprised of chip vendors, smart card + vendors, equipment vendors, software developers, finance and banking + service providers, content providers, and other interested companies. + + Some of the technologies being developed by the NFC Forum need + namespaces that are managed so that they are unique and persistent. + To ensure that the uniqueness is absolute, the registration of a + specific NID for use by the NFC Forum was deemed appropriate. + Therefore, a full and complete registration will follow the namespace + specification process as defined in [RFC3406]. + +2. URN Specification for "nfc" NID + + Namespace ID: + + nfc + + Registration Information: + + Registration version number: 1 + Registration date: 2006-05-17 + + Declared registrant of the namespace: + + Registering organization + Name: Near Field Communication Forum, Inc. + Address: 401 Edgewater Place, Suite 600 + Wakefield, MA 01880 + + Designated contact + Role: Technical Program Manager + Email: TPM@nfc-forum.org + + Declaration of syntactic structure: + + The Namespace Specific String (NSS) of all URNs that use the "nfc" + NID will have the following structure: + + urn:nfc:{NFCresource}:{ResourceSpecificString} + + Where the "{NFCresource}" is a US-ASCII string that conforms to + the URN syntax requirements [RFC2141] and defines a specific class + of resource. Each resource class has a specific labeling scheme + + + + +Abel Informational [Page 2] + +RFC 4729 URN Namespace for the NFC Forum November 2006 + + + that is covered by "{ResourceSpecificString}" which also conforms + to the naming requirements of [RFC2141]. + + NFC Forum working groups will manage the assignment of NFC + resources and the specific registration values assigned for each + resource class. The Technical Committee will coordinate creation + of new resource class assignments based on community need. + + Relevant ancillary documentation: + + The NFC Forum publishes specifications describing the use of + near-field communication for interoperable exchange of information + between devices in close proximity. Among these specifications + are the designation of new data types, schema, XML elements and + attributes, protocols, and other formally named items intended for + machine parsing. Interested parties are referred to the NFC Forum + web site where these publications will be made available to the + community: + + http://www.nfc-forum.org/ + + Identifier uniqueness considerations: + + The NFC Forum working groups and Technical Committee will ensure + uniqueness of resource names assigned by the NFC Forum within the + resource classes for which they are responsible. + + When authority and responsibility for assignment of names with a + resource class are delegated to an external organization, + commitment to adhere to the uniqueness requirements of the + assigned resource names will be a pre-condition of such + delegation. + + The structure of the NFC Forum namespace into resource classes + will further ensure isolation of names in each class from names in + other classes. + + It is anticipated that some resource classes may be open to self- + assignment by any interested individual or organization. To + ensure a degree of uniqueness for these self-assigned resource + names, fully-qualified domain names will be factored into the name + to distinguish the naming authorities. + + It should be understood that due to the flexibility of the domain + name system and the underlying market-based forces that allow for + ownership transfer and abandonment of domain names, no guarantee + of long-term uniqueness or persistence can be made for this class + + + + +Abel Informational [Page 3] + +RFC 4729 URN Namespace for the NFC Forum November 2006 + + + of resource names beyond that made for the domain names + themselves. + + Identifier persistence considerations: + + The NFC Forum will not reassign names and will thus guarantee the + persistence of names beyond the expected lifetime of the named + resource. NFC Forum does not anticipate operating a name + resolution service for the assigned names and does not anticipate + any other usability issues of the assigned names beyond those for + any other naturally aging technology. + + Process of identifier assignment: + + The NFC Forum will provide procedures for registration of each + class of resource that it maintains. Each such resource may have + three types of registration activities: + + 1) Registered names associated with NFC Forum specifications or + services; + 2) Registration of names or resource classes for other entities; + 3) Name models for use in experimental purposes. + + Process for identifier resolution: + + The namespace is not listed with a Resolution Discovery System + (RDS); this is not relevant. + + Rules for Lexical Equivalence: + + No special considerations; the rules for lexical equivalence of + [RFC2141] apply. + + Conformance with URN Syntax: + + No special considerations. + + Validation mechanism: + + None specified. URN assignment and registration will be handled + by procedures implemented in support of NFC Forum activities. + + Scope: + + Global + + + + + + +Abel Informational [Page 4] + +RFC 4729 URN Namespace for the NFC Forum November 2006 + + +3. Examples + + The following examples are representative URNs that could be assigned + by the NFC Forum. They may not be the actual strings that would be + assigned: + + urn:nfc:wkt:Uri + Defines the well-known type identifier used to identify URI + bookmark data objects defined by the NFC Forum and exchanged by + NFC devices. + + urn:nfc:schema:manifest + Declares an XML namespace for elements and attributes, used in + an XML schema to describe an NFC Forum data transfer manifest. + +4. Namespace Considerations + + The NFC Forum is developing a variety of communication protocol and + data exchange specifications. Some of these specifications depend + upon supporting information (e.g., data descriptions, attributes, + schema, etc.) to be fully specified. For proper operation, + descriptions of the needed supporting information must exist and be + available in a unique, reliable, and persistent manner. These + dependencies provide the basis of need for namespaces, in one form or + another. + + As type information is relayed across NFC Forum protocols, the need + for compact, machine-parsed type identification of data and meta- + content, with the attributes of uniqueness and reliability mentioned + above, becomes imperative for proper interoperation across widely + varied implementations. + + As the NFC Forum work is ongoing and covers many technical areas, the + possibility of using various other namespace repositories has been + deemed impractical. Each data object, description, or schema as + defined in the NFC Forum could possibly be related to multiple + different other namespaces, so further conflicts of association might + occur. Thus, the intent is to utilize the requested URN namespace to + manage NFC Forum-defined objects, descriptions, and schema. + +5. Community Considerations + + The objects and descriptions required for specifications produced and + published by the NFC Forum are generally available for use by other + organizations. The NFC Forum will provide access and support for + name requests by these external organizations. This support can be + enabled in a timely and responsive fashion as new objects and + descriptions are produced. + + + +Abel Informational [Page 5] + +RFC 4729 URN Namespace for the NFC Forum November 2006 + + +6. Security Considerations + + There are no additional security considerations other than those + normally associated with the use and resolution of URNs in general. + +7. IANA Considerations + + The requested NID (nfc) has been entered into the IANA registry for + URN NIDs. + +8. Informative References + + [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. + +Acknowledgments + + The author wishes to express thanks to Dwight Smith (Motorola) for + his guidance on the URN registration process and for providing, by + example, a registration that was worthy of emulation. + +Author's Address + + Miller Abel + Technical Committee Delegate, NFC Forum + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + EMail: TPM@nfc-forum.org + + + + + + + + + + + + + + + + + + +Abel Informational [Page 6] + +RFC 4729 URN Namespace for the NFC Forum November 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + +Abel Informational [Page 7] + -- cgit v1.2.3