Extension to the ua-profile Event Package to Support the Application Profile Type

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.

The "appids" 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 , only for the 'application' profile-type. This parameter is useful to the PDS to affect the profile provided. The namespace for application identifiers must be defined in order to ensure uniqueness. A likely choice is to make the appids value be a URN. Examples in this document do not reflect likely application identifiers. The "appids" 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]

appids = "appids=" list-of-app-ids list-of-app-ids = DQUOTE app-id *("," app-id) DQUOTE app-id = 1*(subset-print-chars) subset-print-chars= %x21 /%x23-25 / %x27-29 / %x2D-3C / %x3E-7E ;All printable characters except ", =, &, *, + ;comma or white-space characters. Note: Need to validate the above ABNF. The "appids" 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 appids 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 "appids" parameter MAY be omitted from the initial NOTIFY is when only one application was listed in the SUBSCRIBE. If the SUBSCRIBE included an "appids" parameter, the "appids" 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 appids parameter MUST be the same as followed in the body (see below). Subsequent NOTIFY requests on a single application subscription MAY omit the "appids", since the application context is implied by the subscription dialog.

The following are example Event headers which may occur in SUBSCRIBE requests. The examples are not intended to show complete SUBSCRIBE requests.

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"; appids="myapplication" Event: ua-profile;profile-type=application; vendor="vendor.example.com";model="Z100";version="1.2.3"; appids="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;appids="myapplication1" Event: ua-profile;profile-type=application; appids="myapplication2","myapplication3" The table shows the use of Event header parameters in SUBSCRIBE requests for the application profile type:

profile-type || application =========================== appids || 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 =========================================================== appids || o

This draft defines an enhancement to the by specifying a use for the SUBSCRIBE request body. If the appids parameter contained a list of applications, the body of the SUBSCRIBE SHOULD include appropriate bodies for each of the applications for which the user-agent is subscribing, in the same order in which they are listed in the appids parameter. If present in the SUBSCRIBE request, the body SHALL be used by the each of the application specific PDSs to tailor the NOTIFY responses to the subscribing UA for each of the applications listed.

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 "appids" application values. 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.