idnits 2.17.1 draft-ietf-sip-target-dialog-00.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 597. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 186: '... A UAC SHOULD include a Target-Dialo...' RFC 2119 keyword, line 208: '...s not met, the UAC SHOULD NOT use this...' RFC 2119 keyword, line 210: '... UAS, it SHOULD attempt to send the ...' RFC 2119 keyword, line 214: '... MUST be equal to the Call-ID of the...' RFC 2119 keyword, line 215: '... field parameter MUST be present, and ...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 312 has weird spacing: '... where proxy...' == Line 318 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 (April 4, 2005) is 6963 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-02 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-app-interaction-framework-04 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialog-package-05 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-conference-package-08 Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPP J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: October 3, 2005 April 4, 2005 6 Request Authorization through Dialog Identification in the Session 7 Initiation Protocol (SIP) 8 draft-ietf-sip-target-dialog-00 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 3, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This specification defines the Target-Dialog header field for the 44 Session Initiation Protocol (SIP), and the corresponding option tag, 45 tdialog. This header field is used in requests that create SIP 46 dialogs. It indicates to the recipient that the sender is aware of 47 an existing dialog with the recipient, either because the sender is 48 on the other side of that dialog, or because it has access to the 49 dialog identifiers. The recipient can then authorize the request 50 based on this awareness. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Overview of Operation . . . . . . . . . . . . . . . . . . . 4 56 3. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. User Agent Server Behavior . . . . . . . . . . . . . . . . . 6 58 5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 59 6. Extensibility Considerations . . . . . . . . . . . . . . . . 7 60 7. Header Field Definition . . . . . . . . . . . . . . . . . . 7 61 8. Security Considerations . . . . . . . . . . . . . . . . . . 8 62 9. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 8 63 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 64 10.1 Header Field . . . . . . . . . . . . . . . . . . . . . . 12 65 10.2 SIP Option Tag . . . . . . . . . . . . . . . . . . . . . 12 66 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 12.1 Normative References . . . . . . . . . . . . . . . . . . . 12 69 12.2 Informative References . . . . . . . . . . . . . . . . . . 13 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . 14 71 Intellectual Property and Copyright Statements . . . . . . . 15 73 1. Introduction 75 The Session Initiation Protocol (SIP) [1] defines the concept of a 76 dialog as a persistent relationship between a pair of user agents. 77 Dialogs provide context, including sequence numbers, proxy routes, 78 and dialog identifiers. Dialogs are established through the 79 transmission of SIP requests with particular methods. Specifically, 80 the INVITE, REFER [7], SUBSCRIBE and NOTIFY [2] requests all create 81 dialogs. 83 When a user agent receives a request that creates a dialog, it needs 84 to decide whether to authorize that request. For some requests, 85 authorization is a function of the identity of the sender, the 86 request method, and so on. However, many situations have been 87 identified in which a user agents' authorization decision depends on 88 whether the sender of the request is currently in a dialog with it, 89 or aware of a dialog with it. 91 One such example is call transfer, accomplished through REFER. If 92 user agents A and B are in an INVITE dialog, and user agent A wishes 93 to transfer user agent B to user agent C, user agent A needs to send 94 a REFER request to user agent B, asking user agent B to send an 95 INVITE request to user agent C. User agent B needs to authorize this 96 REFER. The proper authorization decision is that user agent B should 97 accept the request if it came from a user with whom B currently has 98 an INVITE dialog relationship. Current implementations deal with 99 this by sending the REFER on the same dialog as the one in place 100 between user agents A and B. However, this approach has numerous 101 problems [8]. These problems include difficulty in determining the 102 lifecycle of the dialog and its usages and difficulties in 103 determining which messages are associated with each application 104 usage. Instead, a better approach is for user agent A to send the 105 REFER request to user agent C outside of the dialog using its 106 Globally Routable User Agent URI (GRUU) [9]. In that case, a means 107 is needed for user agent B to authorize the REFER. 109 Another example is the application interaction framework [10]. In 110 that framework, proxy servers on the path of a SIP INVITE request can 111 place user interface components on the user agent that generated or 112 received the request. To do this, the proxy server needs to send a 113 REFER request to the user agent, targeted to their GRUU, asking the 114 user agent to fetch an HTTP resource containing the user interface. 115 In such a case, a means is needed for the user agent to authorize the 116 REFER. 118 Another example is if two user agents share an INVITE dialog, and an 119 element on the path of the INVITE request wishes to track the state 120 of the INVITE. In such a case, it sends a SUBSCRIBE request to the 121 GRUU of the user agent, asking for a subscription to the dialog event 122 package. If the SUBSCRIBE request came from an element on the INVITE 123 request path, it should be authorized. 125 2. Overview of Operation 127 +--------+ +--------+ 128 | | INVITE | | 129 | Server |----------->| Server | 130 | A | | B | 131 | |...........>| | 132 +--------+ +--------+ 133 ^ REFER . \ 134 / . \ 135 / . \ 136 / . \ 137 / . \ 138 / V V 139 +--------+ +--------+ 140 | | | | 141 | User | | User | 142 | Agent | | Agent | 143 | A | | B | 144 +--------+ +--------+ 146 Figure 1 148 Figure 1 shows the basic model of operation. User agent A sends an 149 INVITE to user agent B, traversing two servers, server A and server 150 B. Both servers act as proxies for this transaction. User B sends a 151 200 OK response to the INVITE. This 200 OK includes a Supported 152 header field indicating support for both the GRUU specification 153 (through the presence of the gruu option tag) and this specification 154 (through the presence of the tdialog option tag). The 200 OK 155 response establishes a dialog between the two user agents. Next, 156 server A wishes to REFER user agent B to fetch an HTTP resource. So, 157 it acts as a user agent and sends a REFER request to user agent B. 158 This REFER is addressed to the GRUU of user agent B, which server A 159 learned from inspecting the Contact header field in the 200 OK of the 160 INVITE request. This GRUU is a URI that can be used by any element 161 on the Internet, such as server A, to reach the specific user agent 162 instance that generated that 200 OK to the INVITE. 164 The REFER request generated by server A will contain a Target-Dialog 165 header field. This header field contains the dialog identifiers for 166 the INVITE dialog between user agents A and B, composed of the 167 Call-ID, local tag, and remote tag. Server A knew to include the 168 Target-Dialog header field in the REFER request because it knows that 169 user agent B supports it. 171 When the REFER request arrives at user agent B, it needs to make an 172 authorization decision. Because the INVITE dialog was established 173 using a sips URI, and because the dialog identifiers are 174 cryptographically random [1], no entity except for user agent A or 175 the proxies on the path of the initial INVITE request can know the 176 dialog identifiers. Thus, because the REFER request contains those 177 dialog identifiers, user agent B can be certain that the REFER 178 request came from either user agent A, the two proxies, or an entity 179 to whom the user agent or proxies gave the dialog identifiers. As 180 such, it authorizes the REFER request, and fetches the HTTP resource 181 identified by the URI of the Refer-To header field in the REFER 182 request. 184 3. UAC Behavior 186 A UAC SHOULD include a Target-Dialog header field in a request if the 187 following conditions are all true: 189 1. The request is to be sent outside of any existing dialog. 191 2. The user agent client believes that the request will not be 192 authorized by the user agent server unless the user agent client 193 can prove that it is aware of the dialog identifiers for some 194 other dialog. Call this dialog the target dialog. Examples of 195 this condition include (1) REFER requests sent outside of a 196 dialog by a participant in the dialog, (2) subscriptions to the 197 dialog event package [11] when that SUBSCRIBE request is sent by 198 a participant in the dialog, and (3) subscriptions to the 199 conference event package [12] when that SUBSCRIBE request is sent 200 by a participant in the conference with a dialog to the focus. 202 3. The user agent client knows that the user agent server supports 203 the Target-Dialog header field. It can know this if it has seen 204 a request or response from the user agent server within the 205 target dialog that contained a Supported header field which 206 included the tdialog option tag. 208 If the third condition is not met, the UAC SHOULD NOT use this 209 specification. Instead, if it is currently within a dialog with the 210 UAS, it SHOULD attempt to send the request within the existing target 211 dialog. 213 The value of the call-id production in the Target-Dialog header field 214 MUST be equal to the Call-ID of the target dialog. The "remote-tag" 215 header field parameter MUST be present, and MUST contain the tag that 216 would be viewed as the remote tag from the perspective of the 217 recipient of the new request. The "local-tag" header field parameter 218 MUST be present, and MUST contain the tag that would be viewed as the 219 local tag from the perspective of the recipient of the new request. 221 The request sent by the UAC SHOULD include a Require header field 222 that includes the tdialog option tag. This request should, in 223 principle, never fail with a 420 (Bad Extension) response, because 224 the UAC would not have sent the request unless it believed the UAS 225 supported the extension. If a Require header field was not included, 226 and the UAS didn't support the extension, it would normally reject 227 the request becaust it was unauthorized, probably with a 403. 228 However, without the Require header field, the UAC would not be able 229 to differentiate a 403 that arrived because the UAS didn't actually 230 understand the Target-Dialog header field (in which case the client 231 should send the request within the target dialog if it can), from a 232 403 that arrived because the UAS understood the Target-Dialog header 233 field, but elected not to authorize the request despite the fact that 234 the UAC proved its awareness of the target dialog (in which case the 235 client should not resend the request within the target dialog, even 236 if it could). 238 4. User Agent Server Behavior 240 If a user agent server receives a dialog-creating request, and wishes 241 to authorize the request, and that authorization depends on whether 242 or not the sender has knowledge of an existing dialog with the UAS, 243 the UAS SHOULD check the request for the existence of the 244 Target-Dialog header field. If this header field is not present, the 245 UAS MAY still authorize the request based on other means. 247 If the header field is present, and the value of the call-id 248 production, the "remote-tag" and "local-tag" values match the 249 Call-ID, remote tag and local tag of an existing dialog, and the 250 dialog that they match was established using a sips URI, the UAS 251 SHOULD authorize the request if it would authorize any entity on the 252 path of the request that created that dialog, or any entity trusted 253 by an entity on the path of the request that created that dialog. 255 If the dialog identifiers match, but they match a dialog not created 256 with a sips URI, the UAS MAY authorize the request if it would 257 authorize any entity on the path of the request that created that 258 dialog, or any entity trusted by an entity on the path of the request 259 that created that dialog. However, in this case, any eavesdropper on 260 the original dialog path would have access to the dialog identifiers, 261 and thus the authorization strength is reduced to MAY. 263 If the dialog identifiers don't match, or if they don't contain both 264 a "remote-tag" and "local-tag" parameter, the header field MUST be 265 ignored, and authorization MAY be determined by other means. 267 5. Proxy Behavior 269 Proxy behavior is unaffected by this specification. 271 6. Extensibility Considerations 273 This specification depends on a user agent client knowing, ahead of 274 sending a request to a user agent server, whether or not that user 275 agent server supports the Target-Dialog header field. As discussed 276 in Section 3, the UAC can know this because it saw a request or 277 response sent by that UAS within the target dialog that contained the 278 Supported header field whose value included the tdialog option tag. 280 Because of this requirement, it is especially important that user 281 agents compliant to this specification include a Supported header 282 field in all dialog forming requests and responses. Inclusion of the 283 Supported header fields in requests is at SHOULD strength within RFC 284 3261. This specification does not alter that requirement. However, 285 implementors should realize that, unless the tdialog option tag is 286 placed in the Supported header field of requests and responses, this 287 extension is not likely to be used, and instead, the request is 288 likely to be resent within the existing target dialog (assuming the 289 sender is the UA on the other side of the target dialog). As such, 290 the conditions in which the SHOULD would not be followed would be 291 those rare cases in which the UA does not want to enable usage of 292 this extension. 294 7. Header Field Definition 296 The grammar for the Target-Dialog header field is defined as follows: 298 Target-Dialog = "Target-Dialog" HCOLON call-id *(SEMI 299 td-param) 300 td-param = remote-param / local-param / generic-param 301 remote-param = "remote-tag" EQUAL token 302 local-param = "local-tag" EQUAL token 304 Figure 3 and Figure 4 are an extension of Tables 2 and 3 in RFC 3261 306 [1] for the Target-Dialog header field. The column "INF" is for the 307 INFO method [3], "PRA" is for the PRACK method [4], "UPD" is for the 308 UPDATE method [5], "SUB" is for the SUBSCRIBE method [2], "NOT" is 309 for the NOTIFY method [2], "MSG" is for the MESSAGE method [6], and 310 "REF" is for the REFER method [7] 312 Header field where proxy ACK BYE CAN INV OPT REG 314 Target-Dialog R ar - - - o - - 316 Figure 3: Allowed Methods for Target-Dialog 318 Header field where proxy PRA UPD SUB NOT INF MSG REF 319 Target-Dialog R ar - - o - - - o 321 Figure 4: Allowed Methods for Target-Dialog 323 8. Security Considerations 325 The Target-Dialog header field is used to authorize requests based on 326 the fact that the sender of the request has access to information 327 that only certain entities have access to. In order for such an 328 authorization decision to be secure, two conditions have to be met. 329 Firstly, no eavesdroppers can have access to this information. That 330 requires the original SIP dialog to be established using a sips URI, 331 which provides TLS on each hop. With a sips URI, only the user 332 agents and proxies on the request path will be able to know the 333 dialog identifiers. The second condition is that the dialog 334 identifiers be sufficiently random that they cannot be guessed. RFC 335 3261 requires global uniquess for the Call-ID and 32 bits of 336 randomness for each tag (there are two tags for a dialog). Given the 337 short duration over which a typical dialog exists (perhaps as long as 338 a day), this amount of randomness appears adequate to prevent 339 guessing attacks. 341 9. Example Call Flow 343 In this example, user agent A and user agent B establish an INVITE 344 initiated dialog. User agent A would then like to establish a 345 subscription to the dialog event package. To do this, it sends a 346 SUBSCRIBE request outside of the context of the dialog, using the 347 Target-Dialog header field. This call flow is shown in Figure 5. 349 A Proxy A Proxy B B 350 |(1) INVITE | | | 351 |----------->| | | 352 | |(2) INVITE | | 353 | |----------->| | 354 | | |(3) INVITE | 355 | | |----------->| 356 | | |(4) 200 OK | 357 | | |<-----------| 358 | |(5) 200 OK | | 359 | |<-----------| | 360 |(6) 200 OK | | | 361 |<-----------| | | 362 |(7) ACK | | | 363 |------------------------>| | 364 | | |(8) ACK | 365 | | |----------->| 366 |(9) SUBSCRIBE | | 367 |----------->| | | 368 | |(10) SUBSCRIBE | 369 | |----------->| | 370 | | |(11) SUBSCRIBE 371 | | |----------->| 372 | | |(12) 200 OK | 373 | | |<-----------| 374 | |(13) 200 OK | | 375 | |<-----------| | 376 |(14) 200 OK | | | 377 |<-----------| | | 378 | |(15) NOTIFY | | 379 | |<------------------------| 380 |(16) NOTIFY | | | 381 |<-----------| | | 382 |(17) 200 OK | | | 383 |----------->| | | 384 | |(18) 200 OK | | 385 | |------------------------>| 387 Figure 5 389 First, the caller sends an INVITE, as shown in message 1. 391 INVITE sips:B@example.com SIP/2.0 392 Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8 393 From: Caller ;tag=kkaz- 394 To: Callee 395 Call-ID: fa77as7dad8-sd98ajzz@host.example.com 396 CSeq: 1 INVITE 397 Max-Forwards: 70 398 Supported: gruu, tdialog 399 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY 400 Accept: application/dialog-info+xml 401 Contact: 402 Content-Length: ... 403 Content-Type: application/sdp 405 --SDP not shown-- 407 This is forwarded to the callee (messages 2-3), which generates a 200 408 OK response that is forwarded back to the caller (message 4-5). The 409 200 OK received by the caller (message 6) will look like: 411 SIP/2.0 200 OK 412 Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8;received=192.0.2.1 413 From: Caller ;tag=kkaz- 414 To: Callee ;tag=6544 415 Call-ID: fa77as7dad8-sd98ajzz@host.example.com 416 CSeq: 1 INVITE 417 Supported: gruu, tdialog 418 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, SUBSCRIBE 419 Allow-Events: dialog 420 Contact: 421 Content-Length: ... 422 Content-Type: application/sdp 424 --SDP not shown-- 426 The caller generates an ACK (message 7). Because user B made use of 427 a GRUU, even though neither proxy record-routed, the ACK is delivered 428 to the proxy of user B, and then forwarded to them (message 8). User 429 A then decides to subscribe to the dialog event package for dialog 430 events at user B. The SUBSCRIBE it sends looks like: 432 SUBSCRIBE sips:hgasd9f88ggd7gasl@example.org SIP/2.0 433 Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz10 434 From: Caller ;tag=mreysh 435 To: Callee 436 Event: dialog;call-id=fa77as7dad8-sd98ajzz@host.example.com 437 ;from-tag=kkaz-;to-tag=6544 438 Accept: application/dialog-info+xml 439 Target-Dialog: fa77as7dad8-sd98ajzz@host.example.com 440 ;remote-tag=kkaz- 441 ;local-tag=6544 442 Call-ID: 86d65asfklzll8f7asdr@host.example.com 443 CSeq: 1 SUBSCRIBE 444 Max-Forwards: 70 445 Supported: gruu, tdialog 446 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY 447 Contact: ;schemes="sip,sips" 448 Content-Length: 0 450 Note that this SUBSCRIBE request contains both a Target-Dialog header 451 field and Event header field parameters that identify the dialog 452 being subscribed to. Those these have the same content (dialog 453 identifers for the existing INVITE dialog), they have different 454 semantics. The Target-Dialog header field is used for authorization, 455 and the Event header field parameters indicate which dialogs are 456 being subscribed to. These need not be the same. 458 The SUBSCRIBE is forwarded to proxy B (message 10), and from there to 459 user B (message 11). Because of the presence of the Target-Dialog 460 header field, the request is authorized and processed. It responds 461 with a 200 OK (message 12), which is forwarded to proxy A (message 462 13) and then to user A (message 14). This response looks like: 464 SIP/2.0 200 OK 465 Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz10;received=192.0.2.1 466 From: Caller ;tag=mreysh 467 To: Callee ;tag=trdppmdrysh 468 Call-ID: 86d65asfklzll8f7asdr@host.example.com 469 CSeq: 1 SUBSCRIBE 470 Supported: gruu, tdialog 471 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, SUBSCRIBE 472 Allow-Events: dialog 473 Contact: 474 Content-Length: 0 476 This is followed by a NOTIFY (message 15). 478 10. IANA Considerations 480 This specification registers a new SIP header field and a new option 481 tag according to the processes of RFC 3261 [1]. 483 10.1 Header Field 485 RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of 486 this specification.] 488 Header Field Name: Target-Dialog 490 Compact Form: none 492 10.2 SIP Option Tag 494 This specification registers a new SIP option tag per the guidelines 495 in Section 27.1 of RFC 3261. 497 Name: tdialog 499 Description: This option tag is used to identify the target dialog 500 header field extension. When used in a Require header field, it 501 implies that the recipient needs to support the Target-Dialog 502 header field. When used in a Supported header field, it implies 503 that the sender of the message supports it. 505 11. Acknowledgments 507 This specification is based on a header field first proposed by 508 Robert Sparks in the dialog usage draft. John Elwell provided 509 helpful comments. 511 12. References 513 12.1 Normative References 515 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 516 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 517 Session Initiation Protocol", RFC 3261, June 2002. 519 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 520 Notification", RFC 3265, June 2002. 522 [3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 524 [4] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 525 Responses in Session Initiation Protocol (SIP)", RFC 3262, June 526 2002. 528 [5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 529 Method", RFC 3311, October 2002. 531 [6] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. 532 Gurle, "Session Initiation Protocol (SIP) Extension for Instant 533 Messaging", RFC 3428, December 2002. 535 [7] Sparks, R., "The Session Initiation Protocol (SIP) Refer 536 Method", RFC 3515, April 2003. 538 12.2 Informative References 540 [8] Sparks, R., "Multiple Dialog Usages in the Session Initiation 541 Protocol", draft-sparks-sipping-dialogusage-00 (work in 542 progress), July 2004. 544 [9] Rosenberg, J., "Obtaining and Using Globally Routable User 545 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 546 (SIP)", draft-ietf-sip-gruu-02 (work in progress), July 2004. 548 [10] Rosenberg, J., "A Framework for Application Interaction in the 549 Session Initiation Protocol (SIP)", 550 draft-ietf-sipping-app-interaction-framework-04 (work in 551 progress), February 2005. 553 [11] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for 554 the Session Initiation Protocol (SIP)", 555 draft-ietf-sipping-dialog-package-05 (work in progress), 556 November 2004. 558 [12] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 559 Package for Conference State", 560 draft-ietf-sipping-conference-package-08 (work in progress), 561 December 2004. 563 Author's Address 565 Jonathan Rosenberg 566 Cisco Systems 567 600 Lanidex Plaza 568 Parsippany, NJ 07054 569 US 571 Phone: +1 973 952-5000 572 EMail: jdrosen@cisco.com 573 URI: http://www.jdrosen.net 575 Intellectual Property Statement 577 The IETF takes no position regarding the validity or scope of any 578 Intellectual Property Rights or other rights that might be claimed to 579 pertain to the implementation or use of the technology described in 580 this document or the extent to which any license under such rights 581 might or might not be available; nor does it represent that it has 582 made any independent effort to identify any such rights. Information 583 on the procedures with respect to rights in RFC documents can be 584 found in BCP 78 and BCP 79. 586 Copies of IPR disclosures made to the IETF Secretariat and any 587 assurances of licenses to be made available, or the result of an 588 attempt made to obtain a general license or permission for the use of 589 such proprietary rights by implementers or users of this 590 specification can be obtained from the IETF on-line IPR repository at 591 http://www.ietf.org/ipr. 593 The IETF invites any interested party to bring to its attention any 594 copyrights, patents or patent applications, or other proprietary 595 rights that may cover technology that may be required to implement 596 this standard. Please address the information to the IETF at 597 ietf-ipr@ietf.org. 599 Disclaimer of Validity 601 This document and the information contained herein are provided on an 602 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 603 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 604 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 605 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 606 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 607 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 609 Copyright Statement 611 Copyright (C) The Internet Society (2005). This document is subject 612 to the rights, licenses and restrictions contained in BCP 78, and 613 except as set forth therein, the authors retain all their rights. 615 Acknowledgment 617 Funding for the RFC Editor function is currently provided by the 618 Internet Society.