SIMPLE Internet Draft P. Kyzivat Document: draft-kyzivat-simple-prescaps-reqts-00.txt Cisco Expires: April 2003 October 2002 Requirements for SIP Capabilities in PIDF Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document sets forth requirements for the definition of elements for representation of SIP specific features within the Presence Information Data Format (PIDF), as well as for guidelines on how to use these new elements with PIDF to represent the capabilities of a SIP User Agent Server. Conventions used in this 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 [2]. Table of Contents 1. Introduction...................................................2 2. Definitions....................................................2 3. Motivation.....................................................3 Kyzivat Expires - April 2003 [Page 1]
Requirements for SIP Capabilities in PIDF October 2002 4. How Presence Changes SIP Usage.................................3 5. The Role of Caller Preferences.................................4 6. Requirements...................................................5 6.1 DonÆt Change PIDF...............Error! Bookmark not defined. 6.2 Represent a Tag-Set........................................5 6.3 Represent Any Tag Set......................................5 6.4 Compatibility with Registration............................6 Security Considerations...........................................6 References........................................................6 Acknowledgments...................................................7 Author's Addresses................................................7 1. Introduction Interoperation of Instant Messaging and Presence systems has been defined by the IMPP Working Group. That group has also defined a generic model for Presence and Instant Messaging [3] and requirements for protocols implementing such a system [4]. Common Presence and Instant Messaging (CPIM) defines common operations and formats which all Presence and Instant Messaging services must agree upon so that basic interoperability would be possible [5]. The actual base format for presence (PIDF) is being defined in [6]. The PIDF document format standardizes a minimal definition of status. In order to make the PIDF format usable by different presence applications, these applications usually must extend the basic PIDF format as defined in [6]. This document sets forth requirements for the definition of elements for representation of SIP specific features within the Presence Information Data Format (PIDF), as well as for guidelines on how to use these new elements with PIDF to represent the capabilities of a SIP User Agent Server. With this extension SIP and SIMPLE based applications can have available richer and more useful content compared to the baseline PIDF data format. Using presence a SIP client may monitor the status of a potential callee and send a request only when the expectation is high that it will be successful. 2. Definitions This document uses the terms as defined in RFC 2778 [3], RFC 3261 [7], CPIM [5], and Callerprefs [8]. Additionally, the following terms are defined and/or additionally clarified: SIP-PRESENCE-EXTENSIONS: A specification satisfying the requirements defined herein. Kyzivat Expires - April 2003 [Page 2]
Requirements for SIP Capabilities in PIDF October 2002 3. Motivation The PIDF document format [6] defines a <contact> element which may appear once inside every <tuple> element. The content of the <contact> element encodes the CONTACT ADDRESS and CONTACT MEANS as defined in [3]. The <contact> element is defined to be an URI. This URI can be of any URI type. In some uses this URI can uniquely identify the application the <tuple> intends to describe (e.g. im: URIs). However, this is not always the case. For instance a SIP URI can represent different kinds of applications. A SIP URI can be used to contact voice applications, video applications, messaging applications, or an application supporting all of these. If it is not known by other means, it is difficult for applications processing the presence document containing only SIP URI contact addresses to know what particular application the <tuple> intends to describe. Also, when a SIP URI designates an application that supports many features such as audio, video, and messaging, a simple basic status of OPEN/CLOSED may be insufficient to represent the dynamic status. For instance, when engaged in an audio call the application may be CLOSED for additional audio calls yet still be OPEN for messaging. 4. How Presence Changes SIP Usage Common usage of SIP encourages a specific relationship between a caller (UAC) and callee (UAS): o The caller knows the callee by a relatively static address called an Address of Record (AOR), and sends requests intended for the callee to this address. o The callee is represented at any particular time by zero or more UAS devices, each with its own, often transient, contact address. o The callee registers, with a registrar, the association between the AOR and the server device addresses. o A proxy server receives a request addressed to the AOR and makes the decision about how to route the request, deciding among potentially several different contact addresses associated with the requested callee's Address of Record. In making this decision the proxy is guided by information provided to it by the callee using Contacts in REGISTER messages, and by information provided by the caller through headers in the message being routed. o The caller may suggest to the proxy preferences about how choices among contacts should be made, encoding the preferences in request headers. Kyzivat Expires - April 2003 [Page 3]
Requirements for SIP Capabilities in PIDF October 2002 o The caller can only determine if the callee is actually available to receive a call by attempting to send a request and observing the result. Presence, when used in conjunction with a SIP Presentity, provides the opportunity for new relationships between caller and callee: o A potential callee reports aspects of its availability to some potential callers. o A potential caller may decide whether to attempt a call based on the availability reported to it by the callee. The caller has an expectation that the likelihood of the call being answered is high when callee is available - much higher than when attempting calls at random. o The callee may present a single consolidated view of availability and associate it with a single AOR. The caller may then decide when to call based on availability, but depends on the proxy for the AOR to route calls to appropriate device(s). o The callee may report the availability separately for different devices, yet associate each with a single common AOR, and depend upon a proxy to route calls to an appropriate device. The caller may then decide when to call based on the availability of a device with suitable availability characteristics, but depends on the proxy for the AOR to route calls to appropriate device. o The callee may report the availability of different devices separately, associating each with address of a specific device. The caller may then decide when to call based on the availability of a device with suitable availability characteristics, and may then direct the call to that device without depending on a proxy to make the desired selection. To summarize, without presence a caller must poll for availability of a callee by sending a request, and determine availability of the callee by success or failure of the request. Using presence a caller may monitor the status of the callee and send a request only when the expectation is high that it will be successful. If specific device addresses are reported in the presence document the caller also has the opportunity to bypass the routing function of the proxy. 5. The Role of Caller Preferences Callerprefs [8] enhances SIP by permitting the callee to associate with each contact a description of what kinds of call features are acceptable, and by permitting the caller to associate with each call Kyzivat Expires - April 2003 [Page 4]
Requirements for SIP Capabilities in PIDF October 2002 a description of the call features desired. This enhances the ability of a proxy to route a call to an appropriate UAS. However, the benefits of callerprefs and presence are not entirely complementary. Presence availability, as encoded by PIDF, is currently limited to a simple OPEN/CLOSED status. Features such as media support cannot be represented. So a presence- aware caller cannot effectively exploit presence to decide when and how to attempt a call, and instead must resort to polling. For instance, the callee may be available, but not for the medium the caller wishes to use, so that an attempt to make a call to the supposedly available callee may fail. This document sets forth requirements for defining extended data elements that may be used in conjunction with the extensibility of PIDF, so that the callee capabilities defined in callerprefs [8] may also be represented in PIDF documents. 6. Requirements 6.1 Use PIDF Without Change SIP-PRESENCE-EXTENSIONS MUST NOT require changes to PIDF. PIDF has provisions for extensibility built in, within the <presence>, <tuple>, and <status> elements. Those are presumed to provide sufficient latitude to fulfill these requirements. 6.2 Represent a Tag-Set Callerprefs defines a new kind of header parameter called a tag-set. SIP-PRESENCE-EXTENSIONS MUST specify a way of representing a tag-set for use in a PIDF document. 6.3 Represent Any Tag Set The definition of tag-set utilizes Feature tag, defined in RFC 2506 [9]. New feature tags may be defined at any time. Also, there is a form of feature tag that requires no registration. In consequence, new feature tags may begin to be used by SIP UAs at any time. It would be unreasonable to require a revision of SIP-PRESENCE- EXTENSIONS or any other standardization activity before a new feature-tag can be used with PIDF. SIP-PRESENCE-EXTENSIONS MUST be capable of representing ANY valid tag-set. Kyzivat Expires - April 2003 [Page 5]
Requirements for SIP Capabilities in PIDF October 2002 6.4 Compatibility with Registration Callerprefs specifies how to express the capabilities of a UAS in a registration, by including one or more tag-sets as Contact parameters. SIP-PRESENCE-EXTENSIONS MUST specify how the capabilities of a UAS, as represented in a registration, may be equivalently represented in a PIDF document. Note there is no intent to require that a PIDF document be compatible with registration û only that it be possible for it to be. Security Considerations This document provides requirements for new content in a PIDF document. Because it permits the incorporation of new information into a PIDF document, that new information is also subject to disclosure when the PIDF document is distributed. All the security considerations of PIDF apply. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. 4 Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. 5 Crocker, D., "Common Presence and Instant Messaging (CPIM)", draft-ietf-impp-cpim-03.txt, August 2002. 6 Sugano, H., Fujimoto, S., Klyne, G. and A. Bateman, "Common Presence and Instant Messaging (CPIM) Presence Information Data Format", draft-ietf-impp-cpim-pidf-05.txt, May 2002. 7 Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Kyzivat Expires - April 2003 [Page 6]
Requirements for SIP Capabilities in PIDF October 2002 8 Rosenberg, J., Schulzrinne, H., "Session Initiation Protocol (SIP) Caller Preferences and Callee Capabilities", draft-ietf-sip- callerprefs-06.txt, July 2002 9 K. Holtman, A. Mutz, T. Hardie, "Media Feature Tag Registration Procedure", RFC 2506, March 1999. Acknowledgments Thanks to Mikko Lonnfors and Krisztian Kiss for consultation and feedback, and for contributions to the introductory and motivational text. Author's Addresses Paul Kyzivat Cisco Systems Mail Stop LWL3/12/2 900 Chelmsford St. Lowell, MA 01851 Email: pkzivat@cisco.com Kyzivat Expires - April 2003 [Page 7]