One document matched: draft-petrie-sipping-profile-datasets-04.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Datasets</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Datasets">
<meta name="keywords" content="SIP, Configuration, Framework, User Agent, profile, XML, schema, ua-profile, uaprof, urn:ietf:params:xml:ns:uaprof">
<meta name="generator" content="xml2rfc v1.30 (http://xml.resource.org/)">
<style type='text/css'>
<!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
margin: 2em;
font-size: small ; color: #000000 ; background-color: #ffffff ; }
.title { color: #990000; font-size: x-large ;
font-weight: bold; text-align: right;
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
background-color: transparent; }
.filename { color: #666666; font-size: 18px; line-height: 28px;
font-weight: bold; text-align: right;
font-family: helvetica, arial, sans-serif;
background-color: transparent; }
td.rfcbug { background-color: #000000 ; width: 30px ; height: 30px ;
text-align: justify; vertical-align: middle ; padding-top: 2px ; }
td.rfcbug span.RFC { color: #666666; font-weight: bold; text-decoration: none;
background-color: #000000 ;
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-size: x-small ; }
td.rfcbug span.hotText { color: #ffffff; font-weight: normal; text-decoration: none;
text-align: center ;
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-size: x-small ; background-color: #000000; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
div#counter{margin-top: 100px}
a.info{
position:relative; /*this is the key*/
z-index:24;
text-decoration:none}
a.info:hover{z-index:25; background-color:#990000 ; color: #ffffff ;}
a.info span{display: none}
a.info:hover span.info{ /*the span will display just on :hover state*/
display:block;
position:absolute;
font-size: smaller ;
top:2em; left:2em; width:15em;
padding: 2px ;
border:1px solid #333333;
background-color:#eeeeee; color:#990000;
text-align: left ;}
A { font-weight: bold; }
A:link { color: #990000; background-color: transparent ; }
A:visited { color: #333333; background-color: transparent ; }
A:active { color: #333333; background-color: transparent ; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small ; }
p.toc { font-size: small ; font-weight: bold ; margin-left: 3em ;}
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
span.emph { font-style: italic; }
span.strong { font-weight: bold; }
span.verb, span.vbare { font-family: "Courier New", Courier, monospace ; }
span.vemph { font-style: italic; font-family: "Courier New", Courier, monospace ; }
span.vstrong { font-weight: bold; font-family: "Courier New", Courier, monospace ; }
span.vdeluxe { font-weight: bold; font-style: italic; font-family: "Courier New", Courier, monospace ; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
pre { margin-left: 3em; color: #333333; background-color: transparent;
font-family: "Courier New", Courier, monospace ; font-size: small ;
text-align: left;
}
h3 { color: #333333; font-size: medium ;
font-family: helvetica, arial, sans-serif ;
background-color: transparent; }
h4 { font-size: small; font-family: helvetica, arial, sans-serif ; }
table.bug { width: 30px ; height: 15px ; }
td.bug { color: #ffffff ; background-color: #990000 ;
text-align: center ; width: 30px ; height: 15px ;
}
td.bug A.link2 { color: #ffffff ; font-weight: bold;
text-decoration: none;
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-size: x-small ; background-color: transparent }
td.header { color: #ffffff; font-size: x-small ;
font-family: arial, helvetica, sans-serif; vertical-align: top;
background-color: #666666 ; width: 33% ; }
td.author { font-weight: bold; margin-left: 4em; font-size: x-small ; }
td.author-text { font-size: x-small; }
table.full { vertical-align: top ; border-collapse: collapse ;
border-style: solid solid solid solid ;
border-color: black black black black ;
font-size: small ; text-align: center ; }
table.headers, table.none { vertical-align: top ; border-collapse: collapse ;
border-style: none;
font-size: small ; text-align: center ; }
table.full th { font-weight: bold ;
border-style: solid ;
border-color: black black black black ; }
table.headers th { font-weight: bold ;
border-style: none none solid none;
border-color: black black black black ; }
table.none th { font-weight: bold ;
border-style: none; }
table.full td {
border-style: solid solid solid solid ;
border-color: #333333 #333333 #333333 #333333 ; }
table.headers td, table.none td { border-style: none; }
hr { height: 1px }
-->
</style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">SIPPING</td><td class="header">D. Petrie</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">SIPez LLC.</td></tr>
<tr><td class="header">Expires: April 26, 2007</td><td class="header">S. Lawrence</td></tr>
<tr><td class="header"> </td><td class="header">Pingtel Corp.</td></tr>
<tr><td class="header"> </td><td class="header">M. Dolly</td></tr>
<tr><td class="header"> </td><td class="header">AT&T Labs</td></tr>
<tr><td class="header"> </td><td class="header">V.H. Hilt</td></tr>
<tr><td class="header"> </td><td class="header">Bell Labs/Lucent Technologies</td></tr>
<tr><td class="header"> </td><td class="header">October 23, 2006</td></tr>
</table></td></tr></table>
<div align="right"><span class="title"><br />A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Datasets</span></div>
<div align="right"><span class="title"><br />draft-petrie-sipping-profile-datasets-04.txt</span></div>
<h3>Status of this Memo</h3>
<p>
By submitting this Internet-Draft,
each author represents that any applicable patent or other IPR claims of which
he or she is aware have been or will be disclosed,
and any of which he or she becomes aware will be disclosed,
in accordance with Section 6 of BCP 79.</p>
<p>
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.</p>
<p>
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.”</p>
<p>
The list of current Internet-Drafts can be accessed at
<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
<p>
The list of Internet-Draft Shadow Directories can be accessed at
<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
<p>
This Internet-Draft will expire on April 26, 2007.</p>
<h3>Copyright Notice</h3>
<p>
Copyright © The Internet Society (2006).</p>
<h3>Abstract</h3>
<p>
This document defines the requirements and a format for SIP user agent profile data. An overall
schema is specified for the definition of profile datasets. 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
datasets to be included in profile data. It also explores some
specific datasets to test the requirements, assumptions and syntax.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#motivation">1.</a>
Motivation<br />
<a href="#introduction">2.</a>
Introduction<br />
<a href="#terminology">2.1.</a>
Requirements Terminology<br />
<a href="#profileterminology">2.2.</a>
Profile Data Terminology<br />
<a href="#overview">2.3.</a>
Overview<br />
<a href="#requirements">3.</a>
Design Considerations<br />
<a href="#requirement-usecases">3.1.</a>
Use Cases<br />
<a href="#outbound-proxy-usecase">3.1.1.</a>
Outbound Proxy Setting<br />
<a href="#codec-usecase">3.1.2.</a>
Codec Settings<br />
<a href="#transport-protocol-usecase">3.1.3.</a>
Transport Protocol Setting<br />
<a href="#requirement-descriptions">3.2.</a>
Requirement Descriptions<br />
<a href="#extensibility-requirement">3.2.1.</a>
Implementer Extensibility<br />
<a href="#flexible-capabilities-requirement">3.2.2.</a>
Flexible Capabilities<br />
<a href="#xml-requirement">3.2.3.</a>
XML<br />
<a href="#access-control-requirement">3.2.4.</a>
Access Control<br />
<a href="#constraints-requirement">3.2.5.</a>
Data Constraints and Range Definition<br />
<a href="#multiple-sources-requirement">3.2.6.</a>
Support of User, Application, Device, Local Network Sources<br />
<a href="#policy-requirement">3.2.7.</a>
The Ability to Specify Policy<br />
<a href="#schema-definition">4.</a>
Overall Dataset Schema<br />
<a href="#schema-data-primitives">4.1.</a>
Data Primitives<br />
<a href="#schema-namespaces">4.2.</a>
Use of Namespaces<br />
<a href="#propertySet">4.3.</a>
The 'propertySet' Element<br />
<a href="#settingcontainer">4.4.</a>
The Abstract 'setting_container' Element<br />
<a href="#settingelement">4.5.</a>
The Abstract 'setting' Element<br />
<a href="#schema-acl">4.5.1.</a>
The 'visibility' Attribute<br />
<a href="#sec:policy">4.5.2.</a>
The 'policy' Attributes<br />
<a href="#sec:ex-policy">4.5.3.</a>
The 'excludedPolicy' Attributes<br />
<a href="#sec:unidir">4.5.4.</a>
The 'direction' Attribute<br />
<a href="#sec:pref">4.5.5.</a>
The 'q' Attribute<br />
<a href="#anchor1">4.6.</a>
The 'profileUri' Element<br />
<a href="#anchor2">4.7.</a>
The 'profileCredential' Element<br />
<a href="#realm-element">4.7.1.</a>
realm Element<br />
<a href="#auth-user-element">4.7.2.</a>
authUser Element<br />
<a href="#a1Digest">4.7.3.</a>
a1Digest Element<br />
<a href="#password">4.7.4.</a>
password Element<br />
<a href="#anchor3">4.8.</a>
The 'profileContactUri' Element<br />
<a href="#anchor4">4.9.</a>
The 'profileInfo' Element<br />
<a href="#anchor5">4.10.</a>
Example Profile Dataset<br />
<a href="#schema-merging">4.11.</a>
Merging Property Sets<br />
<a href="#numeric-merging_algorithm">4.11.1.</a>
Single Numeric Value Merging Algorithm<br />
<a href="#multivalue-merging_algorithm">4.11.2.</a>
Multiple Enumerated Value Merging Algorithm<br />
<a href="#singlelocal-merging_algorithm">4.11.3.</a>
Closest Value First Merging Algorithm<br />
<a href="#common_types">4.12.</a>
Common Types<br />
<a href="#defining-datasets">5.</a>
Defining Data Sets<br />
<a href="#defining-datasets-schema">5.1.</a>
Namespace<br />
<a href="#defining-datasets-properties">5.2.</a>
Property Definitions<br />
<a href="#defining-datasets-merging">5.3.</a>
Merging Data Sets<br />
<a href="#candidiate-datasets">6.</a>
Candidate Data Sets<br />
<a href="#security-considerations">7.</a>
Security Considerations<br />
<a href="#iana-considerations">8.</a>
IANA Considerations<br />
<a href="#anchor6">8.1.</a>
Content-type registration for 'application/uaprofile+xml'<br />
<a href="#changes">9.</a>
Change History<br />
<a href="#anchor7">9.1.</a>
Changes from draft-petrie-sipping-profile-datasets-03<br />
<a href="#anchor8">9.2.</a>
Changes from draft-petrie-sipping-profile-datasets-02<br />
<a href="#changes01">9.3.</a>
Changes from draft-petrie-sipping-profile-datasets-01<br />
<a href="#changes00">9.4.</a>
Changes from draft-petrie-sipping-profile-datasets-00<br />
<a href="#rfc.references1">10.</a>
References<br />
<a href="#rfc.references1">10.1.</a>
Normative References<br />
<a href="#rfc.references2">10.2.</a>
Informative References<br />
<a href="#sip-ua-profile-schema">Appendix A.</a>
Relax NG SIP UA Profile Schema<br />
<a href="#acknowledgments">Appendix B.</a>
Acknowledgments<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
<a href="#rfc.copyright">§</a>
Intellectual Property and Copyright Statements<br />
</p>
<br clear="all" />
<a name="motivation"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1. Motivation</h3>
<p>
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 <a class="info" href="#I-D.ietf-sipping-config-framework">[I-D.ietf-sipping-config-framework]<span> (</span><span class="info">Petrie, D., “A Framework for Session Initiation Protocol User Agent Profile Delivery,” October 2006.</span><span>)</span></a> and the Framework for
Session SIP Session Policies <a class="info" href="#I-D.hilt-sipping-session-policy-framework">[I-D.hilt-sipping-session-policy-framework]<span> (</span><span class="info">Hilt, V., “A Framework for Session Initiation Protocol (SIP) Session Policies,” March 2006.</span><span>)</span></a> specify 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.
</p>
<p>
While these frameworks define the mechanisms for transmitting profile
data, they do not define a format for the actual
profile data. This document defines the requirements, the default/manditory
to support content type for <a class="info" href="#I-D.ietf-sipping-config-framework">[I-D.ietf-sipping-config-framework]<span> (</span><span class="info">Petrie, D., “A Framework for Session Initiation Protocol User Agent Profile Delivery,” October 2006.</span><span>)</span></a>,
a high level schema for, and guide to how these datasets 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.
</p>
<p>
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.
</p>
<a name="introduction"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2. Introduction</h3>
<p>
</p>
<a name="terminology"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.2.1"></a><h3>2.1. Requirements Terminology</h3>
<p>
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
"MAY" that appear in this document are to be interpreted as described in RFC 2119<a class="info" href="#RFC2119">[RFC2119]<span> (</span><span class="info">Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a>.
</p>
<a name="profileterminology"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.2.2"></a><h3>2.2. Profile Data Terminology</h3>
<p>
</p>
<blockquote class="text"><dl>
<dt>property -</dt>
<dd>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 a range of values, allow for
simultaneous use of many values (as in a
list of allowed possibilities), or a set
of related values that collectively form a
single profile information item.
</dd>
<dt>setting -</dt>
<dd>the binding of a
specific value or set of values to a given
property.
</dd>
<dt>profile -</dt>
<dd>a collection of
settings to be applied for a specific user,
device, or local network.
</dd>
<dt>device -</dt>
<dd>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.
</dd>
<dt>user profile -</dt>
<dd>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).
</dd>
<dt>device profile -</dt>
<dd>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.
</dd>
<dt>local network profile -</dt>
<dd> 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).
</dd>
<dt>dataset -</dt>
<dd>a collection of properties.
</dd>
<dt>working profile -</dt>
<dd>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 .
</dd>
<dt>merging -</dt>
<dd>the operation of resolving
overlapping settings from multiple profiles. Overlap
occurs when the same property occurs in multiple
profiles (e.g. device, user, application, local
network).
</dd>
</dl></blockquote><p>
</p>
<a name="overview"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.2.3"></a><h3>2.3. Overview</h3>
<p>
In this document requirements are specified for containing and expressing
profile data for use on SIP user agents. Though much of this can be
considered independent of SIP there is one primary requirement that
is not well satisfied through more generic profile data mechanisms.
SIP User Agent set up requires the agent to merge settings, which may overlap, from
potentially four different sources
(see <a class="info" href="#I-D.ietf-sipping-config-framework">[I-D.ietf-sipping-config-framework]<span> (</span><span class="info">Petrie, D., “A Framework for Session Initiation Protocol User Agent Profile Delivery,” October 2006.</span><span>)</span></a>);
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.
</p>
<p>
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 datasets 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
(see <a class="info" href="#I-D.ietf-sipping-media-policy-dataset">[I-D.ietf-sipping-media-policy-dataset]<span> (</span><span class="info">Hilt, V., “A User Agent Profile Data Set for Media Policy,” April 2006.</span><span>)</span></a> and
[reference: Core SIP Dataset]). However, some examples are explored here to
illustrate the proposed mechanisms and to validate the requirements.
</p>
<p>
This document defines a set of considerations, syntax and policies
that must be specified when defining datasets. These are to help
authors of dataset specifications to define datasets that will
work in the overall schema defined in this document. The actual
specification of these datasets is outside the scope of this document.
</p>
<a name="requirements"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3. Design Considerations</h3>
<p>
The following section defines some of the design considerations that
were taken into account when defining the schema, syntax and policies
for generating and applying profile data. <a class="info" href="#multiple-sources-requirement">Section 3.2.6<span> (</span><span class="info">Support of User, Application, Device, Local Network Sources</span><span>)</span></a> describes need for merging of the four dataset sources
provided in <a class="info" href="#I-D.ietf-sipping-config-framework">[I-D.ietf-sipping-config-framework]<span> (</span><span class="info">Petrie, D., “A Framework for Session Initiation Protocol User Agent Profile Delivery,” October 2006.</span><span>)</span></a>.
</p>
<a name="requirement-usecases"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1. Use Cases</h3>
<p>
In the following use case scenarios the device profile is provided by
the device 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. In 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 <a class="info" href="#I-D.hilt-sipping-session-policy-framework">[I-D.hilt-sipping-session-policy-framework]<span> (</span><span class="info">Hilt, V., “A Framework for Session Initiation Protocol (SIP) Session Policies,” March 2006.</span><span>)</span></a>. 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.
</p>
<a name="outbound-proxy-usecase"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.1"></a><h3>3.1.1. Outbound Proxy Setting</h3>
<p>
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 owner/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.
</p>
<p>
It seems there are few possible solutions to this conflict resolution problem:
</p>
<ul class="text">
<li>
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.
</li>
<li>
A comprehensive solution 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.
</li>
</ul><p>
</p>
<p>
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.
</p>
<a name="codec-usecase"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.2"></a><h3>3.1.2. Codec Settings</h3>
<p>
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 rationalized 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 of the codec properties, it is assumed that codec properties will need to express a codec definition and a preference order. This is the order that these codecs will be put in SDP for codec negotiation purposes.
</p>
<p>
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.
</p>
<a name="codec-notset-usecase"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.2.1"></a><h3>3.1.2.1. Codec Setting Not Set</h3>
<p>
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 implementations it is s subset of the codecs supported by the device.
</p>
<a name="codec-deviceonly-usecase"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.2.2"></a><h3>3.1.2.2. Codec Set in Device Profile</h3>
<p>
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 are 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.
</p>
<p>
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:
</p>
<ul class="text">
<li>
To have a uniform set of codecs used across all device types
</li>
<li>
To exclude the use of a specific codec due to performance issues/concerns
</li>
</ul><p>
</p>
<p>
The resulting device profile data further will constrain 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. The use agent will ignore codec types included in
the profile that the user agent does not support.
</p>
<a name="codec-deviceuser-usecase"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.2.3"></a><h3>3.1.2.3. Set in Device and User Profiles</h3>
<p>
In the following scenario users are allowed to express a preference over codecs. Users are probably not likely to express specific codes in the form of G.7XX, etc. They are likely to want to express a preference in the form of wideband, normal and low bandwidth. In the following use case, device and user profiles contain codec properties.
</p>
<p>
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.
</p>
<p>
The merging of the data sources is as follows:
</p>
<ul class="text">
<li>
The ordering of the codecs will be determined from the user profile data, which overrides the codec preference ordering from the device profile data.
</li>
<li>
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.
</li>
</ul><p>
</p>
<p>
The case in which none of the codecs in the resulting merged
profile datasets are supported by the device, the profile data constitutes a
misconfiguration between device and user profiles. It may not be possible to
successfully establish a session in this case. It is suggested that the
user agent provide feedback to the user indicating the misconfiguration. The
user agent may also attempt to function in the network by ignoring one or more
of the profile constraints.
</p>
<a name="codec-devicelocal-usecase"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.2.4"></a><h3>3.1.2.4. Set in Device and Local Profiles</h3>
<p>
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 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 the type of codecs that can be applied due to resources available.
</p>
<p>
The merging of the data sources is as follows:
</p>
<ul class="text">
<li>
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.
</li>
</ul><p>
</p>
<p>
The case in which none of the codecs in the resulting merged
profile datasets are supported by the device, the profile data constitutes a
misconfiguration between local network and device. It may not be possible to
successfully establish a session in this case. It is suggested that the
user agent provide feedback to the user indicating the misconfiguration. The
user agent may also attempt to function in the network by ignoring one or more
of the profile constraints.
</p>
<a name="codec-deviceuserlocal-usecase"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.2.5"></a><h3>3.1.2.5. Set in Device, User and Local Profiles</h3>
<p>
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.
</p>
<p>
The merging of the data sources is as follows:
</p>
<ul class="text">
<li>
The ordering of the codecs will be determined from the user profile data, which overrides the ordering from the device profile data.
</li>
<li>
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.
</li>
</ul><p>
</p>
<p>
The case in which none of the codecs in the resulting merged
profile datasets are supported by the device, the profile data constitutes a
misconfiguration between device, user and local network profiles. It may not be
possible to
successfully establish a session in this case. It is suggested that the
user agent provide feedback to the user indicating the misconfiguration. The
user agent may also attempt to function in the network by ignoring one or more
of the profile constraints.
</p>
<a name="codec-usecase-reqs"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.2.6"></a><h3>3.1.2.6. Derived Requirements</h3>
<p>
</p>
<ol class="text">
<li>
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.
</li>
<li>
The device profile data will have a default ordered list of codecs, which implies a preference order that may be offered.
</li>
<li>
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.
</li>
<li>
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.
</li>
<li>
The application profile data containing codec data will be ignored.
</li>
<li>
The profiles need the ability to express codecs that may be used and codecs that should not be used.
</li>
</ol><p>
</p>
<a name="transport-protocol-usecase"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.3"></a><h3>3.1.3. Transport Protocol Setting</h3>
<p>
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 as well as the default order in which to attempt each of
the protocol.
</p>
<a name="protocol-notset-usecase"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.3.1"></a><h3>3.1.3.1. Setting Not Set</h3>
<p>
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.
</p>
<a name="protocol-deviceonly-usecase"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.3.2"></a><h3>3.1.3.2. Set in Device Profile</h3>
<p>
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:
</p>
<ul class="text">
<li>
To have a uniform use of signaling transports used across all device types.
</li>
<li>
To mandate TLS for security reasons.
</li>
<li>
To exclude the use of a specific signaling transport due to performance issues/concerns.
</li>
<li>
To indicate the preferred, default order in which to attempt using each of the
transport protocols.
</li>
</ul><p>
</p>
<p>
This will result in the device profile data further constraining the list of signaling transports that could be used.
The highest preference ordered signaling transport from the device profile dataset will be used first.
</p>
<a name="protocol-deviceuser-usecase"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.3.3"></a><h3>3.1.3.3. Set in Device and User Profiles</h3>
<p>
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:
</p>
<ul class="text">
<li>
Mandate that secure transport must be used. If secure transport is not possible the user does not want to use the user agent.
</li>
<li>
Prefer secure transport. Attempt to use secure transport. If secure transport will not work, use which ever transport protocol will make communication work.
</li>
</ul><p>
</p>
<p>
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.
</p>
<p>
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:
</p>
<ul class="text">
<li>
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.
</li>
<li>
The signaling transports attempted will be those from the merged, constrained list in order of highest to lowest priority.
</li>
</ul><p>
</p>
<a name="protocol-devicelocal-usecase"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.3.4"></a><h3>3.1.3.4. Set in Device and Local Profiles</h3>
<p>
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.
</p>
<p>
The merging of the data sources is as follows:
</p>
<ul class="text">
<li>
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.
</li>
</ul><p>
</p>
<p>
The case in which none of the local network data signaling transports are
supported by the device profile data constitutes a misconfiguration between
local network and device. The device might not be able to successfully
establish a session in this case.
</p>
<a name="protocol-usecase-reqs"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.3.5"></a><h3>3.1.3.5. Derived Requirements</h3>
<p>
</p>
<ol class="text">
<li>
A device will have a set of signaling transports that it supports (note: one can be a set), with a default signaling transport.
</li>
<li>
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 of the signaling transport(s).
</li>
<li>
The user profile data may provide a list of preferred signaling transports to be used (e.g., TLS for securing the signaling).
</li>
<li>
The local network profile data provides a list of signaling transports supported, and will constrain the set of signaling transports that could be used.
</li>
</ol><p>
</p>
<a name="requirement-descriptions"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.2"></a><h3>3.2. Requirement Descriptions</h3>
<a name="extensibility-requirement"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.1"></a><h3>3.2.1. Implementer Extensibility</h3>
<p>
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 datasets to include additional related
features and flexibility. It MUST be possible to extend a dataset
without breaking user agents that support that dataset. This may
require
that user agents ignore parts of a dataset that it does not implement
or extensions that it does support.
</p>
<a name="flexible-capabilities-requirement"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.2"></a><h3>3.2.2. Flexible Capabilities</h3>
<p>
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 datasets 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
capabilities of the device. The degree to which the profile delivery
server has intelligence of the user agent capabilities is an
implementation choice.
</p>
<a name="xml-requirement"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.3"></a><h3>3.2.3. XML</h3>
<p>
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. It is not
a requirement that user agents validate the profile XML document.
This relieves the requirement that the Relax NG schema defined in this
and other datasets documents be enforced on the user agent. The
Relax NG schema should not be used to strictly validate profile XML
documents. Unknown elements and attributes should be ignored to
allow extensions to be supported. Strict enforcement of the Relax NG
schema would make it very difficult to deploy new user agents
without lock step upgrades of the profile delivery server.
Guidelines for the Use of Extensible Markup Language
(XML) within IETF Protocols <a class="info" href="#RFC3470">[RFC3470]<span> (</span><span class="info">Hollenbeck, S., Rose, M., and L. Masinter, “Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols,” January 2003.</span><span>)</span></a> provides useful information in this
regard.
</p>
<a name="access-control-requirement"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.4"></a><h3>3.2.4. Access Control</h3>
<p>
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 dataset 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 dataset.
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.
</p>
<a name="constraints-requirement"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.5"></a><h3>3.2.5. Data Constraints and Range Definition</h3>
<p>
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 dataset. 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.
</p>
<a name="multiple-sources-requirement"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.6"></a><h3>3.2.6. Support of User, Application, Device, Local Network Sources</h3>
<p>
<a class="info" href="#I-D.ietf-sipping-config-framework">[I-D.ietf-sipping-config-framework]<span> (</span><span class="info">Petrie, D., “A Framework for Session Initiation Protocol User Agent Profile Delivery,” October 2006.</span><span>)</span></a> specifies a mechanism
where the user agent retrieves profile data from as many as four
different sources. The separation of the user profile facilitates
a hotelling capability and the ability to easily re-assign a user
to a different device. The separation of the local network profile
facilitates properties specific to operating in the local network
in a roaming scenario (e.g. outbound proxy or NAT traversal
properties). The local network profile may also impose policy
as describe in the next section. The device profile facilitates
device capability based properties as well as a means for the
device owner or manager (e.g. enterprise or service provider) to impose policy.
</p>
<p>
The multiple potential sources of profile data add some complexity
to the user agent that must consolidate these separate profiles into a
single working profile. It would be simpler 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
such as hotelling, roaming and shared profile management.
It would also be simpler if we could define one rule for all
profile datasets 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.
</p>
<p>
The rules to merge profile datasets needs to be defined for each
dataset. In some cases an entire dataset must be considered
atomic when merging one profile source with another.
In other cases it makes sense to merge profile
datasets, aggregating properties from the dataset provided in
each of the profiles. It may also be desirable to have the
effect of filtering of dataset 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 datasets from multiple profiles,
regardless of the means or net result, will be referred to
as "merging" in this document.
</p>
<p>
A profile must have the means to constrain the merging algorithm.
Due to the differences in the desired outcome for each data setting,
the merging algorithm is specific to the setting. When defining
a property setting, the merging algorithm must also be defined. A
few of the more commonly used merging algorithms are defined in this
document. Most settings are likely to use the common set defined
in this document. However authors of profile datasets may define
new algorithms for merging dataset properties
(see <a class="info" href="#schema-merging">Section 4.11<span> (</span><span class="info">Merging Property Sets</span><span>)</span></a> and <a class="info" href="#defining-datasets-merging">Section 5.3<span> (</span><span class="info">Merging Data Sets</span><span>)</span></a>).
</p>
<a name="policy-requirement"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.7"></a><h3>3.2.7. The Ability to Specify Policy</h3>
<p>
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 as 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 constraints to impose policy from the local network.
However the facility to impose policy may be equally useful to the user
and device profiles.
</p>
<p>
It MUST be possible to impose policy in any of the profile sources
that constrains, overwrites or modifies properties provided in
datasets from other sources.
</p>
<a name="schema-definition"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4. Overall Dataset Schema</h3>
<p>
Notifiers and Subscribers of the event package defined in
<a class="info" href="#I-D.ietf-sipping-config-framework">[I-D.ietf-sipping-config-framework]<span> (</span><span class="info">Petrie, D., “A Framework for Session Initiation Protocol User Agent Profile Delivery,” October 2006.</span><span>)</span></a> SHOULD support
the content-type: application/uaprofile+xml. The Notifier SHOULD
indicate all of the dataset schemas that is supports by listing all
of the MIME types for the supported datasets in the SUBSCRIBE request
header: Accept.
This document defines an Relax NG Schema for that content-type with the namespace:
urn:ietf:params:xml:ns:uaprof, for SIP Profile Datasets that provides:
</p>
<ul class="text">
<li>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).
</li>
<li>
Attributes to the "setting" element that define constraints and other
properties used to impose policy that apply to the element value. These attributes are
inherited by elements that are derived from the abstract settings
element.
</li>
<li>
A root element for all property sets (the outermost container).
</li>
</ul><p>
</p>
<p>
The full text of the schema is in <a class="info" href="#sip-ua-profile-schema">Appendix A<span> (</span><span class="info">Relax NG SIP UA Profile Schema</span><span>)</span></a>; the
following describes the usage of the schema in defining properties and
combining them to construct the working profile of a User Agent.
</p>
<a name="schema-data-primitives"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.1"></a><h3>4.1. Data Primitives</h3>
<p>
Each property in a profile data set is defined using
XML Schema Datatypes <a class="info" href="#W3C.REC-xmlschema-2">[W3C.REC-xmlschema-2]<span> (</span><span class="info">Biron, P. and A. Malhotra, “XML Schema Part 2: Datatypes,” May 2001.</span><span>)</span></a> and
Relax NG Schema.
A property is
modeled by an XML element derived from the "setting"
element in the SIP Profile Data Set Schema. The element content is
the setting value.
</p>
<p>Properties consisting of one single value can be expressed
using a single XML element. Properties that may consist of
multiple values require the use of container elements. A
container element is defined for such a property. This container
can contain multiple XML elements, which each defines a possible
value for that property (see examples in <a class="info" href="#sec:policy">Section 4.5.2<span> (</span><span class="info">The 'policy' Attributes</span><span>)</span></a>).
</p>
<p>
When constructing a property set, the creator of a profile may not be
able to know all of the capabilities of the User Agent that will receive
that property set. The creator of profile constraints or policies should be aware
that a user agent may ignore properties that are unsupported or do not apply to
its capabilities.
</p>
<a name="schema-namespaces"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.2"></a><h3>4.2. Use of Namespaces</h3>
<p>
XML namespaces <a class="info" href="#W3C.REC-xml-names-19990114">[W3C.REC-xml-names-19990114]<span> (</span><span class="info">Hollander, D., Bray, T., and A. Layman, “Namespaces in XML,” January 1999.</span><span>)</span></a>
provide a means to uniquely identify the elements and datatypes
defined in a data set. It is therefore RECOMMENDED that each
data set specifies its own namespace. The namespace URIs SHOULD
be <a class="info" href="#RFC2141">URNs<span> (</span><span class="info">Moats, R., “URN Syntax,” May 1997.</span><span>)</span></a> [RFC2141], using the namespace
identifier 'ietf' defined by <a class="info" href="#RFC2648">[RFC2648]<span> (</span><span class="info">Moats, R., “A URN Namespace for IETF Documents,” August 1999.</span><span>)</span></a> and
extended by <a class="info" href="#I-D.mealling-iana-xmlns-registry">[I-D.mealling-iana-xmlns-registry]<span> (</span><span class="info">Mealling, M., “The IETF XML Registry,” June 2003.</span><span>)</span></a>.
The core schema defined in this document defines the namespace:
"urn:ietf:params:xml:ns:uaprof".
Profile datasets that extend this schema SHOULD define a new namespace
by appending a ":" and a unique name to the "urn:ietf:params:xml:ns:uaprof"
namespace. These namespaces MUST be registered with IANA.
</p>
<a name="propertySet"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.3"></a><h3>4.3. The 'propertySet' Element</h3>
<p>
The root element of a property set is "propertySet"; it is
the container that is provided to the user agent. The elements
contained within a propertySet contain the specific properties
which are to be applied to the user agent. The properties may
be simple types with a single value, complex types or container
elements with a list of properties.
</p>
<a name="settingcontainer"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.4"></a><h3>4.4. The Abstract 'setting_container' Element</h3>
<p>
The "setting_container" element is the abstract element in which a list
of properties which allow mutliple values may be contained. Elements
derived from the "setting_container" element may contain zero or more
elements derived from the "setting" element. The "setting_container"
element has an "excludedPolicy" attribute.
</p>
<a name="settingelement"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.5"></a><h3>4.5. The Abstract 'setting' Element</h3>
<p>
The setting element is the abstract element from which all profile
properties or settings shall inherit.
</p>
<p>The setting element has a number of attributes
that provide functionalities, which are generally
useful for many properties. These attributes are
inherited by properties that are derived from the
settings element. This enables the re-use of common
functionalities and ensures a common syntax for these
elements across different data sets. The following
functionalities are provided by attributes of the
settings element:
</p>
<p></p>
<ul class="text">
<li>Property Access Control: 'visibility'
attribute
</li>
<li>Policies: 'policy' attribute
</li>
</ul>
<p>
Additional attributes are defined in the schema that may used in
elements derived from "setting". By default these attributes
cannot be set. These attribute must be explicitly added to
elements derived from the "setting" element:
</p>
<p></p>
<ul class="text">
<li>Unidirectional Properties: 'direction' attribute
</li>
<li>Preferences: 'q' attribute
</li>
</ul>
<a name="schema-acl"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.5.1"></a><h3>4.5.1. The 'visibility' Attribute</h3>
<p>
The attribute "visibility" is defined on the
"setting" element to specify whether or not the user agent
is permitted to display the property value to the user. This is used
to hide setting values that the profile administrator may not want the
user to see or know. The "visibility" attribute has two
possible values:
</p>
<p></p>
<ul class="text">
<li>visible: specifies that display of the property value is
not restricted. This is the default value of the attribute if it is
not specified.
</li>
<li>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.
</li>
</ul>
<a name="sec:policy"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.5.2"></a><h3>4.5.2. The 'policy' Attributes</h3>
<p>The setting element has an optional 'policy' attribute. The
policy attribute is used to define the constraining properties
of an element. It defines how the element value is used by an
endpoint (e.g. whether it can or can not be used in a
session). The following values are defined for the 'policy'
attribute:
</p>
<p></p>
<ul class="text">
<li>allow: the value contained in the element is allowed and
SHOULD be used in sessions. This is the default value that
is used if the 'policy' attribute is omitted.
</li>
<li>disallow: the value contained in the element is forbidden
and SHOULD NOT be used in sessions.
</li>
</ul>
<p>The policy attribute can be omitted if the default policy
'allow' applies.
</p>
<p></p>
<blockquote class="text">
<p>OPEN ISSUE: The policy attribute may not be needed for
elements outside of a settings_container. Further
clarification is needed on this. Using the policy attribute
only inside containers would further simplify the specification
of profile data.
</p>
</blockquote>
<a name="sec:ex-policy"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.5.3"></a><h3>4.5.3. The 'excludedPolicy' Attributes</h3>
<p>The "setting_container" element has an optional
'excludedPolicy' attribute. This attribute specifies the
default policy for all values that are not in the
container. Elements that are present in the container have their
own 'policy' attribute, which defines the policy for that
element. The following values are defined for the
'excludedPolicy' attribute:
</p>
<p></p>
<ul class="text">
<li>allow: values not listed in the container are allowed
and MAY be used in sessions. This is the default value that
is used if the 'excludedPolicy' attribute is omitted.
</li>
<li>disallow: values not listed in the container are
forbidden and MUST NOT be used in sessions.
</li>
</ul>
<p>The excludedPolicy attribute can be omitted if the default
policy 'allow' applies. The following example shows a policy
that allows the media type audio and disallows all other media
types in sessions (effectively, this construct requires the use
of audio):
</p>
<p></p>
<pre>
<media-types excludedPolicy="disallow">
<media-type policy="allow">audio</media-type>
</media-types>
</pre><p>
</p>
<a name="sec:unidir"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.5.4"></a><h3>4.5.4. The 'direction' Attribute</h3>
<p>Some properties are unidirectional and only apply to messages
or data streams transmitted into one direction. For example, a
property for media streams can be restricted to outgoing media
streams only. Unidirectional properties can be expressed by
adding a 'direction' attribute to the respective element.
</p>
<p>The 'direction' attribute can have the following values:
</p>
<p></p>
<ul class="text">
<li>recvonly: the property only applies to incoming messages/streams.
</li>
<li>sendonly: the property only applies to outgoing messages/streams.
</li>
<li>sendrecv: the property applies to messages/streams in both
directions. This is the default value that is used if the
'direction' attribute is omitted.
</li>
</ul>
<a name="sec:pref"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.5.5"></a><h3>4.5.5. The 'q' Attribute</h3>
<p>It should be possible to express a preference for a certain
value, if multiple values are allowed within a property. For
example, it should be possible to express that the codecs G.711
and G.729 are allowed, but G.711 is preferred. Preferences can
be expressed by adding a 'q' attribute to a property
element. Elements derived from the "setting" element for which
multiple occurrences and values are allowed SHOULD have a "q"
attribute if the order is significant. Typically these elements are
contained in an element derived from the "setting_container" element.
The 'q' attribute is only meaningful if the 'policy'
attribute set to 'allowed'. It must be ignored in all other
cases.
</p>
<p>An element with a higher 'q' value is preferred over one with
a lower 'q' value. 'q' attribute values range from 0 to 1. The
default value is 0.5.
</p>
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.6"></a><h3>4.6. The 'profileUri' Element</h3>
<p>The <profileUri> element contains the URI of this
profile on the profile server. The value contained in the
profileUri element may be different than the URI subscribe to
when retrieving this profile. When the user agent retrieves a
profile where the profileUri is different than the subscribe to
URI, the user agent SHOULD unsubscribe to the current URI and
then subscribe to the new URI.
</p>
<p>The <profileUri> element is optional and MAY occur
only once inside a <propertySet> element. The profileUri element is
specific to the local-network, device, user or application profile
in which it occurs. It has no meaning outside of the profile in
which it occurs and SHOULD NOT be merged.
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.7"></a><h3>4.7. The 'profileCredential' Element</h3>
<p>
The <profileCredential> element contains the digest authentication
information that SHOULD be used for authentication for the profile
subscription via SIP or profile retrieval via HTTP, HTTPS, etc. The
profileCredential element is optional and MAY occur only once inside
a propertySet element. The profileCredential element is
specific to the local-network, device, user or application profile
in which it occurs. It has no meaning outside of the profile in
which it occurs and SHOULD NOT be merged. The profileCredential element MUST contain
exactly one of each of the elements: realm, authUser and one of either
a1Digest or password.
</p>
<a name="realm-element"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.7.1"></a><h3>4.7.1. realm Element</h3>
<p>
The realm element contains the string that defines the realm to
which this credential pertains. The value of the realm element is
the same as the realm parameter in the <a class="info" href="#RFC2617">[RFC2617]<span> (</span><span class="info">Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</span><span>)</span></a>
headers: WWW-Authenticate, Authorization and the
<a class="info" href="#RFC3261">SIP<span> (</span><span class="info">Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.</span><span>)</span></a> [RFC3261] headers:
Proxy-Authenticate and Proxy-Authorization.
If a match
of the realm value is found, the user agent uses the values in the authUser
and a1Digest elements contained in the profileCredential element.
Exactly one realm element MUST be contained in a profileCredential
element.
A wildcard of "*" MAY be used as the realm value in which case the
user agent MUST calculate the A1 DIGEST for the realm given in the
authentication challenge. If the wildcard is given for the realm,
the clear text form of the password contained in the password
element MUST also be used.
</p>
<a name="auth-user-element"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.7.2"></a><h3>4.7.2. authUser Element</h3>
<p>
The authUser element contains the string value of the "username" parameter which
SHOULD be used in Authorization and Proxy-Authorization request headers
when retrying a request that was challenged for authentication. Exactly
one authUser element SHOULD be contained in a profileCredential element.
</p>
<a name="a1Digest"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.7.3"></a><h3>4.7.3. a1Digest Element</h3>
<p>
The a1Digest element contains a string with the value of the A1 digest of the
username, realm and password as defined in <a class="info" href="#RFC2617">[RFC2617]<span> (</span><span class="info">Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</span><span>)</span></a>.
At most one a1Digest element MUST be contained in a profileCredential
element. The a1Digest element MUST NOT exist in a profileCredential
element containing a password element.
The username and realm used to construct the value of the a1Digest
element MUST match the values of the realm and authUser elements
contained in the profileCredential element with the a1Digest element.
</p>
<a name="password"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.7.4"></a><h3>4.7.4. password Element</h3>
<p>
The password element contains the clear text password for use with
<a class="info" href="#RFC2617">DIGEST Authentication<span> (</span><span class="info">Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</span><span>)</span></a> [RFC2617]. At most one password
MUST be contained in a profileCredential element. The password
element MUST NOT exist in a profileCredential element containing a a1Digest
element. The user agent uses this password along with the realm and authUser
elements to calculate the A1 digest used for DIGEST Authentication.
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.8"></a><h3>4.8. The 'profileContactUri' Element</h3>
<p>The <profileContactUri> element contains a contact URI
(e.g. a SIP, HTTP URI or email address) under which the issuer of
this profile can be reached. The contact element may, for
example, contain the address of a support hotline.
</p>
<p>The <profileContactUri> element is optional and MAY occur
multiple times inside a <propertySet> element. Multiple instances
of the profileContactUri element allow multiple URI schemes to be provided
for contact information. The user agent MAY use the URI contained
profile-contact-info element which has a URI scheme that the user agent
supports and can make work to provide support help for the profile.
The user agent MAY provide the URIs to the user to contact
the creator of the profile through other communication channels.
The profileContactUri element is
specific to the local-network, device, user or application profile
in which it occurs. It has no meaning outside of the profile in
which it occurs and SHOULD NOT be merged.
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.9"></a><h3>4.9. The 'profileInfo' Element</h3>
<p>The <profileInfo> element provides a short textual
description of the property that should be intelligible to the
human user. This element may, for example, contain
information about the nature of this profile, such as
"Access Network Profile". The text in the <profileInfo>
element is in particular be helpful when a user needs to
decide whether or not to use a newly downloaded profile or
when problems with a profile (e.g. a policy conflict) occur. A
user agent MAY display this information in these cases.
</p>
<p>The <profileInfo> element is optional and MAY occur only
once inside a <propertySet> element. The profileInfo element is
specific to the local-network, device, user or application profile
in which it occurs. It has not meaning outside of the profile in
which it occurs and SHOULD NOT be merged.
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.10"></a><h3>4.10. Example Profile Dataset</h3>
<p>
The following XML example shows a SIP Profile Dataset with example
extension setting elements: ddd, foo, bar, boo, containerElement
and setting container elements:
myContainer, myContainer1, myContainer2 and container3.
</p><pre>
<?xml version="1.0" encoding="UTF-8"?>
<propertySet xmlns="urn:ietf:params:xml:ns:uaprof">
<profileUri>sip:a1b2c3d4e5f6@example.com</profileUri>
<profileCredential>
<realm>example.com</realm>
<authUser>fred</authUser>
<a1Digest>b6b577fd12aa7e1df8d60735ef56fc2e</a1Digest>
<!-- <password>123</password> -->
</profileCredential>
<profileContactUri>tel:+16175551212</profileContactUri>
<profileContactUri>sip:411@example.com</profileContactUri>
<profileContactUri>
http:example.com/sipProfile.html
</profileContactUri>
<profileInfo>
This is an example profile from example.com
</profileInfo>
<ddd xmlns="blatz" policy="allow">fff</ddd>
<foo xmlns="blatz" visibility="visible" policy="allow"
direction="sendrecv" q="0">
</foo>
<bar xmlns="blatz" visibility="hidden" policy=""
direction="sendonly" q="0.1000">
</bar>
<myContainer xmlns="blatz" excludedPolicy="disallow">
<containerElement q="0.1">aaa</containerElement>
<containerElement>bbb</containerElement>
<containerElement q="0.8">ccc</containerElement>
</myContainer>
<boo xmlns="newns" q="1">ggg</boo>
<myContainer1 xmlns="blatz" excludedPolicy="allow">
<myContainer2 xmlns="newns" excludedPolicy="allow">
</myContainer2>
</myContainer1>
<container3 xmlns="ns3">
<containerElement q="0.1">111</containerElement>
<containerElement>222</containerElement>
<containerElement q="0.8">333</containerElement>
</container3>
</propertySet>
</pre>
<a name="schema-merging"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.11"></a><h3>4.11. Merging Property Sets</h3>
<p>A UA may receive property sets from multiple sources, which
need to be merged into a single combined document the UA can
work with.
</p>
<p>Properties that have a single value (e.g. the maximum bandwidth
allowed) require that a common value is determined for this property
during the merging process. The merging rules for determining this value
need to be defined individually for each element in the schema
definition. Properties that allow multiple values (i.e. property containers)
need to be merged by combining the values from the different
data sets. The following sections describe common merging
algorithms. A data set definition may refer to these
algorithms.
</p>
<a name="numeric-merging_algorithm"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.11.1"></a><h3>4.11.1. Single Numeric Value Merging Algorithm</h3>
<p>A general merging rule for elements with numeric values is to select
the largest or the smallest value. For example, a merging rule
for a <max-bandwidth> element would be to select the smallest
value from the values that are in the competing data sets.
</p>
<a name="multivalue-merging_algorithm"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.11.2"></a><h3>4.11.2. Multiple Enumerated Value Merging Algorithm</h3>
<p>Multiple values in property containers are merged by
combining the values from each of the competing data sets. This
is accomplished by copying the elements from each property
container into the merged container. Elements with identical
values are only copied once. The 'policy' attribute of two
elements with the same value is adjusted during the merging
process according to Table 1. If an element exists only in one
property container, then the default policy of the other
container (i.e. the excludedPolicy) is used when accessing
Table 1. For example, if an element is disallowed in one data set
and the element is not contained in the other data set but the
default policy is allowed for that data set, then the values
disallowed and allowed are used to access Table 1. Consequently,
the element will be disallowed in the merged data set. Finally, the
excludedPolicy attributes of the containers are also merged
using Table 1. In addition to these merging rules, each schema
may define specific merging rules for each property container.
</p>
<p></p>
<pre>
set 1 \ set 2 | allow | disallow
--------------+----------+----------
allow | allow | disallow
disallow | disallow | disallow
Table 1: merging policies.
</pre><p>
</p>
<p>The following example illustrates the merging process for two data
sets. All elements are merged into one container and the policy
attributes are adjusted according to Table 1. The merged container has
the default policy disallow, which is determined using Table
1. The entry for PCMA in the merged data set is redundant since
it has the default policy.
</p>
<p></p>
<pre>
Data set 1:
<codecs excludedPolicy='allow'>
<codec policy='disallow'>PCMA</codec>
</codecs>
Data set 2:
<codecs excludedPolicy='disallow'>
<codec policy='allow'>PCMA</codec>
<codec policy='allow'>G729</codec>
</codecs>
Merged data set:
<codecs excludedPolicy='disallow'>
<codec policy='disallow'>PCMA</codec>
<codec policy='allow'>G729</codec>
</codecs>
</pre><p>
</p>
<p>Some constellations of policy attributes result in an illegal
merged data set. They constitute a conflict that can not be
resolved automatically. For example, two data sets may define
two non-overlapping sets of allowed audio codecs and both
disallow all other codes. The resulting merged set of codecs
would be empty, which is illegal according to the schema
definition of the codecs element. If the use of these properties
is enforced by both networks, the UA may experience difficulties
or may not be able to set up a session at all.
</p>
<p>The combined property set MUST again be valid and well-formed
according to the schema definitions. A conflict occurs if the
combined property set is not a well-formed document after the
merging process is completed.
</p>
<a name="singlelocal-merging_algorithm"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.11.3"></a><h3>4.11.3. Closest Value First Merging Algorithm</h3>
<p>Some properties require that the values from different
data sets are ordered based on the origin of the data
set during the merging process. Property values that come
from a domain close to the user agent take precedence
over values that were in a data set delivered by a remote
domain. This order can be used, for example, to select
the property value from the closest domain. In many cases,
this is the local domain of the user agent. For example,
the URI of an outbound proxy could be merged this
way. This order can also be used to generate an ordered
list of property values during the merging process. For
example, multiple values for media intermediaries can
be ordered so that the closest media intermediary is
traversed before the second closest intermediary and so
on.
</p>
<p>This merging algorithm requires that the source of a
data set is considered.
</p>
<p>If property sets are delivered through the
configuration framework <a class="info" href="#I-D.ietf-sipping-config-framework">[I-D.ietf-sipping-config-framework]<span> (</span><span class="info">Petrie, D., “A Framework for Session Initiation Protocol User Agent Profile Delivery,” October 2006.</span><span>)</span></a>, the value
received through a subscription using the "local-network"
profile-type takes precedence over values received
through other profile-type subscriptions.
</p>
<p></p>
<blockquote class="text">
<p>OPEN ISSUE: Can we define an order for 'device', 'user',
and 'application' profiles?
</p>
</blockquote>
<p>The session-specific policy mechanism <a class="info" href="#I-D.hilt-sipping-session-policy-framework">[I-D.hilt-sipping-session-policy-framework]<span> (</span><span class="info">Hilt, V., “A Framework for Session Initiation Protocol (SIP) Session Policies,” March 2006.</span><span>)</span></a>
provides an order among policy servers. This order is
based on the order, in which a SIP message traverses the
network, starting with the closest domain. This order can
directly be used to order property values as described
above.
</p>
<a name="common_types"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4.12"></a><h3>4.12. Common Types</h3>
<p>
The schema also defines a set of common types that are used in
defining data sets (e.g. DataIpPort).
[Need to document common types.]
</p>
<a name="defining-datasets"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5. Defining Data Sets</h3>
<p>
This section covers several issues that should be take into
consideration when specifying new data set schemas. This is intended
to be a guide to authors writing specifications defining a new data set
schema or extensions to existing ones.
</p>
<a name="defining-datasets-schema"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.5.1"></a><h3>5.1. Namespace</h3>
<p>
It is RECOMMENDED that a data set defines a new <a class="info" href="#W3C.REC-xml-names-19990114">XML namespace<span> (</span><span class="info">Hollander, D., Bray, T., and A. Layman, “Namespaces in XML,” January 1999.</span><span>)</span></a> [W3C.REC-xml-names-19990114] to
scope all of the properties that are defined in the name space.
</p>
<a name="defining-datasets-properties"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.5.2"></a><h3>5.2. Property Definitions</h3>
<p>The properties defined in a data set schema may be simple
(i.e. having a single value) or they may be complex (i.e. a container
with multiple 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 "setting" as well.
</p>
<p>
A data set specification 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.
</p>
<p>
The following information should be defined for each property in a data set:
</p>
<ul class="text">
<li>description: describe the meaning and application of the property.
</li>
<li>cardinality: define how many instances of
this property element
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.
</li>
<li>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.
</li>
</ul><p>
</p>
<a name="defining-datasets-merging"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.5.3"></a><h3>5.3. Merging Data Sets</h3>
<p>
User agents may receive data sets from multiple sources. They need to
merge these data sets in order to create an overall data set they can
work with. Collisions on data sets may occur if multiple sources
provide different values for the same properties. These collisions
need to be resolved during the merging process.
</p>
<p>A data set schema MUST define rules for merging data sets from
different sources for each property that is defined. Considerations
for merging data sets are discussed in <a class="info" href="#schema-merging">Section 4.11<span> (</span><span class="info">Merging Property Sets</span><span>)</span></a>. A data set schema must define if and how these consideration apply
and MAY define alternative merging rules for specific settings. A data
set schema must also identify combinations of properties that
constitute a conflict that can't resolved. It may provide additional
guidelines for the behavior of a user agent in these cases.
</p>
<a name="candidiate-datasets"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6. Candidate Data Sets</h3>
<p>
The following sections name some of the candidate data sets that
are or may be defined. These data sets can be aggregated to form
profiles appropriate to the capabilities of a user agent implementation.
</p>
<p></p>
<ul class="text">
<li>SIP Protocol Data Set: the lowest common denominator
set of properties common to all SIP user agents of any
capability. A schema covering the elements of this data
set can be found in <a class="info" href="#I-D.petrie-sipping-sip-dataset">[I-D.petrie-sipping-sip-dataset]<span> (</span><span class="info">Petrie, D., “The Core Session Initiation Protocol User Agent Profile Data Set,” October 2005.</span><span>)</span></a>.
</li>
<li>Media Data Set: this data set contains media related
policies. A schema covering the elements of this data set
can be found in <a class="info" href="#I-D.ietf-sipping-media-policy-dataset">[I-D.ietf-sipping-media-policy-dataset]<span> (</span><span class="info">Hilt, V., “A User Agent Profile Data Set for Media Policy,” April 2006.</span><span>)</span></a>.
</li>
<li>Identity Data Set: AORs and lines (see <a class="info" href="#I-D.petrie-sipping-identity-dataset">[I-D.petrie-sipping-identity-dataset]<span> (</span><span class="info">Petrie, D., “The Session Initiation Protocol User Agent Identity Profile Data Set,” October 2005.</span><span>)</span></a>)
</li>
<li>HTTP Protocol Data Set: server settings. Proxy for
clients.
</li>
<li>NAT Traversal Data Set: settings for STUN, TURN etc.
</li>
<li>SIP Digit Maps Data Set: <a class="info" href="#I-D.petrie-sipping-voip-features-dataset">[I-D.petrie-sipping-voip-features-dataset]<span> (</span><span class="info">Petrie, D., “The Session Initiation Protocol User Agent VoIP Features Data Set,” October 2005.</span><span>)</span></a>
</li>
<li>VoIP Features: <a class="info" href="#I-D.petrie-sipping-voip-features-dataset">[I-D.petrie-sipping-voip-features-dataset]<span> (</span><span class="info">Petrie, D., “The Session Initiation Protocol User Agent VoIP Features Data Set,” October 2005.</span><span>)</span></a>
</li>
<li>Address Book:
</li>
<li>Buddy List:
</li>
</ul>
<a name="security-considerations"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7. Security Considerations</h3>
<p>
Security is mostly a delivery problem. The delivery framework SHOULD provide
a secure means of delivering the profile data as it may contain sensitive
data that would be undesirable if it were stolen or sniffed. Storage of
the profile on the profile delivery server and user agent is an implementation
problem. The profile delivery server and the user agent SHOULD provide
protection that prevents unauthorized access of the profile data. The
profile delivery server and the user agent SHOULD enforce the access
control policies defined in the profile data sets if present.
</p>
<blockquote class="text">
<p>
[The point of the access control construct on the data set is to
provide some security policy on the visibility and ability to
change sensitive properties. Does the access control mechanism
also create a security problem where the local network can set
or hide properties from the user?]
</p>
</blockquote><p>
</p>
<p>
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).
</p>
<a name="iana-considerations"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8. IANA Considerations</h3>
<p>
XML name space registration: urn:ietf:params:xml:ns:uaprof
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.8.1"></a><h3>8.1. Content-type registration for 'application/uaprofile+xml'</h3>
<p>
</p>
<blockquote class="text"><dl>
<dt>To: ietf-types@iana.org</dt>
<dd>
</dd>
<dt>Subject: Registration of MIME media type application/uaprofile+xml</dt>
<dd>
</dd>
<dt>MIME media type name: application</dt>
<dd>
</dd>
<dt>MIME subtype name: uaprofile+xml</dt>
<dd>
</dd>
<dt>Required parameters: (none)</dt>
<dd>
</dd>
<dt>Optional parameters: charset</dt>
<dd>
Indicates the character encoding of enclosed XML. Default is
UTF-8.
</dd>
<dt>Encoding considerations:</dt>
<dd>
Uses XML, which can employ 8-bit characters, depending on the
character encoding used. See RFC 3023 [RFC 3023], section 3.2.
</dd>
<dt>Security considerations:</dt>
<dd>
This content type is designed to carry SIP user agent profile
data, which may be considered private information. Appropriate
precautions should be adopted to limit disclosure of this
information.
</dd>
<dt>Interoperability considerations:</dt>
<dd>
This content type provides a common format for exchange of
SIP user agent profile information.
</dd>
<dt>Published specification:</dt>
<dd>
RFC XXXX
(Note to RFC Editor: Please fill in XXXX with the RFC number of this specification)
</dd>
<dt>Applications which use this media type:</dt>
<dd>
SIP user agents and profile delivery servers.
</dd>
<dt>Additional information:</dt>
<dd>
Magic number(s): File extension(s): Macintosh File Type Code(s):
</dd>
<dt>Person & email address to contact for further information:</dt>
<dd>
Daniel Petrie EMail: dan.ietf AT sipez DOT com
</dd>
<dt>Intended usage:</dt>
<dd>
LIMITED USE
</dd>
<dt>Author/Change controller:</dt>
<dd>
This specification is a proposed work item of the IETF SIPPING
working group, with mailing list address: sipping@ietf.edu.
</dd>
<dt>Other information:</dt>
<dd>
This media type is a specialization of application/xml [RFC 3023],
and many of the considerations described there also apply to
application/uaprof+xml.
</dd>
</dl></blockquote><p>
</p>
<a name="changes"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.9"></a><h3>9. Change History</h3>
<p>
[[RFC Editor: Please remove this entire section upon publication as an RFC.]]
</p>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.9.1"></a><h3>9.1. Changes from draft-petrie-sipping-profile-datasets-03</h3>
<p>
Converted the XML schema to use Relax NG and created a valid schema.
</p>
<p>
Defined XML name space for schema: "urn:ietf:params:xml:ns:uaprof"
</p>
<p>
Defined mime type: application/uaprofile+xml to be used as default content type for the
configuration framework.
</p>
<p>
Changed names of elements, attributes and other data types which contained
"-" or "_" to use camel case.
</p>
<p>
Added password element so that credential can contain either A1 digest or
clear text password as the clear text password is required by the user agent
in some cases (e.g. http GET) or to wildcard the realm.
</p>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.9.2"></a><h3>9.2. Changes from draft-petrie-sipping-profile-datasets-02</h3>
<p>
Removed "mandatory" policy attribute value to simplify use and profile
merging issues.
</p>
<p>
Session Independent Policy draft was split into separate media dataset draft
and policy drafts. Fixed references and information in this draft to
reflect the two drafts.
</p>
<p>
Added concrete properties contained in elements: profileUri,
profileCredential, profileContactUri and profileInfo. Prior
to this draft, there were only abstract elements defined in this
draft. These elements have been added to contain information that
is specific to the profile and are independent of the specific profile
datasets contained in the profile.
</p>
<p>
Split references into normative and informative sections.
</p>
<p>
Numerous editorial changes
</p>
<a name="changes01"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.9.3"></a><h3>9.3. Changes from draft-petrie-sipping-profile-datasets-01</h3>
<p>
Split out the core SIP Protocol dataset into a separate draft.
</p>
<p>
Schema changes: created setting_container, added q and direction attributes
along with other tweaks to the schema.
</p>
<p>
Better integration and coordination with <a class="info" href="#I-D.ietf-sipping-media-policy-dataset">[I-D.ietf-sipping-media-policy-dataset]<span> (</span><span class="info">Hilt, V., “A User Agent Profile Data Set for Media Policy,” April 2006.</span><span>)</span></a>. The media/codec dataset is now completely contained in the policy draft.
</p>
<a name="changes00"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.9.4"></a><h3>9.4. Changes from draft-petrie-sipping-profile-datasets-00</h3>
<p>
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.
</p>
<p>
Added settings element attributes "policy" and "visibility" to provide
merging constraints and access 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.
</p>
<p>
Defined default merging policy and profile source precedence along with
the option for different policies to be describe in specific settings
definition documents.
</p>
<p>
Added example merging with XML profiles from device and user for the
SIP transport protocol.
</p>
<a name="rfc.references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.10"></a><h3>10. References</h3>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>10.1. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="I-D.hilt-sipping-session-policy-framework">[I-D.hilt-sipping-session-policy-framework]</a></td>
<td class="author-text">Hilt, V., “<a href="http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-policy-framework-01.txt">A Framework for Session Initiation Protocol (SIP) Session Policies</a>,” draft-hilt-sipping-session-policy-framework-01 (work in progress), March 2006.</td></tr>
<tr><td class="author-text" valign="top"><a name="I-D.ietf-sipping-config-framework">[I-D.ietf-sipping-config-framework]</a></td>
<td class="author-text">Petrie, D., “<a href="http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-09.txt">A Framework for Session Initiation Protocol User Agent Profile Delivery</a>,” draft-ietf-sipping-config-framework-09 (work in progress), October 2006.</td></tr>
<tr><td class="author-text" valign="top"><a name="I-D.mealling-iana-xmlns-registry">[I-D.mealling-iana-xmlns-registry]</a></td>
<td class="author-text">Mealling, M., “<a href="http://www.ietf.org/internet-drafts/draft-mealling-iana-xmlns-registry-05.txt">The IETF XML Registry</a>,” draft-mealling-iana-xmlns-registry-05 (work in progress), June 2003.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2617">[RFC2617]</a></td>
<td class="author-text"><a href="mailto:john@math.nwu.edu">Franks, J.</a>, <a href="mailto:pbaker@verisign.com">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com">L. Stewart</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2617.txt">HTTP Authentication: Basic and Digest Access Authentication</a>,” RFC 2617, June 1999 (<a href="ftp://ftp.isi.edu/in-notes/rfc2617.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2617.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2617.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3261">[RFC3261]</a></td>
<td class="author-text">Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “<a href="ftp://ftp.isi.edu/in-notes/rfc3261.txt">SIP: Session Initiation Protocol</a>,” RFC 3261, June 2002.</td></tr>
<tr><td class="author-text" valign="top"><a name="W3C.REC-xml-names-19990114">[W3C.REC-xml-names-19990114]</a></td>
<td class="author-text">Hollander, D., Bray, T., and A. Layman, “<a href="http://www.w3.org/TR/1999/REC-xml-names-19990114">Namespaces in XML</a>,” W3C REC REC-xml-names-19990114, January 1999.</td></tr>
<tr><td class="author-text" valign="top"><a name="W3C.REC-xmlschema-1">[W3C.REC-xmlschema-1]</a></td>
<td class="author-text">Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, “<a href="http://www.w3.org/TR/xmlschema-1/">XML Schema Part 1: Structures</a>,” W3C REC-xmlschema-1, May 2001.</td></tr>
<tr><td class="author-text" valign="top"><a name="W3C.REC-xmlschema-2">[W3C.REC-xmlschema-2]</a></td>
<td class="author-text">Biron, P. and A. Malhotra, “<a href="http://www.w3.org/TR/xmlschema-2/">XML Schema Part 2: Datatypes</a>,” W3C REC-xmlschema-2, May 2001.</td></tr>
</table>
<a name="rfc.references2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>10.2. Informative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="I-D.ietf-sipping-media-policy-dataset">[I-D.ietf-sipping-media-policy-dataset]</a></td>
<td class="author-text">Hilt, V., “<a href="http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-policy-dataset-01.txt">A User Agent Profile Data Set for Media Policy</a>,” draft-ietf-sipping-media-policy-dataset-01 (work in progress), April 2006.</td></tr>
<tr><td class="author-text" valign="top"><a name="I-D.petrie-sipping-identity-dataset">[I-D.petrie-sipping-identity-dataset]</a></td>
<td class="author-text">Petrie, D., “<a href="http://www.ietf.org/internet-drafts/draft-petrie-sipping-identity-dataset-00.txt">The Session Initiation Protocol User Agent Identity Profile Data Set</a>,” draft-petrie-sipping-identity-dataset-00 (work in progress), October 2005.</td></tr>
<tr><td class="author-text" valign="top"><a name="I-D.petrie-sipping-sip-dataset">[I-D.petrie-sipping-sip-dataset]</a></td>
<td class="author-text">Petrie, D., “<a href="http://www.ietf.org/internet-drafts/draft-petrie-sipping-sip-dataset-01.txt">The Core Session Initiation Protocol User Agent Profile Data Set</a>,” draft-petrie-sipping-sip-dataset-01 (work in progress), October 2005.</td></tr>
<tr><td class="author-text" valign="top"><a name="I-D.petrie-sipping-voip-features-dataset">[I-D.petrie-sipping-voip-features-dataset]</a></td>
<td class="author-text">Petrie, D., “<a href="http://www.ietf.org/internet-drafts/draft-petrie-sipping-voip-features-dataset-00.txt">The Session Initiation Protocol User Agent VoIP Features Data Set</a>,” draft-petrie-sipping-voip-features-dataset-00 (work in progress), October 2005.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2141">[RFC2141]</a></td>
<td class="author-text"><a href="mailto:jayhawk@ds.internic.net">Moats, R.</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2141.txt">URN Syntax</a>,” RFC 2141, May 1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2141.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2141.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2141.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2648">[RFC2648]</a></td>
<td class="author-text"><a href="mailto:jayhawk@att.com">Moats, R.</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2648.txt">A URN Namespace for IETF Documents</a>,” RFC 2648, August 1999.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3470">[RFC3470]</a></td>
<td class="author-text"><a href="mailto:shollenbeck@verisign.com">Hollenbeck, S.</a>, <a href="mailto:mrose@dbc.mtview.ca.us">Rose, M.</a>, and <a href="mailto:LMM@acm.org">L. Masinter</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc3470.txt">Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols</a>,” BCP 70, RFC 3470, January 2003 (<a href="ftp://ftp.isi.edu/in-notes/rfc3470.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc3470.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc3470.xml">XML</a>).</td></tr>
</table>
<a name="sip-ua-profile-schema"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A. Relax NG SIP UA Profile Schema</h3>
<pre>
<?xml version="1.0"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
ns="urn:ietf:params:xml:ns:uaprof"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<start>
<element name="propertySet">
<optional>
<ref name="ElementProfileUri"/>
</optional>
<optional>
<ref name="ElementProfileCredential"/>
</optional>
<zeroOrMore>
<element name="profileContactUri">
<!-- who to contact for help with this profile -->
<data type="anyURI"/>
</element>
</zeroOrMore>
<optional>
<element name="profileInfo">
<text/>
</element>
</optional>
<zeroOrMore>
<choice>
<ref name="PropertySetExtension"/>
<ref name="ElementGenericSetting"/>
<ref name="ElementGenericSettingContainer"/>
</choice>
</zeroOrMore>
</element>
</start>
<!-- example setting with all setting attributes -->
<!-- <define name="ElementFoo">
<element name="foo">
<ref name="SettingAttributes"/>
<text/>
</element>
</define>
-->
<define name="ElementProfileUri">
<!-- URI to subscribe to for this profile -->
<element name="profileUri">
<ref name="DataSipUri"/>
</element>
</define>
<define name="ElementProfileCredential">
<!-- credentials for subscribing or getting profile -->
<element name="profileCredential">
<ref name="DataCredential"/>
</element>
</define>
<define name="PropertySetExtension">
<!-- place to add new settings in other namespaces -->
<empty/>
</define>
<define name="ElementGenericSettingContainer">
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:uaprof"/>
<nsName ns=""/>
</except>
</anyName>
<ref name="SettingContainerAttributes"/>
<zeroOrMore>
<ref name="AttributeGeneric"/>
</zeroOrMore>
<!-- container can have containers or settings not both -->
<choice>
<zeroOrMore>
<ref name="ElementGenericSetting"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementGenericSettingContainer"/>
</zeroOrMore>
</choice>
</element>
</define>
<define name="ElementGenericSetting">
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:uaprof"/>
<nsName ns=""/>
</except>
</anyName>
<ref name="SettingAttributes"/>
<zeroOrMore>
<ref name="AttributeGeneric"/>
</zeroOrMore>
<zeroOrMore>
<choice>
<text/>
<ref name="ElementGenericSetting"/>
</choice>
</zeroOrMore>
</element>
</define>
<define name="AttributeGeneric">
<attribute>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:uaprof"/>
<nsName ns=""/>
</except>
</anyName>
</attribute>
</define>
<define name="DataCredential">
<element name="realm">
<text/>
</element>
<element name="authUser">
<text/>
</element>
<choice>
<element name="a1Digest">
<data type="string">
<param name="pattern">[0-9,a-f]{32,32}</param>
</data>
</element>
<element name="password">
<text/>
</element>
</choice>
</define>
<define name="DataSipUri">
<choice>
<data type="anyURI">
<param name="pattern">sip:.*</param>
</data>
<data type="anyURI">
<param name="pattern">sips:.*</param>
</data>
</choice>
</define>
<define name="DataSipNameAddr">
<choice>
<data type="anyURI"><!-- need to tighten this up -->
<param name="pattern">"?.*"?<?sip:.*</param>
</data>
<data type="anyURI">
<param name="pattern">"?.*"?<?sips:.*</param>
</data>
</choice>
</define>
<define name="SettingContainerAttributes">
<optional>
<attribute name="excludedPolicy">
<ref name="DataPolicies"/>
</attribute>
</optional>
</define>
<define name="SettingAttributes">
<interleave>
<optional>
<ref name="AttributePolicy"/>
</optional>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeDirection"/>
</optional>
<optional>
<ref name="AttributeQ"/>
</optional>
</interleave>
</define>
<define name="AttributePolicy">
<attribute name="policy">
<ref name="DataPolicies"/>
</attribute>
</define>
<define name="DataPolicies">
<choice>
<value></value><!-- default of allow -->
<value>allow</value>
<value>disallow</value>
</choice>
</define>
<define name="AttributeVisibility">
<attribute name="visibility">
<choice>
<value></value><!-- default of visible -->
<value>visible</value>
<value>hidden</value>
</choice>
</attribute>
</define>
<define name="AttributeDirection">
<attribute name="direction">
<choice>
<value></value><!-- default of sendrecv -->
<value>sendrecv</value>
<value>sendonly</value>
<value>recvonly</value>
</choice>
</attribute>
</define>
<define name="AttributeQ">
<attribute name="q">
<data type="float">
<!-- default of 0.5 -->
<param name="minInclusive">0</param>
<param name="maxInclusive">1</param>
</data>
</attribute>
</define>
<define name="DataIpPort">
<data type="integer">
<param name="minInclusive">1</param>
<param name="maxInclusive">65535</param>
</data>
</define>
<define name="DataIpTransport">
<choice>
<value></value><!-- default of UDP -->
<value>UDP</value>
<value>TCP</value>
<value>TLS</value>
<value>DTLS</value>
<value>SCTP</value>
</choice>
</define>
</grammar>
</pre>
<a name="acknowledgments"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.B"></a><h3>Appendix B. Acknowledgments</h3>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Daniel Petrie</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">SIPez LLC.</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">34 Robbins Rd.</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Arlington, MA 02476</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">US</td></tr>
<tr><td class="author" align="right">Phone: </td>
<td class="author-text">+1 617 273 4000</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:dan.ietf AT SIPez DOT com">dan.ietf AT SIPez DOT com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://www.SIPez.com/">http://www.SIPez.com/</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Scott Lawrence</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Pingtel Corp.</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">400 W. Cummings Park</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Suite 2200</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Woburn, MA 01801</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">US</td></tr>
<tr><td class="author" align="right">Phone: </td>
<td class="author-text">"Scott Lawrence (+1 781 938 5306)" <sip:slawrence@pingtel.com></td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:slawrence AT pingtel DOT com">slawrence AT pingtel DOT com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://skrb.org/scott/">http://skrb.org/scott/</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Martin Dolly</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">AT&T Labs</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">200 Laurel Avenue</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Middletowm, NJ 07748</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">US</td></tr>
<tr><td class="author" align="right">Phone: </td>
<td class="author-text"></td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:mdolly AT att DOT com">mdolly AT att DOT com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href=""></a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Volker Hilt</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Bell Labs/Lucent Technologies</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">101 Crawfords Corner Rd</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Holmdel, NJ 07733</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:volkerh@bell-labs.com">volkerh@bell-labs.com</a></td></tr>
</table>
<a name="rfc.copyright"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>Intellectual Property Statement</h3>
<p class='copyright'>
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.</p>
<p class='copyright'>
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 <a href='http://www.ietf.org/ipr'>http://www.ietf.org/ipr</a>.</p>
<p class='copyright'>
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 <a href='mailto:ietf-ipr@ietf.org'>ietf-ipr@ietf.org</a>.</p>
<h3>Disclaimer of Validity</h3>
<p class='copyright'>
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.</p>
<h3>Copyright Statement</h3>
<p class='copyright'>
Copyright © The Internet Society (2006).
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.</p>
<h3>Acknowledgment</h3>
<p class='copyright'>
Funding for the RFC Editor function is currently provided by the
Internet Society.</p>
</body></html>
| PAFTECH AB 2003-2026 | 2026-04-23 22:54:57 |