idnits 2.17.1 draft-ietf-sipping-gruu-reg-event-06.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 517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 507. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (May 17, 2006) is 6554 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 458, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 467, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-07 -- Obsolete informational reference (is this intentional?): RFC 3455 (ref. '6') (Obsoleted by RFC 7315) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sipping P. Kyzivat 3 Internet-Draft Cisco Systems, Inc. 4 Expires: November 18, 2006 May 17, 2006 6 Registration Event Package Extension for Session Initiation Protocol 7 (SIP) Globally Routable User Agent URIs (GRUU) 8 draft-ietf-sipping-gruu-reg-event-06 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 November 18, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 RFC 3680 defines a Session Initiation Protocol (SIP) event package 42 for registration state. This package allows a watcher to learn about 43 information stored by a SIP registrar, including its registered 44 contact. 46 However, the registered contact is frequently unreachable and thus 47 not useful for watchers. The Globally Routable User Agent URI (GRUU) 48 has been defined for SIP as a URI that is capable of reaching a 49 particular contact, however this URI is not present in the format 50 defined in RFC 3680. This specification defines an extension to the 51 registration event package to include a GRUU. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Notifier Processing of SUBSCRIBE Requests . . . . . . . . . . 4 59 5. Notifier Generation of NOTIFY Requests . . . . . . . . . . . . 4 60 6. Subscriber Processing of NOTIFY Requests . . . . . . . . . . . 4 61 7. Sample reginfo Document . . . . . . . . . . . . . . . . . . . 5 62 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 8.1. Example: Welcome Notice . . . . . . . . . . . . . . . . . 5 64 8.2. Example: Implicit Registration . . . . . . . . . . . . . . 6 65 9. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 8 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 10.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 9 68 10.2. XML Schema Registration . . . . . . . . . . . . . . . . . 10 69 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 71 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 13.1. Normative References . . . . . . . . . . . . . . . . . . . 10 73 13.2. Informative References . . . . . . . . . . . . . . . . . . 11 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 Intellectual Property and Copyright Statements . . . . . . . . . . 13 77 1. Introduction 79 RFC 3680 [2] defines a Session Initiation Protocol (SIP) event 80 package for registration state. This package allows a watcher to 81 learn about information stored by a SIP registrar, including the 82 registered contacts. 84 However, a registered contact is frequently unreachable from hosts 85 outside of the domain of the user agent. It is commonly a private 86 address, or even when public, direct access to it may be blocked by 87 firewalls. 89 The Globally Routable User Agent URI (GRUU) [3] has been defined as a 90 URI that reaches a particular UA instance, but is reachable by any 91 host on the Internet. The GRUU represents another piece of 92 registration state. However, the GRUU is not included in the 93 notifications provided by RFC 3860. For many applications of the 94 registration event package, the GRUU is needed, and not the 95 registered contact. 97 For example, the Welcome Notices example in [2] will only operate 98 correctly if the contact address in the reg event notification is 99 reachable by the sender of the welcome notice. When the registering 100 device is using the GRUU extension, it is likely that the registered 101 contact address will not be globally addressable, and the GRUU should 102 be used as the target address for the MESSAGE. 104 Another case where this feature may be helpful is within the 3GPP IP 105 Multimedia Subsystem (IMS). IMS employs a technique where a REGISTER 106 of a contact address to one Address of Record (AOR) causes the 107 implicit registration of the same contact to other associated AORs. 108 If a GRUU is requested and obtained as part of the registration 109 request, then additional GRUU will also be needed for the implicit 110 registrations. While assigning the additional GRUU is 111 straightforward, informing the registering UA of them is not. In 112 IMS, UAs typically subscribe to the "reg" event, and subscriptions to 113 the "reg" event for an AOR result in notifications containing 114 registration state for all the associated AORs. The proposed 115 extension provides a way to easily deliver the GRUU for the 116 associated AORs. 118 The reg event package has provision for including extension elements 119 within the element. This document defines a new element 120 that may be used in that context to deliver the GRUU corresponding to 121 the contact. 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119. [1] 129 3. Description 131 A new element () is defined which contains a GRUU. 133 This optional element is included within the body of a NOTIFY for the 134 "reg" event package when a GRUU is associated with the contact. The 135 contact URI and the GRUU are then both available to the watcher. 137 4. Notifier Processing of SUBSCRIBE Requests 139 Unchanged from RFC 3680 [2]. 141 5. Notifier Generation of NOTIFY Requests 143 A notifier for the "reg" event package [2] SHOULD include the 144 element when a contact has an Instance ID and a GRUU is associated 145 with the combination of the AOR and the Instance ID. When present, 146 the element MUST be be positioned as a child of the 147 element. 149 Note that it is possible for multiple registered contacts to share 150 the same instance ID. In such a case, each element will 151 have a child element, and the URI contained within those 152 elements will be identical. Since a particular contact can 153 not be associated with more than one instance ID, a element 154 will never have more than one child element. 156 The content of the element is the GRUU that is associated with 157 the instance ID and AOR of the registered contact. 159 6. Subscriber Processing of NOTIFY Requests 161 When a subscriber receives a "reg" event notification [2] with a 162 containing a , it SHOULD use the GRUU in preference 163 to the corresponding when sending SIP requests to the contact. 165 Subscribers that are unaware of this extension will, as required by 166 [2], ignore the element. 168 7. Sample reginfo Document 170 Note: This example and others in the following section are 171 indented for readability by the addition of a fixed amount of 172 whitespace to the beginning of each line. This whitespace is not 173 part of the example. The conventions of [8] are used to describe 174 representation of long message lines. 176 The following is an example registration information document 177 including the new element: 179 180 183 185 188 sip:user@192.0.2.1 189 190 191 "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" 192 193 194 195 sip:user@example.com 196 ;gruu;opaque=hha9s8d-999a 197 198 199 200 202 8. Examples 204 Note: In the following examples the SIP messages have been 205 simplified, removing headers that are not pertinent to the example. 207 When the value of the Content-Length header field is "..." this means 208 that the value should be whatever the computed length of the body is. 210 8.1. Example: Welcome Notice 212 Consider the Welcome Notices example in [2]. When the application 213 server receives a notification of a new registration containing the 214 reginfo shown in Section 7 it should address messages using the 215 contained GRUU as follows: 217 MESSAGE sip:user@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 218 To: 219 From: "SIPland Notifier" ;tag=7xy8 220 Content-Type: text/plain 221 Content-Length: ... 223 Welcome to SIPland! 224 Blah, blah, blah. 226 8.2. Example: Implicit Registration 228 In an 3GPP IMS setting, a UA may send a single register message, 229 requesting assignment of a GRUU, as follows: 231 REGISTER sip:example.net SIP/2.0 232 From: ;tag=5ab4 233 To: 234 Contact: 235 ;expires=3600 236 ;+sip.instance="" 237 Supported: path, gruu 238 Content-Length: 0 240 The response reports success of the registration and returns the GRUU 241 assigned for the combination of AOR, Instance ID, and Contact. It 242 also indicates (via the P-Associated-URI header [6]) that there are 243 two other associated AORs that may have been implicitly registered 244 using the same contact. Each of those implicitly registered AORs 245 will have a unique GRUU assigned. The REGISTER response will not 246 include those GRUU; it will only include the GRUU for the AOR and 247 instance ID explicitly included in the registration. 249 SIP/2.0 200 OK 250 From: ;tag=5ab4 251 To: ;tag=373392 252 Path: 253 Service-Route: 254 Contact: 255 ;expires=3600 256 ;+sip.instance="" 257 ;gruu="sip:user_aor_1@example.net;gruu;opaque=hha9s8d-999a" 258 P-Associated-URI: , 259 260 Content-Length: 0 262 The UA then subscribes to the "reg" event package as follows: 264 SUBSCRIBE sip:user_aor_1@example.net SIP/2.0 265 From: ;tag=27182 266 To: 267 Route: 268 Event: reg 269 Expires: 3600 270 Accept: application/reginfo+xml 271 Contact: 272 Content-Length: 0 274 (The successful response to the subscription is not shown.) Once the 275 subscription is established an initial notification is sent giving 276 registration status. In IMS deployments the response includes, in 277 addition to the status for the requested URI, the status for the 278 other associated URIs. 280 NOTIFY sip:user_aor_1@example.net;gruu;opaque=hha9s8d-999a SIP/2.0 281 From: ;tag=27182 282 To: ;tag=262281 283 Subscription-State: active;expires=3600 284 Event: reg 285 Content-Type: application/reginfo+xml 286 Contact: 287 Content-Length: ... 289 290 293 295 297 298 sip:ua.example.com 299 300 301 302 "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" 303 304 305 306 sip:user_aor_1@example.net 307 ;gruu;opaque=hha9s8d-999a 308 309 310 311 313 315 316 sip:ua.example.com 317 318 319 320 "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" 321 322 323 324 sip:user_aor_2@example.net 325 ;gruu;opaque=hha9s8d-999b 326 327 328 329 333 335 336 sip:ua.example.com 337 338 339 340 "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" 341 342 343 344 sip:+358504821437@example.net;user=phone 345 ;gruu;opaque=hha9s8d-999c 346 347 348 349 351 The status indicates that the associated URIs all have the same 352 contact registered. It also includes the unique GRUU that has been 353 assigned to each. The UA may then retain those GRUU for use when 354 establishing dialogs using the corresponding AORs. 356 9. XML Schema Definition 358 The element is defined within a new XML namespace URI. This 359 namespace is "urn:ietf:params:xml:ns:gruuinfo". The schema for the 360 element is: 362 363 368 369 371 10. IANA Considerations 373 There are two IANA considerations associated with this specification. 375 10.1. URN Sub-Namespace Registration 377 This section registers a new XML namespace, per the guidelines in 378 [4]. 380 URI: The URI for this namespace is urn:ietf:params:xml:ns:gruuinfo 382 Registrant Contact: IETF, SIPPING working group, , 383 Paul Kyzivat 385 XML: 387 BEGIN 388 389 391 392 393 395 Reg Information GRUU Extension Namespace 396 397 398

Namespace for Reg Information GRUU Extension

399

urn:ietf:params:xml:ns:gruuinfo

400

See RFCXXXX [[NOTE 401 TO RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of 402 this specification]].

403 405 406 END 408 10.2. XML Schema Registration 410 This section registers an XML schema per the procedures in [4]. 412 URI: urn:ietf:params:xml:schema:gruuinfo. 414 Registrant Contact: IETF, SIPPING working group, , 415 Paul Kyzivat 417 The XML for this schema can be found in Section 9. 419 11. Security Considerations 421 Security considerations for the registration event package is 422 discussed in RFC 3680 [2], and those considerations apply here. 424 If the contact address is not reachable by the subscriber to the 425 registration event package, then its disclosure may arguably be 426 considered of minimal security risk. In that case the inclusion of 427 the GRUU may be considered to increase the risk by providing a 428 reachable address. On the other hand, requests addressed to the GRUU 429 are always first processed by the servicing proxy before they reach 430 the intended user agent. The proxy may control access as desired, 431 just as it may for the AOR. In this respect disclosing the GRUU 432 presents no more risk than disclosing the AOR. 434 12. Acknowledgements 436 The author would like to thank Jonathan Rosenberg for encouraging 437 this draft, and Jari Urpalainen for assistance with the XML. 439 13. References 441 13.1. Normative References 443 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 444 Levels", BCP 14, RFC 2119, March 1997. 446 [2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 447 Package for Registrations", RFC 3680, March 2004. 449 [3] Rosenberg, J., "Obtaining and Using Globally Routable User Agent 450 (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", 451 draft-ietf-sip-gruu-07 (work in progress), May 2006. 453 [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 454 January 2004. 456 13.2. Informative References 458 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 459 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 460 Session Initiation Protocol", RFC 3261, June 2002. 462 [6] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header 463 (P-Header) Extensions to the Session Initiation Protocol (SIP) 464 for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, 465 January 2003. 467 [7] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User 468 Agent Capabilities in the Session Initiation Protocol (SIP)", 469 RFC 3840, August 2004. 471 [8] Sparks, R., "Session Initiation Protocol Torture Test Messages", 472 draft-ietf-sipping-torture-tests-09 (work in progress), 473 November 2005. 475 Author's Address 477 Paul H. Kyzivat 478 Cisco Systems, Inc. 479 1414 Massachusetts Avenue 480 Boxborough, MA 01719 481 USA 483 Email: pkyzivat@cisco.com 485 Intellectual Property Statement 487 The IETF takes no position regarding the validity or scope of any 488 Intellectual Property Rights or other rights that might be claimed to 489 pertain to the implementation or use of the technology described in 490 this document or the extent to which any license under such rights 491 might or might not be available; nor does it represent that it has 492 made any independent effort to identify any such rights. Information 493 on the procedures with respect to rights in RFC documents can be 494 found in BCP 78 and BCP 79. 496 Copies of IPR disclosures made to the IETF Secretariat and any 497 assurances of licenses to be made available, or the result of an 498 attempt made to obtain a general license or permission for the use of 499 such proprietary rights by implementers or users of this 500 specification can be obtained from the IETF on-line IPR repository at 501 http://www.ietf.org/ipr. 503 The IETF invites any interested party to bring to its attention any 504 copyrights, patents or patent applications, or other proprietary 505 rights that may cover technology that may be required to implement 506 this standard. Please address the information to the IETF at 507 ietf-ipr@ietf.org. 509 Disclaimer of Validity 511 This document and the information contained herein are provided on an 512 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 513 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 514 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 515 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 516 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 517 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 519 Copyright Statement 521 Copyright (C) The Internet Society (2006). This document is subject 522 to the rights, licenses and restrictions contained in BCP 78, and 523 except as set forth therein, the authors retain all their rights. 525 Acknowledgment 527 Funding for the RFC Editor function is currently provided by the 528 Internet Society.