idnits 2.17.1 draft-ietf-sip-join-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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 329 has weird spacing: '...r field whe...' -- 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 (March 3, 2003) is 7717 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 2234 (ref. '3') (Obsoleted by RFC 4234) == Outdated reference: A later version (-05) exists of draft-ietf-sip-replaces-02 -- Obsolete informational reference (is this intentional?): RFC 2543 (ref. '6') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-framework-01 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialog-package-00 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-3pcc-02 == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-03 -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '14') (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 2976 (ref. '15') (Obsoleted by RFC 6086) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG R. Mahy 3 Internet-Draft Cisco Systems, Inc. 4 Expires: September 1, 2003 D. Petrie 5 Pingtel 6 March 3, 2003 8 The Session Inititation Protocol (SIP) "Join" Header 9 draft-ietf-sip-join-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-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 http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 1, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document defines a new header for use with SIP multi-party 40 applications and call control. The Join header is used to logically 41 join an existing SIP dialog with a new SIP dialog. This primitive 42 can be used to enable a variety of features, for example: "Barge-In", 43 answering-machine-style "Message Screening" and "Call Center 44 Monitoring". Note that definition of these example features is 45 non-normative. 47 Table of Contents 49 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Applicability of RFC2804 ("Raven") . . . . . . . . . . . . . 4 52 4. User Agent Server Behavior: Receiving a Join Header . . . . 5 53 5. User Agent Client Behavior: Sending a Join header . . . . . 7 54 6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . 7 55 7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 7.1 The Join Header . . . . . . . . . . . . . . . . . . . . . . 8 57 7.2 New option tag for Require and Supported headers . . . . . . 9 58 8. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 9 59 8.1 Join accepted and transitioned to central mixer . . . . . . 10 60 8.2 Join rejected . . . . . . . . . . . . . . . . . . . . . . . 11 61 9. Security Considerations . . . . . . . . . . . . . . . . . . 11 62 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 63 10.1 Registration of "Join" SIP header . . . . . . . . . . . . . 12 64 10.2 Registration of "join" SIP Option-tag . . . . . . . . . . . 12 65 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 11.1 Changes Since draft-ietf-sip-join-00 . . . . . . . . . . . . 12 67 11.2 Changes Since draft-mahy-join-and-fork-01 . . . . . . . . . 12 68 11.3 Changes Since -00 . . . . . . . . . . . . . . . . . . . . . 13 69 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 70 Normative References . . . . . . . . . . . . . . . . . . . . 13 71 Informational References . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 73 Intellectual Property and Copyright Statements . . . . . . . 16 75 1. Conventions 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC-2119 [2]. 81 This document refers frequently to the terms "confirmed dialog" and 82 "early dialog". These are defined in Section 12 of SIP [1]. 84 2. Overview 86 This document describes a SIP [1] extension header field as part of 87 the SIP multiparty applications architecture framework [7]. The Join 88 header is used to logically join an existing SIP dialog with a new 89 SIP dialog. This is especially useful in peer-to-peer call control 90 environments. 92 One use of the "Join" header is to insert a new participant into a 93 multimedia conversation (which may a two-party call or a conference). 94 While this functionality is already available using 3rd party call 95 control [11] style call control, the 3pcc model requires a central 96 point of control which may not be desirable in many environments. As 97 such, a method of performing these same call control primitives in a 98 distributed, peer-to-peer fashion is very desirable. 100 Use of an explicit Join header is needed in some cases instead of 101 addressing an INVITE to a conference URI for the following reasons: 103 o A conference may not exist--the new invitation may be trying to 104 join an ordinary two-party call. 106 o The party joining may not know if the dialog it wants to join is 107 part of a conference. 109 o The party joining may not know the conference URI. 111 The Join header enables services such as barge-in, real-time message 112 screening, and call center monitoring in a distributed peer-to-peer 113 way. This list of services is not exhaustive. 115 For example, the Boss has an established 2-party conversation with a 116 Customer, and using some out-of-band mechanism (ex:voice, gestures, 117 or email) asks an Assistant to join the conversation. The Assistant 118 sends an INVITE with a Join header to the Boss with the dialog 119 information for the established dialog. The Assistant obtained this 120 information from some other mechanism, for example a web-page, an 121 instant message, or from the SIP session dialog package [8]. 123 Assitant Boss Customer 124 | callid: 4@A | callid: 7@c | 125 | | | 126 | |<============>| 127 | | | 128 |INVITE------>| | 129 |Join: 7@c | | 130 | |reINVITE----->| 131 |<----200-----|<----200------| 132 |-----ACK---->|<----ACK------| 133 | | | 134 | .. begins mixing .. | 135 | | | 136 |<===========>|<============>| 137 |<::::::::::::::::::::::::::>| 139 Note that this operation effectively creates a new conference. The 140 Boss needs to cause a new conference to start (and consequently 141 create or obtain a new conference URI). In our example, the Boss 142 mixes all media locally, so it needs to generate a new conference 143 URI, return the conference URI as the Contact to the Join INVITE, and 144 reINVITE the Customer with the conference URI as the new Contact. 146 3. Applicability of RFC2804 ("Raven") 148 This primitive can be used to create services which are used for 149 monitoring purposes, however these services do not meet the 150 definition of a wiretap according to RFC2804 [9]. The definition 151 from RFC2804 is included here: 153 Wiretapping is what occurs when information passed across the 154 Internet from one party to one or more other parties is delivered 155 to a third party: 157 1. Without the sending party knowing about the third party 159 2. Without any of the recipient parties knowing about the delivery 160 to the third party 162 3. When the normal expectation of the sender is that the 163 transmitted information will only be seen by the recipient 164 parties or parties obliged to keep the information in 165 confidence 167 4. When the third party acts deliberately to target the 168 transmission of the first party, either because he is of 169 interest, or because the second party's reception is of 170 interest. 172 Specifically, item 2 of this definition does not apply to this 173 extension, as one party is always aware of a Join request and can 174 even decline such requests. In addition, in many applications of 175 this primitive, some or all of the other items may not apply. For 176 example, in many call centers which handle financial transactions, 177 all conversations are recorded with the full knowledge and 178 expectation of all parties involved. 180 4. User Agent Server Behavior: Receiving a Join Header 182 The Join header contains information used to match an existing SIP 183 dialog (call-id, to-tag, and from-tag). Upon receiving an INVITE 184 with a Join header, the UA attempts to match this information with a 185 confirmed or early dialog. The to-tag and from-tag parameters are 186 matched as if they were tags present in an incoming request. In 187 other words the to-tag parameter is compared to the local tag, and 188 the from-tag parameter is compared to the remote tag. 190 If more than one Join header field is present in an INVITE, or if a 191 Join header field is present in a request other than INVITE, the UAS 192 MUST reject the request with a 400 Bad Request response. 194 The Join header has specific call control semantics. If both a Join 195 header field and another header field with contradictory semantics 196 (for example a Replaces [5] header field) are present in a request, 197 the request MUST be rejected with a 400 "Bad Request" response. 199 If the Join header field matches more than one dialog, the UA MUST 200 act as if no match is found. 202 If no match is found, but the Request-URI in the INVITE corresponds 203 to a conference URI, the UAS MUST ignore the Join header and continue 204 processing the INVITE as if the Join header did not exist. This 205 allows User Agents which receive an INVITE with Join to redirect the 206 request to a conference. 208 Otherwise if no match is found, the UAS rejects the INVITE and 209 returns a 481 Call/Transaction Does Not Exist response. Likewise, if 210 the Join header field matches a dialog which was not created with an 211 INVITE, the UAS MUST reject the request with a 481 response. 213 If the Join header field matches a dialog which has already 214 terminated, the UA SHOULD decline the request with a 603 Declined 215 response. 217 If the Join header field matches an active dialog (n.b. unlike the 218 Replaces header, the Join header has no limitation on its use with 219 early dialogs), the UA SHOULD verify that the initiator of the new 220 INVITE is authorized to join the matched dialog. If the initiator of 221 the new INVITE has authenticated successfully as equivalent to the 222 user who is being joined, then the join is authorized. The UA MAY 223 also maintain a list of authorized entities who are allowed to join 224 any dialog with certain characteristics (for example, all dialogs 225 placed in the call center context of the UA). In addition, the UA 226 MAY use other authorization mechanisms defined for this purpose in 227 standards track extensions. For example, an extension could define a 228 mechanism for transitively asserting authorization of a join. 230 If authorization is successful, the UA attempts to accept the new 231 INVITE, and assign any mixing or conferencing resources necessary to 232 complete the join. If the UA cannot accept the new INVITE (for 233 example: it cannot establish required QoS or keying, or it has 234 incompatible media), the UA MUST return an appropriate error response 235 and MUST leave the matched dialog unchanged. 237 A User Agent that accepts a Join header needs to setup dialogs or 238 conferences such that the requesting UAC is logically added to the 239 conversation space associated with the matched dialog. Any dialogs 240 which are already logically associated with the matched dialog in the 241 same conversation space are included as well. For a detailed 242 description of various conferencing mechanisms that could be used to 243 handle a Join, please consult the SIP conferencing framework [10]. 245 If the UAS has sufficient resources to locally handle the Join 246 request, the UAS SHOULD accept the Join request and perform the 247 appropriate media mixing or combining. The UAS MAY rearrange 248 appropriate dialogs instead as described below, based on some local 249 policy. 251 If the UAS does not have sufficient resources locally to handle the 252 request, or does not wish to use these local resources, but is aware 253 of other resources which could be used to satisfy the request (ex: a 254 centralized mixer), the UA SHOULD create a conference using this 255 resource (ex: INVITE the centralized mixer to obtain a conference 256 URI), redirect the requestor to this resource, and request other 257 participants in the same conversation space to use this resource. 258 The UA MAY use any appropriate mechanism to transition participants 259 to the new resource (ex: 3xx repsonse, 3rd-party call control 260 reinvitiations, REFER requests, or reinvitations to a multicast 261 group). The UA SHOULD only use mechanisms which are expected to be 262 acceptable to the other participants. For example, the UA SHOULD NOT 263 attempt to transition the participants to a multicast group unless 264 the UA can reasonably expect that all the particpants can support 265 multicast. 267 If the UAS is incapable of satisfying the Join request, it MUST 268 return a 488 "Not Acceptable Here" response. 270 OPEN ISSUE: Using a 488 here may be ambiguous when used with 271 INVITEs with only sessions of messages. Some implementations 272 may automatically retry with page-mode messages. 274 5. User Agent Client Behavior: Sending a Join header 276 A User Agent that wishes to add a new dialog of its own to a single 277 existing early or confirmed dialog and any associated dialogs or 278 conferences, MAY send the target User Agent an INVITE request 279 containing a Join header field. The UAC places the Call-ID, to-tag, 280 and from-tag information for the target dialog in a single Join 281 header field and sends the new INVITE to the target. 283 If the User Agent receives a 300-class response, and acts on this 284 response by sending an INVITE to a Contact in the response, this 285 redirected INVITE MUST contain the same Join header which was present 286 in the original request. Although this is unusual, this allows 287 INVITE requests with a Join header to be redirected before reaching 288 the target UAS. 290 Note that use of the Join mechanism does not provide a way to match 291 multiple dialogs, nor does it provide a way to match an entire call, 292 an entire transaction, or to follow a chain of proxy forking logic. 293 For example, if Alice replaces Cathy in an early dialog with Bob, but 294 he does not answer, Alice's replacement request will not match other 295 dialogs to which Bob's UA redirects, nor other branches to which his 296 proxy forwards. 298 6. Proxy behavior 300 Proxy Servers do not require any new behavior to support this 301 extension. They simply pass the Join header field transparently as 302 described in the SIP specification. 304 Note that it is possible for a proxy (especially when forking based 305 on some application layer logic, such as caller screening or 306 time-of-day routing) to forward an INVITE request containing a Join 307 header field to a completely orthogonal set of Contacts than the 308 original request it was intended to replace. In this case, the 309 INVITE request with the Join header field will fail. 311 7. Syntax 312 7.1 The Join Header 314 The Join header field indicates that a new dialog (created by the 315 INVITE in which the Join header field in contained) should be joined 316 with a dialog identified by the header field, and any associated 317 dialogs or conferences. It is a request header only, and defined 318 only for INVITE requests. The Join header field MAY be encrypted as 319 part of end-to-end encryption. Only a single Join header field value 320 may be present in a SIP request 322 This document adds the following entry to Table 3 of [1]. Additions 323 to this table are also provided for extension methods defined at the 324 time of publication of this document. This is provided as a courtesy 325 to the reader and is not normative in any way. MESSAGE, SUBSCRIBE and 326 NOTIFY, REFER, INFO, UPDATE, and PRACK are defined respectively in 327 [13], [14], [4], [15], [16], and [17]. 329 Header field where proxy ACK BYE CAN INV OPT REG MSG 330 ------------ ----- ----- --- --- --- --- --- --- --- 331 Join R - - - o - - - 333 SUB NOT REF INF UPD PRA 334 --- --- --- --- --- --- 335 Join R - - - - - - 337 The following syntax specification uses the augmented Backus-Naur 338 Form (BNF) as described in RFC-2234 [3]. 340 Join = "Join" HCOLON callid *(SEMI join-param) 341 join-param = to-tag / from-tag / generic-param 342 to-tag = "to-tag" EQUAL token 343 from-tag = "from-tag" EQUAL token 345 A Join header MUST contain exactly one to-tag and exactly one 346 from-tag, as they are required for unique dialog matching. For 347 compatibility with dialogs initiated by RFC2543 [6] compliant UAs, a 348 tag of zero matches both tags of zero and null tags. 350 Examples: 352 Join: 98732@sip.example.com 353 ;from-tag=r33th4x0r 354 ;to-tag=ff87ff 356 Join: 12adf2f34456gs5;to-tag=12345;from-tag=54321 358 Join: 87134@192.0.2.23;to-tag=24796;from-tag=0 360 7.2 New option tag for Require and Supported headers 362 This specification defines a new Require/Supported header option tag 363 "join". UAs which support the Join header MUST include the "join" 364 option tag in a Supported header field. UAs that want explicit 365 failure notification if Join is not supported MAY include the "join" 366 option in a Require header field. 368 Example: 370 Require: join, 100rel 372 8. Usage Examples 374 The following non-normative examples are not intended to enumerate 375 all the possibilities for the usage of this extension, but rather to 376 provide examples or ideas only. For more examples, please see 377 service-examples [12]. 379 8.1 Join accepted and transitioned to central mixer 381 A B C mixer 382 | callid: 4@A | callid: 7@c | | 383 | | | | 384 | |<============>| | 385 | | | | 386 |INVITE------>| | | 387 |Join: 7@c |--INVITE-------------------->| 388 | |<----200---------------------| 389 | |-----ACK-------------------->| 390 |<----300-----| | 391 |INVITE------------------------------------>| 392 |<--200-------------------------------------| 393 |---ACK------------------------------------>| 394 | |--REFER------>| | 395 | |<---200-------|--INVITE----->| 396 | | |<----200------| 397 | |<--NOTIFY-----|-----ACK----->| 398 | |------200---->| | 399 | |---BYE------->| | 400 | |<--200--------| | 401 | | | | 402 |<=========================================>| mixes the 403 | |<===========================>| three sessions 404 | | |<============>| together 406 The conversation now appears identical to the locally mixed one from 407 the example in the Introduction. Details of how the Join are 408 implemented are transparent to A. B could have used 3rd party call 409 control instead to move the necessary sessions. 411 TO DO: Include example messages for this flow 413 8.2 Join rejected 415 A B C 416 | callid: 4@A | callid: 7@c | 417 | | | 418 | |<============>| 419 | | | 420 |INVITE------>| | 421 |Join: 7@c | | 422 | | | 423 |<----486-----| | 424 |-----ACK---->| | 425 | | | 427 In this example B is Busy (does not want to be disturbed), and 428 therefore does not wish to add A. B could also decline the request 429 with a 603 response. 431 TO DO: Include example messages for this flow 433 9. Security Considerations 435 The extension specified in this document significantly changes the 436 relative security of SIP devices. Currently in SIP, even if an 437 eavesdropper learns the Call-ID, To, and From headers of a dialog, 438 they cannot easily modify or destroy that dialog if Digest 439 authentication or end-to-end message integrity are used. 441 This extension can be used to insert or monitor potentially sensitive 442 content in a multimedia conversation. As such, invitations with the 443 Join header MUST only be accepted if the peer requesting replacement 444 has been properly authenticated using a standard SIP mechanism 445 (Digest or S/MIME), and authorized to be joined with the target 446 dialog. Generally authorization for joins are configured as a matter 447 of local policy as long-duration persistent relationships. 449 For example, the UAs used by call center agents might be configured 450 with a list of list of identities who could join their calls 451 (supervisors and any call center monitoring User Agents). 452 Alternatively the call center agents might rely on transitive 453 authorization assertions from a (shorter) list of authorized hosts 454 (ex: a certificate authority). For answering-machine-style message 455 screening this is even easier. Presumably the user screening their 456 messages already has some credentials with their messaging server. 458 Some mechanisms for obtaining the dialog information needed by the 459 Join header (Call-ID, to-tag, and from-tag) include URIs on a web 460 page, subscriptions to an appropriate event package, and notifcations 461 after a REFER request. Use of end-to-end security mechanisms to 462 integrity protect and encrypt this information is also RECOMMENDED. 464 This extension was designed to take advantage of future signature or 465 authorization schemes defined by the SIP Working Group. In general, 466 call control features would benefit considerably from such work. 468 10. IANA Considerations 470 10.1 Registration of "Join" SIP header 472 Name of Header: Join 474 Short form: none 476 Normative description: section 7.1 of this document 478 10.2 Registration of "join" SIP Option-tag 480 Name of option: join 482 Description: Support for the SIP Join header 484 SIP headers defined: Join 486 Normative description: This document 488 11. Changes 490 11.1 Changes Since draft-ietf-sip-join-00 492 o Added more detail about how join authorization could work 494 o Added open issue about 488 handling at the end of section 4 496 11.2 Changes Since draft-mahy-join-and-fork-01 498 o Added discussion about handling of 300-class responses to an 499 INVITE with Join 501 o Fixed several typos 503 o Updated references 504 o Resubmitted as a Working Group item 506 11.3 Changes Since -00 508 o Realigned the text to mirror the outline of Replaces 510 o Removed the fork header 512 o Added a section to explain how this is not a "Raven" wiretap 513 mechanism 515 o Reorganized motivational overview material 517 o Added authorization language in UAS behavior section 519 o Updated and Added references 521 12. Acknowledgments 523 Thanks to Robert Sparks, Alan Johnston, and Ben Campbell and many 524 other members of the SIP WG for their continued support of the cause 525 of distributed call control in SIP. 527 Normative References 529 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 530 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 531 Session Initiation Protocol", RFC 3261, June 2002. 533 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 534 Levels", BCP 14, RFC 2119, March 1997. 536 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 537 Specifications: ABNF", RFC 2234, November 1997. 539 Informational References 541 [4] Sparks, R., "The SIP Refer Method", draft-ietf-sip-refer-07 542 (work in progress), December 2002. 544 [5] Dean, R., Biggs, B. and R. Mahy, "The Session Inititation 545 Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-02 546 (work in progress), May 2002. 548 [6] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 549 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 551 [7] Mahy, R., "A Multi-party Application Framework for SIP", 552 draft-ietf-sipping-cc-framework-01 (work in progress), July 553 2002. 555 [8] Rosenberg, J. and H. Schulzrinne, "A Session Initiation 556 Protocol (SIP) Event Package for Dialog State", 557 draft-ietf-sipping-dialog-package-00 (work in progress), June 558 2002. 560 [9] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000. 562 [10] Rosenberg, J., "A Framework for Conferencing with the Session 563 Initiation Protocol", 564 draft-rosenberg-sipping-conferencing-framework-01 (work in 565 progress), February 2003. 567 [11] Rosenberg, J., Schulzrinne, H., Camarillo, G. and J. Peterson, 568 "Best Current Practices for Third Party Call Control in the 569 Session Initiation Protocol", draft-ietf-sipping-3pcc-02 (work 570 in progress), June 2002. 572 [12] Johnston, A. and S. Donovan, "Session Initiation Protocol 573 Service Examples", draft-ietf-sipping-service-examples-03 (work 574 in progress), November 2002. 576 [13] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 577 D. Gurle, "Session Initiation Protocol (SIP) Extension for 578 Instant Messaging", RFC 3428, December 2002. 580 [14] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 581 Notification", RFC 3265, June 2002. 583 [15] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 585 [16] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 586 Method", RFC 3311, October 2002. 588 [17] jdrosen@dynamicsoft.com and schulzrinne@cs.columbia.edu, 589 "Reliability of Provisional Responses in Session Initiation 590 Protocol (SIP)", RFC 3262, June 2002. 592 Authors' Addresses 594 Rohan Mahy 595 Cisco Systems, Inc. 596 101 Cooper Street 597 Santa Cruz, CA 95060 598 USA 600 EMail: rohan@cisco.com 602 Dan Petrie 603 Pingtel 604 400 West Cummings Park, Suite 2200 605 Woburn, MA 01801 606 USA 608 EMail: dpetrie@pingtel.com 610 Intellectual Property Statement 612 The IETF takes no position regarding the validity or scope of any 613 intellectual property or other rights that might be claimed to 614 pertain to the implementation or use of the technology described in 615 this document or the extent to which any license under such rights 616 might or might not be available; neither does it represent that it 617 has made any effort to identify any such rights. Information on the 618 IETF's procedures with respect to rights in standards-track and 619 standards-related documentation can be found in BCP-11. Copies of 620 claims of rights made available for publication and any assurances of 621 licenses to be made available, or the result of an attempt made to 622 obtain a general license or permission for the use of such 623 proprietary rights by implementors or users of this specification can 624 be obtained from the IETF Secretariat. 626 The IETF invites any interested party to bring to its attention any 627 copyrights, patents or patent applications, or other proprietary 628 rights which may cover technology that may be required to practice 629 this standard. Please address the information to the IETF Executive 630 Director. 632 Full Copyright Statement 634 Copyright (C) The Internet Society (2003). All Rights Reserved. 636 This document and translations of it may be copied and furnished to 637 others, and derivative works that comment on or otherwise explain it 638 or assist in its implementation may be prepared, copied, published 639 and distributed, in whole or in part, without restriction of any 640 kind, provided that the above copyright notice and this paragraph are 641 included on all such copies and derivative works. However, this 642 document itself may not be modified in any way, such as by removing 643 the copyright notice or references to the Internet Society or other 644 Internet organizations, except as needed for the purpose of 645 developing Internet standards in which case the procedures for 646 copyrights defined in the Internet Standards process must be 647 followed, or as required to translate it into languages other than 648 English. 650 The limited permissions granted above are perpetual and will not be 651 revoked by the Internet Society or its successors or assignees. 653 This document and the information contained herein is provided on an 654 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 655 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 656 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 657 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 658 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 660 Acknowledgement 662 Funding for the RFC Editor function is currently provided by the 663 Internet Society.