SIPPING S. Channabasappa Internet-Draft CableLabs Intended status: Standards Track J. Littlefield Expires: May 14, 2008 Cisco Systems, Inc. S. Loreto Ericsson, Inc. November 11, 2007 Extension to the ua-profile Event Package to Support the Application Profile Type draft-channabasappa-sipping-app-profile-type-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 May 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). 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 the application Channabasappa, et al. Expires May 14, 2008 [Page 1] Internet-Draft Application Profile Type November 2007 profile type. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Profile Type Definition . . . . . . . . . . . . . . . . . . . . 3 3.1. appid parameter . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Summary of Event Header . . . . . . . . . . . . . . . . . . 4 3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6 3.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 6 4. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Channabasappa, et al. Expires May 14, 2008 [Page 2] Internet-Draft Application Profile Type November 2007 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 (ua-profile) for profile delivery, and notification of profile changes. The ua-profile event package contains a parameter identified by 'profile-type' that can be used to request data specific to certain type of profiles. This document extends the profile-type parameter to support an additional profile type, termed 'application'. The 'application' profile type is used for delivery and change notification of profile content for the user's applications. 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 [RFC2119]. This document also reuses the SIP terminology defined in [RFC3261] and [RFC3265], and specifies the usage of the following terms. 3. Profile Type Definition This document specifies a new profile type for use with the SIP UA configuration framework. The name of the profile type is 'application'. It is to be used in deployments where SIP UAs are provided with application specific configuration. This document also defines an additional event header parameter for use with the application profile type. 3.1. appid parameter The "appid" parameter describes the application profile being requested. Its value is an identifier unique to the application, and defined by the application specification, along with the profile content. This parameter value SHOULD be provided in the SUBSCRIBE request, along with the other three parameters (vendor, model and version) specified in [I-D.ietf-sipping-config-framework], only for the 'application' profile-type. This parameter is useful to the PDS to affect the profile provided. Channabasappa, et al. Expires May 14, 2008 [Page 3] Internet-Draft Application Profile Type November 2007 COMMENT: The namespace for application identifiers must be defined in order to ensure uniqueness. A likely choice is to make the appid value be a URN. Examples in this document do not reflect likely application identifiers. The "appid" parameter describes the specific application, or the list of applications, for which the user agent desires a profile subscription. In the following ABNF defining the syntax, EQUAL and quoted-string are defined in [RFC3261] appid = "appid=" application-value application-value = quoted-string *("," quoted-string) quoted-string = 1*(subset-print-chars) subset-print-chars= %x21-25 / %x27-29 / %x2C-3C / %x3E-7E ;All printable characters except =, &, *, + ;or white-space characters. Note: Need to validate the above ABNF. The "appid" parameter may appear in the Event header of the NOTIFY request to specify the actual application the NOTIFY belongs to. In the initial NOTIFY following a SUBSCRIBE, the appid parameter SHOULD list all applications obtained in the subscription, which may be a subset of the applications listed in the SUBSCRIBE. The only case in which the "appid" parameter MAY be omitted from the initial NOTIFY is when only one application was listed in the SUBSCRIBE. If the SUBSCRIBE included an "appid" parameter, the "appid" parameter of the initial NOTIFY MUST NOT list applications not present in the SUBSCRIBE. If the parameter contains a list of applications, the order in the appid parameter MUST be the same as followed in the body (see below). Subsequent NOTIFY requests on a single application subscription MAY omit the "appid", since the application context is implied by the subscription dialog. 3.2. Summary of Event Header The following are example Event headers which may occur in SUBSCRIBE requests. The examples are not intended to show complete SUBSCRIBE requests. Channabasappa, et al. Expires May 14, 2008 [Page 4] Internet-Draft Application Profile Type November 2007 Event: ua-profile;profile-type=application; vendor="vendor.example.com";model="Z100";version="1.2.3" Event: ua-profile;profile-type=application; vendor="vendor.example.com";model="Z100";version="1.2.3"; appid="myapplication" Event: ua-profile;profile-type=application; vendor="vendor.example.com";model="Z100";version="1.2.3"; appid="myapplication1","myapplication2","myapplication3" The following are example Event headers which may occur in NOTIFY requests. These example headers are not intended to be complete NOTIFY requests. Event: ua-profile;profile-type=application Event: ua-profile;profile-type=application;appid="myapplication1" Event: ua-profile;profile-type=application; appid="myapplication2","myapplication3" The table shows the use of Event header parameters in SUBSCRIBE requests for the application profile type: profile-type || application =========================== appid || o m - mandatory s - SHOULD be provided o - optional The table shows the use of Event header parameters in NOTIFY requests for the application profile type: profile-type || application =========================================================== appid || o Channabasappa, et al. Expires May 14, 2008 [Page 5] Internet-Draft Application Profile Type November 2007 3.3. SUBSCRIBE Bodies This draft defines an enhancements to the [I-D.ietf-sipping-config-framework] specifying a use for the SUBSCRIBE request body. If present in the SUBSCRIBE request the body SHOULD be used by the subscriber to filter the amount of profile data information available at the PDS for an application. 3.4. NOTIFY Bodies The NOTIFY message body contains a content type specific to the requested application (this type must be listed in the Accept header of the SUBSCRIBE). If the subscription is for multiple applications, the initial NOTIFY message body will contain a "multipart/mixed" content-type, and the ordering of the body-parts corresponds to the ordering of the "appid" application values. COMMENT: An alternative to multipart/mixed content is to require all applications supporting multi-application subscription to conform to a common XML container schema, which in turn contains the application-specific profile content, or content-indirection information. 4. Example Usage SUBSCRIBE sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB @example.com SIP/2.0 Event: ua-profile;profile-type=application;appid="sampleapplication" From: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB @example.com;tag=1234 To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com Call-ID: 3573853342923422@192.0.2.44 CSeq: 2131 SUBSCRIBE Contact: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB @example.com ;+sip.instance="" Via: SIP/2.0/TCP 192.0.2.41; branch=z9hG4bK6d6d35b6e2a203104d97211a3d18f57a Accept: message/external-body, application/x-z100-device-profile Content-Length: 0 Channabasappa, et al. Expires May 14, 2008 [Page 6] Internet-Draft Application Profile Type November 2007 5. IANA Considerations There is one consideration associated with this document. Specifically it registers a new profile type as specified in [I-D.ietf-sipping-config-framework]. Profile Type Reference -------------- --------- application [RFCXXXX] CONTACT: ------- sumanth@cablelabs.com Note to RFC editor: Please replace RFCXXXX with the RFC number assigned to this document. 6. Security Considerations This document is an extension to the SIP Configuration Framework and as such inherits the security considerations for profile delivery as listed in [I-D.ietf-sipping-config-framework]. In addition, the presence of application ids in the SUBSCRIBE and NOTIFY bodies plays an important role in how the profile data is received by the client. A man-in-the-middle who manipulates the application ids can effectively cause a disruption in application profile data delivery. (Editor's note: Need to add more security considerations, e.g., when is the presence of an app-id a threat.) 7. Normative References [I-D.ietf-sipping-config-framework] Channabasappa, S., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-13 (work in progress), October 2007. [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, Channabasappa, et al. Expires May 14, 2008 [Page 7] Internet-Draft Application Profile Type November 2007 June 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. Authors' Addresses Sumanth Channabasappa CableLabs 858 Coal Creek Circle Louisville, Co 80027 USA Email: sumanth@cablelabs.com URI: http://www.cablelabs.com/ Josh Littlefield Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA Email: joshl@cisco.com URI: http://www.cisco.com/ Salvatore Loreto Ericsson, Inc. Hirsalantie 11 Jorvas, 02420 Finland Email: Salvatore.Loreto@ericsson.com URI: http://www.ericsson.com/ Channabasappa, et al. Expires May 14, 2008 [Page 8] Internet-Draft Application Profile Type November 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). Channabasappa, et al. Expires May 14, 2008 [Page 9]