RFC5509

Network Working Group S. Loreto Request for Comments: 5509 Ericsson Category: Standards Track April 2009

    Internet Assigned Numbers Authority (IANA) Registration
         of Instant Messaging and Presence DNS SRV RRs
           for the Session Initiation Protocol (SIP)

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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document registers with IANA two new DNS SRV protocol labels for resolving Instant Messaging and Presence services with SIP.

Introduction

The Service Record (SRV) RFC2782 identifies the host(s) that will support particular services. The DNS is queried for SRV RR in the general form:

_Service._Proto.Name

  Service: the symbolic name of the desired service

  Proto: the protocol of the desired service

  Name: the domain name for which this record is valid

"Address Resolution for Instant Messaging and Presence" RFC3861 provides guidance for locating the services associated with URIs that employ the following two URI schemes RFC3986: 'im' for INSTANT INBOXes RFC3860 and 'pres' for PRESENTITIES RFC3859.

In order to ensure that the association between "_im" and "_pres" and their respective underlying services are deterministic, the IANA has created two independent registries: the Instant Messaging SRV Protocol Label registry and the Presence SRV Protocol Label registry.

This document defines and registers the "_sip" protocol label in both registries so that computer programs can resolve 'im:' and 'pres:' URIs down to SIP addresses.

Moreover, this document explains how the use of SIP for Presence and Instant Messaging uses SRV.

Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119.

DNS SRV Usage of SIP with 'im' and 'pres' URIs

Although there are standard procedures for resolving 'im' and 'pres' URIs (Section 3 of RFC3861), the labels for SIP are not registered.

Section 5 of RFC3428 states that if a user agent (UA) is presented with an IM URI (e.g., "im:[email protected]") as the address for an instant message, it SHOULD resolve it to a SIP URI, and place the resulting URI in the Request-URI of the MESSAGE request before

sending.

Following the procedures defined in RFC3861, in order to resolve the IM URI, the UA performs a SRV lookup for:

_im._sip.example.com

Assuming that the example.com domain offers a SIP service for instant messaging at simple.example.com, this will result in a resolution of _im._sip.example.com. to simple.example.com. Thus, the instant messaging URI im:[email protected] would resolve to a SIP URI of sip:[email protected].

SIP supports both pager RFC3428 and session RFC4975 IM mode. However, a DNS SRV lookup does not specify which SIP IM mode a domain offer. If the user agent client (UAC) supports both session mode and pager mode, it is then suggested to try session mode first; if that mode is rejected, the UAC has to be ready to fall back to pager mode.

Section 5 of RFC3856 states that procedures defined in RFC3861 are also used to resolve the protocol-independent PRES URI for a presentity (e.g., "pres:[email protected]") into a SIP URI.

Following the procedures defined in RFC3861, in order to resolve the PRES URI, the UA performs a SRV lookup for:

_pres._sip.example.com

Assuming that the example.com domain offers a SIP presence service at simple.example.com, this will result in a resolution of _pres._sip.example.com. to simple.example.com. Thus, the protocol- independent PRES URI pres:[email protected] would resolve to a SIP URI of sip:[email protected].

Security Considerations

This document merely serves for the registration of DNS SRV labels in the appropriate IANA registry. The document does not specify a protocol; therefore, there are no security issues associated with it.

IANA Considerations

This specification registers a new SRV protocol label in both the Instant Messaging SRV Protocol Label registry and the Presence SRV Protocol Label registry.

Instant Messaging SRV Protocol Label Registration

"Address Resolution for Instant Messaging and Presence" RFC3861 defines an Instant Messaging SRV Protocol Label registry for protocols that can provide services that conform to the "_im" SRV Service label. Because SIP is one such protocol, IANA registers the "_sip" protocol label in the "Instant Messaging SRV Protocol Label Registry", as follows:

Protocol label: _sip

Specification: RFC 5509

Description: Instant messaging protocol label for the use of SIP for

             Presence and Instant Messaging protocol as defined by
             RFC3428.

Registrant Contact: Salvatore Loreto <[email protected]>

Presence SRV Protocol Label Registration

"Address Resolution for Instant Messaging and Presence" RFC3861 defines a Presence SRV Protocol Label registry for protocols that can provide services that conform to the "_pres" SRV Service label. Because the use of SIP for Presence and Instant Messaging is one such protocol, the IANA registers the "_sip" protocol label in the "Presence SRV Protocol Label Registry", as follows:

Protocol label: _sip

Specification: RFC 5509

Description: Presence protocol label for the use of SIP for Presence

             and Instant Messaging protocol as defined by RFC3856.

Registrant Contact: Salvatore Loreto <[email protected]>

Acknowledgments

The need for this registration was discussed with Jon Peterson and Peter Saint-Andre.

Miguel Garcia reviewed this document on behalf of the Real-time Applications and Infrastructure (RAI) Area Review Team (ART).

Normative References

RFC2119 Bradner, S., "Key words for use in RFCs to Indicate

          Requirement Levels", BCP 14, RFC 2119, March 1997.

RFC2782 Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for

          specifying the location of services (DNS SRV)", RFC 2782,
          February 2000.

RFC3428 Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,

          and D. Gurle, "Session Initiation Protocol (SIP) Extension
          for Instant Messaging", RFC 3428, December 2002.

RFC3856 Rosenberg, J., "A Presence Event Package for the Session

          Initiation Protocol (SIP)", RFC 3856, August 2004.

RFC3859 Peterson, J., "Common Profile for Presence (CPP)",

          RFC 3859, August 2004.

RFC3860 Peterson, J., "Common Profile for Instant Messaging

          (CPIM)", RFC 3860, August 2004.

RFC3861 Peterson, J., "Address Resolution for Instant Messaging

          and Presence", RFC 3861, August 2004.

RFC3986 Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform

          Resource Identifier (URI): Generic Syntax", STD 66,
          RFC 3986, January 2005.

RFC4975 Campbell, B., Mahy, R., and C. Jennings, "The Message

          Session Relay Protocol (MSRP)", RFC 4975, September 2007.

Author's Address

Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland

Email: [email protected]