[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 RFC 3861

IMPP WG                                                       D. Crocker
Internet-Draft                                               Brandenburg
Expires: April 27, 2003                                      A. Diacakis
                                                             F. Mazzoldi
                                                                Net Proj
                                                              C. Huitema
                                                               Microsoft
                                                                G. Klyne
                                                               Baltimore
                                                            J. Rosenberg
                                                               R. Sparks
                                                             dynamicsoft
                                                               H. Sugano
                                                                 Fujitsu
                                                             J. Peterson
                                                                 NeuStar
                                                        October 27, 2002


         Address Resolution for Instant Messaging and Presence
                         draft-ietf-impp-srv-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 27, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.




Crocker, et al.          Expires April 27, 2003                 [Page 1]


Internet-Draft                  IM&P SRV                    October 2002


Abstract

   Presence and instant messaging are defined in RFC2778 [5].  The
   Common Profiles for Presence [2] and Instant Messaging [1] define two
   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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2. Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3. Address Resolution . . . . . . . . . . . . . . . . . . . . . . . 3
   4. Domain Name Lookup . . . . . . . . . . . . . . . . . . . . . . . 3
   5. Processing SRV RRs . . . . . . . . . . . . . . . . . . . . . . . 4
   6. Processing Multiple Addresses  . . . . . . . . . . . . . . . . . 4
   7. Security Considerations  . . . . . . . . . . . . . . . . . . . . 5
   8. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 5
      References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
      Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9






























Crocker, et al.          Expires April 27, 2003                 [Page 2]


Internet-Draft                  IM&P SRV                    October 2002


1. Introduction

   Presence and instant messaging are defined in RFC2778 [5].  The
   Common Profiles for Presence [2] and Instant Messaging [1] define two
   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.

   The system described in this document relies on the use of DNS SRV
   [7] records and A records.

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 RFC2119 [3] and indicate requirement levels for
   compliant implementations.

   This memos makes use of the vocabulary defined in RFC 2778[9].  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 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 IM URI (i.e., domain names that can
   be resolved to SRV[11] or A RRs).

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



Crocker, et al.          Expires April 27, 2003                 [Page 3]


Internet-Draft                  IM&P SRV                    October 2002


   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

   Taking the IM URI for a concrete example, a lookup is performed for
   SRVs for the target domain and a desired IM transfer protocol.

   For example, if the destination INSTANT INBOX is
   "im:fred@example.com", and the sender wishes to use an IM transfer
   protocol called "SIP", then a SRV lookup is performed for:

   _im._sip.example.com.

   The returned RRs, if any, specify the next-hop server.

   The choice of IM transfer protocol is a local configuration option
   for each 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.

   The same logic is used for PRES URIs.

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, multihoming, or both.  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.  Two types of information are used
   to rank the domain addresses: multiple SRV records, and multihomed
   domains.

   Multiple SRV records contain a preference indication that MUST be
   used in sorting.  Lower numbers are preferable to higher ones.  If
   there are multiple destinations with the same preference, and there
   is no clear reason to favor one (e.g., by recognition of an easily-
   reached address), then the sender MUST randomize them to spread the
   load across multiple servers for a specific destination.

   The destination domain (perhaps taken from the preferred SRV record)



Crocker, et al.          Expires April 27, 2003                 [Page 4]


Internet-Draft                  IM&P SRV                    October 2002


   may be multihomed, in which case the resolver will return a list of
   alternative IP addresses.  It is the responsibility of the resolver
   to have ordered this list by decreasing preference if necessary, and
   the sender MUST try them in the order presented.

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]).

8. IANA Considerations

   This document introduces no new considerations for IANA.

References

   [1]  Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G.,
        Rosenberg, J., Sparks, R., Sugano, H. and J. Peterson, "Common
        Profile: Instant Messaging", draft-ietf-impp-im-00 (work in
        progress), October 2002.

   [2]  Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G.,
        Rosenberg, J., Sparks, R., Sugano, H. and J. Peterson, "Common
        Profile: Presence", draft-ietf-impp-pres-00 (work in progress),
        October 2002.

   [3]  Bradner, S., "Key words for use in RFCs to indicate requirement
        levels", RFC 2119, March 1997.

   [4]  Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
        1034, STD 13, 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.








Crocker, et al.          Expires April 27, 2003                 [Page 5]


Internet-Draft                  IM&P SRV                    October 2002


Authors' Addresses

   Dave Crocker
   Brandenburg InternetWorking
   675 Spruce Drive
   Sunnyvale, CA  94086
   US

   Phone: +1 408/246-8253
   EMail: dcrocker@brandenburg.com


   Athanassios Diacakis
   Network Projects Inc.
   4516 Henry Street
   Suite 113
   Pittsburgh, PA  15213
   US

   Phone: +1 412/681-6950 x202
   EMail: thanos@networkprojects.com


   Florencio Mazzoldi
   Network Projects Inc.
   4516 Henry Street
   Suite 113
   Pittsburgh, PA  15213
   US

   Phone: +1 412/681-6950
   EMail: flo@networkprojects.com


   Christian Huitema
   Microsoft Corporation
   One Microsoft Way
   Redmund, WA  98052-6399
   US

   EMail: huitema@microsoft.com










Crocker, et al.          Expires April 27, 2003                 [Page 6]


Internet-Draft                  IM&P SRV                    October 2002


   Graham Klyne
   Baltimore Technologies
   1310 Waterside
   Arlington Business Park
   Theale, Reading  RG7 4SA
   UK

   Phone: +44 118 903 8000
   EMail: gk@acm.org


   Jonathan Rosenberg
   dynamicsoft
   200 Executive Drive
   Suite 120
   West Orange, NJ  07052
   US

   EMail: jdrosen@dynamicsoft.com


   Robert Sparks
   dynamicsoft
   200 Executive Drive
   Suite 120
   West Orange, NJ  07052
   US

   EMail: rsparks@dynamicsoft.com


   Hiroyasu Sugano
   Fujitsu Laboratories Ltd.
   200 Executive Drive
   64 Nishiwaki, Ohkubo-cho
   Akashi  674-8555
   JP

   EMail: suga@flab.fujitsu.co.jp












Crocker, et al.          Expires April 27, 2003                 [Page 7]


Internet-Draft                  IM&P SRV                    October 2002


   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St
   Suite 570
   Concord, CA  94520
   US

   Phone: +1 925/363-8720
   EMail: jon.peterson@neustar.biz










































Crocker, et al.          Expires April 27, 2003                 [Page 8]


Internet-Draft                  IM&P SRV                    October 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Crocker, et al.          Expires April 27, 2003                 [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/