idnits 2.17.00 (12 Aug 2021) /tmp/idnits32793/draft-ietf-iptel-sip-reg-payload-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == 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 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 76: '... SHOULD send the media types of its ...' RFC 2119 keyword, line 91: '...uded, the server SHOULD return the cur...' RFC 2119 keyword, line 95: '... The server SHOULD NOT return the cu...' RFC 2119 keyword, line 98: '... The server MAY perform validation o...' RFC 2119 keyword, line 99: '...script is not valid, the server SHOULD...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 23, 1999) is 8481 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 292 looks like a reference -- Missing reference section? '2' on line 296 looks like a reference -- Missing reference section? '3' on line 300 looks like a reference -- Missing reference section? '4' on line 304 looks like a reference -- Missing reference section? '5' on line 309 looks like a reference -- Missing reference section? '6' on line 313 looks like a reference -- Missing reference section? '7' on line 317 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force IPTEL WG 3 Internet Draft Lennox/Schulzrinne 4 ietf-iptel-sip-reg-payload-00.txt Columbia University 5 February 23, 1999 6 Expires: September 1999 8 Transporting User Control Information in SIP REGISTER Payloads 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 Abstract 30 Several newly developed languages and interfaces, such as the CPL and 31 SIP CGI, allow users or administrators to specify how Internet 32 telephony servers should process calls. There needs to be a method of 33 transporting scripts for such languages between a client and a 34 server. This document proposes using the payload of SIP REGISTER 35 messages, and their responses, as one method to transport them. 37 1 Introduction 39 Several newly developed languages and interfaces, such as the CPL [1] 40 and SIP CGI [2] allow users or administrators to specify how Internet 41 telephony servers should process calls. Scripts typically can be 42 created on a client, but executed on an Internet telephony server. 44 There therefore needs to be a method of transporting these scripts 45 from a client to a server, and of retrieving them from the server so 46 the client can know the current status or modify the script. This 47 method should integrate cleanly with the existing infrastructure of 48 Internet telephony, without requiring significant additional protocol 49 traffic or complexity in either a client or a server. 51 This document proposes using the payload of SIP [3] REGISTER 52 messages, and their responses, as the media to transport these 53 scripts to SIP registration servers alongside the user's 54 registration. Since clients typically will need to register anyway, 55 and servers will need to have registrars to process the clients' 56 registrations, this technique does not impose much additional 57 overhead on servers and clients. 59 This technique is not appropriate for all environments -- most 60 obviously, it is not useful for H.323 [4] servers -- and we do not 61 anticipate that it will be the only such transport mechanism 62 developed. Other protocols considered have included transporting 63 scripts over LDAP [5], ACAP [6], or HTTP file upload [7], or 64 transport mechanisms developed from scratch. 66 2 Transport Details 68 To upload a script, the registration client places the script in the 69 body of the SIP REGISTER request. Bodies of SIP requests are 70 described in [3]. The Content-Type header field is set to the media 71 type of the submitted script. Currently, we expect to register 72 application/sip-cgi as the content type for SIP CGI scripts, and 73 application/cpl for CPL scripts. 75 To inform a client of what types of scripts it supports, a server 76 SHOULD send the media types of its supported scripts in Accept header 77 fields in the response to any successful OPTIONS or REGISTER request. 79 Allowing the client to restrict transmitted scripts by 80 media type allows clients connected by a low-bandwidth 81 network avoid downloading lengthy scripts. 83 Note: this is against the strict wording of the SIP 84 specification, which says that Accept headers are only 85 allowed in requests or 415 (Unsupported Media Type) 86 responses. However, it is always legal to include a header 87 in any request or response, as clients which do not 88 understand it in a given context simply ignore it. 90 In a successful response to any REGISTER request, whether or not a 91 script payload was included, the server SHOULD return the currently 92 specified script in the response body, with its type specified in 93 Content-Type, unless the REGISTER request included a set of Accept 94 headers which did not include the type of the registration script. 95 The server SHOULD NOT return the currently registered script if 96 response to the registration request was an error condition. 98 The server MAY perform validation on scripts at the time they are 99 uploaded to the server. If the script is not valid, the server SHOULD 100 return a 400-class error to the registration request indicating the 101 problem. It MAY include in the body of the response an explanation 102 of the problem as, for instance, text/html or text/plain , if the 103 client specified such a type in its Accept header. 105 When a script of the same type as an existing script is uploaded, the 106 script is replaced in the server. Which script applies to calls in 107 progress at the time the script was changed is not defined by this 108 document, but MAY be specified by specifications of script languages. 109 If the current or new script affects the handling of REGISTER 110 requests, the registration is handled entirely by the existing 111 script; the new script does not take effect until the registration 112 process is complete. 114 The result of uploading a script of a different type from the one 115 currently registered is undefined; if a client wants to change its 116 script from one type to another, it SHOULD first delete the old 117 script by the method described below, then upload a new one. A server 118 MAY support simultaneous registration of separate scripts of 119 different types. 121 This ambiguity allows a simple server to have a single 122 script per user, while a more complex server might allow 123 users to specify simultaneous CGI and CPL scripts, for 124 example. 126 To delete a script, a client sends a REGISTER message with its 127 Content-Type set to the type of the current script and a Content- 128 Length of 0. If the request specifies a Content-Type other than that 129 of a currently defined script, the behavior is undefined. When a 130 script is deleted, the server SHOULD return to its default call 131 handling behavior for subsequent calls, just as if no script had ever 132 been uploaded. 134 Question: should this technique have a Require header? 135 It's possible someone might use REGISTER bodies for some 136 other purpose. 138 3 Persistence Model 140 Registrations in SIP are normally transient -- the data in the 141 Contact header fields last only for the length of time specified in 142 the registration's Expires header, and clients must refresh their 143 registrations periodically. 145 In contrast, scripts sent to registration servers using the method 146 described in this document are persistent -- they remain in the 147 server until replaced or deleted, and they do not need to be 148 refreshed. Servers SHOULD therefore store uploaded scripts in non- 149 volatile storage so they persist through server restarts or failures. 150 Clients SHOULD only upload scripts when they are explicitly requested 151 to, and SHOULD NOT transmit their scripts in every registration 152 request. 154 The model of standard SIP registrations is that each client 155 registers itself; if a location changes or hosts die, old 156 registrations naturally time out. Since a user can be 157 simultaneously registered from many locations, several 158 clients re-registering periodically present no conflicts. 160 The model of scripts is quite different. A user only has one script 161 (or at least only of a given type) at a time, so if clients 162 periodically re-uploaded scripts, two clients with different 163 specified scripts would cause "script flapping," as the behavior 164 specified in the server changed frequently, with unpredictable and 165 probably surprising behavior. Moreover, one of the most important 166 purposes of scripts is to control the processing of a user's requests 167 when he or she is not registered from any location; if scripts timed 168 out and had to be refreshed, this goal could not be accomplished. 170 4 Examples 172 The first example shows a user uploading a simple call-filtering SIP 173 CGI script written in Perl to his server. Note that he is 174 transmitting both a contact address, which persists only for 30 175 minutes, the time specified by the Expires header, and a script, 176 which persists indefinitely. This allows him subsequently to 177 register new contact addresses and have his script apply equally to 178 them. (See [2] for an explanation of SIP CGI as used in the script.) 180 The use of Basic authorization here is for the purposes of the 181 example only; in actual practice much more robust authentication 182 SHOULD be used. See section 5. 184 REGISTER sip:@sip.example.com SIP/2.0 185 From: Joe User 186 To: "J. User" 187 CSeq: 18 REGISTER 188 Expires: 1800 189 Call-ID: 39485832@joespc.example.com 190 Contact: sip:joe@joespc.example.com 191 Accept: application/sip-cgi, application/sdp, text/html 192 Authorization: Basic am9lOnBhc3N3b3JkAFBX 193 Content-Type: application/sip-cgi 194 Content-Length: 168 196 #!/usr/bin/perl 197 if ($ENV{HTTP_FROM} =~ /telemarketers.com/) { 198 print "SIP/2.0 603 Go awayn" 199 } else { 200 print "CGI-DEFAULT-ACTION dummy SIP/2.0n" 201 } 203 In the second example, a few minutes later, the user registers a new 204 contact address, but does not change his script. In the response to 205 the registration, the server reminds him of his contact addresses and 206 his current script. 208 His client sends this request: 210 REGISTER sip:@sip.example.com SIP/2.0 211 From: Joe User 212 To: "J. User" 213 CSeq: 19 REGISTER 214 Expires: 1800 215 Call-ID: 39485832@joespc.example.com 216 Contact: sip:joe@joeshome.example.com 217 Accept: application/sip-cgi, application/sdp, text/html 218 Authorization: Basic am9lOnBhc3N3b3JkAFBX 219 Content-Length: 0 221 And the server replies with this response: 223 SIP/2.0 200 OK 224 From: Joe User 225 To: "J. User" 226 CSeq: 19 REGISTER 227 Contact: sip:joe@joespc.example.com 228 Contact: sip:joe@joeshome.example.com 229 Accept: application/sip-cgi, application/cpl 230 Content-Type: application/sip-cgi 231 Content-Length: 168 233 #!/usr/bin/perl 234 if ($ENV{HTTP_FROM} =~ /telemarketers.com/) { 235 print "SIP/2.0 603 Go awayn" 236 } else { 237 print "CGI-DEFAULT-ACTION dummy SIP/2.0n" 238 } 240 Finally, the user decides to eliminate his script, and the server 241 responds in the same manner as it would respond to an ordinary 242 registration, as though no script had ever been uploaded: 244 REGISTER sip:@sip.example.com SIP/2.0 245 From: Joe User 246 To: "J. User" 247 CSeq: 20 REGISTER 248 Call-ID: 39485832@joespc.example.com 249 Contact: sip:joe@joeshome.example.com 250 Authorization: Basic am9lOnBhc3N3b3JkAFBX 251 Accept: application/sip-cgi, application/sdp, text/html 252 Content-Type: application/sip-cgi 253 Content-Length: 0 255 SIP/2.0 200 OK 256 From: Joe User 257 To: "J. User" 258 CSeq: 20 REGISTER 259 Contact: sip:joe@joespc.example.com 260 Contact: sip:joe@joeshome.example.com 261 Accept: application/sip-cgi, application/cpl 262 Content-Length: 0 264 5 Security Considerations 265 Since the scripts transported by this mechanism control how a server 266 directs private information intended for a user, the server MUST 267 reject all un-authenticated attempts to submit a script, and SHOULD 268 require that the authentication method used verifies the integrity of 269 the submitted script; for example, by having the entire request, 270 including its body, signed with SIP's PGP authentication method. 272 6 Authors' Addresses 274 Jonathan Lennox 275 Dept. of Computer Science 276 Columbia University 277 1214 Amsterdam Avenue, MC 0401 278 New York, NY 10027 279 USA 280 electronic mail: lennox@cs.columbia.edu 282 Henning Schulzrinne 283 Dept. of Computer Science 284 Columbia University 285 1214 Amsterdam Avenue, MC 0401 286 New York, NY 10027 287 USA 288 electronic mail: schulzrinne@cs.columbia.edu 290 7 Bibliography 292 [1] J. Lennox and H. Schulzrinne, "CPL: A language for user control 293 of internet telephony services," Internet Draft, Internet Engineering 294 Task Force, Feb. 1999. Work in progress. 296 [2] J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common gateway 297 interface for SIP," Internet Draft, Internet Engineering Task Force, 298 Nov. 1998. Work in progress. 300 [3] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 301 session initiation protocol," Internet Draft, Internet Engineering 302 Task Force, Jan. 1999. Work in progress. 304 [4] International Telecommunication Union, "Visual telephone systems 305 and equipment for local area networks which provide a non-guaranteed 306 quality of service," Recommendation H.323, Telecommunication 307 Standardization Sector of ITU, Geneva, Switzerland, May 1996. 309 [5] T. Howes, S. Kille, and M. Wahl, "Lightweight directory access 310 protocol (v3)," Request for Comments (Proposed Standard) 2251, 311 Internet Engineering Task Force, Dec. 1997. 313 [6] J. Myers and C. Newman, "ACAP -- application configuration access 314 protocol," Request for Comments (Proposed Standard) 2244, Internet 315 Engineering Task Force, Dec. 1997. 317 [7] E. Nebel and L. Masinter, "Form-based file upload in HTML," 318 Request for Comments (Experimental) 1867, Internet Engineering Task 319 Force, Nov. 1995. 321 Full Copyright Statement 323 Copyright (c) The Internet Society (1999). All Rights Reserved. 325 This document and translations of it may be copied and furnished to 326 others, and derivative works that comment on or otherwise explain it 327 or assist in its implementation may be prepared, copied, published 328 and distributed, in whole or in part, without restriction of any 329 kind, provided that the above copyright notice and this paragraph are 330 included on all such copies and derivative works. However, this 331 document itself may not be modified in any way, such as by removing 332 the copyright notice or references to the Internet Society or other 333 Internet organizations, except as needed for the purpose of 334 developing Internet standards in which case the procedures for 335 copyrights defined in the Internet Standards process must be 336 followed, or as required to translate it into languages other than 337 English. 339 The limited permissions granted above are perpetual and will not be 340 revoked by the Internet Society or its successors or assigns. 342 This document and the information contained herein is provided on an 343 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 344 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 345 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 346 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 347 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 349 Table of Contents 351 1 Introduction ........................................ 1 352 2 Transport Details ................................... 2 353 3 Persistence Model ................................... 4 354 4 Examples ............................................ 4 355 5 Security Considerations ............................. 6 356 6 Authors' Addresses .................................. 7 357 7 Bibliography ........................................ 7