SIPPING D. Petrie Internet-Draft SIPez LLC. Expires: September 21, 2006 March 20, 2006 Extensions to the Session Initiation Protocol (SIP) User Agent Profile Delivery Change Notification Event Package for the Extensible Markup Language Language Configuration Access Protocol (XCAP) draft-ietf-sipping-xcap-config-00.txt 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 September 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The SIP User Agent profile delivery framework describes how a User Agent can retrieve its data using a variety of protocols and defines a SIP event package for notifications of changes to those profiles. This document extends that event package to support XCAP (XML Configuration Access Protocol). Petrie Expires September 21, 2006 [Page 1] Internet-Draft SIP UA Profiles via XCAP March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 3. New Event Package Parameters . . . . . . . . . . . . . . . . 3 4. Relationship of XCAP with the Data Model . . . . . . . . . . 5 5. Example Usage . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . 10 Petrie Expires September 21, 2006 [Page 2] Internet-Draft SIP UA Profiles via XCAP March 2006 1. Introduction The SIP [RFC3261] User Agent profile delivery framework [I-D.ietf- sipping-config-framework] describes how a User Agent (UA) can retrieve its data using a variety of protocols. The framework also defines a SIP event package [RFC3265] for notifications of changes to those profiles. This document extends that event package to support XCAP (XML Configuration Access Protocol) [I-D.ietf-simple-xcap]. XCAP is a usage of HTTP (HyperText Transfer Protocol) [RFC2616] which defines structure of the HTTP URI (Uniform Resource Identifier) to represent a specific document hierarchy. XCAP URIs consist of the document root, the Application Unique ID (AUID), the XCAP User Identifier (XUI), plus additional optional elements for selecting XML nodes within an XML document. The mandatory components point to a specific XCAP document. For example: http://xcap.example.com/root/resource-lists/users/joe |-------------v-------------||------v------||---v---| document root AUID XUI This document extends the UA profile change event package with two new Event header parameters. These allow a UA to subscribe to change notification for a specific XCAP AUID or document. 2. Requirements Terminology Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119]. 3. New Event Package Parameters This document extends the event package defined in Section 7 of [I-D.ietf-sipping-config-framework] with the following two new parameters for the Event header: "document" and "auid". These parameters are for use in both SUBSCRIBE and NOTIFY requests. The motivation for these new parameters is in support of XCAP, but they may be used with other suitable protocols. The "document" parameter is used to specify a relative URI for a specific profile document that the user agent wishes to retrieve and for which it wishes to receive change notification. It can be used with any of the profile-types. The document parameter is useful for profile content like XCAP [I-D.ietf-simple-xcap] where there is a well defined URI schema and the user agent knows the specific content that it wants. This provides a filtering mechanism to restrict the content to be retrieved and for which change notification is to be Petrie Expires September 21, 2006 [Page 3] Internet-Draft SIP UA Profiles via XCAP March 2006 received. (The size of the content is important in limited bandwidth environments.) The "document" parameter value syntax is a quoted string. The values for the "document" parameter are defined as part of the profile data format, which is out of scope for this document. To use the "document" parameter, the profile data format, must also define a URI path schema. For more details on the use of this package and the "document" parameter with XCAP see Section 4. The "document" parameter MAY be set in SUBSCRIBE requests for any of the profile types. It is ignored in all other messages. In the following ABNF EQUAL and quoted-string are defined in [RFC3261]. Document = "document" EQUAL quoted-string The "auid" parameter MAY be set when the "profile-type" parameter value is "application". The "auid" indicates that the user agent wishes to retrieve the profile data or URI and change notification for the application profile data for the specific application indicated in the value of the "auid" parameter. Like the "document" parameter, the "auid" parameter provides a filtering mechanism on the profile content. The "auid" parameter value is a quoted string. The values for the "auid" parameter are defined as part of the profile data format to be used with XCAP (see [I-D.ietf-simple-xcap] ), which is out of scope for this document. The "auid" parameter has meaning only in SUBSCRIBE requests when the "profile-type" Event header parameter is set to "application". When used with XCAP it is not necessary to set both the "document" and "auid" parameters in a SUBSCRIBE request as the document path will also include the application auid. The "auid" parameter is ignored if it conflicts with the parameter "document" path. The "auid" parameter is ignored in all other messages. AUID = "auid" EQUAL quoted-string SUBSCRIBE request Event header example: Event: ua-profile;profile-type="user"; document="user-aor/"; vendor="premier";model="trs8000";version="5.5" The following table shows the use of these new Event header parameters in SUBSCRIBE requests for the four profile types: Petrie Expires September 21, 2006 [Page 4] Internet-Draft SIP UA Profiles via XCAP March 2006 profile-type || device | user | application | local-network =========================================================== document || o | o | o | o auid || | | o | m - mandatory s - SHOULD be provided o - optional Non-specified means that the parameter has no meaning and should be ignored. 4. Relationship of XCAP with the Data Model The UA profile delivery framework [I-D.ietf-sipping-config-framework] describes a rough data model with profile types that can correspond to profile information related to the local-network, devices, users, and applications. Because XCAP defines a specific hierarchy for how documents are organized, it is necessary to discuss how that organization relates to the data model described in the profile delivery framework. When a user or device enrolls with a SUBSCRIBE request, the request URI will contain identifying information for that user or device. This identity is mapped to an XCAP User ID (XUID) based on an implementation specific mapping. The "profile-type" along with the "auid" Event header parameters specify the specific XCAP application usage. In particular, when the Event header parameter "profile-type" is "application", the "auid" MAY be included to contain the XCAP Application Unique ID (AUID). When the "profile-type" is "application", but the "auid" parameter is absent, this specifies that the user wishes to SUBSCRIBE to all documents for all application usages associated with the user in the request-uri. This provides a convenient way for a single subscription to be used to obtain all application data. The XCAP root is determined by a local mapping. When the "profile-type" is "device", or "user" or "local-network", this maps to an AUID and document selector for representing device, user and local-network data, respectively. The mapping is a matter of local policy. This allows different providers to use different XCAP application usages and document schemas for representing these profiles, without having to configure the device with the specific AUID which is being used. Furthermore, when the "document" attribute is present and used with Petrie Expires September 21, 2006 [Page 5] Internet-Draft SIP UA Profiles via XCAP March 2006 XCAP, it identifies a specific document that is being requested. The "document" attribute specifies a relative path from the XCAP root [I-D.ietf-simple-xcap]. That is the "document" attribute is an XCAP Document Selector expressed as a relative path to the XCAP root. 5. Example Usage For example, consider a phone with an instance ID of urn:uuid:00000000-0000-0000-0000-0003968cf920. To obtain its device profile, it generates a SUBSCRIBE that contains the following Request-Line and Event header: (Note that line folding of the Request-URI is illegal in SIP. The Request URI is shown broken across the first 3-lines here only due to formatting limitations of IETF documents.) SUBSCRIBE sip:urn%3auuid%3a00000000-0000-0000-0000-0003968cf920@example.com SIP/2.0 Event: ua-profile;profile-type=device;Vendor="vendor2" ;Model="1";Version="2.2.2" If the profile data is stored in an XCAP server, the profile delivery server maps the "device" profile to an application usage and document selector based on local policy. The user ID, in the case of a device profile, could be the device ID which is identified in the user part of the SUBSCRIBE URI. Assume the XCAP server uses an XCAP root directory of: http://xcap.example.com/root. Local policy provides a mapping for the AUID "vendor2-device-data" based upon the "vendor" parameter and a document called "index" within the user directory, the corresponding HTTP URI for the document would be: (Note that this URI is only one line; it is split across lines due to formatting limitations of IETF documents.) http://xcap.example.com/root/vendor2-device-data/ urn%3auuid%3a00000000-0000-0000-0000-0003968cf920/index The returned user profile would typically specify the user identity (as a SIP AOR) and his or her application-usages. From that, the device can enroll to learn about its application data. To learn about all of the data, the UA sends a subscription with the application profile-type and no AUID: SUBSCRIBE sip:alice@example.com SIP/2.0 Event: ua-profile;profile-type=application;Vendor="vendor2"; Model="1";Version="2.2.2" Petrie Expires September 21, 2006 [Page 6] Internet-Draft SIP UA Profiles via XCAP March 2006 The server maps the SIP Request URI to an XUI (alice, for example) and the xcap root based on local policy. If there are two AUIDs, "resource-lists" [I-D.ietf-simple-xcap-list-usage] and "rls-services" [I-D.ietf-simple-xcap-list-usage], this would result in a subscription to all documents within: http://xcap.example.com/root/rls-services/alice http://xcap.example.com/root/resource-lists/alice The user would not be subscribed to the global data for these two application usages, since that data is not important for users. However, the user/device could be made aware that it needs to subscribe to a specific document. In that case, its subscribe would look like: SUBSCRIBE sip:user-aor@example.com SIP/2.0 Event: ua-profile;profile-type=application;auid="resource-lists"; Vendor="vendor2";Model="1";Version="2.2.2" this would result in a subscription to the single global document for resource-lists. In some cases, these subscriptions are to a multiplicity of documents. In that case, the notification format will need to be one which can indicate what document has changed. This includes content indirection, but also the xcap diff format [I-D.ietf-simple-xcap- diff]. 6. IANA Considerations This specification registers two new Event header parameters and updates the corresponding event package as defined in [RFC3265]. The following information required for this registration: Package Name: ua-profile Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX with the RFC number of this specification). Person to Contact: Daniel Petrie dan.ietf AT SIPez DOT com Additional event header parameters: document, auid 7. Security Considerations Profiles may contain sensitive data such as user credentials and personal information. The security considerations of this document are identical to those of the framework [I-D.ietf-sipping-config- Petrie Expires September 21, 2006 [Page 7] Internet-Draft SIP UA Profiles via XCAP March 2006 framework]. Implementors should also carefully read the security considerations of XCAP [I-D.ietf-simple-xcap] as well. Subscribers implementing this specification MUST implement either HTTP or HTTPS. Subscribers also MUST implement the hash verification scheme described in SIP content indirection [I-D.ietf-sip-content- indirect-mech]. SIP profile delivery servers MUST implement both HTTP and HTTPS, and SHOULD implement a SIP Authentication Service as described in the SIP Identity mechanism [I-D.ietf-sip-identity]. All SIP entities are already required to implement SIP Digest authentication [RFC3261]. 8. Acknowledgements Thanks to Rohan Mahy for editorial work on this document. 9. Normative References [I-D.ietf-simple-xcap] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-08 (work in progress), October 2005. [I-D.ietf-simple-xcap-diff] Rosenberg, J., "An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources", draft-ietf-simple-xcap-diff-02 (work in progress), October 2005. [I-D.ietf-simple-xcap-list-usage] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", draft-ietf-simple-xcap-list-usage-05 (work in progress), February 2005. [I-D.ietf-sip-content-indirect-mech] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", draft-ietf-sip-content-indirect-mech-05 (work in progress), October 2004. [I-D.ietf-sip-identity] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-06 (work in progress), October 2005. Petrie Expires September 21, 2006 [Page 8] Internet-Draft SIP UA Profiles via XCAP March 2006 [I-D.ietf-sipping-config-framework] Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-07 (work in progress), July 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [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. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. Author's Address Daniel Petrie SIPez LLC. 34 Robbins Rd Arlington, MA 02476 US Phone: "+1 617 273 4000 Email: dan.ietf AT SIPez DOT com URI: http://www.SIPez.com/ Petrie Expires September 21, 2006 [Page 9] Internet-Draft SIP UA Profiles via XCAP March 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 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. Petrie Expires September 21, 2006 [Page 10] Internet-Draft SIP UA Profiles via XCAP March 2006 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Petrie Expires September 21, 2006 [Page 11]