SIPPING D. Petrie Internet-Draft S. Lawrence Expires: January 7, 2005 Pingtel Corp. July 9, 2004 A Schema for Session Initiation Protocol User Agent Profile Data Sets draft-petrie-sipping-profile-datasets-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 7, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract 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. Petrie & Lawrence Expires January 7, 2005 [Page 1] Internet-Draft SIP UA Data Sets July 2004 Table of Contents 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Requirements Terminology . . . . . . . . . . . . . . . . . 4 2.2 Profile Data Terminology . . . . . . . . . . . . . . . . . 5 2.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Implementer Extensibility . . . . . . . . . . . . . . . . 6 3.2 Flexible Capabilities . . . . . . . . . . . . . . . . . . 6 3.3 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 Access Control . . . . . . . . . . . . . . . . . . . . . . 7 3.5 Data Constraints and Range Definition . . . . . . . . . . 8 3.6 Support of User, Device, Local Network Sources . . . . . . 8 3.7 The Ability to Specify Policy . . . . . . . . . . . . . . 9 4. Overall Data Set Schema . . . . . . . . . . . . . . . . . . . 9 4.1 Data Primitives . . . . . . . . . . . . . . . . . . . . . 10 4.2 Specifying Access Control . . . . . . . . . . . . . . . . 10 4.3 Grouping and Cardinality of Sets of Data . . . . . . . . . 10 4.3.1 property_set . . . . . . . . . . . . . . . . . . . . . 10 4.3.2 forbid . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.3 set_all . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.4 set_one . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.5 set_any . . . . . . . . . . . . . . . . . . . . . . . 11 4.4 Common Types . . . . . . . . . . . . . . . . . . . . . . . 12 4.5 Merging Property Sets . . . . . . . . . . . . . . . . . . 12 5. Defining Data Sets . . . . . . . . . . . . . . . . . . . . . . 12 5.1 Data Set Properties Definitions . . . . . . . . . . . . . 12 5.2 Data Set Schema Definition . . . . . . . . . . . . . . . . 12 5.3 Merging Different Sources of a Data Set . . . . . . . . . 13 6. Candidate Data Sets . . . . . . . . . . . . . . . . . . . . . 13 6.1 SIP Protocol Data Set . . . . . . . . . . . . . . . . . . 13 6.2 Media Data Set . . . . . . . . . . . . . . . . . . . . . . 13 6.3 Identity Data Set . . . . . . . . . . . . . . . . . . . . 13 6.4 HTTP Protocol Data Set . . . . . . . . . . . . . . . . . . 13 6.5 STUN Protocol Data Set . . . . . . . . . . . . . . . . . . 13 6.6 TURN Protocol Data Set . . . . . . . . . . . . . . . . . . 13 6.7 Address Book . . . . . . . . . . . . . . . . . . . . . . . 14 6.8 Buddy List . . . . . . . . . . . . . . . . . . . . . . . . 14 6.9 SIP Digit Maps Data Set . . . . . . . . . . . . . . . . . 14 7. Example Data Set Definitions . . . . . . . . . . . . . . . . . 14 7.1 SIP Protocol Data Set . . . . . . . . . . . . . . . . . . 14 7.1.1 Data Set Properties Definitions . . . . . . . . . . . 14 7.1.2 Data Set Schema Definition . . . . . . . . . . . . . . 15 7.1.3 Merging Different Sources of a Data Set . . . . . . . 16 7.2 Media Data Set . . . . . . . . . . . . . . . . . . . . . . 17 8. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 17 8.1 Merge Two Data Sets . . . . . . . . . . . . . . . . . . . 17 Petrie & Lawrence Expires January 7, 2005 [Page 2] Internet-Draft SIP UA Data Sets July 2004 8.2 Policy Filtering . . . . . . . . . . . . . . . . . . . . . 17 8.3 Override . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 A. SIP UA Profile Schema . . . . . . . . . . . . . . . . . . . . 19 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . 24 Petrie & Lawrence Expires January 7, 2005 [Page 3] Internet-Draft SIP UA Data Sets July 2004 1. Motivation 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 [I-D.ietf-sipping-config-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 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 three 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 use case is applicable to most of the range of user agent capabilities. 2. Introduction 2.1 Requirements Terminology Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in RFC 2119[RFC2119]. Petrie & Lawrence Expires January 7, 2005 [Page 4] Internet-Draft SIP UA Data Sets July 2004 2.2 Profile Data Terminology property - 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. setting - the binding of a specific value or set of values to a given property. profile - a collection of settings to be applied for a specific user, device, or local network. device - 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. user profile - 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. it rings when someone calls them, it has the users shortcuts installed). device profile - 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. local network profile - 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. data set - a collection of properties. working profile - 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 . merging - 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). 2.3 Overview 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 Petrie & Lawrence Expires January 7, 2005 [Page 5] Internet-Draft SIP UA Data Sets July 2004 settings, which may overlap, from potentially three 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. 3. Requirements 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. 3.1 Implementer Extensibility 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. 3.2 Flexible Capabilities 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 Petrie & Lawrence Expires January 7, 2005 [Page 6] Internet-Draft SIP UA Data Sets July 2004 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. 3.3 XML 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 required functionality. Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols [RFC3265] provides useful information in this regard. 3.4 Access Control 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, 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 an 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. Petrie & Lawrence Expires January 7, 2005 [Page 7] Internet-Draft SIP UA Data Sets July 2004 3.5 Data Constraints and Range Definition 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. 3.6 Support of User, Device, Local Network Sources [I-D.ietf-sipping-config-framework] specifies a mechanism where the user agent retrieves profile data from as many as three 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 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 Petrie & Lawrence Expires January 7, 2005 [Page 8] Internet-Draft SIP UA Data Sets July 2004 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.] 3.7 The Ability to Specify Policy 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. 4. Overall Data Set Schema This document defines an XML Schema, for SIP Profile Data Sets that provides: o a base element type 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). o A set of containers for use when assembling property sets that specify constraints for how settings are to be combined to form a working profile. Petrie & Lawrence Expires January 7, 2005 [Page 9] Internet-Draft SIP UA Data Sets July 2004 o A root element for all property sets (the outermost container). The full text of the schema is in Appendix A; the following describes the usage of the schema in defining properties and combining them to construct the working profile of a User Agent. 4.1 Data Primitives Each property in a profile data set is defined using XML Schema Datatypes [W3C.REC-xmlschema-2] and XML Schema Structures [W3C.REC-xmlschema-1]; 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 [W3C.REC-xml-names] 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. 4.2 Specifying Access Control [Specification of access control for settings will be addressed in a future revision of this draft] 4.3 Grouping and Cardinality of Sets of Data 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 SIP Profile Data Set Schema defines four elements that together express constraints on the valid ways in which the settings within a set can be combined. 4.3.1 property_set 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 Petrie & Lawrence Expires January 7, 2005 [Page 10] Internet-Draft SIP UA Data Sets July 2004 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. 4.3.2 forbid Each property set contains at most one "forbid" element; settings within the forbid container MUST NOT be in the working profile of the User Agent. This allows one property set to prohibit certain settings in other property sets. For example, a local network property set might forbid the use of high bandwidth codecs, even though the user or device property sets include them. An empty setting within the forbid element (for example "") means that that setting MUST NOT be set to any value. A non-empty setting within the forbid element (for example "bar") MUST NOT be set to the indicated value (or any of the indicated values, in the case of multi-valued settings). 4.3.3 set_all The "set_all" container element specifies that the User Agent MUST satisfy all of the elements it contains. If the User Agent cannot (due to inherent limitations or conflicting profile constraints) satisfy the elements within a set_all element, then it MUST NOT use any of them, and the set_all profile element is considered not to have been satisfied. 4.3.4 set_one The "set_one" container element is an ordered list of elements; it specifies that the User Agent MUST satisfy the first of the contained elements that it can without conflicting with other constraints. If the User Agent cannot (due to inherent limitations or conflicting profile settings) satisfy one of the contained settings, then the set_one profile element is considered not to have been satisfied. 4.3.5 set_any The "set_any" container element specifies optional settings; the User Agent SHOULD include any of the contained elements in its working profile, unless inherent limitations or other profile settings conflicts with them. A set_any element is always satisfied, even if none of the elements it contains are satisfied. Petrie & Lawrence Expires January 7, 2005 [Page 11] Internet-Draft SIP UA Data Sets July 2004 4.4 Common Types [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.] 4.5 Merging Property Sets [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.] 5. Defining Data Sets 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. 5.1 Data Set Properties Definitions 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: description - Describe the meaning and application of the property. cardinality - 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. default value - 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. 5.2 Data Set Schema Definition A data set should define a new XML namespace [W3C.REC-xml-names] 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 Petrie & Lawrence Expires January 7, 2005 [Page 12] Internet-Draft SIP UA Data Sets July 2004 properties and all of their child elements each should inherit from "settings" as well. 5.3 Merging Different Sources of a Data Set Collisions may occur on a data set if multiple sources (e.g. user, device and/or local network) provide properties for that data set. Data set specifications MUST define the policy and algorithm by which to resolve the conflict. 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. [Should we define some common algorithms here that authors can refer to? Perhaps the schema should allow this to be expressed as part of the data set?] 6. Candidate Data Sets 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. 6.1 SIP Protocol Data Set The lowest common denominator set of properties common to all SIP user agents of any capability. 6.2 Media Data Set Codecs and media streams 6.3 Identity Data Set AORs and lines 6.4 HTTP Protocol Data Set Server settings. Proxy for clients. 6.5 STUN Protocol Data Set 6.6 TURN Protocol Data Set Petrie & Lawrence Expires January 7, 2005 [Page 13] Internet-Draft SIP UA Data Sets July 2004 6.7 Address Book 6.8 Buddy List 6.9 SIP Digit Maps Data Set 7. Example Data Set Definitions 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.] 7.1 SIP Protocol Data Set 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. 7.1.1 Data Set Properties Definitions transport_protocol - 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. outbound-proxy - 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 [RFC3261]. 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 [RFC3261] for the next hop destination. The following is an example instance of the SIP protocol data set. Petrie & Lawrence Expires January 7, 2005 [Page 14] Internet-Draft SIP UA Data Sets July 2004 UDP 5060 TCP 5060 TLS 5061 sip:outproxy.example.com 7.1.2 Data Set Schema Definition The following is the schema for the SIP protocol data set. SIP Protocol Properties. Container for the properties for a single transport protocol binding for SIP. Petrie & Lawrence Expires January 7, 2005 [Page 15] Internet-Draft SIP UA Data Sets July 2004 Name of the specific transport protocol Port binding for the transport protocol 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. 7.1.3 Merging Different Sources of a Data Set The entire SIP Protocol Data Set is considered atomic when merging from multiple data set. The entire data set is used from the first of the following sources that provides the data set: local network, device or user profile. Petrie & Lawrence Expires January 7, 2005 [Page 16] Internet-Draft SIP UA Data Sets July 2004 7.2 Media Data Set 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 8. Example Use Cases 8.1 Merge Two Data Sets (personal and local service speed dial lists) 8.2 Policy Filtering (allowed and disallowed codecs) 8.3 Override (device prefers default ports 5060, local net requires port 11000) 9. Security Considerations 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 Petrie & Lawrence Expires January 7, 2005 [Page 17] Internet-Draft SIP UA Data Sets July 2004 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). [Should we specify a mechanism to symmetrically encrypt the profile (e.g. AES) and a key format? The profile delivery server would encrypt the profile before delivery and the user agent would decrypt the profile after collecting the appropriate credential information to generate the correct key. Many user agents support a mechanism like this to overcome insecure profile delivery mechanisms. It is lighter weight foot print wise and to implement than adding TLS.] 10 References [I-D.ietf-sipping-config-framework] Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-03 (work in progress), May 2004. [I-D.sinnreich-sipdev-req] Butcher, I., Lass, S., Petrie, D., Sinnreich, H. and C. Stredicke, "SIP Telephony Device Requirements, Configuration and Data", draft-sinnreich-sipdev-req-03 (work in progress), February 2004. [RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [W3C.REC-xml-names] Petrie & Lawrence Expires January 7, 2005 [Page 18] Internet-Draft SIP UA Data Sets July 2004 Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C REC-xml-names, January 1999, . [W3C.REC-xmlschema-1] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, . [W3C.REC-xmlschema-2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C REC-xmlschema-2, May 2001, . Authors' Addresses Daniel Petrie Pingtel Corp. 400 W. Cummings Park Suite 2200 Woburn, MA 01801 US Phone: "Dan Petrie (+1 781 938 5306)" EMail: dpetrie@pingtel.com URI: http://www.pingtel.com/ Scott Lawrence Pingtel Corp. 400 W. Cummings Park Suite 2200 Woburn, MA 01801 US Phone: "Scott Lawrence (+1 781 938 5306)" EMail: slawrence@pingtel.com URI: http://skrb.org/scott/ Appendix A. SIP UA Profile Schema ]> Proposed XML metalanguage for the description of SIP User Agent Profile Data Sets. 0 65535 The property_set element is the root element returned in response to a request for a profile data set. Petrie & Lawrence Expires January 7, 2005 [Page 20] Internet-Draft SIP UA Data Sets July 2004 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. Contains some number of settings; the user agent MAY include none, any, or all of the contained settings, except those also listed in a 'forbid' element of the current configuration. Petrie & Lawrence Expires January 7, 2005 [Page 21] Internet-Draft SIP UA Data Sets July 2004 Contains some number of settings; the user agent MUST include all of the contained settings. Contains an ordered sequence of settings; the user agent MUST include the first of the contained settings of which is capable and which is not listed in a 'forbid' element of the working profile, Petrie & Lawrence Expires January 7, 2005 [Page 22] Internet-Draft SIP UA Data Sets July 2004 Appendix B. Acknowledgments Petrie & Lawrence Expires January 7, 2005 [Page 23] Internet-Draft SIP UA Data Sets July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. Petrie & Lawrence Expires January 7, 2005 [Page 24] Internet-Draft SIP UA Data Sets July 2004 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Petrie & Lawrence Expires January 7, 2005 [Page 25]