A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Data Sets

A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Data Sets Pingtel Corp.

400 W. Cummings Park Suite 2200 Woburn MA 01801 US "Dan Petrie (+1 781 938 5306)" <sip:dpetrie@pingtel.com> dpetrie AT pingtel DOT com http://www.pingtel.com/

Pingtel Corp.

400 W. Cummings Park Suite 2200 Woburn MA 01801 US "Scott Lawrence (+1 781 938 5306)" <sip:slawrence@pingtel.com> slawrence AT pingtel DOT com http://skrb.org/scott/

AT&T Labs

US mdolly AT att DOT com

Transport SIPPING SIP Configuration Framework User Agent profile XML schema This document defines the requirements and a format for SIP user agent profile data. An overall schema is specified for the definition of profile data sets. The schema also provides for expressing constraints for how multiple sources of profile data are to be combined. This document provides a guide to considerations, policies and syntax for defining data sets to be included in profile data. It also explores some specific data sets to test the requirements, assumptions and syntax.

Today all SIP user agent implementers use proprietary means of expressing and delivering user, device, and local network profile information to the user agent. The SIP User Agent Profile Delivery Framework specifies a how SIP user agents locate and retrieve profile data specific to the user, the device, and the local network. It is important for SIP User Agents to be able to obtain and use these multiple sources of profile data in order to support a wide range of applications without undue complexity. The SIP User Agent Profile Delivery Framework does not define a format for the actual profile data. This document proposes the requirements, a high level schema for, and guide to how these data sets can be defined. The goal is to enable any SIP user agent to obtain profile data and be functional in a new environment independent of the implementation or model of user agent. The nature of having profile data from four potential sources requires the definition of policies on how to apply the data in an interoperable way across implementations which may have widely varying capabilities. The ultimate objective of the framework described in the SIP User Agent Profile Delivery Framework and this document is to provide a start up experience similar to that of users of an analog telephone. From the point of view of a user, you just plug in an analog telephone and it works (assuming that you have made the right arrangements with your local phone company). There is no end user setup required to make an analog phone work, at least in a basic sense. So the objective here is to be able to take a new SIP user agent out of the box, plug it in or install the software and have it get its profiles without human intervention other than security measures. This is necessary for cost effective deployment of large numbers of user agents. All user agents do not provide telephone capabilities, but the user set up experience goal is applicable to most of the range of user agent capabilities.

Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in RFC 2119.

a named configurable characteristic of a user agent. A given property has a well-defined range of possible values. A given property may be defined to have range of values, allow for simultaneous use of many values (as in a list of allowed possibilities), or be a set of related values that collectively form a single profile information item. the binding of a specific value or set of values to a given property. a collection of settings to be applied for a specific user, device, or local network. SIP user agent, either software or hardware appliance. This is a logical concept, as there may be no physical dedicated device or it may be part of an assembly of devices. In this document, the terms "user agent" and "device" are interchangeable. the profile that applies to a specific user. This is best illustrated by the "hotelling" use case - a user has an association for some period of time with a particular device. The user profile is that set of profile data the user wants to associate with that device (e.g. ringtones used when someone calls them, the user's shortcuts). data profile that applies to a specific device. In the "hotelling" use case, this is the data that is bound to the device itself independent of the user. It relates to specific capabilities of the device and/or preferences of the owner of the device. data that applies to the user agent in the context of the local network. This is best illustrated by roaming applications; a new device appears in the local network (or a device appears in a new network, depending on the point of view). The local network profile includes settings and perhaps policies that allow the user agent to function in the local network (e.g. how to traverse NAT or firewall, bandwidth constraints). a collection of properties. the set of property values actually set in a SIP User Agent as a result of merging the profiles from all sources; the actual effective profile for the user agent . the operation of resolving overlapping settings from multiple profiles. Overlap occurs when the same property occurs in multiple profiles (e.g. user, device, local network).

In this document requirements are specified for containing and expressing profile data for use on SIP user agents. Though much of this can be considered independent of SIP there is one primary requirement that is not well satisfied through more generic profile data mechanisms. SIP User Agent set up requires the agent to merge settings, which may overlap, from potentially four different sources; each source must not only be able to provide profile information, but also express policies regarding how the profile settings may be combined with that from other sources. A schema and syntax is defined in this document to specify properties that may be aggregated to construct profiles. The general design philosophy is that many small data sets provide flexibility to the implementer to support the aggregated set that best matches the capability of the user agent. The actual properties are not defined in this document. However, some examples are explored here to illustrate the proposed mechanisms and to validate the requirements. This document defines a set of considerations, syntax and policies that must be specified when defining data sets. These are to help authors of data set specifications to define data sets that will work in the overall schema defined in this document. The actual specification of these data sets is outside the scope of this document.

The following section defines some of the requirements that were considered when defining the schema, syntax and policies for generating and applying profile data. This is not an exhaustive list of requirements, but the most significant ones to be satisfied.

In the following use case scenarios the device profile is provided by the owner/manager. The owner/manager may be a service provider, an enterprise or a user administering the device setup. The user is assumed to be the end user operating the user agent to perform SIP functions such as telephony, IM etc. I the scenarios that the user profile is provided, the user profile contains user specific properties that the end user has set directly or indirectly through an administration process. The local network profiles represent the suggested policy behavior that the local network operator would like user agents to adhere to. From a security perspective, the local network operator cannot trust the user agent to follow the local network profile policy. The local network operator must use a means external to the user agent to enforce these policies. The local network profile is intended to express to the user agent, the policies that the user agent should follow if the user agent wants to function properly in the local network.

First consider the use cases for a simple user agent property: the outbound proxy. It is not likely that the user would want to influence the outbound proxy for SIP signaling. Conceptually an application might wish to use a specific outbound proxy for signaling related to that application. For this use case, assume that the only the device own/manager or the local network operator are likely to want to set the outbound proxy property. The device profile defines an outbound proxy perhaps so that the device owner/manager can monitor all signaling. The local network operator also defines an outbound proxy because the proxy allows the SIP signaling to get through a NAT or firewall. It seems there are few possible solutions to this conflict resolution problem: The simple solution is to define a policy where the local network profile overrides the device profile. In this approach the local network profile wins. A more flexible solution allows the profiles a means to express a strength to the property (e.g. mandatory use or allow use). In this scenario the device profile could express a default outbound proxy by expressing a "allow" use strength to the property. The local network profile could then override the default outbound property (set in the device profile) by putting a "mandatory" use strength on the property. One more possibility is to allow the aggregation of the outbound proxies. In this scenario SIP messages would be sent with a pre-populated route set that had two hops. First the outbound proxy set in the local network profile, then the outbound proxy set in the device profile. The aggregation approach is closest to solving the requirements to the use case above. By aggregating the two outbound proxies, the local network provided outbound proxy allows the signaling to get out of the local network and the device profile provided outbound proxy is able to monitor all SIP signaling from the user agent.

Use cases for the codec properties are illustrated here as they are likely one of the more complicated sets of properties with respect to merging and constraining across more than one profile. There are reasonable scenarios where requirements can be rationalize that the device, user and local network profiles may each wish to express preferences and constrains of the codec properties. Without getting into details or syntax on the codec properties, it is assumed that codec properties will need to express a codec definition and a preference order. This is the order that these codecs will be put in SDP for codec negotiation purposes. The following scenarios illustrate some possible combinations of sources of codec properties from the device, user and local network profiles. The scenarios identify rationale for providing codec properties in each of the profiles.

In the scenario where a device has no profiles or the profiles contain no codec properties, the device will enable a default set and preference order of codecs. The default set and preference order of codecs is a implementer specific choice. In some implementation it is s subset of the codecs supported by the device.

Let us assume a scenario where user agents providing telephony capabilities are deployed. The deployment has very simple requirements such that the user agents have fixed locations and always associated with the same user. This scenario does not need the separation between the user, device and local network profiles. A single profile would suffice. Another scenario having similar requirements is one where the user and local network profiles do not provide any codec related properties. This might be because the user does not care what codecs are used and the local network does not wish to impose any constraints on the codes used in the network. In the following use case, the device profile is the only source of codec properties. The codecs in the device profile may differ from the set of codecs supported by the device, due to the administrator of the device profile wanting: To have a uniform set of codecs used across all device types To exclude the use of a specific codec due to performance issues/concerns This will result in the device profile data further constraining the list of codecs that get applied. In addition, the administrator may want to list the order of which the codecs are to be applied. In this scenario the device profile data will dictate the ordered list of codecs to be applied.

In the following scenario users are allowed to express a preference over codecs. Users are probably not likely to express specific codes in the form of G.7XX, etc. They are likely to want to express a preference in the form of wideband, normal and low bandwidth as a preference. The following use case device and user profiles contain codec properties. The user may prefer a higher quality codec to be used, if available. Thereby the user profile data may provide an ordered list of codecs to be applied. The device profile also specifies a list of codecs and a default preference order. The merging of the data sources is as follows: The ordering of the codecs will be determined from the user profile data, which overrides the codec preference ordering from the device profile data. The set of codecs that may be applied, are the codecs listed in the user data constrained by the list of codecs from the device profile data. If none of the user data codecs are included in the device profile data, then the device profile default list will be used.

In another scenario the user is not allowed or does not care to express codec preferences. The owner/manager of the device defines the set of codecs which may be used on the device along with a preference ordering of codecs. There is no user profile or the user profile contains no codec properties. The local network wishes to define a policy over codec usage in the network. It is not clear there is a requirement that the local network be able to express a preference order. However the network operator is very likely to want to express a set of codecs that can or should not be used. The these constraints that the local network operator wishes suggest may relate to the goal of controlling bandwidth or conveying what will work over the available WAN connection. In the following use case, device and local network profiles provide codec properties. The local network may limit type of codecs that can be applied due to resources available. The merging of the data sources is as follows: The set of codecs that may be used is the ordered list of codecs from the device profile data, further constrained by the local network profile data. If none of the local network data codecs are supported by the device profile data, then a TBD policy will dictate the codecs that may be applied.

In this scenario everyone has an opinion on the codecs to be used. The device owner/manager wishes to define a set of codes based upon best interoperability of known end points in the environment. The user wishes to express preferences in the codecs (e.g. prefers wideband audio). The local network wishes to constrain the codecs based upon bandwidth (e.g. a wireless network with limited local network bandwidth, a SOHO network with dialup connectivity, a small office with shared 256kbps WAN connectivity). In the following scenario, device, user and local network profiles provide codec properties. The merging of the data sources is as follows: The ordering of the codecs will be determined from the user profile data, which overrides the ordering from the device profile data. The set of codecs that may be used are the codecs listed in the device profile data, constrained by the list of codecs from the user profile data and further constrained by the list of codecs from the local network profile data. If none of the user data codecs are included in the device profile data, then the device profile default list of codecs, constrained by the local network profile data will be used. If none of the local network data codecs are supported by the device profile data, then a TBD policy will dictate the codecs that may be applied.

A device will have a set of codecs supported, that may be offered. The list of codecs supported by a device may differ from the list of codecs in the device profile data. The list of codecs in the device profile data that get applied is the subset of the codecs supported by the device. Codecs listed in profiles that are not supported by the device are ignored. The device profile data will have a default ordered list of codecs, which implies a preference order that may be offered. The user profile data may provide an ordered list of user preferred codecs. The ordering of the codecs in the user profile data will override the ordering of the codecs in the device profile data. The user list of codecs may further constrain the list of codecs to be used. The local network profile data may provide a list of codecs supported. This list will further constrain the list of codecs that may be offered. The application profile data containing codec data will be ignored. The profiles need to express codecs that may be used and codecs that should not be used.

This section describes use cases related to the use of the SIP transport protocol settings for a user agent. It is assumed that user agents are configurable to define what transport protocols (e.g. UDP, TCP, TLS) are to be used for the SIP signaling.

When none of the profiles are available or the profiles do not specify the SIP transport protocol setting, the device�s default signaling transport(s) will be used.

In the following scenario, the device profile is the only source of profile data. The signaling transports contained in the device profile may differ from the set of signaling transports supported by the device. This may be due to the administrator of the device profile wanting: To have a uniform use of signaling transports used across all device types. To mandate TLS for security reasons. To exclude the use of a specific codec due to performance issues/concerns. This will result in the device profile data further constraining the list of signaling transports that could be used. In addition, the administrator may want to provide a preferred ordering for the signaling transports. The highest ordered signaling transport from the device profile data ordered set of signaling transports will be used.

The following scenario extends the prior case described above. SIP transport protocol properties are provided in both the device and user profiles. Consider that SIP user agents, like email agents, may want to provide the user with options to: Mandate that secure transport must be used. If secure transport is not possible the user does not want to use the user agent. Prefer secure transport. Attempt to use secure transport. If secure transport will not work, use which ever transport protocol will make communication work. When the user mandates the use of secure signaling transports only, the user wishes to constrain the available signaling transports to TLS. When indicating a preference to secure transport, the use is specifying a preference order for the use of transport protocols where TLS is the highest priority. Now consider the merging strategy required to accomplish the goals of this use case scenario where the device and user profiles both contain SIP transport protocol properties. The merging of the data sources is as follows: The set of signaling transports that are allowed to be used is constrained by the device profile data. This is further constrained by the user profile data. The highest preferred signaling transport from the constrained list will be used.

In the following scenario, device and local network profile data is available. The local network may have a limited set of signaling transports that it supports due to NAT or firewall constraints. The merging of the data sources is as follows: The set of signaling transports that may be used is the ordered list of signaling transports from the device profile data, further constrained by the local network profile data. If none of the local network data signaling transports are supported by the device profile data, then a TBD policy will dictate the codecs that may be applied.

A device will have a set of signaling transports that it supports (note: one can be a set), with a default signaling transport. The set of signaling transports supported by a device may differ from the set of signaling transports in the device profile data. The set of signaling transports in the device profile data is an ordered list, that is a subset of the set of signaling transports supported by the device. This may be due to performance issues associated with one the signaling transport(s). The user profile data may provide a list of preferred signaling transports to be used (e.g., TLS for securing the signaling). The local network profile data provides a list of signaling transports supported, and will constrain the set of signaling transports that could be used.

Implementers must be able to differentiate each implementation. In addition, it does not serve user agent owners and administrators well to require an orchestrated upgrade for all user agent implementations and profile delivery servers before a new capability or feature can be supported with the required profile data. Hence one of the most important requirements is to support the ability of implementers to extend specified standard data sets to include additional related features and flexibility. It MUST be possible to extend a data set without breaking user agents that support that data set. This may require that user agents ignore parts of a data set that it does not implement or extensions that it does support.

User agents vary quite widely in their capabilities. Some user agents function like traditional telephones. Some user agents support only text messaging. Some user agents support many media types such as video. Some user agents that function like a telephone have a single line, some have large numbers of lines. There is no such thing as one size fits all. It MUST be possible for an implementer to choose which data sets to support based upon the capabilities that are supported by the user agent. The schema for containing the profile data MUST support a profile that contains only the data sets that a user agent supports. This allows the profile delivery server to create small profiles for specific devices. However a user agent SHOULD ignore properties for capabilities that it does not support. This allows the profile delivery server to be ignorant of the capabilies of the device. The degree to which the profile delivery server has intelligence of the user agent capabilities is an implementation choice.

XML is perhaps not really a requirement, but a solution base upon requirements. However it is hard to ignore the desire to utilize readily available tools to manage and manipulate profile data such as XSLT, XPATH and XCAP. The requirement that should be considered when defining the schema and syntax is that many user agents have limited resources for supporting advanced XML operation. The simplest XML construct possible should be used, that support the required functionality. Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols provides useful information in this regard.

Many user agents (e.g. appliances and softphones running on PCs) provide user interfaces that permit the user to edit properties that are logically part of user, application, device or local network profiles. Operators and administrators would like to be able to specify what an end user can change in those profiles and what an end user is not allowed to change. There may also be sensitive data the user agent requires to function, but that the operator of the system does not want the end user to see. For some properties the system operator may allow the user a fixed set of choices among the supported set of possible values. It MUST be possible to express whether an end user may change a data set property. It MUST be possible to express that a property should not be made visible to the end user. It MUST be possible to express allowable values or ranges that the end user may change a property to. The access control information SHOULD be optional to the data set. It might be useful if it was possible to express the access control independent of the properties themselves. The access control specification by itself might be useful to express a general policy that the device owner or local network operator wish to impose.

There is a need for property value types such as free form text, token/enumerations, integers, real numbers, etc. Many of these properties will have constrained values as opposed to the range of all possible values. These constrains may be due to protocol definitions, implementation limitations, and/or the desire (e.g. by the user, device owner, local network operator) to impose policy on the user agent. The ability to express the property constraints is useful from the perspective of access control as described in the above section. It is also useful to parameterize a user interface (e.g. on the user agent itself or on the profile delivery server) which provides a facility to modify profile data. It MUST be possible for the schema to specify property constraints as ranges or discrete sets of possible values. These constrains SHOULD be optional to the data set. It might be useful if it was possible to express the constraints independent of the properties themselves. The constraints without the property values might be used to specify the capabilities of a particular user agent implementation.

specifies a mechanism where the user agent retrieves profile data from as many as four different sources. The separation of the user profile facilitates a hotelling capability and the ability to easily re-assign a user to a different device. The separation of the local network profile facilitates properties specific to operating in the local network in a roaming scenario (e.g. outbound proxy or NAT traversal properties). The local network profile may also impose policy as describe in the next section. The device profile facilitates device capability based properties as well as a means for the device owner or manager (e.g. enterprise or service provider) to impose policy. The potential sources of profile data add complexity to the user agent that must consolidate these separate profiles into a single working profile. It would be simple if we could define each property as only allowed in one of the profiles. However it overly constrains the profiles and takes away desired functionality. It would also be simpler if we could define one rule for all profile data sets and properties by which we merge the profile (e.g. local network profile overwrites user profile which overwrites device profile for all data). However this too is overly restrictive and eliminates some very useful functionality. The rules to merge profile data sets needs to be defined for each data set. In some cases an entire data set must be considered atomic with a preference as to which profile sources presides over the other. In other cases it makes sense to merge profile data sets, aggregating properties from the data set provided in each of the profiles. It may also be desirable to have the effect of filtering of data set properties. The desired effect might be for the owner of the device or the local network operator to constrain what values are allowed for properties in the profiles. This may also be the mechanism to facilitate imposing of policy as described in the next section. The operation of resolving overlapping data sets from multiple profiles, regardless of the means or net result, will be referred to as "merging" in this document. A profile MUST have the means to constrain the merging algorithm. [It is not clear whether the merging algorithm can be statically defined by the data set type or if there is a need to specify this as part of the data set (i.e. is this text in a data set definition or must the schema support this expression?). It gives operators and administrators more control if it can be expressed in the schema, but that will lead to more complexity and possible run time problems. Need some more thought and input on this.]

Local network operators would like to impose policy on users and devices operating in their network. There is a need to constrain the operation and require specific behavior in the network. This might be a simple as to get access to the Internet, user agents must use a specified outbound proxy and NAT traversal mechanism. The network might have limited bandwidth such that the operator would like to constrain codecs or media streams to keep the network functional. The local network may provide emergency service behavior or functionality properties that are more specific than those provided by the device or user profile. The examples here focus on policy from the local network. However the facility to impose policy may be equally useful to the user and device profiles. It MUST be possible to impose policy in any of the profile sources that constrains, overwrites or modifies properties provided in data sets from other sources.

This document defines an XML Schema, for SIP Profile Data Sets that provides: a base element type "setting" from which all settings in other schema definitions inherit (this allows other definitions to specify the content models for ways of combining settings; it is analogous to a C++ virtual base class). A "policy" attribute to the "setting" element that specifies constraints for how settings are to be combined or overrided to form a working profile. A "visablity" attribute to the "setting" element that specifies access control to the settings values in the profiles. A root element for all property sets (the outermost container). The full text of the schema is in ; the following describes the usage of the schema in defining properties and combining them to construct the working profile of a User Agent.

Each property in a profile data set is defined using XML Schema Datatypes and XML Schema Structures ; a property is modelled by an XML element derived from the "setting" element in the SIP Profile Data Set Schema. The element content is the setting value. The XML Schema specifications provide a rich set of mechanisms for defining this data, and XML Namespaces provide the means to uniquely identify them. Typically each data set will specify its own namespace. A data set has no structural grouping from an XML perspective. The grouping is logical and identified by its namespace.

The attribute "visibility" is defined on the "setting" element to specify whether or not the user agent is permitted to display the property value to the user. It has two possible values: Specifies that display of the property value is not restricted. This is the default value of the attribute if it is not specified. Specifies that the user agent SHOULD NOT display the property value. Display of the property value may be allowed using special administrative interfaces, but is not appropriate to the ordinary user.

When constructing a property set, the profile delivery server may not be able to know all of the constraints of the User Agent that will receive that property set. In particular, the capabilities of the agent may be limited either intrinsically or by other property sets (some of which may come from other profile sources).

The root element of a property set is "property_set"; it is the container that is provided to the user agent. The elements contained within a property_set form a set of constraints to be "satisfied" by the device; some positive (values to be set), and some negative (prohibited values). An element is "satisfied" iff the working profile of the User Agent matches the constraints of the property_set. The property_set contains all properties that are set from all data sets contained in the profile. The data sets do not have structure other than complex properties which may be defined in the data set specification. This allows the structured grouping of properties to be based upon the constraints to be applied. The constraints constructs are described in the following sections.

The setting element is the abstract element from which all profile properties or settings shall inherit.

The setting element has an optional policy attribute. The policy attribute is used to define the conatraint over which the setting may be overrided in other profiles. The possible values for this attribute are: allowed - indicates the setting value should be allowed, but may be overrided. disallowed - indicates the setting values is not allowed. The indicated value for this setting should not be set by any other profile. mandatory - indicates the setting values should be used. Other profiles may not disallow this setting value. It is not an error situation if another profile indicates a policy that contradicts with. The setting from a profile of lower precidence is which contradicts the disallow or mandatory policy setting of another profile are ignored (see merging policies ).

The setting element has a visability attribute which indicates to the user agent (or other retrievers of user agent profiles) that the value of the setting element should not be shown to the user. This is used to hide setting values that the profile administrator may not want the user to see or know. visable - the value of the setting may be shown to the user hidden - the value of the setting should not be shown to the user

[The schema will also define a set of common types that are used in defining data sets (e.g. name-addr) in a future version of this draft.]

[Some discussion is needed here on conflict resolution. Reviewers are encouraged to consider the implications of conflicting property sets, especially when different property sets are provided to the same device possibly from different sources.]

This section defines considerations and information that must be defined when specifying a new data sets. This is intended to be a guide to authors writing specifications defining new data sets or extensions to existing ones.

Data set specification documents should contain a section which defines the meaning of all of the properties contained in the data set. The objective is to define the property such that implementers have a clear definition and semantics to interpret properties in a consistent way. User agents not only need to use the same profile content, they need to apply the properties in a consistent way to achieve true interoperability. The following information should be defined for each property in a data set: Describe the meaning and application of the property. Define how many of this property may occur in a data set (e.g. zero, one or many) as well as its relationship to any other properties in this or other data sets. [For settings with cardinality allowing many do we need to define a wild card to be able to set a policy of disallow, to prevent additional values from being aggregated from other profiles of lower precidence?] Define the default value of this property if it is not set. Describe if the default is different if the property is present and not set vs. completely absent from the data set. Define if the default varies in relation to another property.

A data set should define a new XML namespace to scope all of the properties that are defined in the name space. properties may be simple (i.e. having a single value) or they may be complex (i.e. a container or structure of values). Each property in the data set SHOULD inherit from the "setting" element. Complex properties and all of their child elements each should inherit from "settings" as well.

Collisions may occur on a data set if multiple sources provide properties for that data set. COllisions are resolved through the merging policy. The default order of precidence of the profiles is: device, user, applicaiton, local network. A profile of lower precidence will not override a setting value that has been given the policy attribute value of disallow or mandatory. That is the specific settings in the lower precident profile that have settings which contradict a setting value from a profile with higher precidence designated with the policy attribute value of "mandatory" or "disallow" are ignored. Data set specifications MAY define alternative merging policy algorithms by which to resolve the conflict for specific settings. This resolution of conflict from multiple sources is called merging. The data set specification can determine how merging occurs for that data set. The author may choose to combine, apply a policy of mutually exclusive ordered preference (i.e. the entire atomic data set is used from one profile source in a defined order of preference), or well defined combination of these or other algorithms. In absense of a merging policy algorithm all settings will be merged as defined in the above paragraph. Settings which have cardinality allowing multiple values are by default aggregated accross each profile in the order of the profile precidence. Settings with other cardinality override the setting as allowed by the policy constraint. That is the setting value may be overrided until the highest precident profile defines the setting policy attribute values to "disallow" or "mandatory".

The following sections name some of the candidate data sets that might be defined. These data sets can be aggregated to form profiles appropriate to the capabilities of a user agent implementation.

The lowest common denominator set of properties common to all SIP user agents of any capability.

Codecs and media streams

AORs and lines

Server settings. Proxy for clients.

To test the schema a few example data sets are defined here. [The examples in this section are contained in this document for convenience. At some point in this document's lifecycle they will be split out as separate drafts.]

The SIP Protocol Data Set is intended the be the lowest common denominator among all user agent types regardless of capability. This data set contains properties that all user agents require. That does not mean that all of these properties are mandatory.

This property contains properties related to a SIP transport protocol. It names the transport protocol, defines whether the protocol is enabled or not and defines the port to which that protocol is bound. If the protocol is named it defaults to enabled if not explicitly set. If the port property is not set, it defaults to the default specified by the specification which binds the protocol to SIP. The user agent should enable all the set transport protocols that are supported by the user agent. The user agent ignores protocol bindings that it does not support. The user agent may default transport protocols to enabled, that it supports, if a protocol property for that transport protocol is not present in the data set. The order of the list of transport_protocol setting values indicates the order of preference. The default outbound proxy, through which all SIP requests, not explicitly routed, should be sent. The format of this parameter is of name-addr as specified in . This property is optional. If absent or not set, SIP requests are sent to directly to the URI of the request. If set the effect of this property is to add a loose route as defined in for the next hop destination. The following is an example instance of the SIP protocol data set.

The following is the schema for the SIP protocol data set.

<?xml version='1.0' encoding='iso-8859-1' standalone='yes'?>  <schema xmlns:spds='http://sipfoundry.org/schema/profile-data-sets-00' targetNamespace='http://sipfoundry.org/schema/profile-data-sets-00' xmlns='http://www.w3.org/2001/XMLSchema' > <annotation> <documentation> SIP Protocol Properties. </documentation> </annotation> <element name="transport_protocol" group="spds::setting"> <annotation> <documentation> Container for the properties for a single transport protocol binding for SIP. </documentation> </annotation> <complexType> <sequence> <element ref="spds:name" /> <element ref="spds:port" /> </sequence> </complexType> </element> <element name="name" group="spds::setting"> <annotation> <documentation> Name of the specific transport protocol </documentation> </annotation> <simpleType type="spds:transport"/> </element> <element name="port" group="spds::setting"> <annotation> <documentation> Port binding for the transport protocol </documentation> </annotation> <simpleType type="spds:port_num"/> </element> <element name="outbound_proxy" group="spds::setting"> <annotation> <documentation> The next hop proxy for SIP requests without a defined route set. Value is of name-addr format. There should probably be a type defined for name-addr that outbound_proxy inherits from. </documentation> </annotation> <simpleType /> </element> </schema>

The SIP Protocol Data Set uses the default merging policy defined in

The following is example data that should be defined in the media data set:

Video codec1 codec 2 Audio G.711 G.722.1 G.729A ILBC Text IM realtime-text maximum number of streams/session maximum number of streams total maximum allowed bandwidth per stream IP addresses/ports TOS marking

Consider the use case described in where the user wishes to indicate that only secure SIP transport should be used. The device profile may contain SIP Protocol Data Set (see ) settings that look like the following:

<property_set> <transport_protocol policy="allow"> <name>UDP</name> <port>5060</port> </transport_protocol> <transport_protocol policy="allow"> <name>TCP</name> <port>5060</port> </transport_protocol> <transport_protocol policy="allow"> <name>TLS</name> <port>5061</port> </transport_protocol> <outbound_proxy policy="mandatory"> sip:outproxy.example.com </outbound_proxy> </property_set> The user profile which indicates that only TLS should be used would look like (Note: this example also indicates that port 5061 should be used with a mandatory policy as well. This may be more constrained than the user really wants.):

<property_set> <transport_protocol policy="mandatory"> <name>TLS</name> <port>5061</port> </transport_protocol> <transport_protocol policy="disallow"> <name>UDP</name> </transport_protocol> <transport_protocol policy="disallow"> <name>TCP</name> </transport_protocol> </property_set> The merged result of the device and user profile would look like:

<property_set> <transport_protocol policy="mandatory"> <name>TLS</name> <port>5061</port> </transport_protocol> <transport_protocol policy="disallow"> <name>UDP</name> </transport_protocol> <transport_protocol policy="disallow"> <name>TCP</name> </transport_protocol> <outbound_proxy policy="mandatory"> sip:outproxy.example.com </outbound_proxy> </property_set> (personal and local service speed dial lists)

(allowed and disallowed codecs)

(device prefers default ports 5060, local net requires port 11000)

Security is mostly a delivery problem. The delivery framework SHOULD provide a secure means of delivering the profile data as it may contain sensitive data that would be undesirable if it were stolen or sniffed. Storage of the profile on the profile delivery server and user agent is an implementation problem. The profile delivery server and the user agent SHOULD provide protection that prevents unauthorized access of the profile data. The profile delivery server and the user agent SHOULD enforce the access control policies defined in the profile data sets if present. [The point of the access control construct on the data set is to provide some security policy on the visibility and ability to change sensative properties. Does the access control mechanism also create a security problem where the local network can set or hide properties from the user?] Some transport mechanisms for delivery of the profile data do not provide a secure means of delivery. In addition some user agents may not have the resources to support the secure mechanism used for delivery (e.g. TLS).

Added use case scenarios for codecs, SIP transport protocol and outbound proxy to better illustrate requirements. Some of the derived requirements are listed with the use cases. Added settings element attributes "policy" and "visablity" to provide mering constraints and acccess control capability. Removed the element based merging constraints using the: forbid, set_any, set_all and set_one elements. This greatly simplifies the degree of XML operations required to perform the request merging. Defined default merging policy and profile source precidence along with the option for different policies to be describe in specific settings definition documents. Added example merging with XML profiles from device and user for the SIP transport protocol.

&rfc3265; &I-D.ietf-sipping-config-framework; &I-D.sinnreich-sipdev-req; &rfc0822; &rfc2119; &rfc3261; &rfc3470; XML Schema Part 1: Structures University of Edinburgh Oracle Corporation Commerce One Lotus Development Corporation XML Schema Part 2: Datatypes Kaiser Permanente Microsoft Namespaces in XML Textuality

tbray@textuality.com

Hewlett-Packard Company

dmh@corp.hp.com

Microsoft

andrewl@microsoft.com

<?xml version='1.0' encoding='iso-8859-1' standalone='yes'?> <!DOCTYPE schema [ <!ENTITY % doc_src "http://scm.sipfoundry.org/rep/ietf-draft/petrie/profile-data-sets"> ]>  <schema xmlns:spds='http://sipfoundry.org/schema/profile-data-sets-00a' targetNamespace='http://sipfoundry.org/schema/profile-data-sets-00a' xmlns='http://www.w3.org/2001/XMLSchema' > <annotation> <documentation> Proposed XML metalanguage for the description of SIP User Agent Profile Data Sets. </documentation> <documentation source='%doc_src;'/> </annotation>  <simpleType name="port_num"> <restriction base="integer"> <minExclusive value='0' /> <maxInclusive value='65535' /> </restriction> </simpleType> <simpleType name="transport_protocol"> <restriction base="string"> <enumeration value="TCP"/> <enumeration value="UDP"/> <enumeration value="TLS"/> </restriction> </simpleType>  <element name="property_set"> <annotation> <documentation> The property_set element is the root element returned in response to a request for a profile data set. </documentation> </annotation> <complexType> <sequence minOccurs="0" maxOccurs="unbounded"> <element ref="spds:setting" /> </sequence> </complexType> </element> <element name="setting" abstract="true"> <annotation> <documentation> The 'setting' element is an abstract used as the basis for the definition of the setting elements in property schemas derived from this one. It serves here as a placeholder in constructing the content models for the container elements used to group settings into sets. </documentation> <documentation source='%doc_src;'/> </annotation> <complexType> <complexContent> <restriction base="anyType"> <attribute name="policy" default="allow" > <annotation> <documentation> The policy attribute is used to define the strength to which a setting should be used. It can also be viewed as the finality to which a setting may be overrided. </documentation> <documentation source='%doc_src;'/> </annotation> <simpleType> <restriction> <enumeration value="allow"/> <enumeration value="disallow"/> <enumeration value="mandatory"/> </restriction> </simpleType> </attribute> <attribute name="visibility" default="visible" > <annotation> <documentation> The visibility attribute indicates whether the user agent should show the setting value(s) to the user. </documentation> <documentation source='%doc_src;'/> </annotation> <simpleType> <restriction> <enumeration value="visible"/> <enumeration value="hidden"/> </restriction> </simpleType> </attribute> </restriction> </complexContent> </complexType> </element> </schema>