idnits 2.17.1 draft-rosenberg-sip-gruu-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 75 has weird spacing: '...rencing frame...' == Line 532 has weird spacing: '...egistry for t...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (December 5, 2003) is 7441 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 3265 (ref. '3') (Obsoleted by RFC 6665) == Outdated reference: A later version (-02) exists of draft-ietf-sip-parameter-registry-00 == Outdated reference: A later version (-02) exists of draft-ietf-sip-uri-parameter-reg-00 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-00 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialog-package-02 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Rosenberg 3 Internet-Draft dynamicsoft 4 Expires: June 4, 2004 December 5, 2003 6 Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in 7 the Session Initiation Protocol (SIP) 8 draft-rosenberg-sip-gruu-01 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 other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on June 4, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 Several applications of the Session Initiation Protocol (SIP) require 39 a user agent (UA) to construct and distribute a URI which can be used 40 by anyone on the Internet to route a call to that specific UA 41 instance. A URI which routes to a specific UA instance is called a 42 Globally Routable UA URI (GRUU). This document describes an extension 43 to SIP for obtaining a GRUU from a server, and for communicating a 44 GRUU to a peer within a dialog. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Overview of Operation . . . . . . . . . . . . . . . . . . . 3 50 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 51 4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . 4 52 4.1 REGISTER Processing . . . . . . . . . . . . . . . . . . . . 4 53 4.2 Using the GRUU . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Registrar Behavior . . . . . . . . . . . . . . . . . . . . . 5 55 6. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 56 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 9. Security Considerations . . . . . . . . . . . . . . . . . . 11 59 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 60 10.1 Header Field Parameter . . . . . . . . . . . . . . . . . . . 12 61 10.2 URI Parameter . . . . . . . . . . . . . . . . . . . . . . . 12 62 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 63 Normative References . . . . . . . . . . . . . . . . . . . . 12 64 Informative References . . . . . . . . . . . . . . . . . . . 13 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 66 Intellectual Property and Copyright Statements . . . . . . . 15 68 1. Introduction 70 Several applications of the Session Initiation Protocol (SIP) [1] 71 require a user agent (UA) to construct and distribute a URI which can 72 be used by anyone on the Internet to route a call to that specific UA 73 instance. An example of such an application is call transfer, based 74 on the REFER method [4]. Another application is the usage of 75 endpoint-hosted conferences within the conferencing framework [8]. 76 We call these URIs Globally Routable UA URIs (GRUU). Requirements [9] 77 have been defined which identify the capabilities that any mechanism 78 for obtaining and using a GRUU has to provide. This specification 79 describes a mechanism that meets these requirements. 81 2. Overview of Operation 83 This section is tutorial in nature, and does not specify any 84 normative behavior. 86 This extension allows a UA to obtain a GRUU, and to use a GRUU. These 87 two mechanisms are separate, in that a UA can obtain a GRUU in any 88 way it likes, and use the mechanisms in this specification to use 89 them. Similarly, a UA can obtain a GRUU but never use it. 91 A UA can obtain a GRUU by generating a normal REGISTER request, as 92 specified in RFC 3261 [1]. This request contains a Supported header 93 field with the value "gruu", indicating to the registrar that the UA 94 supports this extension. If the domain that the user is registering 95 against also supports GRUU, the REGISTER responses will contain the 96 "gruu" parameter in each Contact header field. This parameter 97 contains a GRUU which the domain guarantees will route to that 98 specific Contact URI. That GRUU is guaranteed to remain valid for the 99 duration of the registration. 101 Since the GRUU is a URI like any other, it can be handed out by a UA 102 by placing it in any header field which can contain a GRUU. A UA will 103 normally place the GRUU into the Contact header field of dialog 104 creating requests and responses it generates. However, it is 105 important for the UA receiving the message to know whether the 106 Contact URI is a GRUU or not. To make this determination, the UA 107 looks for the presence of the Supported header field in the request 108 or response. If it is present with a value of "gruu", it means that 109 the Contact URI is a GRUU. 111 When a UA uses a GRUU, it has the option of adding the "grid" URI 112 parameter to the GRUU. This parameter is opaque to the proxy server 113 handling the domain. However, when the server maps the GRUU to the 114 corresponding Contact URI, the server will copy the grid parameter 115 into the Contact URI. As a result, when the UA receives the request, 116 the Request URI will contain the grid parameter it placed in the 117 corresponding GRUU. 119 3. Terminology 121 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 122 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 123 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and 124 indicate requirement levels for compliant implementations. 126 4. User Agent Behavior 128 User agent behavior is divided into two separate parts - REGISTER 129 processing, and GRUU usage. 131 4.1 REGISTER Processing 133 When a UA wishes to obtain a GRUU within the domain of its AOR, when 134 it generates a REGISTER request (initial or refresh), it MUST include 135 the Supported header field in the request. The value of that header 136 field MUST include "gruu" as one of the option tags. This alerts the 137 registrar for the domain that the UA supports the GRUU mechanism. 138 Besides the presence of this option tag in the Supported header 139 field, the REGISTER request is constructed identically to the case 140 where this extension was not understood. Specifically, the Contact 141 URI in the REGISTER request SHOULD NOT contain the gruu Contact 142 header field parameter. Any such parameters are ignored by the 143 registrar, as the UA cannot propose a GRUU for usage with the Contact 144 URI. 146 If a UA wishes to guarantee that the request is not processed unless 147 the domain supports and uses this extension, it MAY include a Require 148 header field in the request with a value that contains the "gruu" 149 option tag. 151 If the response is a 2xx, each Contact header field may contain a 152 "gruu" parameter. This parameter contains a SIP URI that represents a 153 GRUU corresponding to that Contact URI. Any requests sent to the GRUU 154 URI will be routed by the domain to the Contact URI. The GRUU will 155 not change in subsequent 2xx responses to REGISTER as long as the UA 156 does not let the registration expire. However, if the UA waits until 157 the last moment to refresh its registration, it may cause a race 158 condition where the registration expires while the registration is in 159 transit. The resulting 200 OK might then contain a different GRUU. 160 Since "last moment" is ill defined, it is RECOMMENDED that a UA be 161 prepared to handle a change in the GRUU during a registration. 162 Handling a change depends on the way in which it has been used. In 163 the case where it is included in the Contact URI of a dialog 164 initiating request or response, the UA would update the Contact URI 165 with a target refresh request. 167 4.2 Using the GRUU 169 A UA first obtains a GRUU using the procedures of Section 4.1. 171 A UA can use the GRUU in the same way it would use any other SIP URI. 172 However, a UA compliant to this specification MUST use a GRUU when 173 populating the Contact header field of dialog-creating requests and 174 responses. This includes the INVITE request and its 2xx response, the 175 SUBSCRIBE [3] request, its 2xx response, and the NOTIFY request, and 176 the REFER [4] request and its 2xx response. Similarly, in those 177 requests and responses where the GRUU is used in the Contact header 178 field, the UA MUST include a Supported header field that contains the 179 option tag "gruu". However, it is not necessary for a UA to know 180 whether or not its peer in the dialog uses a GRUU before inserting 181 one into the Contact header field. 183 When placing a GRUU into the Contact header field of a request or 184 response, a UA MAY add the "grid" URI parameter to the GRUU. This 185 parameter MAY take on any value permitted by the grammar for the 186 parameter, but MUST NOT exceed 128 characters. When a UA sends a 187 request to the GRUU, the proxy for the domain that owns the GRUU will 188 copy this parameter from the GRUU into the Contact URI matching that 189 GRUU. This allows the UA to effectively manufacture an infinite 190 supply of GRUU, each of which differs by the value of the "grid" 191 parameter. When a UA receives a request that was sent to the GRUU, it 192 will be able to tell which GRUU was invoked by the "grid" parameter. 194 An implication of this behavior is that all mid-dialog requests will 195 be routed through intermediate proxies. There will never be direct, 196 UA to UA signaling. It is anticipated that this limitation will be 197 addressed in future specifications. 199 Once a UA knows that the Contact URI provided by its peer is a GRUU, 200 it can use it in any application or SIP extension which requires a 201 globally routable URI to operate. One such example is assisted call 202 transfer. 204 5. Registrar Behavior 206 When a registrar compliant to this specification receives a REGISTER 207 request, it checks for the presence of the Require header field in 208 the request. If present, and if it contains the "gruu" option tag, 209 the registrar MUST follow the procedures in the next paragraph for 210 inclusion of the "gruu" parameter in a 2xx response to REGISTER. If 211 not present, but a Supported header field was present with the "gruu" 212 option tag, the registrar SHOULD follow the procedures in the next 213 paragraph for inclusion of the "gruu" parameter in a 2xx response to 214 REGISTER. If the Supported header field was not present, or it if was 215 present but did not contain the value "gruu", the registrar SHOULD 216 NOT follow the procedures of the next paragraph for inclusion of the 217 "gruu" parameter in a 2xx response to REGISTER. 219 If the register request contained any "gruu" Contact header field 220 parameters, these MUST be ignored by the registrar. A UA cannot 221 suggest or otherwise provide a GRUU to the registrar. 223 A GRUU is provided to a UA by including it in the "gruu" Contact 224 header field parameter for a particular Contact URI. The value of 225 this parameter is a quoted string containing the URI that is the GRUU 226 for the associated Contact URI. If the REGISTER request was 227 refreshing that Contact URI, and the registrar had provided a gruu to 228 the UA previously, the registrar MUST include the "gruu" Contact 229 header field parameter for that Contact URI, and its value MUST 230 contain the same URI provided previously. The result is that there is 231 a one to one mapping of a GRUU to a Contact URI for the duration that 232 the Contact is registered to the UA. Note that, should the 233 registration of that Contact expire, and then the UA re-registers it 234 at a later time, the registrar is under no obligation to use the same 235 GRUU for that Contact URI. The implication of these rules is that a 236 registrar is responsible for reliable storage of the GRUU for the 237 duration of a registration. 239 If the REGISTER request is creating a new Contact URI for a 240 particular address of record, and the registrar decides to provide 241 the UA with a gruu for that Contact URI, it constructs a new GRUU. 242 This specification does not mandate a particular mechanism for 243 construction of the GRUU. However, the GRUU MUST exhibit the 244 following properties: 246 o The domain part of the URI is an IP address present on the public 247 Internet, or, if it is a host name, exists in the global DNS and 248 corresponds to an IP address present on the public Internet. 250 o When a request is sent to this URI, it routes to a proxy server in 251 the same domain as that of the registrar. 253 o A proxy server in the domain can determine that the URI is a GRUU. 255 o When a proxy server in this domain translates this URI, the result 256 is equal to the Contact URI corresponding to the GRUU. 258 o It MUST NOT be possible, based on inspection of the URI, to 259 determine the associated Contact URI or Address of Record. 261 With these rules, it is possible, though not required, to construct a 262 GRUU without requiring the maintenance of any additional state. To do 263 that, the URI would be constructed in the following fashion: 265 user-part = "GRUU" + BASE64(E(K, (salt + Contact URI + AOR))) 267 Where E(K,X) represents a suitable encryption function (such as AES 268 with 128 bit keys) with key K applied to data block X, and the "+" 269 operator implies concatenation. Salt represents a random string that 270 prevents a client from obtaining pairs of known plaintext and 271 ciphertext. A good choice would be at least 128 bits of randomness in 272 the salt. 274 The benefit of this mechanism is that a server need not store 275 additional information on mapping a GRUU to its corresponding Contact 276 URI. The user part of the GRUU can itself contain the Contact URI. 277 Encryption is needed to prevent attacks whereby the server is sent 278 requests with faked GRUU, causing the server to direct requests to 279 any named URI. Even with encryption, the proxy should validate the 280 user part after decryption. In particular, the AOR should be one 281 managed by the proxy in that domain. Should a UA send a request with 282 a fake GRUU, the proxy would decrypt and then discard it because 283 there would be no URI or an invalid URI inside. 285 6. Proxy Behavior 287 When a proxy server receives a request, and the proxy owns the domain 288 in the Request URI, and the proxy is supposed to access a Location 289 Service in order to compute request targets (as specified in Section 290 16.5 of RFC 3261 [1]), the proxy MUST check if the Request URI is a 291 GRUU created by that domain. 293 If the URI is a GRUU, the proxy MUST determine if the Contact URI 294 associated with the GRUU is still registered to the AOR it was 295 registered to when the GRUU was constructed. If that AOR no longer 296 has any registered contacts, or if it does have registered contacts, 297 but none of them equal the Contact URI associated with the GRUU, the 298 proxy MUST generate a 404 (Not Found) response to the request. 300 Otherwise, the proxy MUST populate the target set with a single URI. 301 This URI MUST be equal to the Contact URI associated with that GRUU. 302 Furthermore, if the GRUU contained a "grid" URI parameter, the URI in 303 the target set MUST also contain the same parameter with the same 304 value. 306 A proxy MAY apply other processing to the request, such as execution 307 of called party features. In particular, it is RECOMMENDED that 308 non-routing called party features, such as call logging and 309 screening, that are associated with the AOR are also applied to 310 requests for the GRUU. 312 In many cases, a proxy will record-route an initial INVITE request, 313 and the user agents will insert a GRUU into the Contact header field. 314 When this happens, a mid-dialog request will arrive at the proxy with 315 a Route header field that was inserted by the proxy, and a 316 Request-URI that represents a GRUU. Proxies follow normal processing 317 in this case; they will strip the Route header field, and then 318 process the Request URI as described above. 320 The procedures of RFC 3261 are then followed to proxy the request. 321 The request SHOULD NOT be redirected in this case. In many instances, 322 a GRUU is used by a UA in order to assist in the traversal of NATs, 323 and a redirection may prevent such a case from working. 325 7. Grammar 327 This specification defines a new Contact header field parameter, 328 gruu, and a new URI parameter, grid. 330 contact-params = c-p-q / c-p-expires / c-p-gruu 331 / contact-extension 332 c-p-gruu = "gruu" EQUAL SWS DQUOTE SIP-URI DQUOTE 333 uri-parameter = transport-param / user-param / method-param 334 / ttl-param / maddr-param / lr-param / grid-param 335 / other-param 336 grid-param = "grid=" pvalue 338 8. Examples 340 The following call flow shows a basic registration and call setup, 341 followed by a subscription directed to the GRUU. 343 Caller Proxy Callee 344 | |(1) REGISTER | 345 | |<--------------------| 346 | |(2) 200 OK | 347 | |-------------------->| 348 |(3) INVITE | | 349 |-------------------->| | 350 | |(4) INVITE | 351 | |-------------------->| 352 | |(5) 200 OK | 353 | |<--------------------| 354 |(6) 200 OK | | 355 |<--------------------| | 356 |(7) ACK | | 357 |-------------------->| | 358 | |(8) ACK | 359 | |-------------------->| 360 |(9) SUBSCRIBE | | 361 |-------------------->| | 362 | |(10) SUBSCRIBE | 363 | |-------------------->| 364 | |(11) 200 OK | 365 | |<--------------------| 366 |(12) 200 OK | | 367 |<--------------------| | 368 | |(13) NOTIFY | 369 | |<--------------------| 370 |(14) NOTIFY | | 371 |<--------------------| | 372 |(15) 200 OK | | 373 |-------------------->| | 374 | |(16) 200 OK | 375 | |-------------------->| 377 The Callee supports the GRUU extension. As such, its REGISTER (1) 378 looks like: 380 REGISTER sip:example.com SIP/2.0 381 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bKnashds7 382 Max-Forwards: 70 383 From: Callee ;tag=a73kszlfl 384 Supported: gruu 385 To: Callee 386 Call-ID: 1j9FpLxk3uxtm8tn@client.example.com 387 CSeq: 1 REGISTER 388 Contact: 389 Content-Length: 0 390 The REGISTER response would look like: 392 SIP/2.0 200 OK 393 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bKnashds7 394 From: Callee ;tag=a73kszlfl 395 To: Callee ;tag=b88sn 396 Call-ID: 1j9FpLxk3uxtm8tn@client.example.com 397 CSeq: 1 REGISTER 398 Contact: ;gruu="sip:hha9s8d=-999a@example.com" 399 Content-Length: 0 401 Note how the Contact header field in the REGISTER response contains 402 the gruu parameter with the URI sip:hha9s8d=-999a@example.com. This 403 represents a GRUU associated with the Contact URI 404 sip:callee@client.example.com. 406 The INVITE from the caller is a normal SIP INVITE. The 200 OK 407 generated by the callee, however, now contains a GRUU in the Contact 408 header field. The UA has also chosen to include a grid URI parameter 409 into the GRUU. 411 SIP/2.0 200 OK 412 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8 413 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a 414 From: Caller ;tag=n88ah 415 To: Callee ;tag=a0z8 416 Call-ID: 1j9FpLxk3uxtma7@host.example.com 417 CSeq: 1 INVITE 418 Supported: gruu 419 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 420 Contact: 421 Content-Length: -- 422 Content-Type: application/sdp 424 [SDP Not shown] 426 At some point later in the call, the caller decides to subscribe to 427 the dialog event package [10] at that specific UA. To do that, it 428 generates a SUBSCRIBE request (message 9), but directs it towards the 429 GRUU contained in the Contact header field. 431 SUBSCRIBE sip:hha9s8d=-999a@example.com;grid=99a SIP/2.0 432 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 433 From: Caller ;tag=kkaz- 434 To: Callee 435 Call-ID: faif9a@host.example.com 436 CSeq: 2 SUBSCRIBE 437 Supported: gruu 438 Event: dialog 439 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 440 Contact: 441 Content-Length: 0 443 In this example, the caller itself supports the GRUU extension, and 444 is using its own GRUU to populate the Contact header field of the 445 SUBSCRIBE. 447 This request is routed to the proxy, which proceeds to perform a 448 location lookup on the request URI. It is translated into the Contact 449 URI bound to that GRUU, and then proxied there (message 10). Note how 450 the grid parameter is maintained. 452 SUBSCRIBE sip:callee@client.example.com;grid=99a SIP/2.0 453 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK9555 454 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 455 From: Caller ;tag=kkaz- 456 To: Callee 457 Call-ID: faif9a@host.example.com 458 CSeq: 2 SUBSCRIBE 459 Supported: gruu 460 Event: dialog 461 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 462 Contact: 463 Content-Length: 0 465 9. Security Considerations 467 Since GRUUs do not reveal information about the identity of the 468 associated address-of-record or Contact URI, they provide routability 469 without identity. However, GRUUs do not provide a complete or 470 reliable solution for privacy. In particular, since the GRUU does not 471 change during the lifetime of a registration, an attacker could 472 correlate two calls as coming from the same source, which in and of 473 itself reveals information about the caller. Furthermore, GRUUs do 474 not address other aspects of privacy, such as the addresses used for 475 media transport. For a discussion of how privacy services are 476 provided in SIP, see RFC 3323 [7]. 478 It is important for a UA to be assured of the integrity of a GRUU 479 when it is given one in a REGISTER response. If the GRUU is tampered 480 with by an attacker, the result could be denial of service to the UA. 481 As a result, it is RECOMMENDED that a UA use the SIPS URI scheme when 482 registering. 484 10. IANA Considerations 486 This specification defines a new Contact header field parameter and 487 URI parameter. 489 10.1 Header Field Parameter 491 This specification defines a new header field parameter, as per the 492 registry created by [5]. The required information is as follows: 494 Header field in which the parameter can appear: Contact 496 Name of the Parameter gruu 498 RFC Reference RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 499 RFC number of this specification.]] 501 10.2 URI Parameter 503 This specification defines a new SIP URI parameter, as per the 504 registry created by [6]. 506 Name of the Parameter grid 508 RFC Reference RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 509 RFC number of this specification.]] 511 11. Acknowledgements 513 The author would like to thank Rohan Mahy, Paul Kyzivat, Alan 514 Johnston, and Cullen Jennings for their contributions to this work. 516 Normative References 518 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 519 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 520 Session Initiation Protocol", RFC 3261, June 2002. 522 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 523 Levels", BCP 14, RFC 2119, March 1997. 525 [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 526 Notification", RFC 3265, June 2002. 528 [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer 529 Method", RFC 3515, April 2003. 531 [5] Camarillo, G., "The Internet Assigned Number Authority Header 532 Field Parameter Registry for the Session Initiation Protocol", 533 draft-ietf-sip-parameter-registry-00 (work in progress), August 534 2003. 536 [6] Camarillo, G., "The Internet Assigned Number Authority Universal 537 Resource Identifier Parameter Registry for the Session 538 Initiation Protocol", draft-ietf-sip-uri-parameter-reg-00 (work 539 in progress), August 2003. 541 Informative References 543 [7] Peterson, J., "A Privacy Mechanism for the Session Initiation 544 Protocol (SIP)", RFC 3323, November 2002. 546 [8] Rosenberg, J., "A Framework for Conferencing with the Session 547 Initiation Protocol", 548 draft-ietf-sipping-conferencing-framework-00 (work in 549 progress), May 2003. 551 [9] Rosenberg, J., "Requirements for Construction and Usage of 552 Globally Routable User Agent (UA) URIs for the Session 553 Initiation Protocol (SIP)", 554 draft-rosenberg-sipping-gruu-reqs-01 (work in progress), 555 October 2003. 557 [10] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog 558 Event Package for the Session Initiation Protocol (SIP", 559 draft-ietf-sipping-dialog-package-02 (work in progress), July 560 2003. 562 Author's Address 564 Jonathan Rosenberg 565 dynamicsoft 566 600 Lanidex Plaza 567 Parsippany, NJ 07054 568 US 570 Phone: +1 973 952-5000 571 EMail: jdrosen@dynamicsoft.com 572 URI: http://www.jdrosen.net 574 Intellectual Property Statement 576 The IETF takes no position regarding the validity or scope of any 577 intellectual property or other rights that might be claimed to 578 pertain to the implementation or use of the technology described in 579 this document or the extent to which any license under such rights 580 might or might not be available; neither does it represent that it 581 has made any effort to identify any such rights. Information on the 582 IETF's procedures with respect to rights in standards-track and 583 standards-related documentation can be found in BCP-11. Copies of 584 claims of rights made available for publication and any assurances of 585 licenses to be made available, or the result of an attempt made to 586 obtain a general license or permission for the use of such 587 proprietary rights by implementors or users of this specification can 588 be obtained from the IETF Secretariat. 590 The IETF invites any interested party to bring to its attention any 591 copyrights, patents or patent applications, or other proprietary 592 rights which may cover technology that may be required to practice 593 this standard. Please address the information to the IETF Executive 594 Director. 596 Full Copyright Statement 598 Copyright (C) The Internet Society (2003). All Rights Reserved. 600 This document and translations of it may be copied and furnished to 601 others, and derivative works that comment on or otherwise explain it 602 or assist in its implementation may be prepared, copied, published 603 and distributed, in whole or in part, without restriction of any 604 kind, provided that the above copyright notice and this paragraph are 605 included on all such copies and derivative works. However, this 606 document itself may not be modified in any way, such as by removing 607 the copyright notice or references to the Internet Society or other 608 Internet organizations, except as needed for the purpose of 609 developing Internet standards in which case the procedures for 610 copyrights defined in the Internet Standards process must be 611 followed, or as required to translate it into languages other than 612 English. 614 The limited permissions granted above are perpetual and will not be 615 revoked by the Internet Society or its successors or assignees. 617 This document and the information contained herein is provided on an 618 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 619 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 620 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 621 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 622 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 624 Acknowledgement 626 Funding for the RFC Editor function is currently provided by the 627 Internet Society.