The “application” Profile Type (draft-channabasappa-sipping-app-profile-type-01)

1. Sumanth Channabasappa Josh Littlefield Salvatore Loreto 70th IETF, Vancouver, Canada December 2007 The “application” Profile Type(draft-channabasappa-sipping-app-profile-type-01)

2. Introduction • The “ua-profile” Event Package is specified for use within the SIP Configuration Framework (draft-ietf-sipping-config) • The framework specifies the support for three profile types: local-network, device, and user • This I-D (sipping-app-profile-type) specifies the support for an additional profile type within the SIP Configuration Framework • “application” profile type • The ”application” profile type is used for profile delivery, and change notifications, of profile data related to user applications

3. Overview • The I-D allows a SIP UA to SUBSCRIBE to profile data pertaining to a single, or multiple, applications using a single subscription • This is accomplished using the ‘application’ profile type • To support profile delivery related to multiple applications, it specifies the following • The ‘appids’ event header parameter • Used by the SIP UA to request profile data for multiple applications • Used by a PDS to indicate the applications for which it can provide profile data • Enhancements to the SUBSCRIBE and NOTIFY bodies • A summary of the enhancements is provided in the following slides

4. ‘application’ Profile Type • The I-D specifies a new profile type parameter ‘application’ • This is used by SIP UAs desiring profile data for one or more applications • The applications to which the device needs to subscribe for can be configured using other previously obtained profiles, such as the device or user

5. ‘appids’ Event Header Parameter (1/2) • The ‘appids’ parameter contains • a specific application, or • a list of applications, for which the SIP UA is requesting profile data • Each application identifier is unique to an application, specified by an application specification, along with profile data requirements

6. ‘appids’ Event Header Parameter (2/2) • The ‘appids’ parameter SHOULD be provided in the SUBSCRIBE request, along with applicable parameters specified in the SIP Configuration Framework • This is only for the ‘application’ profile-type • The list of applications that the SIP UA successfully subscribed to is reported in the initial NOTIFY • This may be a subset of the requested list • This can also indicates the profile data being included, if applicable

7. Enhancements to SUBSCRIBE • This draft defines an enhancement to the SIP Configuration Framework by specifying a use for the SUBSCRIBE request body • If present the body will be used by a PDS to tailor the NOTIFY responses to the subscribing UA, for each of the applications

8. Enhancements to NOTIFY • The NOTIFY message body is expected to contain the content types specific to each requested application • If the subscription was for multiple applications, the NOTIFY message body will contain a ”multipart/mixed” content-type, and the ordering of the body-parts corresponds to the ordering of the ”appids” application value

9. Alternative Enhancement to NOTIFY • An alternative to multipart/mixed content is to require all implementations supporting subscriptions to multiple applications to conform to a common XML schema • An extensible container schema that can contain all the application profile data sets, with a way to differentiate them • This is not intended to preclude non-XML Schema based profile data sets • Such profile data sets would need to specify an equivalent container

10. TBD • We need to mandate uniqueness of application identifiers (appids) to avoid ambiguity in implementations • One potential solution is specify it a URN • Any other suggestions? • We need to provide clear requirements on the handling of profile data in notifications • Two options were presented, any recommendations?