1 / 10

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

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

alda
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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?

More Related