1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc5028.txt b/doc/rfc/rfc5028.txt
new file mode 100644
index 0000000..addf9d5
--- /dev/null
+++ b/doc/rfc/rfc5028.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                            R. Mahy
+Request for Comments: 5028                                   Plantronics
+Category: Standards Track                                   October 2007
+
+
+       A Telephone Number Mapping (ENUM) Service Registration for
+                    Instant Messaging (IM) Services
+
+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.
+
+Abstract
+
+   This document registers a Telephone Number Mapping (ENUM) service for
+   Instant Messaging (IM).  Specifically, this document focuses on
+   provisioning 'im:' URIs (Uniform Resource Identifiers) in ENUM.
+
+1.  Introduction
+
+   ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS
+   (Domain Name Service, RFC 1034 [2]) to translate telephone numbers,
+   such as '+12025550100', into URIs (Uniform Resource Identifiers, RFC
+   3986 [3]), such as 'im:user@example.com'.  ENUM exists primarily to
+   facilitate the interconnection of systems that rely on telephone
+   numbers with those that use URIs to identify resources.
+
+   Instant Messaging (IM) is a service defined in RFC 2778 [6] that
+   allows users to send and receive typically short, often textual
+   messages in near real-time.  The IETF has defined a generic URI used
+   to identify an IM service for a particular resource: the 'im:' URI
+   scheme (defined in RFC 3861 [4]).  RFC 3861 [4] also defines rules
+   for discovering service running specific protocols, such as SIP (the
+   Session Initiation Protocol, RFC 3261 [8]) and XMPP (the eXtensible
+   Messaging and Presence Protocol, RFC 3921 [9]) from a specific 'im:'
+   URI.
+
+   RFC 3953 [10] already defines an enumservice for presence services,
+   which returns 'pres:' URIs (also defined in RFC 3861 [4]).  This
+   document registers an enumservice for advertising IM information
+   associated with an E.164 number.
+
+
+
+
+
+
+Mahy                        Standards Track                     [Page 1]
+
+RFC 5028                     IM Enumservice                 October 2007
+
+
+2.  ENUM Service Registration - im
+
+   As defined in RFC 3761 [1], the following is a template covering
+   information needed for the registration of the enumservice specified
+   in this document:
+
+   Enumservice Name:
+      "im"
+   Enumservice Type:
+      "im"
+   Enumservice Subtypes:
+      N/A
+   URI scheme(s):
+      "im:"
+   Functional Specification:
+      This Enumservice indicates that the resource identified is an
+      'im:' URI.  The 'im:' URI scheme does not identify any particular
+      protocol that will be used to handle instant messaging receipt or
+      delivery, rather the mechanism in RFC 3861 [4] is used to discover
+      whether an IM protocol supported by the party querying ENUM is
+      also supported by the target resource.
+   Security considerations:
+      See section 3.
+   Intended usage:
+      COMMON
+   Author:
+      Rohan Mahy (rohan@ekabal.com)
+
+3.  Security Considerations
+
+   The Domain Name System (DNS) does not make policy decisions about
+   which records it provides to a DNS resolver.  All DNS records must be
+   assumed to be available to all inquirers at all times.  The
+   information provided within an ENUM record set must therefore be
+   considered open to the public -- which is a cause for some privacy
+   considerations.
+
+   Revealing an 'im:' URI by itself is unlikely to introduce many
+   privacy concerns, although, depending on the structure of the URI, it
+   might reveal the full name or employer of the target.  The use of
+   anonymous URIs mitigates this risk.
+
+   As ENUM uses DNS, which in its current form is an insecure protocol,
+   there is no mechanism for ensuring that the answer returned to a
+   query is authentic.  An analysis of threats specific to the
+   dependence of ENUM on the DNS is provided in RFC 3761, and a thorough
+   analysis of threats to the DNS itself is covered in RFC 3833 [11].
+   Many of these problems are prevented when the resolver verifies the
+
+
+
+Mahy                        Standards Track                     [Page 2]
+
+RFC 5028                     IM Enumservice                 October 2007
+
+
+   authenticity of answers to its ENUM queries via DNSSEC [5] in zones
+   where it is available.
+
+   More serious security concerns are associated with potential attacks
+   against an underlying Instant Messaging system (for example, message
+   forgery and tampering).  For this reason, IM protocols have a number
+   of security requirements (detailed in RFC 2779 [7]) that call for
+   authentication, integrity and confidentiality properties, and similar
+   measures to prevent such attacks.  Any instant messaging protocol
+   used in conjunction with the 'im:' URI scheme is required to meet
+   these requirements.
+
+   Unlike a traditional telephone number, the resource identified by an
+   'im:' URI may require that callers provide cryptographic credentials
+   for authentication and authorization before instant messages are
+   exchanged.  In concert with instant messaging protocols, ENUM can
+   actually provide far greater protection from unwanted callers than
+   does the existing PSTN, despite the public availability of ENUM
+   records.
+
+4.  IANA Considerations
+
+   This document requests registration of the "im" Enumservice according
+   to the definitions in this document and RFC 3761 [1].
+
+5.  References
+
+5.1.  Normative References
+
+   [1]   Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
+         Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
+         Application (ENUM)", RFC 3761, April 2004.
+
+   [2]   Mockapetris, P., "Domain names - concepts and facilities", STD
+         13, RFC 1034, November 1987.
+
+   [3]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
+         January 2005.
+
+   [4]   Peterson, J., "Address Resolution for Instant Messaging and
+         Presence", RFC 3861, August 2004.
+
+   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Protocol Modifications for the DNS Security Extensions", RFC
+         4035, March 2005.
+
+
+
+
+
+Mahy                        Standards Track                     [Page 3]
+
+RFC 5028                     IM Enumservice                 October 2007
+
+
+5.2.  Informative References
+
+   [6]   Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
+         and Instant Messaging", RFC 2778, February 2000.
+
+   [7]   Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
+         Messaging / Presence Protocol Requirements", RFC 2779, February
+         2000.
+
+   [8]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+         Session Initiation Protocol", RFC 3261, June 2002.
+
+   [9]   Saint-Andre, P., Ed., "Extensible Messaging and Presence
+         Protocol (XMPP): Instant Messaging and Presence", RFC 3921,
+         October 2004.
+
+   [10]  Peterson, J., "Telephone Number Mapping (ENUM) Service
+         Registration for Presence Services", RFC 3953, January 2005.
+
+   [11]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
+         System (DNS)", RFC 3833, August 2004.
+
+Author's Address
+
+   Rohan Mahy
+   Plantronics
+
+   EMail: rohan@ekabal.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mahy                        Standards Track                     [Page 4]
+
+RFC 5028                     IM Enumservice                 October 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Mahy                        Standards Track                     [Page 5]
+