idnits 2.17.00 (12 Aug 2021) /tmp/idnits28023/draft-lennox-sip-reg-payload-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** 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 143: '... "store" MUST be given. The action "...' RFC 2119 keyword, line 151: '...his header field MUST be included in t...' RFC 2119 keyword, line 180: '...ified in this field, the server SHOULD...' RFC 2119 keyword, line 185: '... the server MUST NOT perform the req...' RFC 2119 keyword, line 203: '...-Since header field SHOULD be ignored....' (42 more instances...) 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 31, 2000) is 7865 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 637 looks like a reference -- Missing reference section? '2' on line 641 looks like a reference -- Missing reference section? '3' on line 645 looks like a reference -- Missing reference section? '4' on line 649 looks like a reference -- Missing reference section? '5' on line 653 looks like a reference -- Missing reference section? '6' on line 657 looks like a reference -- Missing reference section? '7' on line 661 looks like a reference -- Missing reference section? '8' on line 665 looks like a reference -- Missing reference section? '9' on line 669 looks like a reference -- Missing reference section? '10' on line 674 looks like a reference -- Missing reference section? '11' on line 678 looks like a reference -- Missing reference section? '12' on line 682 looks like a reference -- Missing reference section? '13' on line 687 looks like a reference -- Missing reference section? '14' on line 692 looks like a reference -- Missing reference section? '15' on line 695 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Individual Submission 3 Internet Draft Lennox/Schulzrinne 4 draft-lennox-sip-reg-payload-01.txt Columbia University 5 October 31, 2000 6 Expires: April 2001 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 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Abstract 33 Several newly developed languages and interfaces, such as the CPL and 34 SIP CGI, allow users or administrators to specify how a SIP proxy and 35 redirect server should process calls. This document defines how SIP 36 REGISTER requests and responses can be used to transport scripts 37 between user agents and SIP proxy and redirect servers. 39 1 Introduction 41 Several newly developed languages and interfaces, such as the CPL [1] 42 and SIP CGI [2] allow users or administrators to specify how Internet 43 telephony servers should process calls. Scripts typically can be 44 created on a client, but executed on an Internet telephony server. 46 There therefore needs to be a method of transporting these scripts 47 from a client to a server, and of retrieving them from the server so 48 the client can know the current status or modify the script. This 49 method should integrate cleanly with the existing infrastructure of 50 Internet telephony, without requiring significant additional protocol 51 traffic or complexity in either a client or a server. 53 This document defines how the payload of SIP [3] REGISTER messages, 54 and their responses, can be used to transport these scripts to SIP 55 registration servers alongside the user's registration. Since 56 clients typically will need to register anyway, and servers will need 57 to have registrars to process the clients' registrations, this 58 technique does not impose much additional overhead on servers and 59 clients. 61 This technique is not appropriate for all environments -- most 62 obviously, it is not useful for H.323 [4] servers -- and we do not 63 anticipate that it will be the only such transport mechanism 64 developed. Other protocols considered have included transporting 65 scripts over LDAP [5], ACAP [6], or HTTP file upload [7], or 66 transport mechanisms developed from scratch. 68 The advantages of this technique, over these other possible methods 69 for transfering scripts to a registration server, are twofold. First 70 of all, a SIP client already needs to know the registrar and 71 addresses to use in order to register a Contact location. Re-using 72 this registration infrastructure makes it trivial to know the 73 location to which a script should be sent. Other methods would 74 require some correlation mechanism, or additional configuration 75 options -- a client would need to be told what HTTP server (for 76 example) to use, in addition to knowing its SIP registrar. 78 Additionally, using this mechanism small SIP end systems can send and 79 retrieve scripts without needing to implement additional protocols. 80 Small embedded end systems are common for SIP; whereas parallel 81 protocols would impose significant additional complexity in these 82 devices, the mechanism described in this document requires very 83 little of these devices over and above the base SIP specification. 85 2 Conventions Of This Document 87 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 88 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 89 and "OPTIONAL" are to be interpreted as described in RFC 2119 [8] and 90 indicate requirement levels for compliant implementations of SIP 91 register payload script uploading. 93 Some paragraphs are indented, like this; they give 94 motivations of design choices, or questions for future 95 discussion in the development of the specification. They 96 are not normative to the specification of the protocol. 98 3 Header Field Definitions 100 Script uploading borrows a number of header fields from HTTP and 101 related MIME protocols. This section defines these extended headers. 103 3.1 Content-Disposition 105 The Content-Disposition header field is defined in RFC 2183 [9]. It 106 has also been added to SIP in the work-in-progress revised SIP 107 specification "2543bis" [10]. In REGISTER requests or responses, this 108 header field is used to describe the intended purpose of a message 109 body. The grammar of this header field is as follows: 111 Content-Disposition = "Content-Disposition" ":" 112 disposition-type *( ";" disposition-param ) 113 disposition-type = "script" | "sip-cgi" | token 114 disposition-param = action-param 115 | modification-date-param 116 | generic-param 117 action-param = "action" "=" action-value 118 action-value = "store" | "remove" | token 119 modification-date-param = "modification-date" "=" quoted-date-time 120 quoted-date-time = <"> SIP-date <"> 122 The grammar symbols "token" and "generic-param" are defined in RFC 123 2543 [3]. 125 The Content-Disposition header field serves to describe the purpose 126 of the message body. The disposition type describes the purpose of 127 the material contained in the body of the message. Currently, two 128 disposition types are defined. The type "script" indicates a CPL 129 script or a similar scripting environment whose use in a SIP server 130 can be uniquely determined by its media type. The type "sip-cgi" 131 refers to SIP CGI scripts, which can be any media type executable on 132 the server platform. Additional types can be registered with IANA 133 through the procedure defined in RFC 2183 [9]. 135 The Content-Type of the uploaded payload is not sufficient 136 to describe the purpose of the payload to the server. A 137 script with a given purpose could, conceivably, be of any 138 of a large number of media types, particularly for SIP CGI. 140 The action parameter to the header field is used when uploading 141 scripts, to specify what the server should do with the script 142 uploaded. If a non-zero-length script is specified, the action 143 "store" MUST be given. The action "remove" MUST only be used when 144 accompanied by a zero-length body. 146 The modification-date parameter is used to indicate the time when the 147 script was last modified. This is used for versioning, to prevent 148 potential race conditions (see Sections 4 and 7). 150 If multipart MIME types [11] are used to indicate several distinct 151 scripts (see Section 4.2), this header field MUST be included in the 152 MIME part header, not in the general SIP header. 154 3.2 Accept-Disposition 156 The Accept-Disposition header field is used to indicate what content 157 disposition types are acceptable to a client or server. 159 Accept-Disposition = "Accept-Disposition" ":" 160 #( (disposition-type | "*") 161 *( ";" generic-param ) ) 163 The special meta-type "*" matches every content disposition type, and 164 indicates that any content disposition is acceptable. 166 The action and modification-date parameters are not meaningful for 167 Accept-Disposition. 169 The Accept-Disposition header field is not currently 170 defined by any other published document as far as we know, 171 but it is a natural counterpart to Content-Disposition. (In 172 general, most Content-* header fields have corresponding 173 Accept-* fields.) 175 3.3 If-Unmodified-Since 177 The If-Unmodified-Since request header field is defined in section 178 14.28 of the HTTP/1.1 specification, RFC 2616 [12]. It is used to 179 make a request conditional. If the requested resource has not been 180 modified since the time specified in this field, the server SHOULD 181 perform the requested operation as if the If-Unmodified-Since header 182 field were not present. 184 If the requested resource has been modified since the specified time, 185 the server MUST NOT perform the requested operation, and MUST return 186 412 Precondition Failed. 188 Specifically, for register bodies, this header field is used to 189 indicate that the client does not want the provided content to be 190 stored if the corresponding content has been modified on the server 191 since the given time. 193 The syntax of this header field is as follows: 195 If-Unmodified-Since = "If-Unmodified-Since" ":" SIP-date 197 An example of this field is: 199 If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT 201 If the request normally (i.e., without the If-Unmodified-Since 202 header) would result in anything other than a 2xx or 412 status, the 203 If-Unmodified-Since header field SHOULD be ignored. 205 If the specified date is invalid, the header field is ignored. 207 4 Transport Details 209 This section describes the procedures by which scripts are uploaded 210 to a server, and retrieved from it. 212 4.1 Script Upload and Removal 214 To upload a script, the registration client places the script in the 215 body of the SIP REGISTER request. Bodies of SIP requests are 216 described in [3]. The Content-Type header field is set to the media 217 type of the submitted script. The MIME type application/cpl+xml 218 designates CPL scripts. Clients SHOULD upload SIP CGI scripts as an 219 appropriate media type for the language the script is written in (for 220 example, application/x-perl), or application/octet-stream if no such 221 media type exists or is known. Registrars MAY perform validation on 222 the media types if they know certain types of scripts cannot be 223 executed on their servers, but SHOULD be permissive about unknown or 224 ambiguous media types for SIP CGI scripts. 226 Which types of SIP CGI scripts can be successfully run on a 227 server depends on the server's environment, including which 228 scripting languages are installed on it. It is possible 229 that the user has more knowledge of this environment than 230 the server. 232 Script uploads MUST also be accompanied by a Content-Disposition 233 header field (see Section 3.1) describing the purpose of the message 234 body. This header field MUST have an action parameter indicating 235 whether the script is to be stored or removed, and MAY have a 236 modification-date parameter giving a timestamp for the script. 238 A script registrar's normal behavior is to enter the script in its 239 database, as specified in section 5, associated with the user in the 240 To field of the REGISTER message. However, if a zero-length script is 241 submitted with the action remove, any existing script of the user's 242 with the given disposition type is instead deleted from the database. 244 Note that having a zero-length script, and not having any 245 script, are quite distinct conditions, and both are legal. 247 A script registrar MAY choose to add contents with an unknown 248 disposition type and an action=store parameter to its script 249 database. (In this case it SHOULD include a "*" field in Accept- 250 Disposition headers that it sends -- see Section 4.2.) It MAY 251 alternately reject a script with an unknown disposition type with a 252 4xx response. 254 We anticipate that the mechanism described in this 255 specification can also be used for purposes such as users' 256 speed-dial lists or device configuration files, and that 257 new disposition types would be registered for these. 259 To delete a script, a client sends a REGISTER message with its 260 Content-Disposition header field with an the appropriate type and a 261 action parameter of "remove", and a Content-Length header field of 0. 262 If there is no script defined with the specified purpose, this 263 message does nothing. When a script is deleted, the server SHOULD 264 return to its default behavior, just as if no script had ever been 265 uploaded. 267 A client MAY include an If-Unmodified-Since header field (see Section 268 3.3) to indicate that the uploaded script should only be accepted if 269 the script on the server has not been modified since the given date. 270 This is typically used if a client has downloaded a script (see 271 Section 4.2), modified it, and wishes to upload the modified script; 272 the If-Unmodified-Since header field guarantees that the script has 273 not in the meantime been modified by any other client. 275 The server MAY perform syntactic and semantic validation on scripts 276 at the time they are uploaded to the server. If the script is not 277 valid, the server SHOULD return a 400-class error to the registration 278 request indicating the problem. It MAY include in the body of the 279 response an explanation of why the script was considered invalid, if 280 the registration included an Accept header field with an appropriate 281 media type for such an explanation (such as text/html or text/plain). 283 When a script with the same disposition type as an existing script is 284 successfully uploaded for a given user, the previous script is 285 replaced in the server. Scripts with different disposition types are 286 stored and deleted independently. 288 How scripts interact with calls on the server is not defined by this 289 document. In particular, which script applies to calls in progress at 290 the time a script is added, changed or deleted is not defined by this 291 document, but MAY be defined by specifications of script languages. 292 However, if a current or new script affects the handling of REGISTER 293 requests, the upload process SHOULD be handled entirely by the 294 existing script; the new script does not take effect until the upload 295 process has completed. 297 The entity which executes the user's script -- i.e., a proxy or 298 redirect server -- needs to have access to the uploaded scripts. This 299 document does not specify how this is done; typically, the registrar 300 and proxy server are co-located. There normally will be a way for a 301 registrar to pass information to an appropriate proxy server; normal 302 SIP information such as registered Contact locations needs to be 303 passed in order for a registrar to be useful. 305 Though the storage of scripts with different disposition types is 306 independent, a server MAY choose not to execute some scripts if 307 scripts with another disposition are present, for instance only 308 executing one of a CPL and SIP CGI script. 310 If a script upload fails for any reason (including a validation 311 failure, or an unsatisfied If-Unmodified-Since header), the script 312 server MUST NOT perform any other actions associated with a 313 successful REGISTER request, such as entering Contact headers in the 314 registration database. 316 A client MAY also include in the upload request an Accept-Disposition 317 header field listing disposition types it wants to receive in its 318 response. (See Section 4.2.) 320 4.2 Server Response 322 In a successful response to any REGISTER request, whether or not a 323 script payload was included, the server SHOULD return the currently 324 stored scripts in the body of the response, unless the client 325 requested otherwise. 327 If the request contained an Accept header, the server SHOULD NOT 328 return any scripts whose media types do not match that header. 329 Similarly, if the request contained an Accept-Disposition header, the 330 server SHOULD NOT return scripts whose disposition types do not match 331 that header. 333 Empty headers are legal for both the Accept and Accept-Disposition 334 headers. (Grammatically, they are "#", not "1#".) If a client does 335 not want to receive any scripts in response to a registration, it 336 SHOULD include an empty Accept-Disposition header field in its 337 REGISTER request. Servers SHOULD correctly honor empty Accept headers 338 as well, but these are less likely to be useful for clients. 340 If multiple scripts are registered and match the Accept and Accept- 341 Disposition headers, the server SHOULD return all of them in a 342 multipart content if and only if the client included an appropriate 343 multipart/* media type in its Accept header. Otherwise, the server 344 MAY select any of the matching registered scripts to return. A 345 client which cannot accept a multipart media type SHOULD NOT include 346 multiple Accept-Disposition headers in its request. 348 Each returned script MUST have its media type specified by a 349 Content-Type header, and its disposition type by a Content- 350 Disposition header. The Content-Disposition header field SHOULD 351 include the modification-date parameter indicating the time the 352 script was modified. This header field SHOULD NOT include an action 353 parameter, as the server is not requesting that the client perform 354 any actions. 356 The server SHOULD NOT return any registered scripts if the response 357 to the registration request was an error condition. 359 To inform a client of what types of scripts it supports, a server 360 SHOULD include Accept and Accept-Disposition headers in any response 361 to a registration, response to an OPTIONS request directed at the 362 registrar request, and any response which rejected a registration on 363 the grounds of an unsupported disposition or media type. A server 364 which accepts arbitrary disposition types SHOULD include the wildcard 365 disposition pattern "*" in its Accept-Disposition header. 367 Note: Including Accept headers in arbitrary REGISTER 368 responses is against the strict wording of RFC 2543 [3], 369 which says that Accept headers are only allowed in requests 370 or 415 (Unsupported Media Type) responses. However, it is 371 always legal to include a header field in any request or 372 response, as clients which do not understand it in a given 373 context simply ignore it. The work-in-progress revised SIP 374 specification [10] allows this usage. 376 5 Persistence Model 378 Registrations in SIP are normally transient -- the data in the 379 Contact header fields last only for the length of time specified in 380 the registration's Expires header, and clients must refresh their 381 registrations periodically. 383 In contrast, scripts sent to registration servers using the method 384 described in this document are persistent -- they remain in the 385 server until replaced or deleted, and they do not need to be 386 refreshed. Servers SHOULD therefore store uploaded scripts in non- 387 volatile storage so they persist through server restarts or failures. 388 Clients SHOULD only upload scripts when they are explicitly requested 389 to, and SHOULD NOT transmit their scripts in every registration 390 request. 392 The model of standard SIP registrations is that each client 393 registers itself; if a location changes or hosts die, old 394 registrations naturally time out. Since a user can be 395 simultaneously registered from many locations, several 396 clients re-registering periodically present no conflicts. 398 The model of scripts is quite different. A user only has one script 399 (or at least only of a given type) at a time, so if clients 400 periodically re-uploaded scripts, two clients with different 401 specified scripts would cause "script flapping," as the behavior 402 specified in the server changed frequently, with unpredictable and 403 probably surprising behavior. Moreover, one of the most important 404 purposes of scripts is to control the processing of a user's requests 405 when he or she is not registered from any location; if scripts timed 406 out and had to be refreshed, this goal could not be accomplished. 408 6 Examples 409 The first example shows a user uploading a simple call-filtering SIP 410 CGI script written in Perl to his server. Note that he is 411 transmitting both a contact address, which persists only for 30 412 minutes, the time specified by the Expires header, and a script, 413 which persists indefinitely. This allows him subsequently to 414 register new contact addresses and have his script apply equally to 415 them. (See [2] for an explanation of SIP CGI as used in the script.) 417 The use of Basic authorization here is for the purposes of the 418 example only; in actual practice much more robust authentication 419 SHOULD be used. See section 8. 421 REGISTER sip:sip.example.com SIP/2.0 422 From: Joe User 423 To: Joe User 424 CSeq: 18 REGISTER 425 Expires: 1800 426 Call-ID: 39485832@joespc.example.com 427 Contact: sip:joe@joespc.example.com 428 Accept: application/x-perl, application/sdp, text/html 429 Accept-Disposition: sip-cgi 430 Authorization: Basic am9lOnBhc3N3b3JkAFBX 431 Content-Type: application/x-perl 432 Content-Length: 137 433 Content-Disposition: sip-cgi; action=store 435 #!/usr/bin/perl 436 if ($ENV{HTTP_FROM} =~ /telemarketers.com/) { 437 print "SIP/2.0 603 Go away\n" 438 } else { 439 exit(0); # Default action 440 } 442 In the second example, a few minutes later, the user registers a new 443 contact address, but does not change his script. In the response to 444 the registration, the server reminds him of his contact addresses and 445 his current script. 447 His client sends this request: 449 REGISTER sip:sip.example.com SIP/2.0 450 From: Joe User 451 To: Joe User 452 CSeq: 19 REGISTER 453 Expires: 1800 454 Call-ID: 39485832@joespc.example.com 455 Contact: sip:joe@joeshome.example.com 456 Accept: application/x-perl, application/sdp, text/html 457 Accept-Disposition: sip-cgi 458 Authorization: Basic am9lOnBhc3N3b3JkAFBX 459 Content-Length: 0 461 And the server replies with this response: 463 SIP/2.0 200 OK 464 From: Joe User 465 To: Joe User 466 CSeq: 19 REGISTER 467 Contact: sip:joe@joespc.example.com 468 Contact: sip:joe@joeshome.example.com 469 Accept: application/cpl+xml, */* 470 Accept-Disposition: script, sip-cgi 471 Content-Type: application/x-perl 472 Content-Disposition: sip-cgi; 473 modification-date="Wed, 25 Oct 2000 21:21:54 GMT" 474 Content-Length: 137 476 #!/usr/bin/perl 477 if ($ENV{HTTP_FROM} =~ /telemarketers.com/) { 478 print "SIP/2.0 603 Go away\n" 479 } else { 480 exit(0); # Default action 481 } 483 Finally, the user decides to eliminate his script, and the server 484 responds in the same manner as it would respond to an ordinary 485 registration, as though no script had ever been uploaded: 487 REGISTER sip:sip.example.com SIP/2.0 488 From: Joe User 489 To: Joe User 490 CSeq: 20 REGISTER 491 Call-ID: 39485832@joespc.example.com 492 Contact: sip:joe@joeshome.example.com 493 Authorization: Basic am9lOnBhc3N3b3JkAFBX 494 Accept: application/x-perl, application/sdp, text/html 495 Content-Length: 0 496 Content-Disposition: sip-cgi; action=remove 498 SIP/2.0 200 OK 499 From: Joe User 500 To: Joe User 501 CSeq: 20 REGISTER 502 Contact: sip:joe@joespc.example.com 503 Contact: sip:joe@joeshome.example.com 504 Accept: application/cpl+xml, */* 505 Accept-Disposition: script, sip-cgi 506 Content-Length: 0 508 7 Usage Notes 510 Because scripts can be long, clients which upload scripts, or which 511 present an Accept header field which could cause scripts to be 512 returned, SHOULD send their REGISTER messages over TCP rather than 513 UDP. 515 A user agent which downloads a script to allow a user to edit it, and 516 then re-uploads the script once the editing is complete, SHOULD 517 include a If-Unmodified-Since header field in the re-uploading 518 process with a value equal to the downloaded script's modification- 519 date. This guarantees that the script has not been modified by any 520 other user agent since it was downloaded. 522 8 Security Considerations 524 Scripts transported by this mechanism can control how a server 525 processes private information intended for a user. Therefore, a 526 server MUST reject all un-authenticated attempts to submit, alter, or 527 delete a script. It is very strongly RECOMMENDED that that the 528 server require an authentication method which verifies the integrity 529 of the submitted script, to prevent an attacker from replaying a 530 script submission with a different script body. Examples of such 531 authentication methods are Digest authentication [13] with the 532 quality of protection "auth-int", and SIP's PGP authentication. 533 Alternately, transport or network-layer authentication and integrity 534 verification (TLS [14] or IPSec [15]) can be used between the client 535 and server. 537 It is also RECOMMENDED that a server authenticate and provide 538 integrity verification of the scripts it returns. PGP, transport- 539 layer and network-layer authentication accomplish this as well. 541 It may be possible to use Digest authentication for 542 server-to-client authentication, but it is not clear how 543 nonce handling would work. 545 9 IANA Considerations 547 The process for registering new Content-Disposition values and 548 parameters is given in RFC 2183 [9]. 550 This document defines two new Content-Disposition values, "script" 551 and "sip-cgi", and one new parameter, "action", which can have the 552 value "store" or "remove". 554 10 Changes From Earlier Versions 556 10.1 Changes From Draft -00 558 The changebars in the Postscript and PDF versions of this document 559 indicate significant changes from this version. 561 o Improved wording in abstract and introduction: this is a 562 specification, not a proposal. It also applies only to SIP. 564 o Added wording to the introduction motivating the use of this 565 specification rather than the other possitiblities. 567 o Changed to using the Content-Disposition header, to be in line 568 with rfc2543bis and HTTP. Eliminated Content-Purpose and 569 Content-Action in favor of the new header. 571 o Added a paragraph motivating the separation of Content- 572 Disposition types from media types. 574 o Added Accept-Disposition header. 576 o Added If-Unmodified-Since header. 578 o Separated description of header syntax from upload and 579 download procedures. 581 o Clarified that scripts are per-user, and associated with the 582 user in the To header. 584 o Clarified that the model is that proxy servers have access to 585 the registered scripts. 587 o Added usage note that user agents which support download- 588 edit-upload functionality should use the If-Unmodified-Since 589 header to prevent race conditions. 591 o Expanded upon the security considerations. Added mention of 592 qop=auth-int. 594 10.2 Changes From IPTel Draft -00 596 This document was originally published as draft-iptel-sip-reg- 597 payload-00, but the consensus of the IPTel working group was that 598 this should not be a work item of that group. 600 o Added Content-Purpose and Content-Action headers. 602 o Changed the procedure by which scripts are deleted. 604 o Eliminated the pseudo-media-type application/sip-cgi, as it is 605 counter to the spirit of MIME. Instead, established that SIP 606 CGI scripts can be any media type. 608 o Added "Conventions," "Usage Notes," and "IANA Considerations" 609 sections. 611 o Updated examples to use the syntax of the current version of 612 SIP CGI. 614 o Updated references to refer to the latest versions of all 615 documents. 617 11 Authors' Addresses 619 Jonathan Lennox 620 Dept. of Computer Science 621 Columbia University 622 1214 Amsterdam Avenue, MC 0401 623 New York, NY 10027 624 USA 625 electronic mail: lennox@cs.columbia.edu 627 Henning Schulzrinne 628 Dept. of Computer Science 629 Columbia University 630 1214 Amsterdam Avenue, MC 0401 631 New York, NY 10027 632 USA 633 electronic mail: schulzrinne@cs.columbia.edu 635 12 Bibliography 637 [1] J. Lennox and H. Schulzrinne, "CPL: a language for user control 638 of internet telephony services," Internet Draft, Internet Engineering 639 Task Force, Mar. 1999. Work in progress. 641 [2] J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common gateway 642 interface for SIP," Internet Draft, Internet Engineering Task Force, 643 June 2000. Work in progress. 645 [3] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 646 session initiation protocol," Request for Comments 2543, Internet 647 Engineering Task Force, Mar. 1999. 649 [4] International Telecommunication Union, "Packet based multimedia 650 communication systems," Recommendation H.323, Telecommunication 651 Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998. 653 [5] M. Wahl, T. Howes, and S. Kille, "Lightweight directory access 654 protocol (v3)," Request for Comments 2251, Internet Engineering Task 655 Force, Dec. 1997. 657 [6] C. Newman and J. G. Myers, "ACAP -- application configuration 658 access protocol," Request for Comments 2244, Internet Engineering 659 Task Force, Nov. 1997. 661 [7] E. Nebel and L. Masinter, "Form-based file upload in HTML," 662 Request for Comments 1867, Internet Engineering Task Force, Nov. 663 1995. 665 [8] S. Bradner, "Key words for use in RFCs to indicate requirement 666 levels," Request for Comments 2119, Internet Engineering Task Force, 667 Mar. 1997. 669 [9] R. Troost, S. Dorner, and K. Moore, "Communicating presentation 670 information in internet messages: The content-disposition header 671 field," Request for Comments 2183, Internet Engineering Task Force, 672 Aug. 1997. 674 [10] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 675 Session initiation protocol," Internet Draft, Internet Engineering 676 Task Force, Aug. 2000. Work in progress. 678 [11] N. Freed and N. Borenstein, "Multipurpose internet mail 679 extensions (MIME) part two: Media types," Request for Comments 2046, 680 Internet Engineering Task Force, Nov. 1996. 682 [12] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 683 Leach, and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," 684 Request for Comments 2616, Internet Engineering Task Force, June 685 1999. 687 [13] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, 688 A. Luotonen, and L. Stewart, "HTTP authentication: Basic and digest 689 access authentication," Request for Comments 2617, Internet 690 Engineering Task Force, June 1999. 692 [14] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request 693 for Comments 2246, Internet Engineering Task Force, Jan. 1999. 695 [15] S. Kent and R. Atkinson, "Security architecture for the internet 696 protocol," Request for Comments 2401, Internet Engineering Task 697 Force, Nov. 1998. 699 Full Copyright Statement 701 Copyright (c) The Internet Society (2000). All Rights Reserved. 703 This document and translations of it may be copied and furnished to 704 others, and derivative works that comment on or otherwise explain it 705 or assist in its implementation may be prepared, copied, published 706 and distributed, in whole or in part, without restriction of any 707 kind, provided that the above copyright notice and this paragraph are 708 included on all such copies and derivative works. However, this 709 document itself may not be modified in any way, such as by removing 710 the copyright notice or references to the Internet Society or other 711 Internet organizations, except as needed for the purpose of 712 developing Internet standards in which case the procedures for 713 copyrights defined in the Internet Standards process must be 714 followed, or as required to translate it into languages other than 715 English. 717 The limited permissions granted above are perpetual and will not be 718 revoked by the Internet Society or its successors or assigns. 720 This document and the information contained herein is provided on an 721 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 722 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 723 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 724 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 725 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 727 Table of Contents 729 1 Introduction ........................................ 1 730 2 Conventions Of This Document ........................ 2 731 3 Header Field Definitions ............................ 3 732 3.1 Content-Disposition ................................. 3 733 3.2 Accept-Disposition .................................. 4 734 3.3 If-Unmodified-Since ................................. 4 735 4 Transport Details ................................... 5 736 4.1 Script Upload and Removal ........................... 5 737 4.2 Server Response ..................................... 8 738 5 Persistence Model ................................... 9 739 6 Examples ............................................ 9 740 7 Usage Notes ......................................... 12 741 8 Security Considerations ............................. 12 742 9 IANA Considerations ................................. 13 743 10 Changes From Earlier Versions ....................... 13 744 10.1 Changes From Draft -00 .............................. 13 745 10.2 Changes From IPTel Draft -00 ........................ 14 746 11 Authors' Addresses .................................. 14 747 12 Bibliography ........................................ 15