SIPPING D. Petrie
Internet-Draft S. Lawrence
Expires: August 20, 2005 Pingtel Corp.
M. Dolly
AT&T Labs
February 19, 2005
A Schema and Guidelines for Defining Session Initiation Protocol User
Agent Profile Data Sets
draft-petrie-sipping-profile-datasets-01.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 August 20, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). 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
Petrie, et al. Expires August 20, 2005 [Page 1]
Internet-Draft SIP UA Data Sets February 2005
data. It also explores some specific data sets to test the
requirements, assumptions and syntax.
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 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1 Outbound Proxy Setting . . . . . . . . . . . . . . . . 7
3.1.2 Codec Settings . . . . . . . . . . . . . . . . . . . . 7
3.1.3 Transport Protocol Setting . . . . . . . . . . . . . . 11
3.2 Requirement Descriptions . . . . . . . . . . . . . . . . . 13
3.2.1 Implementer Extensibility . . . . . . . . . . . . . . 13
3.2.2 Flexible Capabilities . . . . . . . . . . . . . . . . 13
3.2.3 XML . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.4 Access Control . . . . . . . . . . . . . . . . . . . . 14
3.2.5 Data Constraints and Range Definition . . . . . . . . 14
3.2.6 Support of User, Application, Device, Local
Network Sources . . . . . . . . . . . . . . . . . . . 14
3.2.7 The Ability to Specify Policy . . . . . . . . . . . . 15
4. Overall Data Set Schema . . . . . . . . . . . . . . . . . . . 16
4.1 Data Primitives . . . . . . . . . . . . . . . . . . . . . 16
4.2 Specifying Access Control . . . . . . . . . . . . . . . . 16
4.3 Grouping and Cardinality of Sets of Data . . . . . . . . . 17
4.3.1 property_set . . . . . . . . . . . . . . . . . . . . . 17
4.3.2 setting Element . . . . . . . . . . . . . . . . . . . 17
4.3.3 policy Attribute . . . . . . . . . . . . . . . . . . . 17
4.3.4 visablity Attribute . . . . . . . . . . . . . . . . . 18
4.4 Common Types . . . . . . . . . . . . . . . . . . . . . . . 18
4.5 Merging Property Sets . . . . . . . . . . . . . . . . . . 18
5. Defining Data Sets . . . . . . . . . . . . . . . . . . . . . . 18
5.1 Data Set Properties Definitions . . . . . . . . . . . . . 18
5.2 Data Set Schema Definition . . . . . . . . . . . . . . . . 19
5.3 Merging Different Sources of a Data Set . . . . . . . . . 19
6. Candidate Data Sets . . . . . . . . . . . . . . . . . . . . . 20
6.1 SIP Protocol Data Set . . . . . . . . . . . . . . . . . . 20
6.2 Media Data Set . . . . . . . . . . . . . . . . . . . . . . 20
6.3 Identity Data Set . . . . . . . . . . . . . . . . . . . . 20
6.4 HTTP Protocol Data Set . . . . . . . . . . . . . . . . . . 20
6.5 STUN Protocol Data Set . . . . . . . . . . . . . . . . . . 20
6.6 TURN Protocol Data Set . . . . . . . . . . . . . . . . . . 20
6.7 Address Book . . . . . . . . . . . . . . . . . . . . . . . 20
6.8 Buddy List . . . . . . . . . . . . . . . . . . . . . . . . 20
6.9 SIP Digit Maps Data Set . . . . . . . . . . . . . . . . . 21
Petrie, et al. Expires August 20, 2005 [Page 2]
Internet-Draft SIP UA Data Sets February 2005
7. Example Data Set Definitions . . . . . . . . . . . . . . . . . 21
7.1 SIP Protocol Data Set . . . . . . . . . . . . . . . . . . 21
7.1.1 Data Set Properties Definitions . . . . . . . . . . . 21
7.1.2 Data Set Schema Definition . . . . . . . . . . . . . . 22
7.1.3 Merging Different Sources of a Data Set . . . . . . . 23
7.2 Media Data Set . . . . . . . . . . . . . . . . . . . . . . 23
8. Example Profiles and Use . . . . . . . . . . . . . . . . . . . 24
8.1 Merge Two Data Sets . . . . . . . . . . . . . . . . . . . 24
8.2 Policy Filtering . . . . . . . . . . . . . . . . . . . . . 25
8.3 Override . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. Changes from draft-petrie-sipping-profile-datasets-00 . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
A. SIP UA Profile Schema . . . . . . . . . . . . . . . . . . . . 28
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . 32
Petrie, et al. Expires August 20, 2005 [Page 3]
Internet-Draft SIP UA Data Sets February 2005
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 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.
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, et al. Expires August 20, 2005 [Page 4]
Internet-Draft SIP UA Data Sets February 2005
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. ringtones used when someone
calls them, the user's shortcuts).
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 (e.g.
how to traverse NAT or firewall, bandwidth constraints).
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
Petrie, et al. Expires August 20, 2005 [Page 5]
Internet-Draft SIP UA Data Sets February 2005
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.
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 Use Cases
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.
Petrie, et al. Expires August 20, 2005 [Page 6]
Internet-Draft SIP UA Data Sets February 2005
3.1.1 Outbound Proxy Setting
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:
o 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.
o 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.
o 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.
3.1.2 Codec Settings
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
Petrie, et al. Expires August 20, 2005 [Page 7]
Internet-Draft SIP UA Data Sets February 2005
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.
3.1.2.1 Setting Not Set
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.
3.1.2.2 Set in Device Profile
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:
o To have a uniform set of codecs used across all device types
o 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.
3.1.2.3 Set in Device and User Profiles
In the following scenario users are allowed to express a preference
over codecs. Users are probably not likely to express specific codes
Petrie, et al. Expires August 20, 2005 [Page 8]
Internet-Draft SIP UA Data Sets February 2005
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:
o The ordering of the codecs will be determined from the user
profile data, which overrides the codec preference ordering from
the device profile data.
o 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.
3.1.2.4 Set in Device and Local Profiles
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:
o 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.
Petrie, et al. Expires August 20, 2005 [Page 9]
Internet-Draft SIP UA Data Sets February 2005
3.1.2.5 Set in Device, User and Local Profiles
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:
o The ordering of the codecs will be determined from the user
profile data, which overrides the ordering from the device profile
data.
o 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.
3.1.2.6 Derived Requirements
1. 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.
2. The device profile data will have a default ordered list of
codecs, which implies a preference order that may be offered.
3. 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.
4. 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.
5. The application profile data containing codec data will be
ignored.
Petrie, et al. Expires August 20, 2005 [Page 10]
Internet-Draft SIP UA Data Sets February 2005
6. The profiles need to express codecs that may be used and codecs
that should not be used.
3.1.3 Transport Protocol Setting
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.
3.1.3.1 Setting Not Set
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.
3.1.3.2 Set in Device Profile
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:
o To have a uniform use of signaling transports used across all
device types.
o To mandate TLS for security reasons.
o 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.
3.1.3.3 Set in Device and User Profiles
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:
o Mandate that secure transport must be used. If secure transport
is not possible the user does not want to use the user agent.
o Prefer secure transport. Attempt to use secure transport. If
secure transport will not work, use which ever transport protocol
will make communication work.
Petrie, et al. Expires August 20, 2005 [Page 11]
Internet-Draft SIP UA Data Sets February 2005
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:
o 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.
o The highest preferred signaling transport from the constrained
list will be used.
3.1.3.4 Set in Device and Local Profiles
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:
o 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.
3.1.3.5 Derived Requirements
1. A device will have a set of signaling transports that it supports
(note: one can be a set), with a default signaling transport.
2. 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).
3. The user profile data may provide a list of preferred signaling
transports to be used (e.g., TLS for securing the signaling).
4. The local network profile data provides a list of signaling
transports supported, and will constrain the set of signaling
transports that could be used.
Petrie, et al. Expires August 20, 2005 [Page 12]
Internet-Draft SIP UA Data Sets February 2005
3.2 Requirement Descriptions
3.2.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.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
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.2.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 the required
functionality. Guidelines for the Use of Extensible Markup Language
(XML) within IETF Protocols [RFC3470] provides useful information in
this regard.
Petrie, et al. Expires August 20, 2005 [Page 13]
Internet-Draft SIP UA Data Sets February 2005
3.2.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, 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.
3.2.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.2.6 Support of User, Application, Device, Local Network Sources
[I-D.ietf-sipping-config-framework] 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
Petrie, et al. Expires August 20, 2005 [Page 14]
Internet-Draft SIP UA Data Sets February 2005
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.]
3.2.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
Petrie, et al. Expires August 20, 2005 [Page 15]
Internet-Draft SIP UA Data Sets February 2005
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 "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).
o A "policy" attribute to the "setting" element that specifies
constraints for how settings are to be combined or overrided to
form a working profile.
o A "visablity" attribute to the "setting" element that specifies
access control to the settings values in the profiles.
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
The attribute "visibility" is defined on the "setting" element to
Petrie, et al. Expires August 20, 2005 [Page 16]
Internet-Draft SIP UA Data Sets February 2005
specify whether or not the user agent is permitted to display the
property value to the user. It has two possible values:
visible Specifies that display of the property value is not
restricted. This is the default value of the attribute if it is
not specified.
hidden 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.
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).
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
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 setting Element
The setting element is the abstract element from which all profile
properties or settings shall inherit.
4.3.3 policy Attribute
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.
Petrie, et al. Expires August 20, 2005 [Page 17]
Internet-Draft SIP UA Data Sets February 2005
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 Section
5.3 ).
4.3.4 visablity Attribute
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
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
Petrie, et al. Expires August 20, 2005 [Page 18]
Internet-Draft SIP UA Data Sets February 2005
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. [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?]
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
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 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
Petrie, et al. Expires August 20, 2005 [Page 19]
Internet-Draft SIP UA Data Sets February 2005
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".
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
6.7 Address Book
6.8 Buddy List
Petrie, et al. Expires August 20, 2005 [Page 20]
Internet-Draft SIP UA Data Sets February 2005
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. The order
of the list of transport_protocol setting values indicates the
order of preference.
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, et al. Expires August 20, 2005 [Page 21]
Internet-Draft SIP UA Data Sets February 2005
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, et al. Expires August 20, 2005 [Page 22]
Internet-Draft SIP UA Data Sets February 2005
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 SIP Protocol Data Set uses the default merging policy defined in
Section 5.3
7.2 Media Data Set
The following is example data that should be defined in the media
data set:
Petrie, et al. Expires August 20, 2005 [Page 23]
Internet-Draft SIP UA Data Sets February 2005
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 Profiles and Use
8.1 Merge Two Data Sets
Consider the use case described in Section 3.1.3.3 where the user
wishes to indicate that only secure SIP transport should be used.
The device profile may contain SIP Protocol Data Set (see Section
7.1) settings that look like the following:
UDP
5060
TCP
5060
TLS
5061
sip:outproxy.example.com
The user profile which indicates that only TLS should be used would
look like (Note: this example also indicates that port 5061 should be
Petrie, et al. Expires August 20, 2005 [Page 24]
Internet-Draft SIP UA Data Sets February 2005
used with a mandatory policy as well. This may be more constrained
than the user really wants.):
TLS
5061
UDP
TCP
The merged result of the device and user profile would look like:
TLS
5061
UDP
TCP
sip:outproxy.example.com
(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
Petrie, et al. Expires August 20, 2005 [Page 25]
Internet-Draft SIP UA Data Sets February 2005
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).
10. Changes from draft-petrie-sipping-profile-datasets-00
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.
11 References
[I-D.ietf-sipping-config-framework]
Petrie, D., "A Framework for Session Initiation Protocol
User Agent Profile Delivery",
draft-ietf-sipping-config-framework-05 (work in progress),
November 2004.
[I-D.sinnreich-sipdev-req]
Butcher, I., Lass, S., Petrie, D., Sinnreich, H. and C.
Stredicke, "SIP Telephony Device Requirements and
Petrie, et al. Expires August 20, 2005 [Page 26]
Internet-Draft SIP UA Data Sets February 2005
Configuration", draft-sinnreich-sipdev-req-05 (work in
progress), January 2005.
[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.
[RFC3470] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for
the Use of Extensible Markup Language (XML) within IETF
Protocols", BCP 70, RFC 3470, January 2003.
[W3C.REC-xml-names]
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 AT pingtel DOT com
URI: http://www.pingtel.com/
Petrie, et al. Expires August 20, 2005 [Page 27]
Internet-Draft SIP UA Data Sets February 2005
Scott Lawrence
Pingtel Corp.
400 W. Cummings Park
Suite 2200
Woburn, MA 01801
US
Phone: "Scott Lawrence (+1 781 938 5306)"
EMail: slawrence AT pingtel DOT com
URI: http://skrb.org/scott/
Martin Dolly
AT&T Labs
US
Phone:
EMail: mdolly AT att DOT com
URI:
Appendix A. SIP UA Profile Schema
]>
Proposed XML metalanguage for the description of
SIP User Agent Profile Data Sets.
The property_set element is the root element returned in
response to a request for a profile data set.
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.
Petrie, et al. Expires August 20, 2005 [Page 29]
Internet-Draft SIP UA Data Sets February 2005
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.
The visibility attribute indicates whether the user agent
should show the setting value(s) to the user.
Petrie, et al. Expires August 20, 2005 [Page 30]
Internet-Draft SIP UA Data Sets February 2005
Appendix B. Acknowledgments
Petrie, et al. Expires August 20, 2005 [Page 31]
Internet-Draft SIP UA Data Sets February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
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.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Petrie, et al. Expires August 20, 2005 [Page 32]
Internet-Draft SIP UA Data Sets February 2005
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Petrie, et al. Expires August 20, 2005 [Page 33]