Address Resolution for Instant Messaging and Presence
RFC 3861
| Document | Type |
RFC - Proposed Standard
(August 2004; No errata)
Was draft-ietf-impp-srv (impp WG)
|
|
|---|---|---|---|
| Author | Jon Peterson | ||
| Last updated | 2015-10-14 | ||
| Stream | Internent Engineering Task Force (IETF) | ||
| Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 3861 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Ted Hardie | ||
| Send notices to | (None) | ||
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
Show full document text