idnits 2.17.1
draft-petrie-sipping-profile-datasets-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 19.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 1794.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1805.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1812.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1818.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (November 17, 2007) is 6005 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFC 3023' is mentioned on line 1355, but not defined
** Obsolete undefined reference: RFC 3023 (Obsoleted by RFC 7303)
-- Possible downref: Normative reference to a draft: ref.
'I-D.hilt-sipping-session-policy-framework'
== Outdated reference: A later version (-18) exists of
draft-ietf-sipping-config-framework-14
** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615,
RFC 7616, RFC 7617)
== Outdated reference: A later version (-16) exists of
draft-ietf-sipping-media-policy-dataset-04
== Outdated reference: A later version (-02) exists of
draft-petrie-sipping-identity-dataset-01
== Outdated reference: A later version (-03) exists of
draft-petrie-sipping-sip-dataset-02
== Outdated reference: A later version (-02) exists of
draft-petrie-sipping-voip-features-dataset-01
-- Obsolete informational reference (is this intentional?): RFC 2141
(Obsoleted by RFC 8141)
Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SIPPING D. Petrie
3 Internet-Draft SIPez LLC.
4 Intended status: Standards Track S. Channabasappa
5 Expires: May 20, 2008 CableLabs
6 S. Ganesan
7 Motorola
8 November 17, 2007
10 A Schema and Guidelines for Defining Session Initiation Protocol User
11 Agent Profile Datasets
12 draft-petrie-sipping-profile-datasets-05.txt
14 Status of this Memo
16 By submitting this Internet-Draft, each author represents that any
17 applicable patent or other IPR claims of which he or she is aware
18 have been or will be disclosed, and any of which he or she becomes
19 aware will be disclosed, in accordance with Section 6 of BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF), its areas, and its working groups. Note that
23 other groups may also distribute working documents as Internet-
24 Drafts.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 This Internet-Draft will expire on May 20, 2008.
39 Copyright Notice
41 Copyright (C) The IETF Trust (2007).
43 Abstract
45 This document defines the requirements and a format for SIP user
46 agent profile data. An overall schema is specified for the
47 definition of profile datasets. The schema also provides for
48 expressing constraints for how multiple sources of profile data are
49 to be combined. This document provides a guide to considerations,
50 policies and syntax for defining datasets to be included in profile
51 data. It also explores some specific datasets to test the
52 requirements, assumptions and syntax.
54 Table of Contents
56 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
58 2.1. Requirements Terminology . . . . . . . . . . . . . . . . . 5
59 2.2. Profile Data Terminology . . . . . . . . . . . . . . . . . 5
60 2.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
61 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 6
62 3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6
63 3.1.1. Outbound Proxy Setting . . . . . . . . . . . . . . . . 7
64 3.1.2. Codec Settings . . . . . . . . . . . . . . . . . . . . 8
65 3.1.3. Transport Protocol Setting . . . . . . . . . . . . . . 11
66 3.2. Requirement Descriptions . . . . . . . . . . . . . . . . . 13
67 3.2.1. Implementer Extensibility . . . . . . . . . . . . . . 13
68 3.2.2. Flexible Capabilities . . . . . . . . . . . . . . . . 13
69 3.2.3. XML . . . . . . . . . . . . . . . . . . . . . . . . . 14
70 3.2.4. Access Control . . . . . . . . . . . . . . . . . . . . 14
71 3.2.5. Data Constraints and Range Definition . . . . . . . . 15
72 3.2.6. Support of User, Application, Device, Local
73 Network Sources . . . . . . . . . . . . . . . . . . . 15
74 3.2.7. The Ability to Specify Policy . . . . . . . . . . . . 16
75 4. Overall Dataset Schema . . . . . . . . . . . . . . . . . . . . 17
76 4.1. Data Primitives . . . . . . . . . . . . . . . . . . . . . 17
77 4.2. Use of Namespaces . . . . . . . . . . . . . . . . . . . . 18
78 4.3. The 'propertySet' Element . . . . . . . . . . . . . . . . 18
79 4.4. The Abstract 'setting_container' Element . . . . . . . . . 18
80 4.5. The Abstract 'setting' Element . . . . . . . . . . . . . . 18
81 4.5.1. The 'visibility' Attribute . . . . . . . . . . . . . . 19
82 4.5.2. The 'policy' Attributes . . . . . . . . . . . . . . . 19
83 4.5.3. The 'excludedPolicy' Attributes . . . . . . . . . . . 20
84 4.5.4. The 'direction' Attribute . . . . . . . . . . . . . . 20
85 4.5.5. The 'q' Attribute . . . . . . . . . . . . . . . . . . 20
86 4.6. The 'profileUri' Element . . . . . . . . . . . . . . . . . 21
87 4.7. The 'profileCredential' Element . . . . . . . . . . . . . 21
88 4.7.1. realm Element . . . . . . . . . . . . . . . . . . . . 21
89 4.7.2. authUser Element . . . . . . . . . . . . . . . . . . . 22
90 4.7.3. a1Digest Element . . . . . . . . . . . . . . . . . . . 22
91 4.7.4. password Element . . . . . . . . . . . . . . . . . . . 22
92 4.8. The 'profileContactUri' Element . . . . . . . . . . . . . 22
93 4.9. The 'profileInfo' Element . . . . . . . . . . . . . . . . 23
94 4.10. Example Profile Dataset . . . . . . . . . . . . . . . . . 23
95 4.11. Merging Property Sets . . . . . . . . . . . . . . . . . . 24
96 4.11.1. Single Numeric Value Merging Algorithm . . . . . . . . 25
97 4.11.2. Multiple Enumerated Value Merging Algorithm . . . . . 25
98 4.11.3. Closest Value First Merging Algorithm . . . . . . . . 26
99 4.12. Common Types . . . . . . . . . . . . . . . . . . . . . . . 27
100 5. Defining Data Sets . . . . . . . . . . . . . . . . . . . . . . 27
101 5.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 27
102 5.2. Property Definitions . . . . . . . . . . . . . . . . . . . 27
103 5.3. Merging Data Sets . . . . . . . . . . . . . . . . . . . . 28
104 6. Candidate Data Sets . . . . . . . . . . . . . . . . . . . . . 28
105 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
106 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
107 8.1. Content-type registration for
108 'application/uaprofile+xml' . . . . . . . . . . . . . . . 29
109 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 30
110 9.1. Changes from draft-petrie-sipping-profile-datasets-04 . . 30
111 9.2. Changes from draft-petrie-sipping-profile-datasets-03 . . 30
112 9.3. Changes from draft-petrie-sipping-profile-datasets-02 . . 31
113 9.4. Changes from draft-petrie-sipping-profile-datasets-01 . . 31
114 9.5. Changes from draft-petrie-sipping-profile-datasets-00 . . 31
115 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
116 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
117 10.2. Informative References . . . . . . . . . . . . . . . . . . 33
118 Appendix A. Relax NG SIP UA Profile Schema . . . . . . . . . . . 33
119 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 38
120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
121 Intellectual Property and Copyright Statements . . . . . . . . . . 40
123 1. Motivation
125 Today all SIP user agent implementers use proprietary means of
126 expressing and delivering user, device, and local network profile
127 information to the user agent. The SIP User Agent Profile Delivery
128 Framework [I-D.ietf-sipping-config-framework] and the Framework for
129 Session SIP Session Policies
130 [I-D.hilt-sipping-session-policy-framework] specify how SIP user
131 agents locate and retrieve profile data specific to the user, the
132 device, and the local network. It is important for SIP User Agents
133 to be able to obtain and use these multiple sources of profile data
134 in order to support a wide range of applications without undue
135 complexity.
137 While these frameworks define the mechanisms for transmitting profile
138 data, they do not define a format for the actual profile data. This
139 document defines the requirements, the default/manditory to support
140 content type for [I-D.ietf-sipping-config-framework], a high level
141 schema for, and guide to how these datasets can be defined. The goal
142 is to enable any SIP user agent to obtain profile data and be
143 functional in a new environment independent of the implementation or
144 model of user agent. The nature of having profile data from four
145 potential sources requires the definition of policies on how to apply
146 the data in an interoperable way across implementations which may
147 have widely varying capabilities.
149 The ultimate objective of the framework described in the SIP User
150 Agent Profile Delivery Framework and this document is to provide a
151 start up experience similar to that of users of an analog telephone.
152 From the point of view of a user, you just plug in an analog
153 telephone and it works (assuming that you have made the right
154 arrangements with your local phone company). There is no end user
155 setup required to make an analog phone work, at least in a basic
156 sense. So the objective here is to be able to take a new SIP user
157 agent out of the box, plug it in or install the software and have it
158 get its profiles without human intervention other than security
159 measures. This is necessary for cost effective deployment of large
160 numbers of user agents. All user agents do not provide telephone
161 capabilities, but the user set up experience goal is applicable to
162 most of the range of user agent capabilities.
164 2. Introduction
165 2.1. Requirements Terminology
167 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
168 "MAY" that appear in this document are to be interpreted as described
169 in RFC 2119[RFC2119].
171 2.2. Profile Data Terminology
173 property - a named configurable characteristic of a user agent. A
174 given property has a well-defined range of possible values. A
175 given property may be defined to have a range of values, allow for
176 simultaneous use of many values (as in a list of allowed
177 possibilities), or a set of related values that collectively form
178 a single profile information item.
179 setting - the binding of a specific value or set of values to a
180 given property.
181 profile - a collection of settings to be applied for a specific
182 user, device, or local network.
183 device - SIP user agent, either software or hardware appliance.
184 This is a logical concept, as there may be no physical dedicated
185 device or it may be part of an assembly of devices. In this
186 document, the terms "user agent" and "device" are interchangeable.
187 user profile - the profile that applies to a specific user. This is
188 best illustrated by the "hotelling" use case - a user has an
189 association for some period of time with a particular device. The
190 user profile is that set of profile data the user wants to
191 associate with that device (e.g. ringtones used when someone calls
192 them, the user's shortcuts).
193 device profile - data profile that applies to a specific device. In
194 the "hotelling" use case, this is the data that is bound to the
195 device itself independent of the user. It relates to specific
196 capabilities of the device and/or preferences of the owner of the
197 device.
198 local network profile - data that applies to the user agent in the
199 context of the local network. This is best illustrated by roaming
200 applications; a new device appears in the local network (or a
201 device appears in a new network, depending on the point of view).
202 The local network profile includes settings and perhaps policies
203 that allow the user agent to function in the local network (e.g.
204 how to traverse NAT or firewall, bandwidth constraints).
205 dataset - a collection of properties.
206 working profile - the set of property values actually set in a SIP
207 User Agent as a result of merging the profiles from all sources;
208 the actual effective profile for the user agent .
210 merging - the operation of resolving overlapping settings from
211 multiple profiles. Overlap occurs when the same property occurs
212 in multiple profiles (e.g. device, user, application, local
213 network).
215 2.3. Overview
217 In this document requirements are specified for containing and
218 expressing profile data for use on SIP user agents. Though much of
219 this can be considered independent of SIP there is one primary
220 requirement that is not well satisfied through more generic profile
221 data mechanisms. SIP User Agent set up requires the agent to merge
222 settings, which may overlap, from potentially four different sources
223 (see [I-D.ietf-sipping-config-framework]); each source must not only
224 be able to provide profile information, but also express policies
225 regarding how the profile settings may be combined with that from
226 other sources.
228 A schema and syntax is defined in this document to specify properties
229 that may be aggregated to construct profiles. The general design
230 philosophy is that many small datasets provide flexibility to the
231 implementer to support the aggregated set that best matches the
232 capability of the user agent. The actual properties are not defined
233 in this document (see [I-D.ietf-sipping-media-policy-dataset] and
234 [reference: Core SIP Dataset]). However, some examples are explored
235 here to illustrate the proposed mechanisms and to validate the
236 requirements.
238 This document defines a set of considerations, syntax and policies
239 that must be specified when defining datasets. These are to help
240 authors of dataset specifications to define datasets that will work
241 in the overall schema defined in this document. The actual
242 specification of these datasets is outside the scope of this
243 document.
245 3. Design Considerations
247 The following section defines some of the design considerations that
248 were taken into account when defining the schema, syntax and policies
249 for generating and applying profile data. Section 3.2.6 describes
250 need for merging of the four dataset sources provided in
251 [I-D.ietf-sipping-config-framework].
253 3.1. Use Cases
255 In the following use case scenarios the device profile is provided by
256 the device owner/manager. The owner/manager may be a service
257 provider, an enterprise or a user administering the device setup.
258 The user is assumed to be the end user operating the user agent to
259 perform SIP functions such as telephony, IM etc. In the scenarios
260 that the user profile is provided, the user profile contains user
261 specific properties that the end user has set directly or indirectly
262 through an administration process. The local network profiles
263 represent the suggested policy behavior that the local network
264 operator would like user agents to adhere to
265 [I-D.hilt-sipping-session-policy-framework]. From a security
266 perspective, the local network operator cannot trust the user agent
267 to follow the local network profile policy. The local network
268 operator must use a means external to the user agent to enforce these
269 policies. The local network profile is intended to express to the
270 user agent, the policies that the user agent should follow if the
271 user agent wants to function properly in the local network.
273 3.1.1. Outbound Proxy Setting
275 First consider the use cases for a simple user agent property: the
276 outbound proxy. It is not likely that the user would want to
277 influence the outbound proxy for SIP signaling. Conceptually an
278 application might wish to use a specific outbound proxy for signaling
279 related to that application. For this use case, assume that the only
280 the device owner/manager or the local network operator are likely to
281 want to set the outbound proxy property. The device profile defines
282 an outbound proxy perhaps so that the device owner/manager can
283 monitor all signaling. The local network operator also defines an
284 outbound proxy because the proxy allows the SIP signaling to get
285 through a NAT or firewall.
287 It seems there are few possible solutions to this conflict resolution
288 problem:
289 o The simple solution is to define a policy where the local network
290 profile overrides the device profile. In this approach the local
291 network profile wins.
292 o A comprehensive solution is to allow the aggregation of the
293 outbound proxies. In this scenario SIP messages would be sent
294 with a pre-populated route set that had two hops. First the
295 outbound proxy set in the local network profile, then the outbound
296 proxy set in the device profile.
298 The aggregation approach is closest to solving the requirements to
299 the use case above. By aggregating the two outbound proxies, the
300 local network provided outbound proxy allows the signaling to get out
301 of the local network and the device profile provided outbound proxy
302 is able to monitor all SIP signaling from the user agent.
304 3.1.2. Codec Settings
306 Use cases for the codec properties are illustrated here as they are
307 likely one of the more complicated sets of properties with respect to
308 merging and constraining across more than one profile. There are
309 reasonable scenarios where requirements can be rationalized that the
310 device, user and local network profiles may each wish to express
311 preferences and constrains of the codec properties. Without getting
312 into details or syntax of the codec properties, it is assumed that
313 codec properties will need to express a codec definition and a
314 preference order. This is the order that these codecs will be put in
315 SDP for codec negotiation purposes.
317 The following scenarios illustrate some possible combinations of
318 sources of codec properties from the device, user and local network
319 profiles. The scenarios identify rationale for providing codec
320 properties in each of the profiles.
322 3.1.2.1. Codec Setting Not Set
324 In the scenario where a device has no profiles or the profiles
325 contain no codec properties, the device will enable a default set and
326 preference order of codecs. The default set and preference order of
327 codecs is a implementer specific choice. In some implementations it
328 is s subset of the codecs supported by the device.
330 3.1.2.2. Codec Set in Device Profile
332 Let us assume a scenario where user agents providing telephony
333 capabilities are deployed. The deployment has very simple
334 requirements such that the user agents have fixed locations and are
335 always associated with the same user. This scenario does not need
336 the separation between the user, device and local network profiles.
337 A single profile would suffice. Another scenario having similar
338 requirements is one where the user and local network profiles do not
339 provide any codec related properties. This might be because the user
340 does not care what codecs are used and the local network does not
341 wish to impose any constraints on the codes used in the network. In
342 the following use case, the device profile is the only source of
343 codec properties.
345 The codecs in the device profile may differ from the set of codecs
346 supported by the device, due to the administrator of the device
347 profile wanting:
348 o To have a uniform set of codecs used across all device types
349 o To exclude the use of a specific codec due to performance issues/
350 concerns
352 The resulting device profile data further will constrain the list of
353 codecs that get applied. In addition, the administrator may want to
354 list the order of which the codecs are to be applied. In this
355 scenario the device profile data will dictate the ordered list of
356 codecs to be applied. The use agent will ignore codec types included
357 in the profile that the user agent does not support.
359 3.1.2.3. Set in Device and User Profiles
361 In the following scenario users are allowed to express a preference
362 over codecs. Users are probably not likely to express specific codes
363 in the form of G.7XX, etc. They are likely to want to express a
364 preference in the form of wideband, normal and low bandwidth. In the
365 following use case, device and user profiles contain codec
366 properties.
368 The user may prefer a higher quality codec to be used, if available.
369 Thereby the user profile data may provide an ordered list of codecs
370 to be applied. The device profile also specifies a list of codecs
371 and a default preference order.
373 The merging of the data sources is as follows:
374 o The ordering of the codecs will be determined from the user
375 profile data, which overrides the codec preference ordering from
376 the device profile data.
377 o The set of codecs that may be applied, are the codecs listed in
378 the user data constrained by the list of codecs from the device
379 profile data.
381 The case in which none of the codecs in the resulting merged profile
382 datasets are supported by the device, the profile data constitutes a
383 misconfiguration between device and user profiles. It may not be
384 possible to successfully establish a session in this case. It is
385 suggested that the user agent provide feedback to the user indicating
386 the misconfiguration. The user agent may also attempt to function in
387 the network by ignoring one or more of the profile constraints.
389 3.1.2.4. Set in Device and Local Profiles
391 In another scenario the user is not allowed or does not care to
392 express codec preferences. The owner/manager of the device defines
393 the set of codecs which may be used on the device along with a
394 preference ordering of codecs. There is no user profile or the user
395 profile contains no codec properties. The local network wishes to
396 define a policy over codec usage in the network. It is not clear
397 there is a requirement that the local network be able to express a
398 preference order. However the network operator is very likely to
399 want to express a set of codecs that can or should not be used. The
400 constraints that the local network operator wishes suggest may relate
401 to the goal of controlling bandwidth or conveying what will work over
402 the available WAN connection. In the following use case, device and
403 local network profiles provide codec properties. The local network
404 may limit the type of codecs that can be applied due to resources
405 available.
407 The merging of the data sources is as follows:
408 o The set of codecs that may be used is the ordered list of codecs
409 from the device profile data, further constrained by the local
410 network profile data.
412 The case in which none of the codecs in the resulting merged profile
413 datasets are supported by the device, the profile data constitutes a
414 misconfiguration between local network and device. It may not be
415 possible to successfully establish a session in this case. It is
416 suggested that the user agent provide feedback to the user indicating
417 the misconfiguration. The user agent may also attempt to function in
418 the network by ignoring one or more of the profile constraints.
420 3.1.2.5. Set in Device, User and Local Profiles
422 In this scenario everyone has an opinion on the codecs to be used.
423 The device owner/manager wishes to define a set of codes based upon
424 best interoperability of known end points in the environment. The
425 user wishes to express preferences in the codecs (e.g. prefers
426 wideband audio). The local network wishes to constrain the codecs
427 based upon bandwidth (e.g. a wireless network with limited local
428 network bandwidth, a SOHO network with dialup connectivity, a small
429 office with shared 256kbps WAN connectivity). In the following
430 scenario, device, user and local network profiles provide codec
431 properties.
433 The merging of the data sources is as follows:
434 o The ordering of the codecs will be determined from the user
435 profile data, which overrides the ordering from the device profile
436 data.
437 o The set of codecs that may be used are the codecs listed in the
438 device profile data, constrained by the list of codecs from the
439 user profile data and further constrained by the list of codecs
440 from the local network profile data.
442 The case in which none of the codecs in the resulting merged profile
443 datasets are supported by the device, the profile data constitutes a
444 misconfiguration between device, user and local network profiles. It
445 may not be possible to successfully establish a session in this case.
446 It is suggested that the user agent provide feedback to the user
447 indicating the misconfiguration. The user agent may also attempt to
448 function in the network by ignoring one or more of the profile
449 constraints.
451 3.1.2.6. Derived Requirements
453 1. A device will have a set of codecs supported, that may be
454 offered. The list of codecs supported by a device may differ
455 from the list of codecs in the device profile data. The list of
456 codecs in the device profile data that get applied is the subset
457 of the codecs supported by the device. Codecs listed in profiles
458 that are not supported by the device are ignored.
459 2. The device profile data will have a default ordered list of
460 codecs, which implies a preference order that may be offered.
461 3. The user profile data may provide an ordered list of user
462 preferred codecs. The ordering of the codecs in the user profile
463 data will override the ordering of the codecs in the device
464 profile data. The user list of codecs may further constrain the
465 list of codecs to be used.
466 4. The local network profile data may provide a list of codecs
467 supported. This list will further constrain the list of codecs
468 that may be offered.
469 5. The application profile data containing codec data will be
470 ignored.
471 6. The profiles need the ability to express codecs that may be used
472 and codecs that should not be used.
474 3.1.3. Transport Protocol Setting
476 This section describes use cases related to the use of the SIP
477 transport protocol settings for a user agent. It is assumed that
478 user agents are configurable to define what transport protocols (e.g.
479 UDP, TCP, TLS) are to be used for the SIP signaling as well as the
480 default order in which to attempt each of the protocol.
482 3.1.3.1. Setting Not Set
484 When none of the profiles are available or the profiles do not
485 specify the SIP transport protocol setting, the device's default
486 signaling transport(s) will be used.
488 3.1.3.2. Set in Device Profile
490 In the following scenario, the device profile is the only source of
491 profile data. The signaling transports contained in the device
492 profile may differ from the set of signaling transports supported by
493 the device. This may be due to the administrator of the device
494 profile wanting:
496 o To have a uniform use of signaling transports used across all
497 device types.
498 o To mandate TLS for security reasons.
499 o To exclude the use of a specific signaling transport due to
500 performance issues/concerns.
501 o To indicate the preferred, default order in which to attempt using
502 each of the transport protocols.
504 This will result in the device profile data further constraining the
505 list of signaling transports that could be used. The highest
506 preference ordered signaling transport from the device profile
507 dataset will be used first.
509 3.1.3.3. Set in Device and User Profiles
511 The following scenario extends the prior case described above. SIP
512 transport protocol properties are provided in both the device and
513 user profiles. Consider that SIP user agents, like email agents, may
514 want to provide the user with options to:
515 o Mandate that secure transport must be used. If secure transport
516 is not possible the user does not want to use the user agent.
517 o Prefer secure transport. Attempt to use secure transport. If
518 secure transport will not work, use which ever transport protocol
519 will make communication work.
521 When the user mandates the use of secure signaling transports only,
522 the user wishes to constrain the available signaling transports to
523 TLS. When indicating a preference to secure transport, the use is
524 specifying a preference order for the use of transport protocols
525 where TLS is the highest priority.
527 Now consider the merging strategy required to accomplish the goals of
528 this use case scenario where the device and user profiles both
529 contain SIP transport protocol properties. The merging of the data
530 sources is as follows:
531 o The set of signaling transports that are allowed to be used is
532 constrained by the device profile data. This is further
533 constrained by the user profile data.
534 o The signaling transports attempted will be those from the merged,
535 constrained list in order of highest to lowest priority.
537 3.1.3.4. Set in Device and Local Profiles
539 In the following scenario, device and local network profile data is
540 available. The local network may have a limited set of signaling
541 transports that it supports due to NAT or firewall constraints.
543 The merging of the data sources is as follows:
545 o The set of signaling transports that may be used is the ordered
546 list of signaling transports from the device profile data, further
547 constrained by the local network profile data.
549 The case in which none of the local network data signaling transports
550 are supported by the device profile data constitutes a
551 misconfiguration between local network and device. The device might
552 not be able to successfully establish a session in this case.
554 3.1.3.5. Derived Requirements
556 1. A device will have a set of signaling transports that it supports
557 (note: one can be a set), with a default signaling transport.
558 2. The set of signaling transports supported by a device may differ
559 from the set of signaling transports in the device profile data.
560 The set of signaling transports in the device profile data is an
561 ordered list, that is a subset of the set of signaling transports
562 supported by the device. This may be due to performance issues
563 associated with one of the signaling transport(s).
564 3. The user profile data may provide a list of preferred signaling
565 transports to be used (e.g., TLS for securing the signaling).
566 4. The local network profile data provides a list of signaling
567 transports supported, and will constrain the set of signaling
568 transports that could be used.
570 3.2. Requirement Descriptions
572 3.2.1. Implementer Extensibility
574 Implementers must be able to differentiate each implementation. In
575 addition, it does not serve user agent owners and administrators well
576 to require an orchestrated upgrade for all user agent implementations
577 and profile delivery servers before a new capability or feature can
578 be supported with the required profile data. Hence one of the most
579 important requirements is to support the ability of implementers to
580 extend specified standard datasets to include additional related
581 features and flexibility. It MUST be possible to extend a dataset
582 without breaking user agents that support that dataset. This may
583 require that user agents ignore parts of a dataset that it does not
584 implement or extensions that it does support.
586 3.2.2. Flexible Capabilities
588 User agents vary quite widely in their capabilities. Some user
589 agents function like traditional telephones. Some user agents
590 support only text messaging. Some user agents support many media
591 types such as video. Some user agents that function like a telephone
592 have a single line, some have large numbers of lines. There is no
593 such thing as one size fits all. It MUST be possible for an
594 implementer to choose which datasets to support based upon the
595 capabilities that are supported by the user agent. The schema for
596 containing the profile data MUST support a profile that contains only
597 the data sets that a user agent supports. This allows the profile
598 delivery server to create small profiles for specific devices.
599 However a user agent SHOULD ignore properties for capabilities that
600 it does not support. This allows the profile delivery server to be
601 ignorant of the capabilities of the device. The degree to which the
602 profile delivery server has intelligence of the user agent
603 capabilities is an implementation choice.
605 3.2.3. XML
607 XML is perhaps not really a requirement, but a solution base upon
608 requirements. However it is hard to ignore the desire to utilize
609 readily available tools to manage and manipulate profile data such as
610 XSLT, XPATH and XCAP. The requirement that should be considered when
611 defining the schema and syntax is that many user agents have limited
612 resources for supporting advanced XML operation. The simplest XML
613 construct possible should be used, that support the required
614 functionality. It is not a requirement that user agents validate the
615 profile XML document. This relieves the requirement that the Relax
616 NG schema defined in this and other datasets documents be enforced on
617 the user agent. The Relax NG schema should not be used to strictly
618 validate profile XML documents. Unknown elements and attributes
619 should be ignored to allow extensions to be supported. Strict
620 enforcement of the Relax NG schema would make it very difficult to
621 deploy new user agents without lock step upgrades of the profile
622 delivery server. Guidelines for the Use of Extensible Markup
623 Language (XML) within IETF Protocols [RFC3470] provides useful
624 information in this regard.
626 3.2.4. Access Control
628 Many user agents (e.g. appliances and softphones running on PCs)
629 provide user interfaces that permit the user to edit properties that
630 are logically part of user, application, device or local network
631 profiles. Operators and administrators would like to be able to
632 specify what an end user can change in those profiles and what an end
633 user is not allowed to change. There may also be sensitive data the
634 user agent requires to function, but that the operator of the system
635 does not want the end user to see. For some properties the system
636 operator may allow the user a fixed set of choices among the
637 supported set of possible values. It MUST be possible to express
638 whether an end user may change a dataset property. It MUST be
639 possible to express that a property should not be made visible to the
640 end user. It MUST be possible to express allowable values or ranges
641 that the end user may change a property to. The access control
642 information SHOULD be optional to the dataset. It might be useful if
643 it was possible to express the access control independent of the
644 properties themselves. The access control specification by itself
645 might be useful to express a general policy that the device owner or
646 local network operator wish to impose.
648 3.2.5. Data Constraints and Range Definition
650 There is a need for property value types such as free form text,
651 token/enumerations, integers, real numbers, etc. Many of these
652 properties will have constrained values as opposed to the range of
653 all possible values. These constrains may be due to protocol
654 definitions, implementation limitations, and/or the desire (e.g. by
655 the user, device owner, local network operator) to impose policy on
656 the user agent. The ability to express the property constraints is
657 useful from the perspective of access control as described in the
658 above section. It is also useful to parameterize a user interface
659 (e.g. on the user agent itself or on the profile delivery server)
660 which provides a facility to modify profile data. It MUST be
661 possible for the schema to specify property constraints as ranges or
662 discrete sets of possible values. These constrains SHOULD be
663 optional to the dataset. It might be useful if it was possible to
664 express the constraints independent of the properties themselves.
665 The constraints without the property values might be used to specify
666 the capabilities of a particular user agent implementation.
668 3.2.6. Support of User, Application, Device, Local Network Sources
670 [I-D.ietf-sipping-config-framework] specifies a mechanism where the
671 user agent retrieves profile data from as many as four different
672 sources. The separation of the user profile facilitates a hotelling
673 capability and the ability to easily re-assign a user to a different
674 device. The separation of the local network profile facilitates
675 properties specific to operating in the local network in a roaming
676 scenario (e.g. outbound proxy or NAT traversal properties). The
677 local network profile may also impose policy as describe in the next
678 section. The device profile facilitates device capability based
679 properties as well as a means for the device owner or manager (e.g.
680 enterprise or service provider) to impose policy.
682 The multiple potential sources of profile data add some complexity to
683 the user agent that must consolidate these separate profiles into a
684 single working profile. It would be simpler if we could define each
685 property as only allowed in one of the profiles. However it overly
686 constrains the profiles and takes away desired functionality such as
687 hotelling, roaming and shared profile management. It would also be
688 simpler if we could define one rule for all profile datasets and
689 properties by which we merge the profile (e.g. local network profile
690 overwrites user profile which overwrites device profile for all
691 data). However this too is overly restrictive and eliminates some
692 very useful functionality.
694 The rules to merge profile datasets needs to be defined for each
695 dataset. In some cases an entire dataset must be considered atomic
696 when merging one profile source with another. In other cases it
697 makes sense to merge profile datasets, aggregating properties from
698 the dataset provided in each of the profiles. It may also be
699 desirable to have the effect of filtering of dataset properties. The
700 desired effect might be for the owner of the device or the local
701 network operator to constrain what values are allowed for properties
702 in the profiles. This may also be the mechanism to facilitate
703 imposing of policy as described in the next section. The operation
704 of resolving overlapping datasets from multiple profiles, regardless
705 of the means or net result, will be referred to as "merging" in this
706 document.
708 A profile must have the means to constrain the merging algorithm.
709 Due to the differences in the desired outcome for each data setting,
710 the merging algorithm is specific to the setting. When defining a
711 property setting, the merging algorithm must also be defined. A few
712 of the more commonly used merging algorithms are defined in this
713 document. Most settings are likely to use the common set defined in
714 this document. However authors of profile datasets may define new
715 algorithms for merging dataset properties (see Section 4.11 and
716 Section 5.3).
718 3.2.7. The Ability to Specify Policy
720 Local network operators would like to impose policy on users and
721 devices operating in their network. There is a need to constrain the
722 operation and require specific behavior in the network. This might
723 be as simple as to get access to the Internet, user agents must use a
724 specified outbound proxy and NAT traversal mechanism. The network
725 might have limited bandwidth such that the operator would like to
726 constrain codecs or media streams to keep the network functional.
727 The local network may provide emergency service behavior or
728 functionality properties that are more specific than those provided
729 by the device or user profile. The examples here focus on
730 constraints to impose policy from the local network. However the
731 facility to impose policy may be equally useful to the user and
732 device profiles.
734 It MUST be possible to impose policy in any of the profile sources
735 that constrains, overwrites or modifies properties provided in
736 datasets from other sources.
738 4. Overall Dataset Schema
740 Notifiers and Subscribers of the event package defined in
741 [I-D.ietf-sipping-config-framework] SHOULD support the content-type:
742 application/uaprofile+xml. The Notifier SHOULD indicate all of the
743 dataset schemas that is supports by listing all of the MIME types for
744 the supported datasets in the SUBSCRIBE request header: Accept. This
745 document defines an Relax NG Schema for that content-type with the
746 namespace: urn:ietf:params:xml:ns:uaprof, for SIP Profile Datasets
747 that provides:
748 o a base element type "setting" from which all settings in other
749 schema definitions inherit (this allows other definitions to
750 specify the content models for ways of combining settings; it is
751 analogous to a C++ virtual base class).
752 o Attributes to the "setting" element that define constraints and
753 other properties used to impose policy that apply to the element
754 value. These attributes are inherited by elements that are
755 derived from the abstract settings element.
756 o A root element for all property sets (the outermost container).
758 The full text of the schema is in Appendix A; the following describes
759 the usage of the schema in defining properties and combining them to
760 construct the working profile of a User Agent.
762 4.1. Data Primitives
764 Each property in a profile data set is defined using XML Schema
765 Datatypes [W3C.REC-xmlschema-2] and Relax NG Schema. A property is
766 modeled by an XML element derived from the "setting" element in the
767 SIP Profile Data Set Schema. The element content is the setting
768 value.
770 Properties consisting of one single value can be expressed using a
771 single XML element. Properties that may consist of multiple values
772 require the use of container elements. A container element is
773 defined for such a property. This container can contain multiple XML
774 elements, which each defines a possible value for that property (see
775 examples in Section 4.5.2).
777 When constructing a property set, the creator of a profile may not be
778 able to know all of the capabilities of the User Agent that will
779 receive that property set. The creator of profile constraints or
780 policies should be aware that a user agent may ignore properties that
781 are unsupported or do not apply to its capabilities.
783 4.2. Use of Namespaces
785 XML namespaces [W3C.REC-xml-names-19990114] provide a means to
786 uniquely identify the elements and datatypes defined in a data set.
787 It is therefore RECOMMENDED that each data set specifies its own
788 namespace. The namespace URIs SHOULD be URNs [RFC2141], using the
789 namespace identifier 'ietf' defined by [RFC2648] and extended by
790 [I-D.mealling-iana-xmlns-registry]. The core schema defined in this
791 document defines the namespace: "urn:ietf:params:xml:ns:uaprof".
792 Profile datasets that extend this schema SHOULD define a new
793 namespace by appending a ":" and a unique name to the
794 "urn:ietf:params:xml:ns:uaprof" namespace. These namespaces MUST be
795 registered with IANA.
797 4.3. The 'propertySet' Element
799 The root element of a property set is "propertySet"; it is the
800 container that is provided to the user agent. The elements contained
801 within a propertySet contain the specific properties which are to be
802 applied to the user agent. The properties may be simple types with a
803 single value, complex types or container elements with a list of
804 properties.
806 4.4. The Abstract 'setting_container' Element
808 The "setting_container" element is the abstract element in which a
809 list of properties which allow mutliple values may be contained.
810 Elements derived from the "setting_container" element may contain
811 zero or more elements derived from the "setting" element. The
812 "setting_container" element has an "excludedPolicy" attribute.
814 4.5. The Abstract 'setting' Element
816 The setting element is the abstract element from which all profile
817 properties or settings shall inherit.
819 The setting element has a number of attributes that provide
820 functionalities, which are generally useful for many properties.
821 These attributes are inherited by properties that are derived from
822 the settings element. This enables the re-use of common
823 functionalities and ensures a common syntax for these elements across
824 different data sets. The following functionalities are provided by
825 attributes of the settings element:
827 o Property Access Control: 'visibility' attribute
828 o Policies: 'policy' attribute
830 Additional attributes are defined in the schema that may used in
831 elements derived from "setting". By default these attributes cannot
832 be set. These attribute must be explicitly added to elements derived
833 from the "setting" element:
835 o Unidirectional Properties: 'direction' attribute
836 o Preferences: 'q' attribute
838 4.5.1. The 'visibility' Attribute
840 The attribute "visibility" is defined on the "setting" element to
841 specify whether or not the user agent is permitted to display the
842 property value to the user. This is used to hide setting values that
843 the profile administrator may not want the user to see or know. The
844 "visibility" attribute has two possible values:
846 o visible: specifies that display of the property value is not
847 restricted. This is the default value of the attribute if it is
848 not specified.
849 o hidden: Specifies that the user agent SHOULD NOT display the
850 property value. Display of the property value may be allowed
851 using special administrative interfaces, but is not appropriate to
852 the ordinary user.
854 4.5.2. The 'policy' Attributes
856 The setting element has an optional 'policy' attribute. The policy
857 attribute is used to define the constraining properties of an
858 element. It defines how the element value is used by an endpoint
859 (e.g. whether it can or can not be used in a session). The following
860 values are defined for the 'policy' attribute:
862 o allow: the value contained in the element is allowed and SHOULD be
863 used in sessions. This is the default value that is used if the
864 'policy' attribute is omitted.
865 o disallow: the value contained in the element is forbidden and
866 SHOULD NOT be used in sessions.
868 The policy attribute can be omitted if the default policy 'allow'
869 applies.
871 OPEN ISSUE: The policy attribute may not be needed for elements
872 outside of a settings_container. Further clarification is needed
873 on this. Using the policy attribute only inside containers would
874 further simplify the specification of profile data.
876 4.5.3. The 'excludedPolicy' Attributes
878 The "setting_container" element has an optional 'excludedPolicy'
879 attribute. This attribute specifies the default policy for all
880 values that are not in the container. Elements that are present in
881 the container have their own 'policy' attribute, which defines the
882 policy for that element. The following values are defined for the
883 'excludedPolicy' attribute:
885 o allow: values not listed in the container are allowed and MAY be
886 used in sessions. This is the default value that is used if the
887 'excludedPolicy' attribute is omitted.
888 o disallow: values not listed in the container are forbidden and
889 MUST NOT be used in sessions.
891 The excludedPolicy attribute can be omitted if the default policy
892 'allow' applies. The following example shows a policy that allows
893 the media type audio and disallows all other media types in sessions
894 (effectively, this construct requires the use of audio):
896
897 audio
898
900 4.5.4. The 'direction' Attribute
902 Some properties are unidirectional and only apply to messages or data
903 streams transmitted into one direction. For example, a property for
904 media streams can be restricted to outgoing media streams only.
905 Unidirectional properties can be expressed by adding a 'direction'
906 attribute to the respective element.
908 The 'direction' attribute can have the following values:
910 o recvonly: the property only applies to incoming messages/streams.
911 o sendonly: the property only applies to outgoing messages/streams.
912 o sendrecv: the property applies to messages/streams in both
913 directions. This is the default value that is used if the
914 'direction' attribute is omitted.
916 4.5.5. The 'q' Attribute
918 It should be possible to express a preference for a certain value, if
919 multiple values are allowed within a property. For example, it
920 should be possible to express that the codecs G.711 and G.729 are
921 allowed, but G.711 is preferred. Preferences can be expressed by
922 adding a 'q' attribute to a property element. Elements derived from
923 the "setting" element for which multiple occurrences and values are
924 allowed SHOULD have a "q" attribute if the order is significant.
925 Typically these elements are contained in an element derived from the
926 "setting_container" element. The 'q' attribute is only meaningful if
927 the 'policy' attribute set to 'allowed'. It must be ignored in all
928 other cases.
930 An element with a higher 'q' value is preferred over one with a lower
931 'q' value. 'q' attribute values range from 0 to 1. The default value
932 is 0.5.
934 4.6. The 'profileUri' Element
936 The element contains the URI of this profile on the
937 profile server. The value contained in the profileUri element may be
938 different than the URI subscribe to when retrieving this profile.
939 When the user agent retrieves a profile where the profileUri is
940 different than the subscribe to URI, the user agent SHOULD
941 unsubscribe to the current URI and then subscribe to the new URI.
943 The element is optional and MAY occur only once inside a
944 element. The profileUri element is specific to the
945 local-network, device, user or application profile in which it
946 occurs. It has no meaning outside of the profile in which it occurs
947 and SHOULD NOT be merged.
949 4.7. The 'profileCredential' Element
951 The element contains the digest authentication
952 information that SHOULD be used for authentication for the profile
953 subscription via SIP or profile retrieval via HTTP, HTTPS, etc. The
954 profileCredential element is optional and MAY occur only once inside
955 a propertySet element. The profileCredential element is specific to
956 the local-network, device, user or application profile in which it
957 occurs. It has no meaning outside of the profile in which it occurs
958 and SHOULD NOT be merged. The profileCredential element MUST contain
959 exactly one of each of the elements: realm, authUser and one of
960 either a1Digest or password.
962 4.7.1. realm Element
964 The realm element contains the string that defines the realm to which
965 this credential pertains. The value of the realm element is the same
966 as the realm parameter in the [RFC2617] headers: WWW-Authenticate,
967 Authorization and the SIP [RFC3261] headers: Proxy-Authenticate and
968 Proxy-Authorization. If a match of the realm value is found, the
969 user agent uses the values in the authUser and a1Digest elements
970 contained in the profileCredential element. Exactly one realm
971 element MUST be contained in a profileCredential element. A wildcard
972 of "*" MAY be used as the realm value in which case the user agent
973 MUST calculate the A1 DIGEST for the realm given in the
974 authentication challenge. If the wildcard is given for the realm,
975 the clear text form of the password contained in the password element
976 MUST also be used.
978 4.7.2. authUser Element
980 The authUser element contains the string value of the "username"
981 parameter which SHOULD be used in Authorization and Proxy-
982 Authorization request headers when retrying a request that was
983 challenged for authentication. Exactly one authUser element SHOULD
984 be contained in a profileCredential element.
986 4.7.3. a1Digest Element
988 The a1Digest element contains a string with the value of the A1
989 digest of the username, realm and password as defined in [RFC2617].
990 At most one a1Digest element MUST be contained in a profileCredential
991 element. The a1Digest element MUST NOT exist in a profileCredential
992 element containing a password element. The username and realm used
993 to construct the value of the a1Digest element MUST match the values
994 of the realm and authUser elements contained in the profileCredential
995 element with the a1Digest element.
997 4.7.4. password Element
999 The password element contains the clear text password for use with
1000 DIGEST Authentication [RFC2617]. At most one password MUST be
1001 contained in a profileCredential element. The password element MUST
1002 NOT exist in a profileCredential element containing a a1Digest
1003 element. The user agent uses this password along with the realm and
1004 authUser elements to calculate the A1 digest used for DIGEST
1005 Authentication.
1007 4.8. The 'profileContactUri' Element
1009 The element contains a contact URI (e.g. a SIP,
1010 HTTP URI or email address) under which the issuer of this profile can
1011 be reached. The contact element may, for example, contain the
1012 address of a support hotline.
1014 The element is optional and MAY occur multiple
1015 times inside a element. Multiple instances of the
1016 profileContactUri element allow multiple URI schemes to be provided
1017 for contact information. The user agent MAY use the URI contained
1018 profile-contact-info element which has a URI scheme that the user
1019 agent supports and can make work to provide support help for the
1020 profile. The user agent MAY provide the URIs to the user to contact
1021 the creator of the profile through other communication channels. The
1022 profileContactUri element is specific to the local-network, device,
1023 user or application profile in which it occurs. It has no meaning
1024 outside of the profile in which it occurs and SHOULD NOT be merged.
1026 4.9. The 'profileInfo' Element
1028 The element provides a short textual description of the
1029 property that should be intelligible to the human user. This element
1030 may, for example, contain information about the nature of this
1031 profile, such as "Access Network Profile". The text in the
1032 element is in particular be helpful when a user needs
1033 to decide whether or not to use a newly downloaded profile or when
1034 problems with a profile (e.g. a policy conflict) occur. A user agent
1035 MAY display this information in these cases.
1037 The element is optional and MAY occur only once inside
1038 a element. The profileInfo element is specific to the
1039 local-network, device, user or application profile in which it
1040 occurs. It has not meaning outside of the profile in which it occurs
1041 and SHOULD NOT be merged.
1043 4.10. Example Profile Dataset
1045 The following XML example shows a SIP Profile Dataset with example
1046 extension setting elements: ddd, foo, bar, boo, containerElement and
1047 setting container elements: myContainer, myContainer1, myContainer2
1048 and container3.
1050
1051
1052 sip:a1b2c3d4e5f6@example.com
1053
1054 example.com
1055 fred
1056 b6b577fd12aa7e1df8d60735ef56fc2e
1057
1058
1059 tel:+16175551212
1060 sip:411@example.com
1061
1062 http:example.com/sipProfile.html
1063
1064
1065 This is an example profile from example.com
1066
1067 fff
1068
1070
1071
1073
1074
1075 aaa
1076 bbb
1077 ccc
1078
1079 ggg
1080
1081
1082
1083
1084
1085 111
1086 222
1087 333
1088
1089
1091 4.11. Merging Property Sets
1093 A UA may receive property sets from multiple sources, which need to
1094 be merged into a single combined document the UA can work with.
1096 Properties that have a single value (e.g. the maximum bandwidth
1097 allowed) require that a common value is determined for this property
1098 during the merging process. The merging rules for determining this
1099 value need to be defined individually for each element in the schema
1100 definition. Properties that allow multiple values (i.e. property
1101 containers) need to be merged by combining the values from the
1102 different data sets. The following sections describe common merging
1103 algorithms. A data set definition may refer to these algorithms.
1105 4.11.1. Single Numeric Value Merging Algorithm
1107 A general merging rule for elements with numeric values is to select
1108 the largest or the smallest value. For example, a merging rule for a
1109 element would be to select the smallest value from
1110 the values that are in the competing data sets.
1112 4.11.2. Multiple Enumerated Value Merging Algorithm
1114 Multiple values in property containers are merged by combining the
1115 values from each of the competing data sets. This is accomplished by
1116 copying the elements from each property container into the merged
1117 container. Elements with identical values are only copied once. The
1118 'policy' attribute of two elements with the same value is adjusted
1119 during the merging process according to Table 1. If an element
1120 exists only in one property container, then the default policy of the
1121 other container (i.e. the excludedPolicy) is used when accessing
1122 Table 1. For example, if an element is disallowed in one data set
1123 and the element is not contained in the other data set but the
1124 default policy is allowed for that data set, then the values
1125 disallowed and allowed are used to access Table 1. Consequently, the
1126 element will be disallowed in the merged data set. Finally, the
1127 excludedPolicy attributes of the containers are also merged using
1128 Table 1. In addition to these merging rules, each schema may define
1129 specific merging rules for each property container.
1131 set 1 \ set 2 | allow | disallow
1132 --------------+----------+----------
1133 allow | allow | disallow
1134 disallow | disallow | disallow
1136 Table 1: merging policies.
1138 The following example illustrates the merging process for two data
1139 sets. All elements are merged into one container and the policy
1140 attributes are adjusted according to Table 1. The merged container
1141 has the default policy disallow, which is determined using Table 1.
1142 The entry for PCMA in the merged data set is redundant since it has
1143 the default policy.
1145 Data set 1:
1146
1147 PCMA
1148
1150 Data set 2:
1151
1152 PCMA
1153 G729
1154
1156 Merged data set:
1157
1158 PCMA
1159 G729
1160
1162 Some constellations of policy attributes result in an illegal merged
1163 data set. They constitute a conflict that can not be resolved
1164 automatically. For example, two data sets may define two non-
1165 overlapping sets of allowed audio codecs and both disallow all other
1166 codes. The resulting merged set of codecs would be empty, which is
1167 illegal according to the schema definition of the codecs element. If
1168 the use of these properties is enforced by both networks, the UA may
1169 experience difficulties or may not be able to set up a session at
1170 all.
1172 The combined property set MUST again be valid and well-formed
1173 according to the schema definitions. A conflict occurs if the
1174 combined property set is not a well-formed document after the merging
1175 process is completed.
1177 4.11.3. Closest Value First Merging Algorithm
1179 Some properties require that the values from different data sets are
1180 ordered based on the origin of the data set during the merging
1181 process. Property values that come from a domain close to the user
1182 agent take precedence over values that were in a data set delivered
1183 by a remote domain. This order can be used, for example, to select
1184 the property value from the closest domain. In many cases, this is
1185 the local domain of the user agent. For example, the URI of an
1186 outbound proxy could be merged this way. This order can also be used
1187 to generate an ordered list of property values during the merging
1188 process. For example, multiple values for media intermediaries can
1189 be ordered so that the closest media intermediary is traversed before
1190 the second closest intermediary and so on.
1192 This merging algorithm requires that the source of a data set is
1193 considered.
1195 If property sets are delivered through the configuration framework
1196 [I-D.ietf-sipping-config-framework], the value received through a
1197 subscription using the "local-network" profile-type takes precedence
1198 over values received through other profile-type subscriptions.
1200 OPEN ISSUE: Can we define an order for 'device', 'user', and
1201 'application' profiles?
1203 The session-specific policy mechanism
1204 [I-D.hilt-sipping-session-policy-framework] provides an order among
1205 policy servers. This order is based on the order, in which a SIP
1206 message traverses the network, starting with the closest domain.
1207 This order can directly be used to order property values as described
1208 above.
1210 4.12. Common Types
1212 The schema also defines a set of common types that are used in
1213 defining data sets (e.g. DataIpPort). [Need to document common
1214 types.]
1216 5. Defining Data Sets
1218 This section covers several issues that should be take into
1219 consideration when specifying new data set schemas. This is intended
1220 to be a guide to authors writing specifications defining a new data
1221 set schema or extensions to existing ones.
1223 5.1. Namespace
1225 It is RECOMMENDED that a data set defines a new XML namespace
1226 [W3C.REC-xml-names-19990114] to scope all of the properties that are
1227 defined in the name space.
1229 5.2. Property Definitions
1231 The properties defined in a data set schema may be simple (i.e.
1232 having a single value) or they may be complex (i.e. a container with
1233 multiple values). Each property in the data set SHOULD inherit from
1234 the "setting" element. Complex properties and all of their child
1235 elements each should inherit from "setting" as well.
1237 A data set specification should contain a section which defines the
1238 meaning of all of the properties contained in the data set. The
1239 objective is to define the property such that implementers have a
1240 clear definition and semantics to interpret properties in a
1241 consistent way. User agents not only need to use the same profile
1242 content, they need to apply the properties in a consistent way to
1243 achieve true interoperability.
1245 The following information should be defined for each property in a
1246 data set:
1247 o description: describe the meaning and application of the property.
1248 o cardinality: define how many instances of this property element
1249 may occur in a data set (e.g. zero, one or many) as well as its
1250 relationship to any other properties in this or other data sets.
1251 o default value: define the default value of this property if it is
1252 not set. Describe if the default is different if the property is
1253 present and not set vs. completely absent from the data set.
1254 Define if the default varies in relation to another property.
1256 5.3. Merging Data Sets
1258 User agents may receive data sets from multiple sources. They need
1259 to merge these data sets in order to create an overall data set they
1260 can work with. Collisions on data sets may occur if multiple sources
1261 provide different values for the same properties. These collisions
1262 need to be resolved during the merging process.
1264 A data set schema MUST define rules for merging data sets from
1265 different sources for each property that is defined. Considerations
1266 for merging data sets are discussed in Section 4.11. A data set
1267 schema must define if and how these consideration apply and MAY
1268 define alternative merging rules for specific settings. A data set
1269 schema must also identify combinations of properties that constitute
1270 a conflict that can't resolved. It may provide additional guidelines
1271 for the behavior of a user agent in these cases.
1273 6. Candidate Data Sets
1275 The following sections name some of the candidate data sets that are
1276 or may be defined. These data sets can be aggregated to form
1277 profiles appropriate to the capabilities of a user agent
1278 implementation.
1280 o SIP Protocol Data Set: the lowest common denominator set of
1281 properties common to all SIP user agents of any capability. A
1282 schema covering the elements of this data set can be found in
1283 [I-D.petrie-sipping-sip-dataset].
1284 o Media Data Set: this data set contains media related policies. A
1285 schema covering the elements of this data set can be found in
1286 [I-D.ietf-sipping-media-policy-dataset].
1288 o Identity Data Set: AORs and lines (see
1289 [I-D.petrie-sipping-identity-dataset])
1290 o HTTP Protocol Data Set: server settings. Proxy for clients.
1291 o NAT Traversal Data Set: settings for STUN, TURN etc.
1292 o SIP Digit Maps Data Set:
1293 [I-D.petrie-sipping-voip-features-dataset]
1294 o VoIP Features: [I-D.petrie-sipping-voip-features-dataset]
1295 o Address Book:
1296 o Buddy List:
1298 7. Security Considerations
1300 Security is mostly a delivery problem. The delivery framework SHOULD
1301 provide a secure means of delivering the profile data as it may
1302 contain sensitive data that would be undesirable if it were stolen or
1303 sniffed. Storage of the profile on the profile delivery server and
1304 user agent is an implementation problem. The profile delivery server
1305 and the user agent SHOULD provide protection that prevents
1306 unauthorized access of the profile data. The profile delivery server
1307 and the user agent SHOULD enforce the access control policies defined
1308 in the profile data sets if present.
1309 [The point of the access control construct on the data set is to
1310 provide some security policy on the visibility and ability to
1311 change sensitive properties. Does the access control mechanism
1312 also create a security problem where the local network can set or
1313 hide properties from the user?]
1315 Some transport mechanisms for delivery of the profile data do not
1316 provide a secure means of delivery. In addition some user agents may
1317 not have the resources to support the secure mechanism used for
1318 delivery (e.g. TLS).
1320 8. IANA Considerations
1322 XML name space registration: urn:ietf:params:xml:ns:uaprof
1324 8.1. Content-type registration for 'application/uaprofile+xml'
1326 To: ietf-types@iana.org
1327 Subject: Registration of MIME media type application/uaprofile+xml
1328 MIME media type name: application
1329 MIME subtype name: uaprofile+xml
1330 Required parameters: (none)
1331 Optional parameters: charset Indicates the character encoding of
1332 enclosed XML. Default is UTF-8.
1333 Encoding considerations: Uses XML, which can employ 8-bit
1334 characters, depending on the character encoding used. See RFC
1335 3023 [RFC 3023], section 3.2.
1336 Security considerations: This content type is designed to carry SIP
1337 user agent profile data, which may be considered private
1338 information. Appropriate precautions should be adopted to limit
1339 disclosure of this information.
1340 Interoperability considerations: This content type provides a common
1341 format for exchange of SIP user agent profile information.
1342 Published specification: RFC XXXX (Note to RFC Editor: Please fill
1343 in XXXX with the RFC number of this specification)
1344 Applications which use this media type: SIP user agents and profile
1345 delivery servers.
1346 Additional information: Magic number(s): File extension(s):
1347 Macintosh File Type Code(s):
1348 Person & email address to contact for further information: Daniel
1349 Petrie EMail: dan.ietf AT sipez DOT com
1350 Intended usage: LIMITED USE
1351 Author/Change controller: This specification is a proposed work item
1352 of the IETF SIPPING working group, with mailing list address:
1353 sipping@ietf.edu.
1354 Other information: This media type is a specialization of
1355 application/xml [RFC 3023], and many of the considerations
1356 described there also apply to application/uaprof+xml.
1358 9. Change History
1360 [[RFC Editor: Please remove this entire section upon publication as
1361 an RFC.]]
1363 9.1. Changes from draft-petrie-sipping-profile-datasets-04
1365 Re-reved and activated draft
1367 9.2. Changes from draft-petrie-sipping-profile-datasets-03
1369 Converted the XML schema to use Relax NG and created a valid schema.
1371 Defined XML name space for schema: "urn:ietf:params:xml:ns:uaprof"
1373 Defined mime type: application/uaprofile+xml to be used as default
1374 content type for the configuration framework.
1376 Changed names of elements, attributes and other data types which
1377 contained "-" or "_" to use camel case.
1379 Added password element so that credential can contain either A1
1380 digest or clear text password as the clear text password is required
1381 by the user agent in some cases (e.g. http GET) or to wildcard the
1382 realm.
1384 9.3. Changes from draft-petrie-sipping-profile-datasets-02
1386 Removed "mandatory" policy attribute value to simplify use and
1387 profile merging issues.
1389 Session Independent Policy draft was split into separate media
1390 dataset draft and policy drafts. Fixed references and information in
1391 this draft to reflect the two drafts.
1393 Added concrete properties contained in elements: profileUri,
1394 profileCredential, profileContactUri and profileInfo. Prior to this
1395 draft, there were only abstract elements defined in this draft.
1396 These elements have been added to contain information that is
1397 specific to the profile and are independent of the specific profile
1398 datasets contained in the profile.
1400 Split references into normative and informative sections.
1402 Numerous editorial changes
1404 9.4. Changes from draft-petrie-sipping-profile-datasets-01
1406 Split out the core SIP Protocol dataset into a separate draft.
1408 Schema changes: created setting_container, added q and direction
1409 attributes along with other tweaks to the schema.
1411 Better integration and coordination with
1412 [I-D.ietf-sipping-media-policy-dataset]. The media/codec dataset is
1413 now completely contained in the policy draft.
1415 9.5. Changes from draft-petrie-sipping-profile-datasets-00
1417 Added use case scenarios for codecs, SIP transport protocol and
1418 outbound proxy to better illustrate requirements. Some of the
1419 derived requirements are listed with the use cases.
1421 Added settings element attributes "policy" and "visibility" to
1422 provide merging constraints and access control capability. Removed
1423 the element based merging constraints using the: forbid, set_any,
1424 set_all and set_one elements. This greatly simplifies the degree of
1425 XML operations required to perform the request merging.
1427 Defined default merging policy and profile source precedence along
1428 with the option for different policies to be describe in specific
1429 settings definition documents.
1431 Added example merging with XML profiles from device and user for the
1432 SIP transport protocol.
1434 10. References
1436 10.1. Normative References
1438 [I-D.hilt-sipping-session-policy-framework]
1439 Hilt, V., "A Framework for Session Initiation Protocol
1440 (SIP) Session Policies",
1441 draft-hilt-sipping-session-policy-framework-01 (work in
1442 progress), March 2006.
1444 [I-D.ietf-sipping-config-framework]
1445 Channabasappa, S., "A Framework for Session Initiation
1446 Protocol User Agent Profile Delivery",
1447 draft-ietf-sipping-config-framework-14 (work in progress),
1448 November 2007.
1450 [I-D.mealling-iana-xmlns-registry]
1451 Mealling, M., "The IETF XML Registry",
1452 draft-mealling-iana-xmlns-registry-05 (work in progress),
1453 June 2003.
1455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1456 Requirement Levels", BCP 14, RFC 2119, March 1997.
1458 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
1459 Leach, P., Luotonen, A., and L. Stewart, "HTTP
1460 Authentication: Basic and Digest Access Authentication",
1461 RFC 2617, June 1999.
1463 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
1464 A., Peterson, J., Sparks, R., Handley, M., and E.
1465 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
1466 June 2002.
1468 [W3C.REC-xml-names-19990114]
1469 Hollander, D., Bray, T., and A. Layman, "Namespaces in
1470 XML", W3C REC REC-xml-names-19990114, January 1999.
1472 [W3C.REC-xmlschema-1]
1473 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
1474 "XML Schema Part 1: Structures", W3C REC-xmlschema-1,
1475 May 2001, .
1477 [W3C.REC-xmlschema-2]
1478 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
1479 W3C REC-xmlschema-2, May 2001,
1480 .
1482 10.2. Informative References
1484 [I-D.ietf-sipping-media-policy-dataset]
1485 Hilt, V., "A User Agent Profile Data Set for Media
1486 Policy", draft-ietf-sipping-media-policy-dataset-04 (work
1487 in progress), May 2007.
1489 [I-D.petrie-sipping-identity-dataset]
1490 Petrie, D., "The Session Initiation Protocol User Agent
1491 Identity Profile Data Set",
1492 draft-petrie-sipping-identity-dataset-01 (work in
1493 progress), October 2006.
1495 [I-D.petrie-sipping-sip-dataset]
1496 Petrie, D., "The Core Session Initiation Protocol User
1497 Agent Protocol Data Set",
1498 draft-petrie-sipping-sip-dataset-02 (work in progress),
1499 October 2006.
1501 [I-D.petrie-sipping-voip-features-dataset]
1502 Petrie, D., "The Session Initiation Protocol User Agent
1503 VoIP Features Data Set",
1504 draft-petrie-sipping-voip-features-dataset-01 (work in
1505 progress), October 2006.
1507 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
1509 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
1510 August 1999.
1512 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for
1513 the Use of Extensible Markup Language (XML)
1514 within IETF Protocols", BCP 70, RFC 3470, January 2003.
1516 Appendix A. Relax NG SIP UA Profile Schema
1517
1518
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637 [0-9,a-f]{32,32}
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648 sip:.*
1649
1650
1651 sips:.*
1652
1653
1654
1655
1656
1657
1658 "?.*"?<?sip:.*
1659
1660
1661 "?.*"?<?sips:.*
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697 allow
1698 disallow
1699
1700
1701
1702
1703
1704
1705 visible
1706 hidden
1707
1708
1709
1710
1711
1712
1713
1714 sendrecv
1715 sendonly
1716 recvonly
1717
1718
1719
1720
1721
1722
1723
1724 0
1725 1
1726
1727
1728
1729
1730
1731 1
1732 65535
1733
1734
1735
1736
1737
1738 UDP
1739 TCP
1740 TLS
1741 DTLS
1742 SCTP
1743
1744
1745
1747 Appendix B. Acknowledgments
1748 Authors' Addresses
1750 Daniel Petrie
1751 SIPez LLC.
1752 34 Robbins Rd.
1753 Arlington, MA 02476
1754 US
1756 Phone: +1 617 273 4000
1757 Email: dan.ietf AT SIPez DOT com
1758 URI: http://www.SIPez.com/
1760 Sumanth Channabasappa
1761 CableLabs
1762 858 Coal Creek Circle
1763 Louisville, CO 80027
1764 US
1766 Phone:
1767 Email: sumanth@cablelabs.com
1768 URI:
1770 Sam Ganesan
1771 Motorola
1772 80 Central Street
1773 Boxborough, MA 01719
1774 US
1776 Phone:
1777 Email: sam.ganesan@motorola.com
1778 URI:
1780 Full Copyright Statement
1782 Copyright (C) The IETF Trust (2007).
1784 This document is subject to the rights, licenses and restrictions
1785 contained in BCP 78, and except as set forth therein, the authors
1786 retain all their rights.
1788 This document and the information contained herein are provided on an
1789 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1790 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1791 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1792 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1793 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1794 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1796 Intellectual Property
1798 The IETF takes no position regarding the validity or scope of any
1799 Intellectual Property Rights or other rights that might be claimed to
1800 pertain to the implementation or use of the technology described in
1801 this document or the extent to which any license under such rights
1802 might or might not be available; nor does it represent that it has
1803 made any independent effort to identify any such rights. Information
1804 on the procedures with respect to rights in RFC documents can be
1805 found in BCP 78 and BCP 79.
1807 Copies of IPR disclosures made to the IETF Secretariat and any
1808 assurances of licenses to be made available, or the result of an
1809 attempt made to obtain a general license or permission for the use of
1810 such proprietary rights by implementers or users of this
1811 specification can be obtained from the IETF on-line IPR repository at
1812 http://www.ietf.org/ipr.
1814 The IETF invites any interested party to bring to its attention any
1815 copyrights, patents or patent applications, or other proprietary
1816 rights that may cover technology that may be required to implement
1817 this standard. Please address the information to the IETF at
1818 ietf-ipr@ietf.org.
1820 Acknowledgment
1822 Funding for the RFC Editor function is provided by the IETF
1823 Administrative Support Activity (IASA).