doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc3861.txt b/doc/rfc/rfc3861.txt
new file mode 100644
index 0000000..87dfe31
--- /dev/null
+++ b/doc/rfc/rfc3861.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                        J. Peterson
+Request for Comments: 3861                                       NeuStar
+Category: Standards Track                                    August 2004
+
+
+         Address Resolution for Instant Messaging and Presence
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   Presence and instant messaging are defined in RFC 2778.  The Common
+   Profiles for Presence and Instant Messaging define two Universal
+   Resource Identifier (URI) schemes: 'im' for INSTANT INBOXes and
+   'pres' for PRESENTITIES.  This document provides guidance for
+   locating the resources associated with URIs that employ these
+   schemes.
+
+Table of Contents
+
+   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   3.  Address Resolution. . . . . . . . . . . . . . . . . . . . . . . 3
+   4.  Domain Name Lookup. . . . . . . . . . . . . . . . . . . . . . . 4
+   5.  Processing SRV RRs. . . . . . . . . . . . . . . . . . . . . . . 4
+   6.  Processing Multiple Addresses . . . . . . . . . . . . . . . . . 5
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+   9.  Contributors. . . . . . . . . . . . . . . . . . . . . . . . . . 6
+   10. Normative References. . . . . . . . . . . . . . . . . . . . . . 6
+   11. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . 7
+   12. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+Peterson                    Standards Track                     [Page 1]
+
+RFC 3861                        IM&P SRV                     August 2004
+
+
+1.  Introduction
+
+   Presence and instant messaging are defined in RFC 2778 [5].  The
+   Common Profiles for Presence (CPP) [2] and Instant Messaging (CPIM)
+   [1] define two Universal Resource Identifier (URI) schemes: 'im' for
+   INSTANT INBOXes and 'pres' for PRESENTITIES.  This document provides
+   rules for locating the resources associated with URIs that employ
+   these schemes via the Domain Name Service (DNS) [4].  These rules
+   could no doubt be applied to the resolution of other URI schemes that
+   are unrelated to instant messaging and presence.
+
+   CPIM and CPP both specify operations that have 'source' and
+   'destination' attributes.  While only the semantics, not the syntax,
+   of these attributes are defined by CPIM and CPP, many instant
+   messaging and presence protocols today support the use of URIs to
+   reflect the source and destination of their operations.  The 'im' and
+   'pres' URI schemes allow such protocols to express the identities of
+   the principals associated with a protocol exchange.  When these
+   operations pass through a CPIM or CPP gateway, these URIs could be
+   relayed without modification, which has a number of desirable
+   properties for the purposes of interoperability.
+
+   These URI schemes are also useful in cases where no CPIM/CPP
+   gatewaying will occur.  If a particular principal's endpoint supports
+   multiple instant messaging applications, for example, then a domain
+   that identifies that host might use the sort of DNS records described
+   in this document to provide greater compatibility with clients that
+   support only one instant messaging protocol.  A client would look up
+   the corresponding record to the supported protocol, and learn how to
+   contact the endpoint for that protocol.  The principal in this
+   instance would use an IM URI as their canonical address.
+
+   In some architectures, these URIs might also be used to locate a CPIM
+   or CPP gateway that serves a particular domain.  If a particular IM
+   service provider wishes to operate CPIM/CPP gateways in its own
+   domain that map standard Internet protocols to an internal
+   proprietary protocol, that gateway could be identified by an IM URI.
+   In that case, the DNS records used to dereference the IM URI would
+   serve a purpose similar to that of Mail Exchange (MX) records.
+
+   The system described in this document relies on the use of DNS
+   service (SRV) [7] records and address (A) records.
+
+
+
+
+
+
+
+
+
+Peterson                    Standards Track                     [Page 2]
+
+RFC 3861                        IM&P SRV                     August 2004
+
+
+2.  Terminology
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
+   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
+   described in BCP 14, RFC 2119 [3] and indicate requirement levels for
+   compliant implementations.
+
+   This memo makes use of the vocabulary defined in RFC 2778 [5].  Terms
+   such as CLOSED, INSTANT INBOX, INSTANT MESSAGE, and OPEN are used in
+   the same meaning as defined therein.
+
+3.  Address Resolution
+
+   A client determines the address of an appropriate system running a
+   server, on behalf of the system referenced by the domain, by
+   resolving the destination domain name that is part of the identifier
+   to either an intermediate relay system or a final target system.
+
+   Only resolvable, fully-qualified, domain names (FQDNs) are permitted
+   when domain names are used in an Instant Messaging (IM) URI (i.e.,
+   domain names that can be resolved to SRV [7] or A Resource Record
+   (RR)).
+
+   The symbolic name used in the Service field of the SRV record is
+   "_im" for instant messaging and "_pres" for presence (matching their
+   respective URI schemes).  However, the advertisement of these
+   services in the DNS is incomplete if it does not include the protocol
+   that will be used to instantiate the instant messaging or presence
+   operations.  Thus, the Protocol field of the SRV record contains an
+   IANA-registered label corresponding to the underlying instant
+   messaging or presence protocol being advertised (see Section 8 for
+   more information on valid Protocol fields).
+
+   Taking the IM URI as a concrete example, a lookup is performed for
+   SRVs for the target domain, a desired service (using the "_im"
+   Service label) and a desired IM transfer protocol.  If the
+   destination INSTANT INBOX is "im:fred@example.com", and the sender
+   wishes to use an IM transfer protocol called "BIP" (and supposing
+   "_bip" were registered with IANA as a valid Protocol label for the IM
+   Service), then a SRV lookup is performed for:
+
+   _im._bip.example.com.
+
+   The same procedure is used for PRES URIs, with the "_pres" Service
+   label.
+
+
+
+
+
+Peterson                    Standards Track                     [Page 3]
+
+RFC 3861                        IM&P SRV                     August 2004
+
+
+   Some clients may support multiple instant messaging or presence
+   protocols; in these cases they may make several such SRV queries, in
+   an application-specific order, until they find one supported in
+   common with the target domain.
+
+4.  Domain Name Lookup
+
+   Once a client lexically identifies a domain to which instant
+   messaging or presence operations will be delivered for processing, a
+   DNS lookup MUST be performed to resolve the domain.  The names MUST
+   be fully-qualified domain names (FQDNs) -- mechanisms for inferring
+   FQDNs from partial names or local aliases are a local matter.
+
+   The lookup first attempts to locate SRV RRs associated with the
+   domain.  If a canonical name (CNAME) RR is found instead, the
+   resulting domain is processed as if it were the initial domain.
+
+   If one or more SRV RRs are found for a given domain, a sender MUST
+   NOT utilize any A RRs associated with that domain unless they are
+   located using the SRV RRs.  If no SRV RRs are found, but an A RR is
+   found, then the A RR is treated as if it was associated with an
+   implicit SRV RR, with a preference of 0, pointing to that domain.
+
+5.  Processing SRV RRs
+
+   The returned DNS RRs, if any, specify the next-hop server, which may
+   be a protocol gateway or an endpoint.
+
+   Receiving systems that are registered for this DNS-based SRV
+   resolution service list the transfer protocols by which they can be
+   reached, either directly or through a translating gateway (using
+   combinations of Service and Protocol labels as described above).  The
+   transfer-time choice of the IM transfer protocol to be used (and,
+   therefore, to be resolved) is a local configuration option for each
+   sending system.
+
+   Using this mechanism, seamless routing of IM traffic is possible,
+   regardless of whether a gateway is necessary for interoperation.  To
+   achieve this transparency, a separate RR for a gateway must be
+   present for each transfer protocol and domain pair that it serves.
+
+
+
+
+
+
+
+
+
+
+
+Peterson                    Standards Track                     [Page 4]
+
+RFC 3861                        IM&P SRV                     August 2004
+
+
+6.  Processing Multiple Addresses
+
+   When the lookup succeeds, the mapping can result in a list of
+   alternative delivery addresses rather than a single address, because
+   of multiple SRV records.  For reliable operations, the client MUST be
+   able to try each of the relevant addresses in this list in order,
+   until a delivery attempt succeeds.  However, there MAY also be a
+   configurable limit on the number of alternate addresses that can be
+   tried.  In any case, the client SHOULD try at least two addresses.
+
+   Resolvers must follow the standard procedures in RFC 2782 [7] for
+   handling the priority and weight fields of SRV records.
+
+7.  Security Considerations
+
+   The usage of IM and PRES URIs, and the DNS procedures in this
+   document, introduce no security considerations beyond those described
+   in the requirements for instant messaging and presence ([6]) and the
+   SRV specification ([7]).
+
+   Subsequent registrations of Protocol labels for use with the "_im" or
+   "_pres" Service labels MUST, however, explain any security
+   considerations that arise from the use of the protocol in question
+   with SRV.
+
+8.  IANA Considerations
+
+   This document reserves the use of "_im" and "_pres" Service labels.
+   Since these relate to a service which may pass messages over a number
+   of different message transports, they must be associated with a
+   specific instant messaging or presence service.
+
+   In order to ensure that the association between "_im" and "_pres" and
+   their respective underlying services are deterministic, the IANA has
+   created two independent registries: the Instant Messaging SRV
+   Protocol Label registry and the Presence SRV Protocol Label registry.
+   For each registry, an entry shall consist of a label name and a
+   pointer to a specification describing how the protocol named in the
+   label uses SRV.  Specifications should conform to the requirements
+   listed in RFC 2434 [8] for "specification required".
+
+   Protocol labels compliant with this specification MUST begin with the
+   underscore character "_" and follow all other rules for SRV Protocol
+   labels described in [7].
+
+
+
+
+
+
+
+Peterson                    Standards Track                     [Page 5]
+
+RFC 3861                        IM&P SRV                     August 2004
+
+
+9.  Contributors
+
+   Dave Crocker edited earlier versions of this document.
+
+   The following individuals made substantial textual contributions to
+   this document:
+
+      Athanassios Diacakis (thanos.diacakis@openwave.com)
+
+      Florencio Mazzoldi (flo@networkprojects.com)
+
+      Christian Huitema (huitema@microsoft.com)
+
+      Graham Klyne (gk@ninebynine.org)
+
+      Jonathan Rosenberg (jdrosen@dynamicsoft.com)
+
+      Robert Sparks (rsparks@dynamicsoft.com)
+
+      Hiroyasu Sugano (suga@flab.fujitsu.co.jp)
+
+10.  Normative References
+
+   [1]  Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC
+        3860, August 2004.
+
+   [2]  Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
+        August 2004.
+
+   [3]  Bradner, S., "Key words for use in RFCs to indicate requirement
+        levels", BCP 14, RFC 2119, March 1997.
+
+   [4]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
+        13, RFC 1034, November 1987.
+
+   [5]  Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
+        Instant Messaging", RFC 2778, February 2000.
+
+   [6]  Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging /
+        Presence Protocol Requirements", RFC 2779, February 2000.
+
+   [7]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+        Specifying the Location of Services (SRV)", RFC 2782, February
+        2000.
+
+   [8]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", RFC 2434, BCP 26, October 1998.
+
+
+
+
+Peterson                    Standards Track                     [Page 6]
+
+RFC 3861                        IM&P SRV                     August 2004
+
+
+11.  Author's Address
+
+   Jon Peterson
+   NeuStar, Inc.
+   1800 Sutter St
+   Suite 570
+   Concord, CA  94520
+   US
+
+   Phone: +1 925/363-8720
+   EMail: jon.peterson@neustar.biz
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peterson                    Standards Track                     [Page 7]
+
+RFC 3861                        IM&P SRV                     August 2004
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  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 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.
+
+
+
+
+
+
+
+
+
+Peterson                    Standards Track                     [Page 8]
+