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 "<foo/>")
means that that setting MUST NOT be set to any value.
A non-empty setting within the forbid element (for example
"<foo>bar</foo>") 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
<property_set>
<forbid>
<transport_protocol>
<name>UDP</name>
<port>5060</port>
</transport_protocol>
</forbid>
<set_any>
<transport_protocol>
<name>TCP</name>
<port>5060</port>
</transport_protocol>
<transport_protocol>
<name>TLS</name>
<port>5061</port>
</transport_protocol>
</set_any>
<set_all>
<outbound_proxy>sip:outproxy.example.com</outbound_proxy>
</set_all>
</property_set>
7.1.2 Data Set Schema Definition
The following is the schema for the SIP protocol data set.
<?xml version='1.0' encoding='iso-8859-1' standalone='yes'?>
<!--
XML Schema for SIP Protocol core Data Sets
-->
<schema
xmlns:spds='http://sipfoundry.org/schema/profile-data-sets-00'
targetNamespace='http://sipfoundry.org/schema/profile-data-sets-00'
xmlns='http://www.w3.org/2001/XMLSchema'
>
<annotation>
<documentation>
SIP Protocol Properties.
</documentation>
</annotation>
<element name="transport_protocol" group="spds::setting">
<annotation>
<documentation>
Container for the properties for a single transport protocol
binding for SIP.
</documentation>
Petrie & Lawrence Expires January 7, 2005 [Page 15]
Internet-Draft SIP UA Data Sets July 2004
</annotation>
<complexType>
<sequence>
<element ref="spds:name" />
<element ref="spds:port" />
</sequence>
</complexType>
</element>
<element name="name" group="spds::setting">
<annotation>
<documentation>
Name of the specific transport protocol
</documentation>
</annotation>
<simpleType type="spds:transport"/>
</element>
<element name="port" group="spds::setting">
<annotation>
<documentation>
Port binding for the transport protocol
</documentation>
</annotation>
<simpleType type="spds:port_num"/>
</element>
<element name="outbound_proxy" group="spds::setting">
<annotation>
<documentation>
The next hop proxy for SIP requests without a defined
route set. Value is of name-addr format. There should
probably be a type defined for name-addr that outbound_proxy
inherits from.
</documentation>
</annotation>
<simpleType />
</element>
</schema>
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,
<http://www.w3.org/TR/REC-xml-names>.
[W3C.REC-xmlschema-1]
Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn,
"XML Schema Part 1: Structures", W3C REC-xmlschema-1, May
2001, <http://www.w3.org/TR/xmlschema-1/>.
[W3C.REC-xmlschema-2]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
W3C REC-xmlschema-2, May 2001,
<http://www.w3.org/TR/xmlschema-2/>.
Authors' Addresses
Daniel Petrie
Pingtel Corp.
400 W. Cummings Park
Suite 2200
Woburn, MA 01801
US
Phone: "Dan Petrie (+1 781 938 5306)" <sip:dpetrie@pingtel.com>
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)" <sip:slawrence@pingtel.com>
EMail: slawrence@pingtel.com
URI: http://skrb.org/scott/
Appendix A. SIP UA Profile Schema
<?xml version='1.0' encoding='iso-8859-1' standalone='yes'?>
<!DOCTYPE schema [
<!ENTITY % doc_src
"http://scm.sipfoundry.org/rep/ietf-draft/petrie/profile-data-sets">
]>
<!--
Petrie & Lawrence Expires January 7, 2005 [Page 19]
Internet-Draft SIP UA Data Sets July 2004
XML Schema for SIP Profile Data Sets
-->
<schema
xmlns:spds='http://sipfoundry.org/schema/profile-data-sets-00'
targetNamespace='http://sipfoundry.org/schema/profile-data-sets-00'
xmlns='http://www.w3.org/2001/XMLSchema'
>
<annotation>
<documentation>
Proposed XML metalanguage for the description of
SIP User Agent Profile Data Sets.
</documentation>
<documentation source='%doc_src;'/>
</annotation>
<!-- Types
Later versions of the Internet-Draft of which this is a part may
include additional data type definitions and entities useful
in defining SIP data.
-->
<simpleType name="port_num">
<restriction base="integer">
<minExclusive>0</minExclusive>
<maxInclusive>65535</maxInclusive>
</restriction>
</simpleType>
<simpleType name="transport_protocol">
<restriction base="string">
<enumeration value="TCP"/>
<enumeration value="UDP"/>
<enumeration value="TLS"/>
</restriction>
</simpleType>
<!-- Elements
Later versions of the Internet-Draft of which this is a part may
include additional data type definitions and entities useful
in defining SIP data.
-->
<element name="property_set">
<annotation>
<documentation>
The property_set element is the root element returned in
response to a request for a profile data set.
</documentation>
Petrie & Lawrence Expires January 7, 2005 [Page 20]
Internet-Draft SIP UA Data Sets July 2004
</annotation>
<complexType>
<sequence>
<element ref="spds:forbid" minOccurs="0" maxOccurs="1"/>
<sequence minOccurs="0" maxOccurs="unbounded">
<choice>
<element ref="spds:set_any" />
<element ref="spds:set_all" />
</choice>
</sequence>
</sequence>
</complexType>
</element>
<element name="setting" type="anyType" abstract="true">
<annotation>
<documentation>
The 'setting' element is an abstract used as the basis for the
definition of the setting elements in property schemas derived
from this one.
It serves here as a placeholder in constructing the content
models for the container elements used to group settings into
sets.
</documentation>
<documentation source='%doc_src;'/>
</annotation>
</element>
<element name="forbid">
<complexType>
<sequence minOccurs="1" maxOccurs="unbounded">
<element ref="spds:setting"/>
</sequence>
</complexType>
</element>
<element name='set_any'>
<annotation>
<documentation>
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.
</documentation>
</annotation>
<complexType>
<sequence minOccurs="1" maxOccurs="unbounded">
<choice>
Petrie & Lawrence Expires January 7, 2005 [Page 21]
Internet-Draft SIP UA Data Sets July 2004
<element ref="spds:setting" />
<element ref="spds:set_all" />
<element ref="spds:set_one" />
</choice>
</sequence>
</complexType>
</element>
<element name='set_all'>
<annotation>
<documentation>
Contains some number of settings; the user agent MUST
include all of the contained settings.
</documentation>
</annotation>
<complexType>
<sequence minOccurs="1" maxOccurs="unbounded">
<choice>
<element ref="spds:setting" />
<element ref="spds:set_any" />
<element ref="spds:set_one" />
</choice>
</sequence>
</complexType>
</element>
<element name='set_one'>
<annotation>
<documentation>
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,
</documentation>
</annotation>
<complexType>
<sequence minOccurs="1" maxOccurs="unbounded">
<choice>
<element ref="spds:setting" />
<element ref="spds:set_any" />
<element ref="spds:set_all" />
</choice>
</sequence>
</complexType>
</element>
</schema>
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]