idnits 2.17.1 draft-ietf-sip-join-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: ---------------------------------------------------------------------------- == 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 (Oct 2002) is 7865 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) == Unused Reference: '11' is defined on line 545, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) == Outdated reference: A later version (-07) exists of draft-ietf-sip-refer-06 == 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 (-01) exists of draft-rosenberg-sipping-conferencing-framework-00 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-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-02 -- 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 (~~), 12 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: April 1, 2003 D. Petrie 5 Pingtel 6 Oct 2002 8 The Session Inititation Protocol (SIP) "Join" Header 9 draft-ietf-sip-join-00.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 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 1, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This document defines a new header for use with SIP multi-party 41 applications and call control. The Join header is used to logically 42 join an existing SIP dialog with a new SIP dialog. This primitive 43 can be used to enable a variety of features, for example: "Barge-In", 44 answering-machine-style "Message Screening" and "Call Center 45 Monitoring". Note that definition of these example features is non- 46 normative. 48 Table of Contents 50 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Applicability of RFC2804 ("Raven") . . . . . . . . . . . . . 4 53 4. User Agent Server Behavior: Receiving a Join Header . . . . 5 54 5. User Agent Client Behavior: Sending a Join header . . . . . 7 55 6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . 7 56 7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 7.1 The Join Header . . . . . . . . . . . . . . . . . . . . . . 8 58 7.2 New option tag for Require and Supported headers . . . . . . 9 59 8. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 9 60 8.1 Join accepted and transitioned to central mixer . . . . . . 10 61 8.2 Join rejected . . . . . . . . . . . . . . . . . . . . . . . 11 62 9. Security Considerations . . . . . . . . . . . . . . . . . . 11 63 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 64 10.1 Registration of "Join" SIP header . . . . . . . . . . . . . 12 65 10.2 Registration of "join" SIP Option-tag . . . . . . . . . . . 12 66 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 11.1 Changes Since draft-mahy-join-and-fork-01 . . . . . . . . . 12 68 11.2 Changes Since -00 . . . . . . . . . . . . . . . . . . . . . 12 69 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 70 Normative References . . . . . . . . . . . . . . . . . . . . 13 71 Informational References . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 73 Full Copyright Statement . . . . . . . . . . . . . . . . . . 15 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 [12] 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 are matched as if 186 they were present in an incoming request. In other words the to-tag 187 is compared to the local tag, and the from-tag is compared to the 188 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 an appropriate response 212 (ex: 400, 481, or 501). 214 If the Join header field matches a dialog which has already 215 terminated, the UA SHOULD decline the request with a 603 Declined 216 response. 218 If the Join header field matches a active dialog, the UA SHOULD 219 verify that the initiator of the new INVITE is authorized to join the 220 matched dialog. If the initiator of the new INVITE has authenticated 221 successfully as equivalent to the user who is being joined, then the 222 join is authorized. The UA MAY also maintain a list of authorized 223 entities who are allowed to join any dialog with certain 224 characteristics (for example, all dialogs placed in the call center 225 context of the UA). In addition, the UA MAY use other authorization 226 mechanisms defined for this purpose in standards track extensions. 227 For example, an extension could define a mechanism for transitively 228 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. All the participants 242 in a conversation space should have access to all the media/content 243 sent in the context of that conversation space. That a participant 244 does not negotiate a specific type of media does not mean that it is 245 not otherwise a full participant. For a detailed description of 246 various conferencing mechanisms that could be used to handle a Join, 247 please consult the SIP conferencing framework [10]. 249 If the UAS has sufficient resources to locally handle the Join 250 request, the UAS SHOULD accept the Join request and perform the 251 appropriate media mixing or combining. The UAS MAY rearrange 252 appropriate dialogs instead as described below, based on some local 253 policy. 255 If the UAS does not have sufficient resources locally to handle the 256 request, or does not wish to use these local resources, but is aware 257 of other resources which could be used to satisfy the request (ex: a 258 centralized mixer), the UA SHOULD create a conference using this 259 resource (ex: INVITE the centralized mixer to obtain a conference 260 URI), redirect the requestor to this resource, and request other 261 participants in the same conversation space to use this resource. 262 The UA MAY use any appropriate mechanism to transition participants 263 to the new resource (ex: 3xx repsonse, 3rd-party call control 264 reinvitiations, REFER requests, or reinvitations to a multicast 265 group). The UA SHOULD only use mechanisms which are expected to be 266 acceptable to the other participants. For example, the UA SHOULD NOT 267 attempt to transition the participants to a multicast group unless 268 the UA can reasonably expect that all the particpants can support 269 multicast. 271 If the UAS is incapable of satisfying the Join request, it MUST 272 return a 488 "Not Acceptable Here" response. 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 time-of- 306 day routing) to forward an INVITE request containing a Join header 307 field to a completely orthogonal set of Contacts than the original 308 request it was intended to replace. In this case, the INVITE request 309 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. SUBSCRIBE and NOTIFY, 326 REFER, INFO, UPDATE, and PRACK are defined respectively in [14], [4], 327 [15], [16], and [17]. 329 Header field where proxy ACK BYE CAN INV OPT REG 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 from- 346 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 [13]. 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 space now looks identical to the locally mixed 407 example in the Introduction. Details of how the Join are implemented 408 are transparent to A. B could have used 3rd party call control 409 instead to move the necessary sessions. 411 [ B , C ] --> [ A , B , C ] 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 9. Security Considerations 433 The extension specified in this document significantly changes the 434 relative security of SIP devices. Currently in SIP, even if an 435 eavesdropper learns the Call-ID, To, and From headers of a dialog, 436 they cannot easily modify or destroy that dialog if Digest 437 authentication or end-to-end message integrity are used. 439 This extension can be used to insert or monitor potentially sensitive 440 content in a multimedia conversation. As such, invitations with the 441 Join header SHOULD only be accepted if the peer requesting 442 replacement has been properly authenticated using a standard SIP 443 mechanism, and authorized to by joined with the target dialog. 445 Some mechanisms for obtaining the dialog information needed by the 446 Join header (Call-ID, to-tag, and from-tag) include URIs on a web 447 page, subscriptions to an appropriate event package, and notifcations 448 after a REFER request. Use of end-to-end security mechanisms to 449 encrypt this information is also RECOMMENDED. 451 This extension was designed to take advantage of future signature or 452 authorization schemes defined by the SIP Working Group. In general, 453 call control features would benefit considerably from such work. 455 10. IANA Considerations 456 10.1 Registration of "Join" SIP header 458 Name of Header: Join 460 Short form: none 462 Normative description: section 7.1 of this document 464 10.2 Registration of "join" SIP Option-tag 466 Name of option: join 468 Description: Support for the SIP Join header 470 SIP headers defined: Join 472 Normative description: This document 474 11. Changes 476 11.1 Changes Since draft-mahy-join-and-fork-01 478 o Added discussion about handling of 300-class responses to an 479 INVITE with Join 481 o Fixed several typos 483 o Updated references 485 o Resubmitted as a Working Group item 487 11.2 Changes Since -00 489 o Realigned the text to mirror the outline of Replaces 491 o Removed the fork header 493 o Added a section to explain how this is not a "Raven" wiretap 494 mechanism 496 o Reorganized motivational overview material 498 o Added authorization language in UAS behavior section 500 o Updated and Added references 502 12. Acknowledgments 504 Thanks to Robert Sparks, Alan Johnston, and Ben Campbell and many 505 other members of the SIP WG for their continued support of the cause 506 of distributed call control in SIP. 508 Normative References 510 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 511 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 512 Session Initiation Protocol", RFC 3261, June 2002. 514 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 515 Levels", BCP 14, RFC 2119, March 1997. 517 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 518 Specifications: ABNF", RFC 2234, November 1997. 520 Informational References 522 [4] Sparks, R., "The SIP Refer Method", draft-ietf-sip-refer-06 523 (work in progress), July 2002. 525 [5] Dean, R., Biggs, B. and R. Mahy, "The Session Inititation 526 Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-02 527 (work in progress), May 2002. 529 [6] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 530 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 532 [7] Mahy, R., "A Multi-party Application Framework for SIP", draft- 533 ietf-sipping-cc-framework-01 (work in progress), July 2002. 535 [8] Rosenberg, J. and H. Schulzrinne, "A Session Initiation 536 Protocol (SIP) Event Package for Dialog State", draft-ietf- 537 sipping-dialog-package-00 (work in progress), June 2002. 539 [9] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000. 541 [10] Rosenberg, J., "SIP Conferencing Framework", draft-rosenberg- 542 sipping-conferencing-framework-00.txt (work in progress), Oct 543 2002. 545 [11] Sparks, R. and A. Johnston, "SIP Call Control - Transfer", 546 draft-ietf-sipping-cc-transfer-00.txt (work in progress), Oct 547 2002. 549 [12] Rosenberg, J., Schulzrinne, H., Camarillo, G. and J. Peterson, 550 "Best Current Practices for Third Party Call Control in the 551 Session Initiation Protocol", draft-ietf-sipping-3pcc-02 (work 552 in progress), June 2002. 554 [13] Johnston, A., "SIP Service Examples", draft-ietf-sipping- 555 service-examples-02 (work in progress), July 2002. 557 [14] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 558 Notification", RFC 3265, June 2002. 560 [15] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 562 [16] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 563 Method", RFC 3311, October 2002. 565 [17] jdrosen@dynamicsoft.com and schulzrinne@cs.columbia.edu, 566 "Reliability of Provisional Responses in Session Initiation 567 Protocol (SIP)", RFC 3262, June 2002. 569 Authors' Addresses 571 Rohan Mahy 572 Cisco Systems, Inc. 573 101 Cooper Street 574 Santa Cruz, CA 95060 575 USA 577 EMail: rohan@cisco.com 579 Dan Petrie 580 Pingtel 581 400 West Cummings Park, Suite 2200 582 Woburn, MA 01801 583 USA 585 EMail: dpetrie@pingtel.com 587 Full Copyright Statement 589 Copyright (C) The Internet Society (2002). All Rights Reserved. 591 This document and translations of it may be copied and furnished to 592 others, and derivative works that comment on or otherwise explain it 593 or assist in its implementation may be prepared, copied, published 594 and distributed, in whole or in part, without restriction of any 595 kind, provided that the above copyright notice and this paragraph are 596 included on all such copies and derivative works. However, this 597 document itself may not be modified in any way, such as by removing 598 the copyright notice or references to the Internet Society or other 599 Internet organizations, except as needed for the purpose of 600 developing Internet standards in which case the procedures for 601 copyrights defined in the Internet Standards process must be 602 followed, or as required to translate it into languages other than 603 English. 605 The limited permissions granted above are perpetual and will not be 606 revoked by the Internet Society or its successors or assigns. 608 This document and the information contained herein is provided on an 609 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 610 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 611 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 612 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 613 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 615 Acknowledgement 617 Funding for the RFC Editor function is currently provided by the 618 Internet Society.