Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Capabilities
draft-saintandre-sip-xmpp-caps-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

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 September 3, 2009.

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 defines a bi-directional protocol mapping for the exchange of information about device capabilities between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). In particular it describes a shorthand notation for device capabilities that is consistent with the notation used in the XMPP community, a SIP header field to enable seamless exchange of capabilities information between XMPP and SIP, a method for transforming any existing SIP capability or feature into a Uniform Resource Name (URN) for input to the shorthand notation, and a branch of the IETF URN tree to be used for registration of SIP capabilities or features.

Table of Contents

1.  Introduction
2.  Approach
3.  Algorithm
4.  URN Transformation
5.  Definition of the Caps Header Field
6.  IANA Considerations
7.  Security Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses

1.  Introduction

Entities that implement either the Session Initiation Protocol [SIP] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) or the Extensible Messaging and Presence Protocol [XMPP] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) can provide information about their capabilities. To ensure interworking between these technologies, it is important to define bi-directional protocol mappings.

The architectural assumptions underlying such protocol mappings are provided in [SIP‑XMPP] (Saint-Andre, P., Houri, A., and J. Hildebrand, “Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core,” January 2008.) (including mapping of addresses and error conditions), and mappings for presence information, single instant messages, one-to-one text chat sessions, and multi-party chat sessions are provided by other documents in this unofficial series.

Both SIP and XMPP include methods for discovering the capabilities of another entity: [RFC3840] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.) for SIP and [XEP‑0030] (Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-Andre, “Service Discovery,” June 2008.) for XMPP. Because full capabilities information can become verbose, the XMPP community has defined a "shorthand" notation for XMPP capabilities, as specified in [XEP‑0115] (Hildebrand, J., Saint-Andre, P., Tronçon, R., and J. Konieczny, “Entity Capabilities,” February 2008.). To encourage interoperability, this document defines a SIP header for encapsulating a similar shorthand notation.

Note: The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [TERMS].

2.  Approach

The general approach pursued in this document is as follows:

• Re-use the shorthand notation defined for XMPP, specifically the algorithm for generation of a "verification string" from an ordered series of Uniform Resource Names [URN] (Moats, R., “URN Syntax,” May 1997.) that identify capabilities.
• Define a transformation of existing SIP capabilities into URNs so that they can serve as input to the algorithm.
• Define a SIP header that can contain the shorthand notation.

3.  Algorithm

The value of the verification string MUST be generated according to the following method.

Note: All sorting operations MUST be performed using "i;octet" collation as specified in Section 9.3 of [RFC4790] (Newman, C., Duerst, M., and A. Gulbrandsen, “Internet Application Protocol Collation Registry,” March 2007.).

1. Initialize an empty string S.
2. Generate one or more "identities" for the entity, where each identity formed of a string CATEGORY '/' [TYPE] '/' [LANG] '/' [NAME]. The CATEGORY shall be "client", the TYPE shall be "sip", the LANG shall be the value of the Accept-Language SIP header [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) if typically included by the entity, and the NAME shall be the value of the User Agent SIP header [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) if typically provided by the entity.
3. For each identity, append the 'category/type/lang/name' to S, followed by the '<' character.
4. Sort the supported capabilities (where each capability is formed using the transformation method described in the next section).
5. For each capability, append the feature to S, followed by the '<' character.
6. Ensure that S is encoded according to the UTF-8 encoding as specified in [RFC3269] (Kermode, R. and L. Vicisano, “Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents,” April 2002.).
7. Compute the verification string by hashing S using the desired hashing algorithm (e.g., SHA-1 as defined in [RFC3174] (Eastlake, D. and P. Jones, “US Secure Hash Algorithm 1 (SHA1),” September 2001.). The hashed data MUST be generated with binary output and encoded using Base64 as specified in Section 4 of [RFC4648] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.) (note: the Base64 output MUST NOT include whitespace and MUST set padding bits to zero). For example, the OpenSSL command for producing such output with SHA-1 is "echo -n 'S' | openssl dgst -binary -sha1 | openssl enc -nopad -base64".

4.  URN Transformation

The caps-generation algorithm requires consistent input formats, preferably Uniform Resource Names (URNs) or Uniform Resource Identifiers (URIs). We propose a new branch of the IETF URN tree for input to the caps-generation algorithm, where each SIP feature shall be of the following form:

urn:ietf:params:sip:feature:[tag]:[value]

Each feature tag shall be constructed according to the rules in [RFC3840] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.).

Each feature value shall be constructed according to the rules in [RFC3840] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.), with the following exceptions:

1. If the term of the conjunction is a disjunction, the value of the contact parameter is a quoted string, where the quoted string is a comma separated list of strings, each one derived from one of the terms in the disjunction. However, instead of converting the quote characters containing quoted strings to the less-than sign "<" and greater-than sign ">" as in [RFC3840] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.), each entity from the comma-separated string shall be encapsulated as a separate URN. For example, the feature value sip.description="PC, MyClient" shall be transformed into two URNs: "urn:ietf:params:sip:feature:description:PC" and "urn:ietf:params:sip:feature:description:MyClient".
2. Filters shall not be converted, since a conversion algorithm for filters has not yet been defined in this specification. (A future version of this specification could define such a transformation.)

As an example, consider the feature predicate shown in [RFC3840] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.):

(& (sip.mobility=fixed)
   (| (! (sip.events=presence)) (sip.events=message-summary))
   (| (language=en) (language=de))
   (sip.description="PC")
   (sip.newparam=TRUE)
   (rangeparam=-4..5125/1000))

That feature predicate would be converted to the following URNs:

urn:ietf:params:sip:feature:mobility:fixed
urn:ietf:params:sip:feature:events:presence
urn:ietf:params:sip:feature:events:message-summary
urn:ietf:params:sip:feature:language:en
urn:ietf:params:sip:feature:language:de
urn:ietf:params:sip:feature:description:PC
urn:ietf:params:sip:feature:+sip.newparam
urn:ietf:params:sip:feature:+rangeparam:-4:+5.125

5.  Definition of the Caps Header Field

The following is the augmented Backus-Naur Form (BNF) [RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) syntax of the Caps header field. The hash-func element is defined in [RFC4572] (Lennox, J., “Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP),” July 2006.).

   caps      = hash-func ":" ver
   ver       = 1*(hash-out)
   hash-out  = ALPHA / DIGIT / "/" / "+" / "="

6.  IANA Considerations

IANA shall add the following new SIP header field to the Header Fields subregistry under the SIP Parameters registry.

Header Name:

Caps

Compact Form:

(none)

Reference:

XXXX

7.  Security Considerations

To follow.

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses