idnits 2.17.1 draft-donovan-publish-requirements-01.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 167: '... The extension MUST support the abil...' RFC 2119 keyword, line 170: '... The extension MUST support the abil...' RFC 2119 keyword, line 175: '... The extension MUST support the abil...' RFC 2119 keyword, line 180: '... The extension MUST support the abil...' RFC 2119 keyword, line 183: '... The extension MUST support the abil...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (November 21, 2001) is 8191 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) ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Working Group S. Donovan 3 Internet-Draft dynamicsoft 4 Expires: May 22, 2002 November 21, 2001 6 Requirements for Publication of SIP related service data 7 draft-donovan-publish-requirements-01.txt 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. 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. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on May 22, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 This document defines the requirements for a proposed extension to 39 the Session Initiation Protocol [1]. This extension would provide a 40 general-purpose mechanism for uploading service related data. For 41 instance, there is currently the need to upload or publish CPL to SIP 42 Proxies and presence documents to SIP Presence Servers. 44 This document does NOT outline an extension to SIP to handle these 45 requirements. The author is attempting to follow the guidelines that 46 requirements should be defined and agreed to before work on the an 47 extension begins. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Why SIP? . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Why not SIP? . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5.1 Publication Data Requirements . . . . . . . . . . . . . . . . 5 57 5.2 Authentication and Authorization Requirements . . . . . . . . 5 58 5.3 Data Handling Requirements . . . . . . . . . . . . . . . . . . 5 59 5.4 Privacy Requirements . . . . . . . . . . . . . . . . . . . . . 6 60 5.5 Error Cases . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 64 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 This document defines the requirements for a proposed extension to 69 the Session Initiation Protocol [1]. This extension would provide 70 for a general-purpose mechanism for uploading service related data. 71 For instance, there is currently the need to upload or publish CPL to 72 SIP Proxies and presence documents to SIP Presence Servers. 74 Note that CPL is currently uploaded using the SIP REGISTER request. 75 It is thought that the REGISTER request, which was designed 76 specifically for publishing Contacts which are in turn used to 77 control routing of SIP requests, is not sufficiently general purpose 78 to handle the uploading of generic service related data. For 79 instance, there is currently no clean mechanism for reporting on the 80 failure to upload CPL while the registration of Contacts is 81 successful. 83 While this draft proposes that the solution to the requirements 84 outlined in this document should be based on SIP, it is recognized 85 that there is currently no consensus that SIP is the correct protocol 86 to be used for the generic publishing of service related data. If 87 there is consensus that something other than SIP should be used, then 88 the requirements in this document still apply to whatever solution is 89 selected. 91 2. Motivation 93 There are various situations where SIP clients need the ability to 94 supply service related information to SIP servers in order for the 95 services supplied by the SIP servers to operate properly. 97 The following are two well understood examples: 99 o Call Processing Language - Clients load Call Processing Language 100 (CPL) scripts to SIP Proxies. The SIP Proxies then use the CPL 101 scripts to control the routing of subsequent SIP requests. 103 o Presence Documents - Clients load Presence Documents to Presence 104 Servers. The Presence Servers then use the presence documents 105 when notifying watchers of the clients presence state. 107 It is felt that there is the need for a general-purpose mechanism for 108 uploading of SIP service information. Furthermore, it is felt that 109 the SIP REGISTER request is NOT the appropriate mechanism for handing 110 this loading of SIP service information. The semantics of the 111 REGISTER request are tightly coupled with the handling of the 112 contacts contained in the REGISTER request. There is not a clean way 113 to define handling of other service data without also effecting the 114 handling of REGISTERed contacts. 116 3. Why SIP? 118 It is valid to ask why the loading of service data should be defined 119 using the SIP protocol. 121 The primary reason for basing it on SIP is that both of the user's of 122 the information, the SIP client that creates it and the SIP server 123 that consumes it, already have SIP implementations running on them. 124 In addition, it might not be easy to put another protocol engine on 125 these devices, especially SIP phones. 127 The other possible reason to base it on SIP is that there is not 128 necessarily a clear mapping between the address of a SIP server that 129 would handle the publication of a CPL script and the address of 130 another protocol's server. As such, there will be additional 131 configuration complexity in the client associated with the ability to 132 send the message to a different server. 134 It can also be argued that SIP already supports a publication 135 mechanism in the REGISTER request. The only problem is that the 136 REGISTER request is not a general-purpose publication mechanism. So 137 all that is being proposed is a generalization of something that is 138 already in SIP (although this draft does NOT propose deprecating the 139 use of REGISTER for the original purpose of associating contacts with 140 a SIP url). 142 4. Why not SIP? 144 It is fairly easy to model the publication of SIP service information 145 as an HTTP PUT operation. 147 In fact, the draft "Guidelines for Authors of SIP Extensions" [2] 148 explicitly says: 150 "SIP is not a transfer protocol. It is not meant to send large 151 amounts of data unrelated to SIPs operation. It is not meant as a 152 replacement for HTTP..." 154 However, the same draft also says that REGISTER is an exception to 155 this rule, and this draft proposes a generalization of the REGISTER 156 function. In addition, the data being published is clearly related 157 to SIPs operation. This draft does NOT propose that this mechanism 158 apply to any and all uploads of data. 160 5. Requirements 162 This section contains the requirements for the proposed SIP 163 extension. 165 5.1 Publication Data Requirements 167 The extension MUST support the ability to carry arbitrary message 168 bodies, here-after called publication data. 170 The extension MUST support the ability to associate publication data 171 contained in a message body with a service. 173 For instance, presence and cpl are services. 175 The extension MUST support the ability to identify the 176 format/encoding of the publication data. 178 5.2 Authentication and Authorization Requirements 180 The extension MUST support the ability to identify the user to which 181 the publication data applies. 183 The extension MUST support the ability to authenticate the source of 184 the publication requests. 186 The extension MUST support the ability to determine the authorization 187 of the source of the publication request to publish data for the user 188 effected by the publication data. 190 The extension MUST support the ability for the user determined to be 191 the source of the publication request to be different than the user 192 determined to be the target of the publication request. 194 Another way of saying this it that the third party registration 195 concept currently supported for registrations must also be supported 196 for publications. 198 5.3 Data Handling Requirements 200 The extension MUST support the ability to treat the published data as 201 hard state. 203 CPL is an example of data that would be treated as hard state. As 204 such, it should not have an expiration period applied to it and it is 205 kept in place until it is replaced or explicitly removed. 207 The extension MUST support the ability for the server to indicate 208 that a request to store published data as hard state will not be 209 honored. 211 The server might not want to be told to store something forever. It 212 is envisioned that this could be achieved by including an expires 213 timer in the response, much has would be done in the soft state case 214 discussed in the next requirement. 216 The extension MUST support the ability to treat the published data 217 as soft state. As such, the extension MUST support the ability to 218 associate an expiration time with a message body. 220 There are times that a presence document could be considered to be 221 soft state, with the explicit requirement that there is an explicit 222 period of time that the presence document is valid. If this is the 223 case then the presentity publishing the data would be required to 224 refresh the publication in order to keep it in effect. 226 The extension MUST support the ability to query or retrieve 227 publication data associated with a service. 229 The extension MUST support the ability to define a desired action to 230 be taken on the published data. Example actions are replace, remove, 231 append and merge. Each service that uses the publication capability 232 must define the actions that apply to that service. 234 The extension MUST allow for the list of actions to be extensible. 236 Note: It is not clear that the action to be taken should be part of 237 the extension or should be a part of the message body containing the 238 publication data. Making it a part of the message body makes it a 239 service/application specific definition, which might make for a 240 cleaner separation from the publication extension and the service to 241 which the publication is targeted. 243 5.4 Privacy Requirements 245 The extension MUST support the ability to encrypt the publication 246 data. 248 The extension MUST support the ability for the response to 249 unauthorized requests to hide the fact that the source user is not 250 authorized to publish for the target user. 252 It is anticipated that there will be cases where returning a response 253 indicating that the source user is not authorized will supply 254 information about either the server or the target user of the server 255 that could enable attacks on one or the other. As such, it is 256 envisioned that a generic "accepted" response, that can be 257 differentiated from "successful" and "unauthorized", would be useful 258 in this case 260 5.5 Error Cases 262 The extension MUST support the ability to reject the publication 263 request when the contents of the publication data are malformed or 264 erroneous. 266 The extension MUST support the ability to reject the publication 267 request because the source user is not authorized to access the 268 particular service. This rejection should indicate the services that 269 the server supports. 271 The extension MUST support the ability to reject the publication 272 request because the source is not allowed to publish data for the 273 target user. 275 The extension MUST support the ability to reject the publication 276 request because the target user is not known to the server. 278 The extension MUST support the ability to reject the publication 279 because the type of the indicated service is not supported. This 280 rejection should indicate the services that the server supports. 282 The extension MUST support the ability to reject the publication 283 because the type of the data is not supported. This rejection 284 should indicate the services for which publication is allowed. 286 The extension MUST support the ability to reject the publication 287 because the operation (replace, remove, append and merge) is not 288 permitted for the particular service. 290 6. Security Considerations 292 The security considerations are addressed in the Authentication, 293 Authorization and Privacy requirements. 295 References 297 [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 298 "The Session Initiation Protocol", RFC 2543, March 1999. 300 [2] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of SIP 301 Extensions", RFC Guidelines, March 2001. 303 Author's Address 305 Steven R. Donovan 306 dynamicsoft 307 5100 Tennyson Parkway 308 Suite 1200 309 Plano, TX 75024 310 US 312 EMail: sdonovan@dynamicsoft.com 314 Full Copyright Statement 316 Copyright (C) The Internet Society (2001). All Rights Reserved. 318 This document and translations of it may be copied and furnished to 319 others, and derivative works that comment on or otherwise explain it 320 or assist in its implementation may be prepared, copied, published 321 and distributed, in whole or in part, without restriction of any 322 kind, provided that the above copyright notice and this paragraph are 323 included on all such copies and derivative works. However, this 324 document itself may not be modified in any way, such as by removing 325 the copyright notice or references to the Internet Society or other 326 Internet organizations, except as needed for the purpose of 327 developing Internet standards in which case the procedures for 328 copyrights defined in the Internet Standards process must be 329 followed, or as required to translate it into languages other than 330 English. 332 The limited permissions granted above are perpetual and will not be 333 revoked by the Internet Society or its successors or assigns. 335 This document and the information contained herein is provided on an 336 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 337 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 338 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 339 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 340 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 342 Acknowledgement 344 Funding for the RFC Editor function is currently provided by the 345 Internet Society.