Address Resolution for Instant Messaging and Presence
Extracted elements (15)
IM and PRES URIs are useful even without CPIM/CPP gatewaying: if a principal's endpoint supports multiple IM applications, DNS SRV records allow clients supporting only one protocol to discover compatible endpoints, using an IM URI as the canonical address.
The DNS-based SRV mechanism serves a role analogous to MX records for email: an IM service provider can operate CPIM/CPP gateways identified by an IM URI, mapping standard Internet protocols to internal proprietary protocols.
The '_im' and '_pres' SRV Service labels must be paired with a specific Protocol label because these services may pass messages over multiple different transport protocols. Without the Protocol field, the advertisement would be incomplete and non-deterministic.
Clients supporting multiple IM or presence protocols may make several SRV queries in application-specific order until they find a protocol supported in common with the target domain. Resolvers must follow RFC 2782 procedures for handling priority and weight fields.
A DNS lookup MUST be performed to resolve the domain once a client identifies a domain for IM or presence delivery. The names MUST be fully-qualified domain names (FQDNs).
For reliable operations, the client MUST be able to try each of the relevant addresses in the list of alternative delivery addresses in order, until a delivery attempt succeeds. The client SHOULD try at least two addresses.
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.
Protocol labels compliant with this specification MUST begin with the underscore character '_' and follow all other rules for SRV Protocol labels described in RFC 2782.
Subsequent registrations of Protocol labels for use with the '_im' or '_pres' Service labels MUST explain any security considerations that arise from the use of the protocol in question with SRV.
If a CNAME RR is found during the SRV lookup, the resulting domain is processed as if it were the initial domain.
If no SRV RRs are found but an A RR is found, the A RR is treated as if it was associated with an implicit SRV RR with a preference of 0, pointing to that domain.
Receiving systems list transfer protocols by which they can be reached (directly or through a translating gateway) using combinations of Service and Protocol labels in SRV records. A separate RR for a gateway must be present for each transfer protocol and domain pair it serves.
The SRV Service field symbolic name is '_im' for instant messaging and '_pres' for presence, matching their respective URI schemes. The Protocol field contains an IANA-registered label for the underlying IM or presence protocol.
IANA created two independent registries: the Instant Messaging SRV Protocol Label registry and the Presence SRV Protocol Label registry. Each entry consists of a label name and a pointer to a specification describing how the named protocol uses SRV. Specifications must conform to RFC 2434 'specification required' requirements.
The usage of IM and PRES URIs and the DNS procedures in this document introduce no security considerations beyond those described in RFC 2779 (IM/presence requirements) and RFC 2782 (SRV specification).