Sipping J. Arauz Internet-Draft Ericsson Intended status: Standards Track June 20, 2007 Expires: December 22, 2007 Registration Event Package Extension for IP Multimedia Subsystem (IMS) Grouping of Addresses of Record (AoR) draft-jarauz-sipping-grouping-reg-event-01 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 December 22, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). 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 December 22, 2007 [Page 1] Internet-Draft Reg Event Grouping Extension June 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Notifier Processing of SUBSCRIBE Requests . . . . . . . . . . 5 5. Notifier Generation of NOTIFY Requests . . . . . . . . . . . . 5 6. Subscriber Processing of NOTIFY Requests . . . . . . . . . . . 6 7. Sample reginfo Document . . . . . . . . . . . . . . . . . . . 7 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Example: Implicit Registration . . . . . . . . . . . . . . 8 9. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 11 10.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 13.2. Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Arauz Expires December 22, 2007 [Page 2] Internet-Draft Reg Event Grouping Extension June 2007 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. 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. Arauz Expires December 22, 2007 [Page 3] Internet-Draft Reg Event Grouping Extension June 2007 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 he/she owns the P-CSCF by virtue of its subscription to the reg-event package receives the identities that have been actually registered, including information about the Grouped Identities Set each AoR belongs to. A UA may also need to know about which identities are alias to each other. One case would be when different groups of alias identities receive different charging rates. A subscriber is charged differently depending on the AoR the user chooses for the communication so the user should know about those groups to decide which AoR to use at each moment. Another case would be when a user has bound an AoR to a certain application (e.g. a work AoR is bound to the Enterprise Communicator application while a personal AoR is bound to the normal multi-media phone application). When an incoming request is recieved at the UA for an AoR not explicitly bound by the user, the expected behavior at the UA would be that the right application is started and thus the UA needs to know the alias group to which the implicitly-bound AoR belongs. The extension described in this document can also be useful outside the context of the IMS. &F;or instance, in the open Internet a UA might implement a call barring service. When a user sets up a call barring service usually he/she is trying to bar users, not identities. The extension proposed in this document would allow a UA to know about the alias identities of barred users, so that by barring one of the identities the UA automatically bars any other alias identities within the same group as the former. 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", Arauz Expires December 22, 2007 [Page 4] Internet-Draft Reg Event Grouping Extension June 2007 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] [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). The definition of a Grouped Identity Set is as follows: "the set of AoRs that are alias to each other". This definition rules out redundant sets (i.e. sets that span exactly the same AoRs) and subsets (i.e. sets that span some AoRs from within those that are part of a larger set), since as per the definition above they are indeed the same set. Also notice that the definition above has the transitive property, so that if B is alias to A and C is alias to B then C is alias to A. This means that any two sets that share at least one AoR are actually a single set that spans the sum of the AoRs in the former sets. A corollary to the above paragraphs is therefore that at any given moment every AoR may belong to one and only one Grouped Identities Set. 4. Notifier Processing of SUBSCRIBE Requests Unchanged from RFC 3680 [RFC3680] [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. When present, the element MUST be be positioned as an instance of the XSD element within the element. Arauz Expires December 22, 2007 [Page 5] Internet-Draft Reg Event Grouping Extension June 2007 If a notifier includes elements in event notifications, for each AoR that belongs to a Grouped Identities Set the notifier MUST include within the element which 'aor' attribute value matches said AoR one and only one element. For any two AoRs belonging to the same Grouped Identities Set, the elements within their respective elements MUST contain exactly the same text, with the only exception of leading and trailing white spaces, tab and CR/LF characters. For any two AoRs belonging to different Grouped Identities Sets, the elements within their respective elements MUST contain different text after discarding leading and trailing white spaces, tab and CR/LF characters. Note that the conditions in the two paragraphs above mutually exclude each other, i.e. any two AoRs cannot simultaneously belong to the same set and to different sets (since by the transitive property of Grouped Identities Sets those different sets are actually one single set). 6. Subscriber Processing of NOTIFY Requests When a subscriber receives a "reg" event notification [2] with element(s) containing one element, it MAY compare the text within the respective elements after discarding leading and trailing white spaces, tab and CR/LF characters. Any AoRs whose respective elements contain a element with exactly the same text MUST be associated to the same Grouped Identities Set by the subscriber. Any AoRs whose respective elements contain a element with different texts MUST be associated to different Grouped Identities Sets by the subscriber. An AoR which element does not contain any element is either not associated to any Grouped Identities set by the subscriber, or associated to a singular Grouped Identities Set that spans only that AoR. The subscriber MAY use the information about the Grouped Identities Sets as it sees fit. The identities within a given Grouped Identities Set MUST 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. Arauz Expires December 22, 2007 [Page 6] Internet-Draft Reg Event Grouping Extension June 2007 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: 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. Arauz Expires December 22, 2007 [Page 7] Internet-Draft Reg Event Grouping Extension June 2007 8.1. Example: Implicit Registration In an IMS network, a UA may send a single register message, requesting registration of an AoR. The IMS network may actually register other AoRs, in addition to the one conveyed in the registration request (this is known as implicit registration in IMS, and the set of AoRs that are actually registered is known as Implicit Registration Set, IRS). 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: 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: Arauz Expires December 22, 2007 [Page 8] Internet-Draft Reg Event Grouping Extension June 2007 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 December 22, 2007 [Page 9] Internet-Draft Reg Event Grouping Extension June 2007 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 December 22, 2007 [Page 10] Internet-Draft Reg Event Grouping Extension June 2007 9. XML Schema Definition A Grouped Identities Set 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:aliasinfo BEGIN END 10. IANA Considerations There are no IANA considerations associated with this specification. 10.1. URN Sub-Namespace Registration This section registers a new XML namespace, per the guidelines in [4]. URI: The URI for this namespace is urn:ietf:params:xml:ns:aliasinfo Registrant Contact: IETF, SIPPING working group, , Javier Arauz XML: Arauz Expires December 22, 2007 [Page 11] Internet-Draft Reg Event Grouping Extension June 2007 BEGIN Reg Information Alias Extension Namespace

Namespace for Reg Information Alias Extension

urn:ietf:params:xml:ns:aliasinfo

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

END 10.2. XML Schema Registration This section registers an XML schema per the procedures in [4]. URI: urn:ietf:params:xml:schema:aliasinfo. The XML for this schema can be found in Section 9. 11. Security Considerations Security considerations for the registration event package is discussed in RFC 3680 [2], and those considerations apply here. The addition of Grouped Identity Sets information to the registration event package provides a way for a subscriber to that package to find out the alias relationship between those AoRs belonging to the same set. Since the network behavior is exactly the same for any AoR within the same group, revealing those relationships should not raise any security/privacy concern, since using an alias AoR does not open any new possibilities to parties using the alias AoR instead of the AoR they already know. 12. Acknowledgements This work is heavily based on a similar one carried out by Paul E. Kyzivat in relation to GRUU[9]. Arauz Expires December 22, 2007 [Page 12] Internet-Draft Reg Event Grouping Extension June 2007 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] 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. [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. 13.2. Informative References [I-D.ietf-sipping-torture-tests] Sparks, R., "Session Initiation Protocol Torture Test Messages", draft-ietf-sipping-torture-tests-09 (work in progress), November 2005. Author's Address Javier Arauz Ericsson Via de los Poblados 13 Madrid, Madrid 28033 SP Phone: +34 91 339 2997 Email: jesus.javier.arauz@ericsson.com Arauz Expires December 22, 2007 [Page 13] Internet-Draft Reg Event Grouping Extension June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Arauz Expires December 22, 2007 [Page 14]