Sipping J. Arauz Internet-Draft Ericsson Expires: March 21, 2007 Sep 20, 2006 Registration Event Package Extension for IP Multimedia Subsystem (IMS) Grouping of Addresses of Record (AoR) draft-jarauz-sipping-grouping-reg-event-00 Status of this Memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 21, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This draft defines an extension to RFC 3680 [2] for representing the grouping of AoRs associated with a user in registration event notifications. Arauz Expires March 20, 2007 [Page 1] Internet-Draft Reg Event Grouping Extension Sep 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Notifier Processing of SUBSCRIBE Requests . . . . . . . . . . 3 5. Notifier Generation of NOTIFY Requests . . . . . . . . . . . . 3 6. Subscriber Processing of NOTIFY Requests . . . . . . . . . . . 3 7. Sample reginfo Document . . . . . . . . . . . . . . . . . . . 3 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1. Example: Implicit Registration . . . . . . . . . . . . . . 4 9. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 7 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 13.1. Normative References . . . . . . . . . . . . . . . . . . . 9 13.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Arauz Expires March 20, 2007 [Page 2] Internet-Draft Reg Event Grouping Extension Sep 2006 1. Introduction In IMS a user may own more than one AoR. All the AoRs owned by a user are conceptually linked in a so-called User Profile. A user is free to use any of the AoRs he/she owns as the originating party identity when initiating traffic procedures, and other users may use any of those AoRs to contact the user. One of the leif motives of IMS is to support the provision of network-based value-added services to its users. In order to achieve this a service architecture and corresponding data model are defined. A user may be provided with one or more so-called Service Profiles, which are data structures containing information related to the services enjoyed by that user. For instance, one of the most relevant pieces of information stored in a Service Profile are the patterns that determine when the user's home proxy must select an Application Server (AS) as the next hop proxy for a SIP request. Service Profiles are further categorized into Individual Service Profiles and Shared Service Profiles. An Individual Service Profile applies to one and only one of the AoRs owned by a given user. On the contrary, a Shared Service Profile applies to two or more of the AoRs owned by that user. Shared Service Profiles are useful when the AoRs to which they are associated represent aliases for each other. For example a user owning both a business AoR (sip:robert@example.com) and a private AoR (sip:bob@example.net) will probably have different Service Profiles associated to each of those identities. The Service Profile for the business identity might determine that sessions from/to that identity pass through the company's virtual PBX AS while the Service Profile for the private identity might instead determine that sessions to/from that identity pass through the ISP's spam filter AS. But when the user owns several AoRs that are aliases for each other (sip:robert.sales@example.com and sip:robert.support@example.com) the services afforded to those identities will be the same and thus it is useful that the Service Profile describing those services is shared between the alias identities. Therefore in IMS it is possible to assign a Shared Service Profile to multiple AoRs of a user in the IMS users database, the Home Subscriber Server (HSS). The set of AoRs associated with the same Shared Service Profile are known as a Grouped Identities Set. A user may own multiple Grouped Identities Sets and it is commonly understood that the AoRs within a Grouped Identities Set are aliases to each other. Arauz Expires March 20, 2007 [Page 3] Internet-Draft Reg Event Grouping Extension Sep 2006 It is foreseen that network nodes that are not the user's home proxy will need to know about the Grouped Identities Sets owned by a user. One of these nodes is the first hop proxy that connects a UA to the IMS network, the Proxy Call Signalling Control Function (P-CSCF). The P-CSCF acts as a Policy Enforcing Point (PEP) for network access. It would make sense that the same policies are applied to alias AoRs so it would be interesting for the Policy Decision Point (PDP) to know about the Grouped Identities Sets of a user in order to apply the same policies to all the identities in the same set. To allow the P-CSCF to know about the Grouped Identities Sets of a user an extension to the reg-event package is proposed that describes these sets. Once a user registers any of the AoRs within its IRS the P-CSCF by virtue of its subscription to the reg-event package receives the identities within the IRS including information about the Grouped Identities Set each AoR belogs to. The reg event package has provision for including extension elements within the element. This document defines a new element that may be used in that context to deliver the membership status of each AoR to each Grouped Identities Set defined for the user. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. [1] 3. Description A new element () is defined which describes a Grouped Identities Set. This optional element is included within the body of a NOTIFY for the "reg" event package when one or more Grouped Identities Sets are defined amongst the AoRs included in the NOTIFY. As many elements as Grouped Identities Sets are defined for the set of AoRs included in the NOTIFY are included by the notifier. In this way both the AoR URI and the Grouped Identities Set it belongs to are then available to the watcher (e.g. the P-CSCF). Arauz Expires March 20, 2007 [Page 4] Internet-Draft Reg Event Grouping Extension Sep 2006 4. Notifier Processing of SUBSCRIBE Requests Unchanged from RFC 3680 [2]. 5. Notifier Generation of NOTIFY Requests A notifier for the "reg" event package [2] SHOULD include the element when one or more Grouped Identities Sets are defined amongst the AoR(s) included in the reg-event body of the NOTIFY. As many elements as Grouped Identities Sets are defined amongst the AoR(s) SHOULD be included by the notifier. When present, the element MUST be be positioned as an instance of the element within the element. 6. Subscriber Processing of NOTIFY Requests When a subscriber receives a "reg" event notification [2] with a containing a , it MAY use the information about the Grouped Identities Set as it sees fit. The identities within a given Grouped Identities Set can be considered aliases for each other by the subscriber and thus the subscriber can use them indistinctly when no indication otherwise exists. Subscribers that are unaware of this extension will, as required by [2], ignore the element. 7. Sample reginfo Document Note: This example and others in the following section are indented for readability by the addition of a fixed amount of whitespace to the beginning of each line. This whitespace is not part of the example. The conventions of [8] are used to describe representation of long message lines. The following is an example registration information document including the new element: Arauz Expires March 20, 2007 [Page 5] Internet-Draft Reg Event Grouping Extension Sep 2006 sip:user@192.0.2.1 1 2 sip:user@192.0.2.1 1 sip:user@192.0.2.1 2 8. Examples Note: In the following examples the SIP messages have been simplified, removing headers that are not pertinent to the example. 8.1. Example: Implicit Registration In an IMS network, a UA may send a single register message, requesting registration of an AoR. All the other AoRs the registrar knows belong to the same IRS as the AoR being requested by the UA get registered together with that AoR, as follows: Arauz Expires March 20, 2007 [Page 6] Internet-Draft Reg Event Grouping Extension Sep 2006 REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bKnashds7 From: ;tag=3n8cf To: Contact: ;expires=3600 Route: Path: Require: path Content-Length: 0 The UE routes the request through the first hop proxy it knows it must use to access the IMS, in this case pcscf@foreign.net. The response reports success of the registration and returns the contact(s) assigned for the explicitly registered AoR. It also indicates (via the P-Associated-URI header [6]) that there are other associated AoRs that may have been implicitly registered using the same contact. But each of those implicitly registered AoRs may belong to the same or different Grouped Identities Sets as the explicitly registered AoR: SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bKnashds7 From: ;tag=3n8cf To: ;tag=fj3894f Supported: path Service-Route: Contact: ;expires=3600 P-Associated-URI: , Content-Length: 0 The UA then subscribes to the 'reg' event package as follows: SUBSCRIBE sip:alice@example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bKnashds8 From: ;tag=fj34890c To: Route: Route: Event: reg Expires: 3600 Accept: application/reginfo+xml Contact: Content-Length: 0 (The successful response to the subscription is not shown.) Once the subscription is established an initial notification is sent giving registration status. In IMS deployments the response includes, in addition to the status for the requested URI, the status for the other associated URIs. Arauz Expires March 20, 2007 [Page 7] Internet-Draft Reg Event Grouping Extension Sep 2006 NOTIFY sip:user@192.0.2.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bKnashds8 Via: SIP/2.0/UDP pcscf.foreign.net;branch=z9hG4bKnashdq4 Via: SIP/2.0/UDP scscf1.example.com;branch=z9hG4bKnashdr2 From: ;tag=fj34890c To: ;tag=j23902 Subscription-State: active;expires=3600 Event: reg Content-Type: application/reginfo+xml Contact: Content-Length: (...) sip:user@192.0.2.1 1 sip:user@192.0.2.1 2 sip:user@192.0.2.1 1 The status indicates that the associated AoRs all have the same contact registered. It also includes the Grouped Identities Sets to whose each AoR belong. The UA may then retain those sets for use them when the subscriber needs them. Arauz Expires March 20, 2007 [Page 8] Internet-Draft Reg Event Grouping Extension Sep 2006 9. XML Schema Definition A TRUU document is an XML document that MUST be well-formed and SHOULD be valid. TRUU documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying TRUU documents. The namespace URI for elements defined for this purpose is a URN, using the namespace identifier 'ietf'. This URN is: urn:ietf:params:xml:ns:gruuinfo BEGIN END 10. IANA Considerations There are no IANA considerations associated with this specification. 11. Security Considerations Security considerations for the registration event package is discussed in RFC 3680 [2], and those considerations apply here. The addition of TRUU information to the registration event package provides a way for a subscriber to that package to find out the relationship between a TRUU and its associated contact address. The relationship between a contact address and an AoR is already part of the package so combining both relationships a subscriber has a way to find out also the AoR to which a TRUU is associated. Since the main motivation of TRUU is to provide privacy and disallow direct contact, the ability to discover the TRUU<->contact<->AoR associations defeats the purpose of TRUU. Therefore access to the registration event information MUST be restricted to trusted parties. Access MAY be allowed to non-trusted parties but in that case the TRUU information MUST be filtered out from the event information. Arauz Expires March 20, 2007 [Page 9] Internet-Draft Reg Event Grouping Extension Sep 2006 12. Acknowledgements This work is heavily based on a similar one carried out by Paul E. Kyzivat in relation to GRUU[9]. 13. References 13.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. [3] Van Bemmel, J., "Obtaining and Using Temporarily Routable User Agent (UA) URIs (TRUU) in the Session Initiation Protocol (SIP)", draft-jbemmel-sip-truu-02 (work in progress), April 2006. [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. 13.2. Informative References [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [6] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, January 2003. [7] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [8] Sparks, R., "Session Initiation Protocol Torture Test Messages", draft-ietf-sipping-torture-tests-09 (work in progress), November 2005. Arauz Expires March 20, 2007 [Page 10] Internet-Draft Reg Event Grouping Extension Sep 2006 Author's Address Javier Arauz Ericsson Via de los Poblados 13 Madrid 28033 SPAIN Email: jesus.javier.arauz@ericsson.com Arauz Expires March 20, 2007 [Page 1] Internet-Draft Reg Event Grouping Extension Sep 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Arauz Expires March 20, 2007 [Page 1] Internet-Draft Reg Event Grouping Extension Sep 2006 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Arauz Expires March 20, 2007 [Page 1]