IMPP WG J. Peterson
Internet-Draft NeuStar
Expires: November 17, 2003 May 19, 2003
Address Resolution for Instant Messaging and Presence
draft-ietf-impp-srv-03
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 November 17, 2003.
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 November 17, 2003 [Page 1]
Internet-Draft IM&P SRV May 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Address Resolution . . . . . . . . . . . . . . . . . . . . . . . 4
4. Domain Name Lookup . . . . . . . . . . . . . . . . . . . . . . . 4
5. Processing SRV RRs . . . . . . . . . . . . . . . . . . . . . . . 4
6. Processing Multiple Addresses . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Normative References . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8
Peterson Expires November 17, 2003 [Page 2]
Internet-Draft IM&P SRV May 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 November 17, 2003 [Page 3]
Internet-Draft IM&P SRV May 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).
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
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.
Peterson Expires November 17, 2003 [Page 4]
Internet-Draft IM&P SRV May 2003
The choice of IM transfer protocol is a local configuration option
for each system.
Receiving systems that are registed for this DNS-based SRV resolution
service list the transfer protocols by which they can be reached,
either directly or through a translating gateway. 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.
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)
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]).
Peterson Expires November 17, 2003 [Page 5]
Internet-Draft IM&P SRV May 2003
8. IANA Considerations
This document introduces no new considerations for IANA.
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)
Normative References
[1] Crocker, D. and J. Peterson, "Common Profile: Instant
Messaging", draft-ietf-impp-im-00 (work in progress), October
2002.
[2] Crocker, D. 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
Peterson Expires November 17, 2003 [Page 6]
Internet-Draft IM&P SRV May 2003
2000.
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 November 17, 2003 [Page 7]
Internet-Draft IM&P SRV May 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 November 17, 2003 [Page 8]