Cisco

psaintan@cisco.com

Cisco

jhildebr@cisco.com

Applications RAI 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.

Entities that implement either the Session Initiation Protocol or the Extensible Messaging and Presence Protocol 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 (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: for SIP and for XMPP. Because full capabilities information can become verbose, the XMPP community has defined a "shorthand" notation for XMPP capabilities, as specified in . 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.

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 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.

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 . Initialize an empty string S. 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 if typically included by the entity, and the NAME shall be the value of the User Agent SIP header if typically provided by the entity. For each identity, append the 'category/type/lang/name' to S, followed by the '<' character. Sort the supported capabilities (where each capability is formed using the transformation method described in the next section). For each capability, append the feature to S, followed by the '<' character. Ensure that S is encoded according to the UTF-8 encoding as specified in . Compute the verification string by hashing S using the desired hashing algorithm (e.g., SHA-1 as defined in . The hashed data MUST be generated with binary output and encoded using Base64 as specified in Section 4 of (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".

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:

Each feature tag shall be constructed according to the rules in . Each feature value shall be constructed according to the rules in , with the following exceptions: 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 , 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". 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 :

That feature predicate would be converted to the following URNs:

The following is the augmented Backus-Naur Form (BNF) syntax of the Caps header field. The hash-func element is defined in .

IANA shall add the following new SIP header field to the Header Fields subregistry under the SIP Parameters registry. Caps (none) &rfc.number;

To follow.

The purpose of this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available to the Internet community. This memo provides information for the Internet community. This document provides general guidelines to assist the authors of Reliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed. This memo provides information for the Internet community. This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS TRACK] This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field. [STANDARDS TRACK] This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.</t><t> This document extends and updates RFC 4145. [STANDARDS TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS TRACK] Many Internet application protocols include string-based lookup, searching, or sorting operations. However, the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the Internet Engineering Task Force (IETF). Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function, and the repertoire of comparison functions can be extended in the future. [STANDARDS TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS TRACK] This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS TRACK] Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 -

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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. Note that the force of these words is modified by the requirement level of the document in which they are used. AT&T

15621 Drexel Circle Omaha NE 68135-2358 USA +1 402 894-9456 jayhawk@ds.internic.net

Applications URN uniform resource Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it.

jhildebrand@jabber.com

reatmon@jabber.org

jhildebrand@jabber.com

jajcus@jajcus.net

Jabber Software Foundation

stpeter@jabber.org

Applications XMPP Working Group RFC Request for Comments I-D Internet-Draft XMPP Extensible Messaging and Presence Protocol Jabber IM Instant Messaging Presence XML Extensible Markup Language This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. As a foundation for the definition of application-specific, bi-directional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.