idnits 2.17.1 draft-kyzivat-simple-prescaps-reqts-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7863 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 13 looks like a reference -- Missing reference section? '2' on line 42 looks like a reference -- Missing reference section? '3' on line 101 looks like a reference -- Missing reference section? '4' on line 65 looks like a reference -- Missing reference section? '5' on line 90 looks like a reference -- Missing reference section? '6' on line 98 looks like a reference -- Missing reference section? '7' on line 90 looks like a reference -- Missing reference section? '8' on line 209 looks like a reference -- Missing reference section? '9' on line 232 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE 3 Internet Draft P. Kyzivat 4 Document: draft-kyzivat-simple-prescaps-reqts-00.txt Cisco 5 Expires: April 2003 October 2002 7 Requirements for SIP Capabilities in PIDF 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [1]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document sets forth requirements for the definition of elements 32 for representation of SIP specific features within the Presence 33 Information Data Format (PIDF), as well as for guidelines on how to 34 use these new elements with PIDF to represent the capabilities of a 35 SIP User Agent Server. 37 Conventions used in this document 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC-2119 [2]. 43 Table of Contents 45 1. Introduction...................................................2 46 2. Definitions....................................................2 47 3. Motivation.....................................................3 48 4. How Presence Changes SIP Usage.................................3 49 5. The Role of Caller Preferences.................................4 50 6. Requirements...................................................5 51 6.1 Don�t Change PIDF...............Error! Bookmark not defined. 52 6.2 Represent a Tag-Set........................................5 53 6.3 Represent Any Tag Set......................................5 54 6.4 Compatibility with Registration............................6 55 Security Considerations...........................................6 56 References........................................................6 57 Acknowledgments...................................................7 58 Author's Addresses................................................7 60 1. Introduction 62 Interoperation of Instant Messaging and Presence systems has been 63 defined by the IMPP Working Group. That group has also defined a 64 generic model for Presence and Instant Messaging [3] and requirements 65 for protocols implementing such a system [4]. Common Presence and 66 Instant Messaging (CPIM) defines common operations and formats which 67 all Presence and Instant Messaging services must agree upon so that 68 basic interoperability would be possible [5]. The actual base format 69 for presence (PIDF) is being defined in [6]. The PIDF document format 70 standardizes a minimal definition of status. In order to make the 71 PIDF format usable by different presence applications, these 72 applications usually must extend the basic PIDF format as defined in 73 [6]. 75 This document sets forth requirements for the definition of elements 76 for representation of SIP specific features within the Presence 77 Information Data Format (PIDF), as well as for guidelines on how to 78 use these new elements with PIDF to represent the capabilities of a 79 SIP User Agent Server. 81 With this extension SIP and SIMPLE based applications can have 82 available richer and more useful content compared to the baseline 83 PIDF data format. Using presence a SIP client may monitor the status 84 of a potential callee and send a request only when the expectation is 85 high that it will be successful. 87 2. Definitions 89 This document uses the terms as defined in RFC 2778 [3], RFC 3261 90 [7], CPIM [5], and Callerprefs [8]. Additionally, the following terms 91 are defined and/or additionally clarified: 93 SIP-PRESENCE-EXTENSIONS: 94 A specification satisfying the requirements defined herein. 96 3. Motivation 98 The PIDF document format [6] defines a element which may 99 appear once inside every element. The content of the 100 element encodes the CONTACT ADDRESS and CONTACT MEANS as 101 defined in [3]. The element is defined to be an URI. This 102 URI can be of any URI type. In some uses this URI can uniquely 103 identify the application the intends to describe (e.g. im: 104 URIs). However, this is not always the case. For instance a SIP URI 105 can represent different kinds of applications. A SIP URI can be used 106 to contact voice applications, video applications, messaging 107 applications, or an application supporting all of these. If it is not 108 known by other means, it is difficult for applications processing the 109 presence document containing only SIP URI contact addresses to know 110 what particular application the intends to describe. 112 Also, when a SIP URI designates an application that supports many 113 features such as audio, video, and messaging, a simple basic status 114 of OPEN/CLOSED may be insufficient to represent the dynamic status. 115 For instance, when engaged in an audio call the application may be 116 CLOSED for additional audio calls yet still be OPEN for messaging. 118 4. How Presence Changes SIP Usage 120 Common usage of SIP encourages a specific relationship between a 121 caller (UAC) and callee (UAS): 123 o The caller knows the callee by a relatively static address called 124 an Address of Record (AOR), and sends requests intended for the 125 callee to this address. 127 o The callee is represented at any particular time by zero or more 128 UAS devices, each with its own, often transient, contact address. 130 o The callee registers, with a registrar, the association between 131 the AOR and the server device addresses. 133 o A proxy server receives a request addressed to the AOR and makes 134 the decision about how to route the request, deciding among 135 potentially several different contact addresses associated with 136 the requested callee's Address of Record. In making this decision 137 the proxy is guided by information provided to it by the callee 138 using Contacts in REGISTER messages, and by information provided 139 by the caller through headers in the message being routed. 141 o The caller may suggest to the proxy preferences about how choices 142 among contacts should be made, encoding the preferences in request 143 headers. 145 o The caller can only determine if the callee is actually available 146 to receive a call by attempting to send a request and observing 147 the result. 149 Presence, when used in conjunction with a SIP Presentity, provides 150 the opportunity for new relationships between caller and callee: 152 o A potential callee reports aspects of its availability to some 153 potential callers. 155 o A potential caller may decide whether to attempt a call based on 156 the availability reported to it by the callee. The caller has an 157 expectation that the likelihood of the call being answered is high 158 when callee is available - much higher than when attempting calls 159 at random. 161 o The callee may present a single consolidated view of availability 162 and associate it with a single AOR. The caller may then decide 163 when to call based on availability, but depends on the proxy for 164 the AOR to route calls to appropriate device(s). 166 o The callee may report the availability separately for different 167 devices, yet associate each with a single common AOR, and depend 168 upon a proxy to route calls to an appropriate device. The caller 169 may then decide when to call based on the availability of a device 170 with suitable availability characteristics, but depends on the 171 proxy for the AOR to route calls to appropriate device. 173 o The callee may report the availability of different devices 174 separately, associating each with address of a specific device. 175 The caller may then decide when to call based on the availability 176 of a device with suitable availability characteristics, and may 177 then direct the call to that device without depending on a proxy 178 to make the desired selection. 180 To summarize, without presence a caller must poll for availability of 181 a callee by sending a request, and determine availability of the 182 callee by success or failure of the request. Using presence a caller 183 may monitor the status of the callee and send a request only when the 184 expectation is high that it will be successful. If specific device 185 addresses are reported in the presence document the caller also has 186 the opportunity to bypass the routing function of the proxy. 188 5. The Role of Caller Preferences 190 Callerprefs [8] enhances SIP by permitting the callee to associate 191 with each contact a description of what kinds of call features are 192 acceptable, and by permitting the caller to associate with each call 193 a description of the call features desired. This enhances the ability 194 of a proxy to route a call to an appropriate UAS. 196 However, the benefits of callerprefs and presence are not entirely 197 complementary. Presence availability, as encoded by PIDF, is 198 currently limited to a simple OPEN/CLOSED status. 200 Features such as media support cannot be represented. So a presence- 201 aware caller cannot effectively exploit presence to decide when and 202 how to attempt a call, and instead must resort to polling. For 203 instance, the callee may be available, but not for the medium the 204 caller wishes to use, so that an attempt to make a call to the 205 supposedly available callee may fail. 207 This document sets forth requirements for defining extended data 208 elements that may be used in conjunction with the extensibility of 209 PIDF, so that the callee capabilities defined in callerprefs [8] may 210 also be represented in PIDF documents. 212 6. Requirements 214 6.1 Use PIDF Without Change 216 SIP-PRESENCE-EXTENSIONS MUST NOT require changes to PIDF. 218 PIDF has provisions for extensibility built in, within the 219 , , and elements. Those are presumed to 220 provide sufficient latitude to fulfill these requirements. 222 6.2 Represent a Tag-Set 224 Callerprefs defines a new kind of header parameter called a tag-set. 226 SIP-PRESENCE-EXTENSIONS MUST specify a way of representing a tag-set 227 for use in a PIDF document. 229 6.3 Represent Any Tag Set 231 The definition of tag-set utilizes Feature tag, defined in RFC 2506 232 [9]. New feature tags may be defined at any time. Also, there is a 233 form of feature tag that requires no registration. In consequence, 234 new feature tags may begin to be used by SIP UAs at any time. It 235 would be unreasonable to require a revision of SIP-PRESENCE- 236 EXTENSIONS or any other standardization activity before a new 237 feature-tag can be used with PIDF. 239 SIP-PRESENCE-EXTENSIONS MUST be capable of representing ANY valid 240 tag-set. 242 6.4 Compatibility with Registration 244 Callerprefs specifies how to express the capabilities of a UAS in a 245 registration, by including one or more tag-sets as Contact 246 parameters. 248 SIP-PRESENCE-EXTENSIONS MUST specify how the capabilities of a UAS, 249 as represented in a registration, may be equivalently represented in 250 a PIDF document. 252 Note there is no intent to require that a PIDF document be compatible 253 with registration � only that it be possible for it to be. 255 Security Considerations 257 This document provides requirements for new content in a PIDF 258 document. Because it permits the incorporation of new information 259 into a PIDF document, that new information is also subject to 260 disclosure when the PIDF document is distributed. All the security 261 considerations of PIDF apply. 263 References 265 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 266 9, RFC 2026, October 1996. 268 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 269 Levels", BCP 14, RFC 2119, March 1997 271 3 Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 272 Instant Messaging", RFC 2778, February 2000. 274 4 Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant Messaging 275 / Presence Protocol Requirements", RFC 2779, February 2000. 277 5 Crocker, D., "Common Presence and Instant Messaging (CPIM)", 278 draft-ietf-impp-cpim-03.txt, August 2002. 280 6 Sugano, H., Fujimoto, S., Klyne, G. and A. Bateman, "Common 281 Presence and Instant Messaging (CPIM) Presence Information Data 282 Format", draft-ietf-impp-cpim-pidf-05.txt, May 2002. 284 7 Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 285 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 286 Session Initiation Protocol", RFC 3261, June 2002. 288 8 Rosenberg, J., Schulzrinne, H., "Session Initiation Protocol (SIP) 289 Caller Preferences and Callee Capabilities", draft-ietf-sip- 290 callerprefs-06.txt, July 2002 292 9 K. Holtman, A. Mutz, T. Hardie, "Media Feature Tag Registration 293 Procedure", RFC 2506, March 1999. 295 Acknowledgments 297 Thanks to Mikko Lonnfors and Krisztian Kiss for consultation and 298 feedback, and for contributions to the introductory and motivational 299 text. 301 Author's Addresses 303 Paul Kyzivat 304 Cisco Systems 305 Mail Stop LWL3/12/2 306 900 Chelmsford St. 307 Lowell, MA 01851 308 Email: pkzivat@cisco.com