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

IMPP WG                                                      J. Peterson
Internet-Draft                                                   NeuStar
Expires: March 1, 2004                                    September 2003

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

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 March 1, 2004.

Copyright Notice

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

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.

Peterson                 Expires March 1, 2004                  [Page 1]
Internet-Draft                  IM&P SRV                  September 2003

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2. Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3. Address Resolution . . . . . . . . . . . . . . . . . . . . . . . 4
   4. Domain Name Lookup . . . . . . . . . . . . . . . . . . . . . . . 5
   5. Processing SRV RRs . . . . . . . . . . . . . . . . . . . . . . . 5
   6. Processing Multiple Addresses  . . . . . . . . . . . . . . . . . 5
   7. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
   8. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 6
   9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 6
      Normative References . . . . . . . . . . . . . . . . . . . . . . 7
      Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
      Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8

Peterson                 Expires March 1, 2004                  [Page 2]
Internet-Draft                  IM&P SRV                  September 2003

1. Introduction

   Presence and instant messaging are defined in RFC2778 [5].  The
   Common Profiles for Presence (CPP [2]) and Instant Messaging (CPIM
   [1]) define two 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 [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 in order to provide greater compatibility with
   clients that support only one instant messaging protocol.  A client
   would look up the record corresponding 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 MX records.

   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

Peterson                 Expires March 1, 2004                  [Page 3]
Internet-Draft                  IM&P SRV                  September 2003

   described in RFC2119 [3] and indicate requirement levels for
   compliant implementations.

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

   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.

   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.

Peterson                 Expires March 1, 2004                  [Page 4]
Internet-Draft                  IM&P SRV                  September 2003

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

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 RFC2782 [7] for
   handling the priority and weight fields of SRV records.

Peterson                 Expires March 1, 2004                  [Page 5]
Internet-Draft                  IM&P SRV                  September 2003

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 is deterministic, this document
   requests that IANA create 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].

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)

Peterson                 Expires March 1, 2004                  [Page 6]
Internet-Draft                  IM&P SRV                  September 2003

      Robert Sparks (rsparks@dynamicsoft.com)

      Hiroyasu Sugano (suga@flab.fujitsu.co.jp)

Normative References

   [1]  Peterson, J., "Common Profile: Instant Messaging", draft-ietf-
        impp-im-04 (work in progress), October 2003.

   [2]  Peterson, J., "Common Profile: Presence", draft-ietf-impp-pres-
        04 (work in progress), October 2003.

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

   [8]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", RFC 2434, BCP 26, October 1998.

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                 Expires March 1, 2004                  [Page 7]
Internet-Draft                  IM&P SRV                  September 2003

Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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.

Peterson                 Expires March 1, 2004                  [Page 8]