idnits 2.17.1 draft-kyzivat-sipping-gruu-reg-event-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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 409. ** 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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 111: '... A notifier for the "reg" event package [1] SHOULD include the ...' RFC 2119 keyword, line 114: '...e element MUST be be positioned...' RFC 2119 keyword, line 120: '...ing a , it SHOULD use the gruu i...' RFC 2119 keyword, line 301: '...ML document that MUST be well-formed a...' RFC 2119 keyword, line 302: '... SHOULD be valid. Gruu documents MU...' 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 (July 15, 2005) is 6859 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: '4' is defined on line 360, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 369, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-04 -- Obsolete informational reference (is this intentional?): RFC 3455 (ref. '5') (Obsoleted by RFC 7315) == Outdated reference: A later version (-09) exists of draft-ietf-sipping-torture-tests-07 Summary: 5 errors (**), 0 flaws (~~), 6 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: January 16, 2006 July 15, 2005 6 Reg Event Package Extension for GRUUs 7 draft-kyzivat-sipping-gruu-reg-event-03 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 16, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This draft defines an extension to RFC 3680 [1] for representing the 41 GRUU associated with a Contact. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Description . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Notifier Processing of SUBSCRIBE Requests . . . . . . . . . 3 48 4. Notifier Generation of NOTIFY Requests . . . . . . . . . . . 3 49 5. Subscriber Processing of NOTIFY Requests . . . . . . . . . . 4 50 6. Sample reginfo Document . . . . . . . . . . . . . . . . . . 4 51 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 7.1 Example: Welcome Notice . . . . . . . . . . . . . . . . . 5 53 7.2 Example: Implicit Registration . . . . . . . . . . . . . . 5 54 8. XML Schema Definition . . . . . . . . . . . . . . . . . . . 8 55 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 56 10. Security Considerations . . . . . . . . . . . . . . . . . . 8 57 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 58 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 12.1 Normative References . . . . . . . . . . . . . . . . . . 9 60 12.2 Informative References . . . . . . . . . . . . . . . . . 9 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 62 Intellectual Property and Copyright Statements . . . . . . . 11 64 1. Introduction 66 The addition of GRUU (Globally Routable Unique URI) support to the 67 REGISTER message, defined in [2], introduces another element of state 68 to the registrar. Subscribers to the registration event package [1] 69 will sometimes have need for the new state. 71 For example, the Welcome Notices example in [1] will only operate 72 correctly if the contact address in the reg event notification is 73 reachable by the sender of the welcome notice. When the registering 74 device is using the gruu extension, it is likely that the registered 75 contact address will not be globally addressable, and the gruu should 76 be used as the target address for the MESSAGE. 78 Another case where this feature may be helpful is within the 3GPP IP 79 Multimedia Subsystem (IMS). IMS employs a technique where a REGISTER 80 of a contact address to one Address of Record (AOR) causes the 81 implicit registration of the same contact to other associated AORs. 82 If a GRUU is requested and obtained as part of the registration 83 request, then additional GRUUs will also be needed for the implicit 84 registrations. While assigning the additional GRUUs is 85 straightforward, informing the registering UA of them is not. In 86 IMS, UAs typically subscribe to the 'reg' event, and subscriptions to 87 the 'reg' event for an AOR result in notifications containing 88 registration state for all the associated AORs. The proposed 89 extension provides a way to easily deliver the GRUUs for the 90 associated AORs. 92 The reg event package has provision for including extension elements 93 within the element. This document defines a new element 94 that may be used in that context to deliver the GRUU corresponding to 95 the contact. 97 2. Description 99 A new element () is defined which contains a GRUU. 101 This optional element is included within the body of a NOTIFY for the 102 "reg" event package when a GRUU is associated with the contact. The 103 contact URI and the GRUU are then both available to the watcher. 105 3. Notifier Processing of SUBSCRIBE Requests 107 Unchanged from RFC 3680 [1]. 109 4. Notifier Generation of NOTIFY Requests 111 A notifier for the "reg" event package [1] SHOULD include the 112 element when a contact has an Instance ID and a GRUU is associated 113 with the combination of the AOR and the Instance ID. When present, 114 the element MUST be be positioned as an instance of the 115 element within the element. 117 5. Subscriber Processing of NOTIFY Requests 119 When a subscriber receives a "reg" event notification [1] with a 120 containing a , it SHOULD use the gruu in preference 121 to the corresponding when sending SIP requests to the contact. 123 Subscribers that are unaware of this extension will, as required by 124 [1], ignore the element. 126 6. Sample reginfo Document 128 The following is an example registration information document 129 including the new element: 131 132 136 138 141 sip:user@192.0.2.1 142 143 "" 144 145 146 sip:user@example.com;opaque=hha9s8d-999a 147 148 149 150 152 7. Examples 154 Note: In the following examples the SIP messages have been 155 simplified, removing headers that are not pertinent to the example. 156 The conventions of [7] are used to describe representation of long 157 message lines. 159 7.1 Example: Welcome Notice 161 Consider the Welcome Notices example in [1]. When the application 162 server receives a notification of a new registration containing the 163 reginfo shown in Section 6 it should address messages using the 164 contained GRUU as follows: 166 MESSAGE sip:user@example.com;opaque=hha9s8d-999a SIP/2.0 167 To: 168 From: "SIPland Notifier" 169 Content-Type: text/plain 170 Content-Length: ... 172 Welcome to SIPland! 173 Blah, blah, blah. 175 7.2 Example: Implicit Registration 177 In an 3GPP IMS setting, a UA may send a single register message, 178 requesting assignment of a gruu, as follows: 180 REGISTER sip:example.net SIP/2.0 181 From: ;tag=5ab4 182 To: 183 Contact: 184 ;expires=3600 185 ;+sip.instance="" 186 Supported: path, gruu 187 Content-Length: 0 189 The response reports success of the registration and returns the GRUU 190 assigned for the combination of AOR, Instance ID, and Contact. It 191 also indicates (via the P-Associated-URI header [5]) that there are 192 two other associated AORs that may have been implicitly registered 193 using the same contact. But each of those implicitly registered AORs 194 will have had a unique GRUU assigned, and there is no way defined to 195 report that assignment in the response. 197 SIP/2.0 200 OK 198 From: ;tag=5ab4 199 To: ;tag=373392 200 Path: 201 Service-Route: 202 Contact: 203 ;expires=3600 204 ;+sip.instance="" 205 ;gruu="" 206 P-Associated-URI: , 207 208 Content-Length: 0 210 The UA then subscribes to the 'reg' event package as follows: 212 SUBSCRIBE sip:user_aor_1@example.net SIP/2.0 213 From: ;tag=27182 214 To: 215 Route: 216 Event: reg 217 Expires: 3600 218 Accept: application/reginfo+xml 219 Contact: 220 Content-Length: 0 222 (The successful response to the subscription is not shown.) Once the 223 subscription is established an initial notification is sent giving 224 registration status. In IMS deployments the response includes, in 225 addition to the status for the requested URI, the status for the 226 other associated URIs. 228 NOTIFY sip:user_aor_1@example.net;opaque=hha9s8d-999a SIP/2.0 229 From: ;tag=27182 230 To: ;tag=262281 231 Subscription-State: active;expires=3600 232 Event: reg 233 Content-Type: application/reginfo+xml 234 Contact: 235 Content-Length: (...) 237 238 242 244 246 247 sip:ua.example.com 248 249 250 "" 251 252 253 sip:user_aor_1@example.net 254 ;opaque=hha9s8d-999a 255 256 257 258 260 262 263 sip:ua.example.com 264 265 266 "" 267 268 269 sip:user_aor_2@example.net 270 ;opaque=hha9s8d-999b 271 272 273 274 278 280 281 sip:ua.example.com 282 283 284 "" 285 286 287 sip:+358504821437@example.net;user=phone 288 ;opaque=hha9s8d-999c 289 290 291 292 294 The status indicates that the associated URIs all have the same 295 contact registered. It also includes the unique GRUU that has been 296 assigned to each. The UA may then retain those GRUUs for use when 297 establishing dialogs using the corresponding AORs. 299 8. XML Schema Definition 301 A gruu document is an XML document that MUST be well-formed and 302 SHOULD be valid. Gruu documents MUST be based on XML 1.0 and MUST be 303 encoded using UTF-8. This specification makes use of XML namespaces 304 for identifying gruu documents. The namespace URI for elements 305 defined for this purpose is a URN, using the namespace identifier 306 'ietf'. This URN is: 307 urn:ietf:params:xml:ns:gruu 309 310 315 316 318 9. IANA Considerations 320 This document calls for IANA to register a new XML namespace URN and 321 schema per [3]. 323 URI: urn:ietf:params:xml:ns:gruu 325 Description: TBD 327 Registrant Contact: TBD 329 XML: TBD 331 10. Security Considerations 333 Security considerations for the registration event package is 334 discussed in RFC 3680 [1], and those considerations apply here. 336 The addition of gruu information does not impact security negatively 337 because the gruu is less sensitive than the contact URI itself. 339 11. Acknowledgements 341 The author would like to thank Jonathan Rosenberg for encouraging 342 this draft. 344 12. References 346 12.1 Normative References 348 [1] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 349 Package for Registrations", RFC 3680, March 2004. 351 [2] Rosenberg, J., "Obtaining and Using Globally Routable User Agent 352 (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", 353 draft-ietf-sip-gruu-04 (work in progress), July 2005. 355 [3] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 356 January 2004. 358 12.2 Informative References 360 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 361 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 362 Session Initiation Protocol", RFC 3261, June 2002. 364 [5] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header 365 (P-Header) Extensions to the Session Initiation Protocol (SIP) 366 for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, 367 January 2003. 369 [6] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User 370 Agent Capabilities in the Session Initiation Protocol (SIP)", 371 RFC 3840, August 2004. 373 [7] Sparks, R., "Session Initiation Protocol Torture Test Messages", 374 draft-ietf-sipping-torture-tests-07 (work in progress), 375 May 2005. 377 Author's Address 379 Paul H. Kyzivat 380 Cisco Systems, Inc. 381 1414 Massachusetts Avenue 382 Boxborough, MA 01719 383 USA 385 Email: pkyzivat@cisco.com 387 Intellectual Property Statement 389 The IETF takes no position regarding the validity or scope of any 390 Intellectual Property Rights or other rights that might be claimed to 391 pertain to the implementation or use of the technology described in 392 this document or the extent to which any license under such rights 393 might or might not be available; nor does it represent that it has 394 made any independent effort to identify any such rights. Information 395 on the procedures with respect to rights in RFC documents can be 396 found in BCP 78 and BCP 79. 398 Copies of IPR disclosures made to the IETF Secretariat and any 399 assurances of licenses to be made available, or the result of an 400 attempt made to obtain a general license or permission for the use of 401 such proprietary rights by implementers or users of this 402 specification can be obtained from the IETF on-line IPR repository at 403 http://www.ietf.org/ipr. 405 The IETF invites any interested party to bring to its attention any 406 copyrights, patents or patent applications, or other proprietary 407 rights that may cover technology that may be required to implement 408 this standard. Please address the information to the IETF at 409 ietf-ipr@ietf.org. 411 Disclaimer of Validity 413 This document and the information contained herein are provided on an 414 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 415 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 416 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 417 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 418 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 419 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 421 Copyright Statement 423 Copyright (C) The Internet Society (2005). This document is subject 424 to the rights, licenses and restrictions contained in BCP 78, and 425 except as set forth therein, the authors retain all their rights. 427 Acknowledgment 429 Funding for the RFC Editor function is currently provided by the 430 Internet Society.