doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

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]
+