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

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

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

‘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

‘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

‘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

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

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

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

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?