idnits 2.17.1 draft-ietf-sip-target-dialog-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 715. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 692. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 705. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- ** 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 195: '... A UAC SHOULD include a Target-Dialo...' RFC 2119 keyword, line 214: '...s not met, the UAC SHOULD NOT use this...' RFC 2119 keyword, line 216: '... UAS, it SHOULD attempt to send the ...' RFC 2119 keyword, line 260: '... field SHOULD discuss specific condi...' RFC 2119 keyword, line 264: '...log header field MUST be equal to the ...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 365 has weird spacing: '... where proxy...' == Line 371 has weird spacing: '... where proxy...' -- 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 19, 2005) is 6701 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. '2') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 2976 (ref. '3') (Obsoleted by RFC 6086) == Outdated reference: A later version (-01) exists of draft-sparks-sipping-dialogusage-00 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-05 == Outdated reference: A later version (-08) exists of draft-ietf-sipping-kpml-07 == Outdated reference: A later version (-09) exists of draft-ietf-sipping-torture-tests-07 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: June 22, 2006 December 19, 2005 6 Request Authorization through Dialog Identification in the Session 7 Initiation Protocol (SIP) 8 draft-ietf-sip-target-dialog-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 22, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This specification defines the Target-Dialog header field for the 42 Session Initiation Protocol (SIP), and the corresponding option tag, 43 tdialog. This header field is used in requests that create SIP 44 dialogs. It indicates to the recipient that the sender is aware of 45 an existing dialog with the recipient, either because the sender is 46 on the other side of that dialog, or because it has access to the 47 dialog identifiers. The recipient can then authorize the request 48 based on this awareness. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Overview of Operation . . . . . . . . . . . . . . . . . . . 4 54 3. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. User Agent Server Behavior . . . . . . . . . . . . . . . . . 7 56 5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 57 6. Extensibility Considerations . . . . . . . . . . . . . . . . 8 58 7. Header Field Definition . . . . . . . . . . . . . . . . . . 8 59 8. Security Considerations . . . . . . . . . . . . . . . . . . 9 60 9. Relationship with In-Reply-To . . . . . . . . . . . . . . . 9 61 10. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 10 62 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 63 11.1 Header Field . . . . . . . . . . . . . . . . . . . . . . 13 64 11.2 Header Field Parameters . . . . . . . . . . . . . . . . 13 65 11.2.1 local-tag . . . . . . . . . . . . . . . . . . . . . 13 66 11.2.2 remote-tag . . . . . . . . . . . . . . . . . . . . . 13 67 11.3 SIP Option Tag . . . . . . . . . . . . . . . . . . . . . 14 68 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14 69 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 13.1 Normative References . . . . . . . . . . . . . . . . . . 14 71 13.2 Informative References . . . . . . . . . . . . . . . . . 15 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . 16 73 Intellectual Property and Copyright Statements . . . . . . . 17 75 1. Introduction 77 The Session Initiation Protocol (SIP) [1] defines the concept of a 78 dialog as a persistent relationship between a pair of user agents. 79 Dialogs provide context, including sequence numbers, proxy routes, 80 and dialog identifiers. Dialogs are established through the 81 transmission of SIP requests with particular methods. Specifically, 82 the INVITE, REFER [7] and SUBSCRIBE [2] requests all create dialogs. 84 When a user agent receives a request that creates a dialog, it needs 85 to decide whether to authorize that request. For some requests, 86 authorization is a function of the identity of the sender, the 87 request method, and so on. However, many situations have been 88 identified in which a user agents' authorization decision depends on 89 whether the sender of the request is currently in a dialog with that 90 user agent, or whether the sender of the request is aware of a dialog 91 the user agent has with another entity. 93 One such example is call transfer, accomplished through REFER. If 94 user agents A and B are in an INVITE dialog, and user agent A wishes 95 to transfer user agent B to user agent C, user agent A needs to send 96 a REFER request to user agent B, asking user agent B to send an 97 INVITE request to user agent C. User agent B needs to authorize this 98 REFER. The proper authorization decision is that user agent B should 99 accept the request if it came from a user with whom B currently has 100 an INVITE dialog relationship. Current implementations deal with 101 this by sending the REFER on the same dialog as the one in place 102 between user agents A and B. However, this approach has numerous 103 problems [10]. These problems include difficulty in determining the 104 lifecycle of the dialog and its usages, and difficulties in 105 determining which messages are associated with each application 106 usage. Instead, a better approach is for user agent A to send the 107 REFER request to user agent B outside of the dialog using its 108 Globally Routable User Agent URI (GRUU) [11]. In that case, a means 109 is needed for user agent B to authorize the REFER. 111 Another example is the application interaction framework [12]. In 112 that framework, proxy servers on the path of a SIP INVITE request can 113 place user interface components on the user agent that generated or 114 received the request. To do this, the proxy server needs to send a 115 REFER request to the user agent, targeted to their GRUU, asking the 116 user agent to fetch an HTTP resource containing the user interface 117 component. In such a case, a means is needed for the user agent to 118 authorize the REFER. The appplication interaction framework 119 recommends that the request be authorized if it was sent from an 120 entity on the path of the original dialog. This can be done by 121 including the dialog identifiers in the REFER, which prove that the 122 user agent that sent the REFER is aware of those dialog identifiers 123 (this needs to be secured against eavesdroppers through the sips 124 mechanism, of course) 126 Another example is if two user agents share an INVITE dialog, and an 127 element on the path of the INVITE request wishes to track the state 128 of the INVITE. In such a case, it sends a SUBSCRIBE request to the 129 GRUU of the user agent, asking for a subscription to the dialog event 130 package. If the SUBSCRIBE request came from an element on the INVITE 131 request path, it should be authorized. 133 2. Overview of Operation 135 +--------+ +--------+ 136 | | INVITE | | 137 | Server |----------->| Server | 138 | A | | B | 139 | |...........>| | 140 +--------+ +--------+ 141 ^ REFER . \ 142 / . \ 143 / . \ 144 / . \ 145 / . \ 146 / V V 147 +--------+ +--------+ 148 | | | | 149 | User | | User | 150 | Agent | | Agent | 151 | A | | B | 152 +--------+ +--------+ 154 Figure 1 156 Figure 1 shows the basic model of operation. User agent A sends an 157 INVITE to user agent B, traversing two servers, server A and server 158 B. Both servers act as proxies for this transaction. User B sends a 159 200 OK response to the INVITE. This 200 OK includes a Supported 160 header field indicating support for both the GRUU specification 161 (through the presence of the gruu option tag) and this specification 162 (through the presence of the tdialog option tag). The 200 OK 163 response establishes a dialog between the two user agents. 165 Next, an entity that was present along the request path (server A, 166 for example) wishes to send a dialog-forming request (such as REFER) 167 requiring to user agent A or B (user B for example). So, the entity 168 acts as a user agent and sends the request to user agent B. This 169 request is addressed to the GRUU of user agent B, which server A 170 learned from inspecting the Contact header field in the 200 OK of the 171 INVITE request. This GRUU is a URI that can be used by any element 172 on the Internet, such as server A, to reach the specific user agent 173 instance that generated that 200 OK to the INVITE. 175 The request generated by server A will contain a Target-Dialog header 176 field. This header field contains the dialog identifiers for the 177 INVITE dialog between user agents A and B, composed of the Call-ID, 178 local tag, and remote tag. Server A knew to include the Target- 179 Dialog header field in the REFER request because it knows that user 180 agent B supports it. 182 When the request arrives at user agent B, it needs to make an 183 authorization decision. Because the INVITE dialog was established 184 using a sips URI, and because the dialog identifiers are 185 cryptographically random [1], no entity except for user agent A or 186 the proxies on the path of the initial INVITE request can know the 187 dialog identifiers. Thus, because the request contains those dialog 188 identifiers, user agent B can be certain that the request came from 189 either user agent A, the two proxies, or an entity to whom the user 190 agent or proxies gave the dialog identifiers. As such, it authorizes 191 the request and performs the requested actions. 193 3. UAC Behavior 195 A UAC SHOULD include a Target-Dialog header field in a request if the 196 following conditions are all true: 198 1. The request is to be sent outside of any existing dialog. 200 2. The user agent client believes that the request may not be 201 authorized by the user agent server unless the user agent client 202 can prove that it is aware of the dialog identifiers for some 203 other dialog. Call this dialog the target dialog. 205 3. The request does not otherwise contain information that indicates 206 that the UAC is aware of those dialog identifiers. 208 4. The user agent client knows that the user agent server supports 209 the Target-Dialog header field. It can know this if it has seen 210 a request or response from the user agent server within the 211 target dialog that contained a Supported header field which 212 included the tdialog option tag. 214 If the fourth condition is not met, the UAC SHOULD NOT use this 215 specification. Instead, if it is currently within a dialog with the 216 UAS, it SHOULD attempt to send the request within the existing target 217 dialog. 219 The following are examples of use cases in which these conditions are 220 met: 222 o A REFER request is sent according to the principles of [12]. 223 These REFER are sent outside of a dialog, and do not contain any 224 other information which indicates awareness of the target dialog. 225 [12] also mandates that the REFER be sent only if the UA indicates 226 support for the target dialog specification. 228 o User A is in separate calls with users B and user C. It decides to 229 start a three way call, and so morphs into a focus [15]. User B 230 would like to learn the other participants in the conference. So, 231 it sends a SUBSCRIBE request to user A (who is now acting as the 232 focus) for the conference event package [14]. It is sent outside 233 of the existing dialog between user B and the focus, and would be 234 authorized by A if user B could prove that it knows the dialog 235 identifiers for its existing dialog with the focus. Thus, the 236 Target-Dialog header field would be include in the SUBSCRIBE. 238 The following are examples of use cases in which these conditions are 239 not met: 241 o A server acting as a proxy is a participant in an INVITE dialog 242 that establishes a session. The server would like to use the 243 Keypad Markup Language (KPML) event package [16] to find out about 244 keypresses from the originating user agent. To do this, it sends 245 a SUBSCRIBE request. However, the Event header field of this 246 SUBSCRIBE contains event parameters which indicate the target 247 dialog of the subscription. As such, the request can be 248 authorized without additional information. 250 o A server acting as a proxy is a participant in an INVITE dialog 251 that establishes a session. The server would like to use the 252 dialog event package [13] to find out about dialogs at the 253 originating user agent. To do this, it sends a SUBSCRIBE request. 254 However, the Event header field of this SUBSCRIBE contains event 255 parameters which indicate the target dialog of the subscription. 256 As such, the request can be authorized without additional 257 information. 259 Specifications which intend to make use of the Target-Dialog header 260 field SHOULD discuss specific conditions in which it is to be 261 included. 263 Assuming it is to be included, the value of the call-id production in 264 the Target-Dialog header field MUST be equal to the Call-ID of the 265 target dialog. The "remote-tag" header field parameter MUST be 266 present, and MUST contain the tag that would be viewed as the remote 267 tag from the perspective of the recipient of the new request. The 268 "local-tag" header field parameter MUST be present, and MUST contain 269 the tag that would be viewed as the local tag from the perspective of 270 the recipient of the new request. 272 The request sent by the UAC SHOULD include a Require header field 273 that includes the tdialog option tag. This request should, in 274 principle, never fail with a 420 (Bad Extension) response, because 275 the UAC would not have sent the request unless it believed the UAS 276 supported the extension. If a Require header field was not included, 277 and the UAS didn't support the extension, it would normally reject 278 the request becaust it was unauthorized, probably with a 403. 279 However, without the Require header field, the UAC would not be able 280 to differentiate a 403 that arrived because the UAS didn't actually 281 understand the Target-Dialog header field (in which case the client 282 should send the request within the target dialog if it can), from a 283 403 that arrived because the UAS understood the Target-Dialog header 284 field, but elected not to authorize the request despite the fact that 285 the UAC proved its awareness of the target dialog (in which case the 286 client should not resend the request within the target dialog, even 287 if it could). 289 4. User Agent Server Behavior 291 If a user agent server receives a dialog-creating request, and wishes 292 to authorize the request, and that authorization depends on whether 293 or not the sender has knowledge of an existing dialog with the UAS, 294 and information outside of the Target-Dialog header field does not 295 provide proof of this knowledge, the UAS SHOULD check the request for 296 the existence of the Target-Dialog header field. If this header 297 field is not present, the UAS MAY still authorize the request based 298 on other means. 300 If the header field is present, and the value of the call-id 301 production, the "remote-tag" and "local-tag" values match the 302 Call-ID, remote tag and local tag of an existing dialog, and the 303 dialog that they match was established using a sips URI, the UAS 304 SHOULD authorize the request if it would authorize any entity on the 305 path of the request that created that dialog, or any entity trusted 306 by an entity on the path of the request that created that dialog. 308 If the dialog identifiers match, but they match a dialog not created 309 with a sips URI, the UAS MAY authorize the request if it would 310 authorize any entity on the path of the request that created that 311 dialog, or any entity trusted by an entity on the path of the request 312 that created that dialog. However, in this case, any eavesdropper on 313 the original dialog path would have access to the dialog identifiers, 314 and thus the authorization is optional. 316 If the dialog identifiers don't match, or if they don't contain both 317 a "remote-tag" and "local-tag" parameter, the header field MUST be 318 ignored, and authorization MAY be determined by other means. 320 5. Proxy Behavior 322 Proxy behavior is unaffected by this specification. 324 6. Extensibility Considerations 326 This specification depends on a user agent client knowing, ahead of 327 sending a request to a user agent server, whether or not that user 328 agent server supports the Target-Dialog header field. As discussed 329 in Section 3, the UAC can know this because it saw a request or 330 response sent by that UAS within the target dialog that contained the 331 Supported header field whose value included the tdialog option tag. 333 Because of this requirement, it is especially important that user 334 agents compliant to this specification include a Supported header 335 field in all dialog forming requests and responses. Inclusion of the 336 Supported header fields in requests is at SHOULD strength within RFC 337 3261. This specification does not alter that requirement. However, 338 implementors should realize that, unless the tdialog option tag is 339 placed in the Supported header field of requests and responses, this 340 extension is not likely to be used, and instead, the request is 341 likely to be resent within the existing target dialog (assuming the 342 sender is the UA on the other side of the target dialog). As such, 343 the conditions in which the SHOULD would not be followed would be 344 those rare cases in which the UA does not want to enable usage of 345 this extension. 347 7. Header Field Definition 349 The grammar for the Target-Dialog header field is defined as follows: 351 Target-Dialog = "Target-Dialog" HCOLON call-id *(SEMI 352 td-param) 353 td-param = remote-param / local-param / generic-param 354 remote-param = "remote-tag" EQUAL token 355 local-param = "local-tag" EQUAL token 357 Figure 3 and Figure 4 are an extension of Tables 2 and 3 in RFC 3261 359 [1] for the Target-Dialog header field. The column "INF" is for the 360 INFO method [3], "PRA" is for the PRACK method [4], "UPD" is for the 361 UPDATE method [5], "SUB" is for the SUBSCRIBE method [2], "NOT" is 362 for the NOTIFY method [2], "MSG" is for the MESSAGE method [6], "REF" 363 is for the REFER method [7], and "PUB" is for the PUBLISH method [8]. 365 Header field where proxy ACK BYE CAN INV OPT REG PUB 367 Target-Dialog R ar - - - o - - - 369 Figure 3: Allowed Methods for Target-Dialog 371 Header field where proxy PRA UPD SUB NOT INF MSG REF 372 Target-Dialog R ar - - o - - - o 374 Figure 4: Allowed Methods for Target-Dialog 376 8. Security Considerations 378 The Target-Dialog header field is used to authorize requests based on 379 the fact that the sender of the request has access to information 380 that only certain entities have access to. In order for such an 381 authorization decision to be secure, two conditions have to be met. 382 Firstly, no eavesdroppers can have access to this information. That 383 requires the original SIP dialog to be established using a sips URI, 384 which provides TLS on each hop. With a sips URI, only the user 385 agents and proxies on the request path will be able to know the 386 dialog identifiers. The second condition is that the dialog 387 identifiers be cryptographically random that they cannot be guessed. 388 RFC 3261 requires global uniquess for the Call-ID and 32 bits of 389 cryptographic randomness for each tag (there are two tags for a 390 dialog). Given the short duration over which a typical dialog exists 391 (perhaps as long as a day), this amount of randomness appears 392 adequate to prevent guessing attacks. However, its important to note 393 that this specification truly requires cryptographic randomness, as 394 opposed to just pseudorandom identifiers. Pseudorandom identifiers 395 reduce the probability of collision, but because they are guessable, 396 they are not sufficient to prevent an attacker from observing a 397 sequence of identifiers, guessing the next one, and then using this 398 specification to launch an attack. 400 9. Relationship with In-Reply-To 402 RFC 3261 defines the In-Reply-To header field. It provides a list of 403 Call-IDs for calls that the current request references or returns. 404 It was meant to serve a similar purpose as the Reply-To in email; to 405 faciliate in the construction of "threads" of conversations in a user 406 interface. Target-Dialog is similar, in that it also references a 407 previous session. Due to their similarities, it is important to 408 understand the differences, as these two header fields are not 409 substitutes for each other. 411 Firstly, In-Reply-To is meant for consumption by a human or a user 412 interface widget, for providing the user with a context that allows 413 them to decide what a call is about and whether they should take it. 414 Target-Dialog, on the other hand, is meant for consumption by the 415 user agent itself, to facilitate authorization of session requests in 416 specific cases where authorization is not a function of the user, but 417 rather the underlying protocols. A UA will authorize a call 418 containing Target-Dialog based on a correct value of the Target- 419 Dialog header field. 421 Secondly, Target-Dialog references a specific dialog which must be 422 currently in progress. In-Reply-To references a previous call 423 attempt, most likely one that did not result in a dialog. This is 424 why In-Reply-To uses a Call-ID, and Target-Dialog uses a set of 425 dialog identifiers. 427 Finally, In-Reply-To implies cause and effect. When In-Reply-To is 428 present, it means that the request is being sent because of the 429 previous request that was delivered. Target-Dialog does not imply 430 cause-and-effect, merely awareness for the purposes of authorization. 432 10. Example Call Flow 434 In this example, user agent A and user agent B establish an INVITE 435 initiated dialog through Server-A and Server-B, each of which acts as 436 a proxy for the INVITE. Server B would then like to use the app 437 interaction framework [12] to request user agent A to fetch an HTML 438 user interface component. To do that, it sends a REFER request to 439 A's GRUU. The flow for this is shown in Figure 5. The conventions 440 of [17] are used to describe representation of long message lines. 442 A Server-A Server-B B 443 |(1) INVITE | | | 444 |----------->| | | 445 | |(2) INVITE | | 446 | |----------->| | 447 | | |(3) INVITE | 448 | | |----------->| 449 | | |(4) 200 OK | 450 | | |<-----------| 451 | |(5) 200 OK | | 452 | |<-----------| | 453 |(6) 200 OK | | | 454 |<-----------| | | 455 |(7) ACK | | | 456 |------------------------------------->| 457 | |(8) REFER | | 458 | |<-----------| | 459 |(9) REFER | | | 460 |<-----------| | | 461 |(10) 200 OK | | | 462 |----------->| | | 463 | |(11) 200 OK | | 464 | |----------->| | 466 Figure 5 468 First, the caller sends an INVITE, as shown in message 1. 470 INVITE sips:B@example.com SIP/2.0 471 Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8 472 From: Caller ;tag=kkaz- 473 To: Callee 474 Call-ID: fa77as7dad8-sd98ajzz@host.example.com 475 CSeq: 1 INVITE 476 Max-Forwards: 70 477 Supported: gruu, tdialog 478 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER 479 Accept: application/sdp, text/html 480 481 Contact: ;schemes="http,sip,sips" 483 484 Content-Length: ... 485 Content-Type: application/sdp 487 --SDP not shown-- 488 The INVITE indicates that the caller supports GRUU (note its presence 489 in the Contact header field of the INVITE) and the Target-Dialog 490 header field. This INVITE is forwarded to the callee (messages 2-3), 491 which generates a 200 OK response that is forwarded back to the 492 caller (message 4-5). Message 5 might look like: 494 SIP/2.0 200 OK 495 Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8 496 From: Caller ;tag=kkaz- 497 To: Callee ;tag=6544 498 Call-ID: fa77as7dad8-sd98ajzz@host.example.com 499 CSeq: 1 INVITE 500 Contact: 501 Content-Length: ... 502 Content-Type: application/sdp 504 --SDP not shown-- 506 In this case, the called party does not support GRUU or the Target- 507 Dialog header field. The caller generates an ACK (message 7). 508 Server B then decides to send a REFER to user A: 510 511 REFER sips:A@example.com;opaque=urn:uuid:f81d4f 512 ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a SIP/2.0 513 514 Via: SIP/2.0/TLS serverB.example.org;branch=z9hG4bK9zz10 515 From: Server B ;tag=mreysh 516 517 To: Caller 519 520 Target-Dialog: fa77as7dad8-sd98ajzz@host.example.com 521 ;local-tag=kkaz- 522 ;remote-tag=6544 523 Refer-To: http://serverB.example.org/ui-component.html 524 Call-ID: 86d65asfklzll8f7asdr@host.example.com 525 CSeq: 1 REFER 526 Max-Forwards: 70 527 Require: tdialog 528 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY 529 Event: refer 530 Contact: 531 Content-Length: 0 533 This REFER will be delivered to server A because it was sent to the 534 GRUU. From there, it is forwarded to user agent A (message 9), and 535 authorized because of the presence of the Target-Dialog header field. 537 11. IANA Considerations 539 This specification registers a new SIP header field, and a new option 540 tag according to the processes of RFC 3261 [1], and two new header 541 field parameters according to the processes of RFC 3968 [9]. 543 11.1 Header Field 545 RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of 546 this specification.] 548 Header Field Name: Target-Dialog 550 Compact Form: none 552 11.2 Header Field Parameters 554 This section registers two header field parameters according to the 555 processes of RFC 3968 [9]. 557 11.2.1 local-tag 559 Header Field: Target-Dialog 561 Header Field Parameter: local-tag 563 Predefined Values: None 565 RFC: RFC XXXX [Note to IANA: Fill in with the RFC number of this 566 specification.] 568 11.2.2 remote-tag 570 Header Field: Target-Dialog 572 Header Field Parameter: remote-tag 574 Predefined Values: None 576 RFC: RFC XXXX [Note to IANA: Fill in with the RFC number of this 577 specification.] 579 11.3 SIP Option Tag 581 This specification registers a new SIP option tag per the guidelines 582 in Section 27.1 of RFC 3261. 584 Name: tdialog 586 Description: This option tag is used to identify the target dialog 587 header field extension. When used in a Require header field, it 588 implies that the recipient needs to support the Target-Dialog 589 header field. When used in a Supported header field, it implies 590 that the sender of the message supports it. 592 12. Acknowledgments 594 This specification is based on a header field first proposed by 595 Robert Sparks in the dialog usage draft. John Elwell provided 596 helpful comments. 598 13. References 600 13.1 Normative References 602 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 603 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 604 Session Initiation Protocol", RFC 3261, June 2002. 606 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 607 Notification", RFC 3265, June 2002. 609 [3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 611 [4] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 612 Responses in Session Initiation Protocol (SIP)", RFC 3262, 613 June 2002. 615 [5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 616 Method", RFC 3311, October 2002. 618 [6] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 619 D. Gurle, "Session Initiation Protocol (SIP) Extension for 620 Instant Messaging", RFC 3428, December 2002. 622 [7] Sparks, R., "The Session Initiation Protocol (SIP) Refer 623 Method", RFC 3515, April 2003. 625 [8] Niemi, A., "Session Initiation Protocol (SIP) Extension for 626 Event State Publication", RFC 3903, October 2004. 628 [9] Camarillo, G., "The Internet Assigned Number Authority (IANA) 629 Header Field Parameter Registry for the Session Initiation 630 Protocol (SIP)", BCP 98, RFC 3968, December 2004. 632 13.2 Informative References 634 [10] Sparks, R., "Multiple Dialog Usages in the Session Initiation 635 Protocol", draft-sparks-sipping-dialogusage-00 (work in 636 progress), July 2004. 638 [11] Rosenberg, J., "Obtaining and Using Globally Routable User 639 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 640 (SIP)", draft-ietf-sip-gruu-05 (work in progress), 641 September 2005. 643 [12] Rosenberg, J., "A Framework for Application Interaction in the 644 Session Initiation Protocol (SIP)", 645 draft-ietf-sipping-app-interaction-framework-05 (work in 646 progress), July 2005. 648 [13] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for 649 the Session Initiation Protocol (SIP)", 650 draft-ietf-sipping-dialog-package-06 (work in progress), 651 April 2005. 653 [14] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 654 Package for Conference State", 655 draft-ietf-sipping-conference-package-12 (work in progress), 656 July 2005. 658 [15] Rosenberg, J., "A Framework for Conferencing with the Session 659 Initiation Protocol", 660 draft-ietf-sipping-conferencing-framework-05 (work in 661 progress), May 2005. 663 [16] Burger, E., "A Session Initiation Protocol (SIP) Event Package 664 for Key Press Stimulus (KPML)", draft-ietf-sipping-kpml-07 665 (work in progress), December 2004. 667 [17] Sparks, R., "Session Initiation Protocol Torture Test 668 Messages", draft-ietf-sipping-torture-tests-07 (work in 669 progress), May 2005. 671 Author's Address 673 Jonathan Rosenberg 674 Cisco Systems 675 600 Lanidex Plaza 676 Parsippany, NJ 07054 677 US 679 Phone: +1 973 952-5000 680 Email: jdrosen@cisco.com 681 URI: http://www.jdrosen.net 683 Intellectual Property Statement 685 The IETF takes no position regarding the validity or scope of any 686 Intellectual Property Rights or other rights that might be claimed to 687 pertain to the implementation or use of the technology described in 688 this document or the extent to which any license under such rights 689 might or might not be available; nor does it represent that it has 690 made any independent effort to identify any such rights. Information 691 on the procedures with respect to rights in RFC documents can be 692 found in BCP 78 and BCP 79. 694 Copies of IPR disclosures made to the IETF Secretariat and any 695 assurances of licenses to be made available, or the result of an 696 attempt made to obtain a general license or permission for the use of 697 such proprietary rights by implementers or users of this 698 specification can be obtained from the IETF on-line IPR repository at 699 http://www.ietf.org/ipr. 701 The IETF invites any interested party to bring to its attention any 702 copyrights, patents or patent applications, or other proprietary 703 rights that may cover technology that may be required to implement 704 this standard. Please address the information to the IETF at 705 ietf-ipr@ietf.org. 707 Disclaimer of Validity 709 This document and the information contained herein are provided on an 710 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 711 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 712 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 713 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 714 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 715 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 717 Copyright Statement 719 Copyright (C) The Internet Society (2005). This document is subject 720 to the rights, licenses and restrictions contained in BCP 78, and 721 except as set forth therein, the authors retain all their rights. 723 Acknowledgment 725 Funding for the RFC Editor function is currently provided by the 726 Internet Society.