idnits 2.17.1
draft-petrie-sipping-profile-datasets-03.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 21.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 1664.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1641.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1648.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1654.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 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 (October 23, 2005) is 6760 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: 'TBD' is mentioned on line 1239, but not defined
== Unused Reference: 'I-D.hilt-sipping-session-policy-framework' is defined
on line 1296, but no explicit reference was found in the text
== Unused Reference: 'I-D.petrie-sipping-identity-dataset' is defined on
line 1347, but no explicit reference was found in the text
== Outdated reference: A later version (-01) exists of
draft-hilt-sipping-session-policy-framework-00
-- 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-07
** 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-00
== Outdated reference: A later version (-02) exists of
draft-petrie-sipping-identity-dataset-00
== Outdated reference: A later version (-03) exists of
draft-petrie-sipping-sip-dataset-00
== Outdated reference: A later version (-02) exists of
draft-petrie-sipping-voip-features-dataset-00
-- Obsolete informational reference (is this intentional?): RFC 2141
(Obsoleted by RFC 8141)
Summary: 4 errors (**), 0 flaws (~~), 12 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 Expires: April 26, 2006 S. Lawrence
5 Pingtel Corp.
6 M. Dolly
7 AT&T Labs
8 V. Hilt
9 Bell Labs/Lucent Technologies
10 October 23, 2005
12 A Schema and Guidelines for Defining Session Initiation Protocol User
13 Agent Profile Data Sets
14 draft-petrie-sipping-profile-datasets-03.txt
16 Status of this Memo
18 By submitting this Internet-Draft, each author represents that any
19 applicable patent or other IPR claims of which he or she is aware
20 have been or will be disclosed, and any of which he or she becomes
21 aware will be disclosed, in accordance with Section 6 of BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that
25 other groups may also distribute working documents as Internet-
26 Drafts.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 The list of current Internet-Drafts can be accessed at
34 http://www.ietf.org/ietf/1id-abstracts.txt.
36 The list of Internet-Draft Shadow Directories can be accessed at
37 http://www.ietf.org/shadow.html.
39 This Internet-Draft will expire on April 26, 2006.
41 Copyright Notice
43 Copyright (C) The Internet Society (2005).
45 Abstract
47 This document defines the requirements and a format for SIP user
48 agent profile data. An overall schema is specified for the
49 definition of profile data sets. The schema also provides for
50 expressing constraints for how multiple sources of profile data are
51 to be combined. This document provides a guide to considerations,
52 policies and syntax for defining data sets to be included in profile
53 data. It also explores some specific data sets to test the
54 requirements, assumptions and syntax.
56 Table of Contents
58 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
60 2.1. Requirements Terminology . . . . . . . . . . . . . . . . . 4
61 2.2. Profile Data Terminology . . . . . . . . . . . . . . . . . 5
62 2.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
63 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 6
64 3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6
65 3.1.1. Outbound Proxy Setting . . . . . . . . . . . . . . . . 7
66 3.1.2. Codec Settings . . . . . . . . . . . . . . . . . . . . 7
67 3.1.3. Transport Protocol Setting . . . . . . . . . . . . . . 11
68 3.2. Requirement Descriptions . . . . . . . . . . . . . . . . . 13
69 3.2.1. Implementer Extensibility . . . . . . . . . . . . . . 13
70 3.2.2. Flexible Capabilities . . . . . . . . . . . . . . . . 13
71 3.2.3. XML . . . . . . . . . . . . . . . . . . . . . . . . . 14
72 3.2.4. Access Control . . . . . . . . . . . . . . . . . . . . 14
73 3.2.5. Data Constraints and Range Definition . . . . . . . . 14
74 3.2.6. Support of User, Application, Device, Local
75 Network Sources . . . . . . . . . . . . . . . . . . . 15
76 3.2.7. The Ability to Specify Policy . . . . . . . . . . . . 16
77 4. Overall Data Set Schema . . . . . . . . . . . . . . . . . . . 16
78 4.1. Data Primitives . . . . . . . . . . . . . . . . . . . . . 17
79 4.2. Use of Namespaces . . . . . . . . . . . . . . . . . . . . 17
80 4.3. The 'property_set' Element . . . . . . . . . . . . . . . . 17
81 4.4. The Abstract 'setting_container' Element . . . . . . . . . 18
82 4.5. The Abstract 'setting' Element . . . . . . . . . . . . . . 18
83 4.5.1. The 'visibility' Attribute . . . . . . . . . . . . . . 18
84 4.5.2. The 'policy' Attributes . . . . . . . . . . . . . . . 19
85 4.5.3. The 'excluded_policy' Attributes . . . . . . . . . . . 19
86 4.5.4. The 'direction' Attribute . . . . . . . . . . . . . . 20
87 4.5.5. The 'q' Attribute . . . . . . . . . . . . . . . . . . 20
88 4.6. The 'profile-uri' Element . . . . . . . . . . . . . . . . 20
89 4.7. The 'profile-credential' Element . . . . . . . . . . . . . 21
90 4.7.1. realm Element . . . . . . . . . . . . . . . . . . . . 21
91 4.7.2. auth_user Element . . . . . . . . . . . . . . . . . . 21
92 4.7.3. a1_digest Element . . . . . . . . . . . . . . . . . . 21
93 4.8. The 'profile-contact-uri' Element . . . . . . . . . . . . 21
94 4.9. The 'profile-info' Element . . . . . . . . . . . . . . . . 22
95 4.10. Merging Property Sets . . . . . . . . . . . . . . . . . . 22
96 4.10.1. Single Numeric Value Merging Algorithm . . . . . . . . 22
97 4.10.2. Multiple Enumerated Value Merging Algorithm . . . . . 23
98 4.10.3. Closest Value First Merging Algorithm . . . . . . . . 24
99 4.11. Common Types . . . . . . . . . . . . . . . . . . . . . . . 25
100 5. Defining Data Sets . . . . . . . . . . . . . . . . . . . . . . 25
101 5.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 25
102 5.2. Property Definitions . . . . . . . . . . . . . . . . . . . 25
103 5.3. Merging Data Sets . . . . . . . . . . . . . . . . . . . . 26
104 6. Candidate Data Sets . . . . . . . . . . . . . . . . . . . . . 26
105 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
106 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
107 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 27
108 9.1. Changes from draft-petrie-sipping-profile-datasets-02 . . 27
109 9.2. Changes from draft-petrie-sipping-profile-datasets-01 . . 28
110 9.3. Changes from draft-petrie-sipping-profile-datasets-00 . . 28
111 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
112 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
113 10.2. Informative References . . . . . . . . . . . . . . . . . . 30
114 Appendix A. SIP UA Profile Schema . . . . . . . . . . . . . . . . 30
115 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 35
116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
117 Intellectual Property and Copyright Statements . . . . . . . . . . 37
119 1. Motivation
121 Today all SIP user agent implementers use proprietary means of
122 expressing and delivering user, device, and local network profile
123 information to the user agent. The SIP User Agent Profile Delivery
124 Framework [I-D.ietf-sipping-config-framework] and the Framework for
125 Session SIP Session Policies [I-D.hilt-sipping-session-policy-
126 framework] specify how SIP user agents locate and retrieve profile
127 data specific to the user, the device, and the local network. It is
128 important for SIP User Agents to be able to obtain and use these
129 multiple sources of profile data in order to support a wide range of
130 applications without undue complexity.
132 While these frameworks define the mechanisms for transmitting profile
133 data, they do not define a format for the actual profile data. This
134 document proposes the requirements, a high level schema for, and
135 guide to how these data sets can be defined. The goal is to enable
136 any SIP user agent to obtain profile data and be functional in a new
137 environment independent of the implementation or model of user agent.
138 The nature of having profile data from four potential sources
139 requires the definition of policies on how to apply the data in an
140 interoperable way across implementations which may have widely
141 varying capabilities.
143 The ultimate objective of the framework described in the SIP User
144 Agent Profile Delivery Framework and this document is to provide a
145 start up experience similar to that of users of an analog telephone.
146 From the point of view of a user, you just plug in an analog
147 telephone and it works (assuming that you have made the right
148 arrangements with your local phone company). There is no end user
149 setup required to make an analog phone work, at least in a basic
150 sense. So the objective here is to be able to take a new SIP user
151 agent out of the box, plug it in or install the software and have it
152 get its profiles without human intervention other than security
153 measures. This is necessary for cost effective deployment of large
154 numbers of user agents. All user agents do not provide telephone
155 capabilities, but the user set up experience goal is applicable to
156 most of the range of user agent capabilities.
158 2. Introduction
160 2.1. Requirements Terminology
162 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
163 "MAY" that appear in this document are to be interpreted as described
164 in RFC 2119[RFC2119].
166 2.2. Profile Data Terminology
168 property - a named configurable characteristic of a user agent. A
169 given property has a well-defined range of possible values. A
170 given property may be defined to have a range of values, allow for
171 simultaneous use of many values (as in a list of allowed
172 possibilities), or a set of related values that collectively form
173 a single profile information item.
174 setting - the binding of a specific value or set of values to a given
175 property.
176 profile - a collection of settings to be applied for a specific user,
177 device, or local network.
178 device - SIP user agent, either software or hardware appliance. This
179 is a logical concept, as there may be no physical dedicated device
180 or it may be part of an assembly of devices. In this document,
181 the terms "user agent" and "device" are interchangeable.
182 user profile - the profile that applies to a specific user. This is
183 best illustrated by the "hotelling" use case - a user has an
184 association for some period of time with a particular device. The
185 user profile is that set of profile data the user wants to
186 associate with that device (e.g. ringtones used when someone calls
187 them, the user's shortcuts).
188 device profile - data profile that applies to a specific device. In
189 the "hotelling" use case, this is the data that is bound to the
190 device itself independent of the user. It relates to specific
191 capabilities of the device and/or preferences of the owner of the
192 device.
193 local network profile - data that applies to the user agent in the
194 context of the local network. This is best illustrated by roaming
195 applications; a new device appears in the local network (or a
196 device appears in a new network, depending on the point of view).
197 The local network profile includes settings and perhaps policies
198 that allow the user agent to function in the local network (e.g.
199 how to traverse NAT or firewall, bandwidth constraints).
200 data set - a collection of properties.
201 working profile - the set of property values actually set in a SIP
202 User Agent as a result of merging the profiles from all sources;
203 the actual effective profile for the user agent .
204 merging - the operation of resolving overlapping settings from
205 multiple profiles. Overlap occurs when the same property occurs
206 in multiple profiles (e.g. device, user, application, local
207 network).
209 2.3. Overview
211 In this document requirements are specified for containing and
212 expressing profile data for use on SIP user agents. Though much of
213 this can be considered independent of SIP there is one primary
214 requirement that is not well satisfied through more generic profile
215 data mechanisms. SIP User Agent set up requires the agent to merge
216 settings, which may overlap, from potentially four different sources
217 (see [I-D.ietf-sipping-config-framework]); each source must not only
218 be able to provide profile information, but also express policies
219 regarding how the profile settings may be combined with that from
220 other sources.
222 A schema and syntax is defined in this document to specify properties
223 that may be aggregated to construct profiles. The general design
224 philosophy is that many small data sets provide flexibility to the
225 implementer to support the aggregated set that best matches the
226 capability of the user agent. The actual properties are not defined
227 in this document (see [I-D.ietf-sipping-media-policy-dataset] and
228 [reference: Core SIP Dataset]). However, some examples are explored
229 here to illustrate the proposed mechanisms and to validate the
230 requirements.
232 This document defines a set of considerations, syntax and policies
233 that must be specified when defining data sets. These are to help
234 authors of data set specifications to define data sets that will work
235 in the overall schema defined in this document. The actual
236 specification of these data sets is outside the scope of this
237 document.
239 3. Design Considerations
241 The following section defines some of the design considerations that
242 were taken into account when defining the schema, syntax and policies
243 for generating and applying profile data. Section 3.2.6 describes
244 need for merging of the four data set sources provided in [I-D.ietf-
245 sipping-config-framework].
247 3.1. Use Cases
249 In the following use case scenarios the device profile is provided by
250 the device owner/manager. The owner/manager may be a service
251 provider, an enterprise or a user administering the device setup.
252 The user is assumed to be the end user operating the user agent to
253 perform SIP functions such as telephony, IM etc. In the scenarios
254 that the user profile is provided, the user profile contains user
255 specific properties that the end user has set directly or indirectly
256 through an administration process. The local network profiles
257 represent the suggested policy behavior that the local network
258 operator would like user agents to adhere to [I-D.hilt-sipping-
259 session-policy-framework]. From a security perspective, the local
260 network operator cannot trust the user agent to follow the local
261 network profile policy. The local network operator must use a means
262 external to the user agent to enforce these policies. The local
263 network profile is intended to express to the user agent, the
264 policies that the user agent should follow if the user agent wants to
265 function properly in the local network.
267 3.1.1. Outbound Proxy Setting
269 First consider the use cases for a simple user agent property: the
270 outbound proxy. It is not likely that the user would want to
271 influence the outbound proxy for SIP signaling. Conceptually an
272 application might wish to use a specific outbound proxy for signaling
273 related to that application. For this use case, assume that the only
274 the device owner/manager or the local network operator are likely to
275 want to set the outbound proxy property. The device profile defines
276 an outbound proxy perhaps so that the device owner/manager can
277 monitor all signaling. The local network operator also defines an
278 outbound proxy because the proxy allows the SIP signaling to get
279 through a NAT or firewall.
281 It seems there are few possible solutions to this conflict resolution
282 problem:
283 o The simple solution is to define a policy where the local network
284 profile overrides the device profile. In this approach the local
285 network profile wins.
286 o A comprehensive solution is to allow the aggregation of the
287 outbound proxies. In this scenario SIP messages would be sent
288 with a pre-populated route set that had two hops. First the
289 outbound proxy set in the local network profile, then the outbound
290 proxy set in the device profile.
292 The aggregation approach is closest to solving the requirements to
293 the use case above. By aggregating the two outbound proxies, the
294 local network provided outbound proxy allows the signaling to get out
295 of the local network and the device profile provided outbound proxy
296 is able to monitor all SIP signaling from the user agent.
298 3.1.2. Codec Settings
300 Use cases for the codec properties are illustrated here as they are
301 likely one of the more complicated sets of properties with respect to
302 merging and constraining across more than one profile. There are
303 reasonable scenarios where requirements can be rationalized that the
304 device, user and local network profiles may each wish to express
305 preferences and constrains of the codec properties. Without getting
306 into details or syntax of the codec properties, it is assumed that
307 codec properties will need to express a codec definition and a
308 preference order. This is the order that these codecs will be put in
309 SDP for codec negotiation purposes.
311 The following scenarios illustrate some possible combinations of
312 sources of codec properties from the device, user and local network
313 profiles. The scenarios identify rationale for providing codec
314 properties in each of the profiles.
316 3.1.2.1. Codec Setting Not Set
318 In the scenario where a device has no profiles or the profiles
319 contain no codec properties, the device will enable a default set and
320 preference order of codecs. The default set and preference order of
321 codecs is a implementer specific choice. In some implementations it
322 is s subset of the codecs supported by the device.
324 3.1.2.2. Codec Set in Device Profile
326 Let us assume a scenario where user agents providing telephony
327 capabilities are deployed. The deployment has very simple
328 requirements such that the user agents have fixed locations and are
329 always associated with the same user. This scenario does not need
330 the separation between the user, device and local network profiles.
331 A single profile would suffice. Another scenario having similar
332 requirements is one where the user and local network profiles do not
333 provide any codec related properties. This might be because the user
334 does not care what codecs are used and the local network does not
335 wish to impose any constraints on the codes used in the network. In
336 the following use case, the device profile is the only source of
337 codec properties.
339 The codecs in the device profile may differ from the set of codecs
340 supported by the device, due to the administrator of the device
341 profile wanting:
342 o To have a uniform set of codecs used across all device types
343 o To exclude the use of a specific codec due to performance issues/
344 concerns
346 The resulting device profile data further will constrain the list of
347 codecs that get applied. In addition, the administrator may want to
348 list the order of which the codecs are to be applied. In this
349 scenario the device profile data will dictate the ordered list of
350 codecs to be applied. The use agent will ignore codec types included
351 in the profile that the user agent does not support.
353 3.1.2.3. Set in Device and User Profiles
355 In the following scenario users are allowed to express a preference
356 over codecs. Users are probably not likely to express specific codes
357 in the form of G.7XX, etc. They are likely to want to express a
358 preference in the form of wideband, normal and low bandwidth. In the
359 following use case, device and user profiles contain codec
360 properties.
362 The user may prefer a higher quality codec to be used, if available.
363 Thereby the user profile data may provide an ordered list of codecs
364 to be applied. The device profile also specifies a list of codecs
365 and a default preference order.
367 The merging of the data sources is as follows:
368 o The ordering of the codecs will be determined from the user
369 profile data, which overrides the codec preference ordering from
370 the device profile data.
371 o The set of codecs that may be applied, are the codecs listed in
372 the user data constrained by the list of codecs from the device
373 profile data.
375 The case in which none of the codecs in the resulting merged profile
376 data sets are supported by the device, the profile data constitutes a
377 misconfiguration between device and user profiles. It may not be
378 possible to successfully establish a session in this case. It is
379 suggested that the user agent provide feedback to the user indicating
380 the misconfiguration. The user agent may also attempt to function in
381 the network by ignoring one or more of the profile constraints.
383 3.1.2.4. Set in Device and Local Profiles
385 In another scenario the user is not allowed or does not care to
386 express codec preferences. The owner/manager of the device defines
387 the set of codecs which may be used on the device along with a
388 preference ordering of codecs. There is no user profile or the user
389 profile contains no codec properties. The local network wishes to
390 define a policy over codec usage in the network. It is not clear
391 there is a requirement that the local network be able to express a
392 preference order. However the network operator is very likely to
393 want to express a set of codecs that can or should not be used. The
394 constraints that the local network operator wishes suggest may relate
395 to the goal of controlling bandwidth or conveying what will work over
396 the available WAN connection. In the following use case, device and
397 local network profiles provide codec properties. The local network
398 may limit the type of codecs that can be applied due to resources
399 available.
401 The merging of the data sources is as follows:
402 o The set of codecs that may be used is the ordered list of codecs
403 from the device profile data, further constrained by the local
404 network profile data.
406 The case in which none of the codecs in the resulting merged profile
407 data sets are supported by the device, the profile data constitutes a
408 misconfiguration between local network and device. It may not be
409 possible to successfully establish a session in this case. It is
410 suggested that the user agent provide feedback to the user indicating
411 the misconfiguration. The user agent may also attempt to function in
412 the network by ignoring one or more of the profile constraints.
414 3.1.2.5. Set in Device, User and Local Profiles
416 In this scenario everyone has an opinion on the codecs to be used.
417 The device owner/manager wishes to define a set of codes based upon
418 best interoperability of known end points in the environment. The
419 user wishes to express preferences in the codecs (e.g. prefers
420 wideband audio). The local network wishes to constrain the codecs
421 based upon bandwidth (e.g. a wireless network with limited local
422 network bandwidth, a SOHO network with dialup connectivity, a small
423 office with shared 256kbps WAN connectivity). In the following
424 scenario, device, user and local network profiles provide codec
425 properties.
427 The merging of the data sources is as follows:
428 o The ordering of the codecs will be determined from the user
429 profile data, which overrides the ordering from the device profile
430 data.
431 o The set of codecs that may be used are the codecs listed in the
432 device profile data, constrained by the list of codecs from the
433 user profile data and further constrained by the list of codecs
434 from the local network profile data.
436 The case in which none of the codecs in the resulting merged profile
437 data sets are supported by the device, the profile data constitutes a
438 misconfiguration between device, user and local network profiles. It
439 may not be possible to successfully establish a session in this case.
440 It is suggested that the user agent provide feedback to the user
441 indicating the misconfiguration. The user agent may also attempt to
442 function in the network by ignoring one or more of the profile
443 constraints.
445 3.1.2.6. Derived Requirements
447 1. A device will have a set of codecs supported, that may be
448 offered. The list of codecs supported by a device may differ
449 from the list of codecs in the device profile data. The list of
450 codecs in the device profile data that get applied is the subset
451 of the codecs supported by the device. Codecs listed in profiles
452 that are not supported by the device are ignored.
454 2. The device profile data will have a default ordered list of
455 codecs, which implies a preference order that may be offered.
456 3. The user profile data may provide an ordered list of user
457 preferred codecs. The ordering of the codecs in the user profile
458 data will override the ordering of the codecs in the device
459 profile data. The user list of codecs may further constrain the
460 list of codecs to be used.
461 4. The local network profile data may provide a list of codecs
462 supported. This list will further constrain the list of codecs
463 that may be offered.
464 5. The application profile data containing codec data will be
465 ignored.
466 6. The profiles need the ability to express codecs that may be used
467 and codecs that should not be used.
469 3.1.3. Transport Protocol Setting
471 This section describes use cases related to the use of the SIP
472 transport protocol settings for a user agent. It is assumed that
473 user agents are configurable to define what transport protocols (e.g.
474 UDP, TCP, TLS) are to be used for the SIP signaling as well as the
475 default order in which to attempt each of the protocol.
477 3.1.3.1. Setting Not Set
479 When none of the profiles are available or the profiles do not
480 specify the SIP transport protocol setting, the device's default
481 signaling transport(s) will be used.
483 3.1.3.2. Set in Device Profile
485 In the following scenario, the device profile is the only source of
486 profile data. The signaling transports contained in the device
487 profile may differ from the set of signaling transports supported by
488 the device. This may be due to the administrator of the device
489 profile wanting:
490 o To have a uniform use of signaling transports used across all
491 device types.
492 o To mandate TLS for security reasons.
493 o To exclude the use of a specific signaling transport due to
494 performance issues/concerns.
495 o To indicate the preferred, default order in which to attempt using
496 each of the transport protocols.
498 This will result in the device profile data further constraining the
499 list of signaling transports that could be used. The highest
500 preference ordered signaling transport from the device profile data
501 set will be used first.
503 3.1.3.3. Set in Device and User Profiles
505 The following scenario extends the prior case described above. SIP
506 transport protocol properties are provided in both the device and
507 user profiles. Consider that SIP user agents, like email agents, may
508 want to provide the user with options to:
509 o Mandate that secure transport must be used. If secure transport
510 is not possible the user does not want to use the user agent.
511 o Prefer secure transport. Attempt to use secure transport. If
512 secure transport will not work, use which ever transport protocol
513 will make communication work.
515 When the user mandates the use of secure signaling transports only,
516 the user wishes to constrain the available signaling transports to
517 TLS. When indicating a preference to secure transport, the use is
518 specifying a preference order for the use of transport protocols
519 where TLS is the highest priority.
521 Now consider the merging strategy required to accomplish the goals of
522 this use case scenario where the device and user profiles both
523 contain SIP transport protocol properties. The merging of the data
524 sources is as follows:
525 o The set of signaling transports that are allowed to be used is
526 constrained by the device profile data. This is further
527 constrained by the user profile data.
528 o The signaling transports attempted will be those from the merged,
529 constrained list in order of highest to lowest priority.
531 3.1.3.4. Set in Device and Local Profiles
533 In the following scenario, device and local network profile data is
534 available. The local network may have a limited set of signaling
535 transports that it supports due to NAT or firewall constraints.
537 The merging of the data sources is as follows:
538 o The set of signaling transports that may be used is the ordered
539 list of signaling transports from the device profile data, further
540 constrained by the local network profile data.
542 The case in which none of the local network data signaling transports
543 are supported by the device profile data constitutes a
544 misconfiguration between local network and device. The device might
545 not be able to successfully establish a session in this case.
547 3.1.3.5. Derived Requirements
548 1. A device will have a set of signaling transports that it supports
549 (note: one can be a set), with a default signaling transport.
550 2. The set of signaling transports supported by a device may differ
551 from the set of signaling transports in the device profile data.
552 The set of signaling transports in the device profile data is an
553 ordered list, that is a subset of the set of signaling transports
554 supported by the device. This may be due to performance issues
555 associated with one of the signaling transport(s).
556 3. The user profile data may provide a list of preferred signaling
557 transports to be used (e.g., TLS for securing the signaling).
558 4. The local network profile data provides a list of signaling
559 transports supported, and will constrain the set of signaling
560 transports that could be used.
562 3.2. Requirement Descriptions
564 3.2.1. Implementer Extensibility
566 Implementers must be able to differentiate each implementation. In
567 addition, it does not serve user agent owners and administrators well
568 to require an orchestrated upgrade for all user agent implementations
569 and profile delivery servers before a new capability or feature can
570 be supported with the required profile data. Hence one of the most
571 important requirements is to support the ability of implementers to
572 extend specified standard data sets to include additional related
573 features and flexibility. It MUST be possible to extend a data set
574 without breaking user agents that support that data set. This may
575 require that user agents ignore parts of a data set that it does not
576 implement or extensions that it does support.
578 3.2.2. Flexible Capabilities
580 User agents vary quite widely in their capabilities. Some user
581 agents function like traditional telephones. Some user agents
582 support only text messaging. Some user agents support many media
583 types such as video. Some user agents that function like a telephone
584 have a single line, some have large numbers of lines. There is no
585 such thing as one size fits all. It MUST be possible for an
586 implementer to choose which data sets to support based upon the
587 capabilities that are supported by the user agent. The schema for
588 containing the profile data MUST support a profile that contains only
589 the data sets that a user agent supports. This allows the profile
590 delivery server to create small profiles for specific devices.
591 However a user agent SHOULD ignore properties for capabilities that
592 it does not support. This allows the profile delivery server to be
593 ignorant of the capabilities of the device. The degree to which the
594 profile delivery server has intelligence of the user agent
595 capabilities is an implementation choice.
597 3.2.3. XML
599 XML is perhaps not really a requirement, but a solution base upon
600 requirements. However it is hard to ignore the desire to utilize
601 readily available tools to manage and manipulate profile data such as
602 XSLT, XPATH and XCAP. The requirement that should be considered when
603 defining the schema and syntax is that many user agents have limited
604 resources for supporting advanced XML operation. The simplest XML
605 construct possible should be used, that support the required
606 functionality. It is not a requirement that user agents validate the
607 profile XML document. This relieves the requirement that the XML
608 schema defined in this and other data sets documents be enforced on
609 the user agent. The XML schema should not be used to strictly
610 validate profile XML documents. Unknown elements and attributes
611 should be ignored to allow extensions to be supported. Strict
612 enforcement of the XML schema would make it very difficult to deploy
613 new user agents without lock step upgrades of the profile delivery
614 server. Guidelines for the Use of Extensible Markup Language (XML)
615 within IETF Protocols [RFC3470] provides useful information in this
616 regard.
618 3.2.4. Access Control
620 Many user agents (e.g. appliances and softphones running on PCs)
621 provide user interfaces that permit the user to edit properties that
622 are logically part of user, application, device or local network
623 profiles. Operators and administrators would like to be able to
624 specify what an end user can change in those profiles and what an end
625 user is not allowed to change. There may also be sensitive data the
626 user agent requires to function, but that the operator of the system
627 does not want the end user to see. For some properties the system
628 operator may allow the user a fixed set of choices among the
629 supported set of possible values. It MUST be possible to express
630 whether an end user may change a data set property. It MUST be
631 possible to express that a property should not be made visible to the
632 end user. It MUST be possible to express allowable values or ranges
633 that the end user may change a property to. The access control
634 information SHOULD be optional to the data set. It might be useful
635 if it was possible to express the access control independent of the
636 properties themselves. The access control specification by itself
637 might be useful to express a general policy that the device owner or
638 local network operator wish to impose.
640 3.2.5. Data Constraints and Range Definition
642 There is a need for property value types such as free form text,
643 token/enumerations, integers, real numbers, etc. Many of these
644 properties will have constrained values as opposed to the range of
645 all possible values. These constrains may be due to protocol
646 definitions, implementation limitations, and/or the desire (e.g. by
647 the user, device owner, local network operator) to impose policy on
648 the user agent. The ability to express the property constraints is
649 useful from the perspective of access control as described in the
650 above section. It is also useful to parameterize a user interface
651 (e.g. on the user agent itself or on the profile delivery server)
652 which provides a facility to modify profile data. It MUST be
653 possible for the schema to specify property constraints as ranges or
654 discrete sets of possible values. These constrains SHOULD be
655 optional to the data set. It might be useful if it was possible to
656 express the constraints independent of the properties themselves.
657 The constraints without the property values might be used to specify
658 the capabilities of a particular user agent implementation.
660 3.2.6. Support of User, Application, Device, Local Network Sources
662 [I-D.ietf-sipping-config-framework] specifies a mechanism where the
663 user agent retrieves profile data from as many as four different
664 sources. The separation of the user profile facilitates a hotelling
665 capability and the ability to easily re-assign a user to a different
666 device. The separation of the local network profile facilitates
667 properties specific to operating in the local network in a roaming
668 scenario (e.g. outbound proxy or NAT traversal properties). The
669 local network profile may also impose policy as describe in the next
670 section. The device profile facilitates device capability based
671 properties as well as a means for the device owner or manager (e.g.
672 enterprise or service provider) to impose policy.
674 The multiple potential sources of profile data add some complexity to
675 the user agent that must consolidate these separate profiles into a
676 single working profile. It would be simpler if we could define each
677 property as only allowed in one of the profiles. However it overly
678 constrains the profiles and takes away desired functionality such as
679 hotelling, roaming and shared profile management. It would also be
680 simpler if we could define one rule for all profile data sets and
681 properties by which we merge the profile (e.g. local network profile
682 overwrites user profile which overwrites device profile for all
683 data). However this too is overly restrictive and eliminates some
684 very useful functionality.
686 The rules to merge profile data sets needs to be defined for each
687 data set. In some cases an entire data set must be considered atomic
688 when merging one profile source with another. In other cases it
689 makes sense to merge profile data sets, aggregating properties from
690 the data set provided in each of the profiles. It may also be
691 desirable to have the effect of filtering of data set properties.
692 The desired effect might be for the owner of the device or the local
693 network operator to constrain what values are allowed for properties
694 in the profiles. This may also be the mechanism to facilitate
695 imposing of policy as described in the next section. The operation
696 of resolving overlapping data sets from multiple profiles, regardless
697 of the means or net result, will be referred to as "merging" in this
698 document.
700 A profile must have the means to constrain the merging algorithm.
701 Due to the differences in the desired outcome for each data setting,
702 the merging algorithm is specific to the setting. When defining a
703 property setting, the merging algorithm must also be defined. A few
704 of the more commonly used merging algorithms are defined in this
705 document. Most settings are likely to use the common set defined in
706 this document. However authors of profile datasets may define new
707 algorithms for merging dataset properties (see Section 4.10 and
708 Section 5.3).
710 3.2.7. The Ability to Specify Policy
712 Local network operators would like to impose policy on users and
713 devices operating in their network. There is a need to constrain the
714 operation and require specific behavior in the network. This might
715 be as simple as to get access to the Internet, user agents must use a
716 specified outbound proxy and NAT traversal mechanism. The network
717 might have limited bandwidth such that the operator would like to
718 constrain codecs or media streams to keep the network functional.
719 The local network may provide emergency service behavior or
720 functionality properties that are more specific than those provided
721 by the device or user profile. The examples here focus on
722 constraints to impose policy from the local network. However the
723 facility to impose policy may be equally useful to the user and
724 device profiles.
726 It MUST be possible to impose policy in any of the profile sources
727 that constrains, overwrites or modifies properties provided in data
728 sets from other sources.
730 4. Overall Data Set Schema
732 This document defines an XML Schema, for SIP Profile Data Sets that
733 provides:
734 o a base element type "setting" from which all settings in other
735 schema definitions inherit (this allows other definitions to
736 specify the content models for ways of combining settings; it is
737 analogous to a C++ virtual base class).
739 o Attributes to the "setting" element that define constraints and
740 other properties used to impose policy that apply to the element
741 value. These attributes are inherited by elements that are
742 derived from the abstract settings element.
743 o A root element for all property sets (the outermost container).
745 The full text of the schema is in Appendix A; the following describes
746 the usage of the schema in defining properties and combining them to
747 construct the working profile of a User Agent.
749 4.1. Data Primitives
751 Each property in a profile data set is defined using XML Schema
752 Datatypes [W3C.REC-xmlschema-2] and XML Schema Structures [W3C.REC-
753 xmlschema-1]. A property is modeled by an XML element derived from
754 the "setting" element in the SIP Profile Data Set Schema. The
755 element content is the setting value.
757 Properties consisting of one single value can be expressed using a
758 single XML element. Properties that may consist of multiple values
759 require the use of container elements. A container element is
760 defined for such a property. This container can contain multiple XML
761 elements, which each defines a possible value for that property (see
762 examples in Section 4.5.2).
764 When constructing a property set, the creator of a profile may not be
765 able to know all of the capabilities of the User Agent that will
766 receive that property set. The creator of profile constraints or
767 policies should be aware that a user agent may ignore properties that
768 are unsupported or do not apply to its capabilities.
770 4.2. Use of Namespaces
772 XML namespaces [W3C.REC-xml-names-19990114] provide a means to
773 uniquely identify the elements and datatypes defined in a data set.
774 It is therefore RECOMMENDED that each data set specifies its own
775 namespace. The namespace URIs SHOULD be URNs [RFC2141], using the
776 namespace identifier 'ietf' defined by [RFC2648] and extended by
777 [I-D.mealling-iana-xmlns-registry].
779 4.3. The 'property_set' Element
781 The root element of a property set is "property_set"; it is the
782 container that is provided to the user agent. The elements contained
783 within a property_set contain the specific properties which are to be
784 applied to the user agent. The properties may be simple types with a
785 single value, complex types or container elements with a list of
786 properties.
788 4.4. The Abstract 'setting_container' Element
790 The "setting_container" element is the abstract element in which a
791 list of properties which allow mutliple values may be contained.
792 Elements derived from the "setting_container" element may contain
793 zero or more elements derived from the "setting" element. The
794 "setting_container" element has an "excluded_policy" attribute.
796 4.5. The Abstract 'setting' Element
798 The setting element is the abstract element from which all profile
799 properties or settings shall inherit.
801 The setting element has a number of attributes that provide
802 functionalities, which are generally useful for many properties.
803 These attributes are inherited by properties that are derived from
804 the settings element. This enables the re-use of common
805 functionalities and ensures a common syntax for these elements across
806 different data sets. The following functionalities are provided by
807 attributes of the settings element:
809 o Property Access Control: 'visibility' attribute
810 o Policies: 'policy' attribute
812 Additional attributes are defined in the schema that may used in
813 elements derived from "setting". By default these attributes cannot
814 be set. These attribute must be explicitly added to elements derived
815 from the "setting" element:
817 o Unidirectional Properties: 'direction' attribute
818 o Preferences: 'q' attribute
820 4.5.1. The 'visibility' Attribute
822 The attribute "visibility" is defined on the "setting" element to
823 specify whether or not the user agent is permitted to display the
824 property value to the user. This is used to hide setting values that
825 the profile administrator may not want the user to see or know. The
826 "visibility" attribute has two possible values:
828 o visible: specifies that display of the property value is not
829 restricted. This is the default value of the attribute if it is
830 not specified.
831 o hidden: Specifies that the user agent SHOULD NOT display the
832 property value. Display of the property value may be allowed
833 using special administrative interfaces, but is not appropriate to
834 the ordinary user.
836 4.5.2. The 'policy' Attributes
838 The setting element has an optional 'policy' attribute. The policy
839 attribute is used to define the constraining properties of an
840 element. It defines how the element value is used by an endpoint
841 (e.g. whether it can or can not be used in a session). The following
842 values are defined for the 'policy' attribute:
844 o allow: the value contained in the element is allowed and SHOULD be
845 used in sessions. This is the default value that is used if the
846 'policy' attribute is omitted.
847 o disallow: the value contained in the element is forbidden and
848 SHOULD NOT be used in sessions.
850 The policy attribute can be omitted if the default policy 'allow'
851 applies.
853 OPEN ISSUE: The policy attribute may not be needed for elements
854 outside of a settings_container. Further clarification is needed
855 on this. Using the policy attribute only inside containers would
856 further simplify the specification of profile data.
858 4.5.3. The 'excluded_policy' Attributes
860 The "setting_container" element has an optional 'excluded_policy'
861 attribute. This attribute specifies the default policy for all
862 values that are not in the container. Elements that are present in
863 the container have their own 'policy' attribute, which defines the
864 policy for that element. The following values are defined for the
865 'excluded_policy' attribute:
867 o allow: values not listed in the container are allowed and MAY be
868 used in sessions. This is the default value that is used if the
869 'excluded_policy' attribute is omitted.
870 o disallow: values not listed in the container are forbidden and
871 MUST NOT be used in sessions.
873 The excluded_policy attribute can be omitted if the default policy
874 'allow' applies. The following example shows a policy that allows
875 the media type audio and disallows all other media types in sessions
876 (effectively, this construct requires the use of audio):
878
879 audio
880
882 4.5.4. The 'direction' Attribute
884 Some properties are unidirectional and only apply to messages or data
885 streams transmitted into one direction. For example, a property for
886 media streams can be restricted to outgoing media streams only.
887 Unidirectional properties can be expressed by adding a 'direction'
888 attribute to the respective element.
890 The 'direction' attribute can have the following values:
892 o recvonly: the property only applies to incoming messages/streams.
893 o sendonly: the property only applies to outgoing messages/streams.
894 o sendrecv: the property applies to messages/streams in both
895 directions. This is the default value that is used if the
896 'direction' attribute is omitted.
898 4.5.5. The 'q' Attribute
900 It should be possible to express a preference for a certain value, if
901 multiple values are allowed within a property. For example, it
902 should be possible to express that the codecs G.711 and G.729 are
903 allowed, but G.711 is preferred. Preferences can be expressed by
904 adding a 'q' attribute to a property element. Elements derived from
905 the "setting" element for which multiple occurrences and values are
906 allowed SHOULD have a "q" attribute if the order is significant.
907 Typically these elements are contained in an element derived from the
908 "setting_container" element. The 'q' attribute is only meaningful if
909 the 'policy' attribute set to 'allowed'. It must be ignored in all
910 other cases.
912 An element with a higher 'q' value is preferred over one with a lower
913 'q' value. 'q' attribute values range from 0 to 1. The default value
914 is 0.5.
916 4.6. The 'profile-uri' Element
918 The element contains the URI of this profile on the
919 profile server. The value contained in the profile-uri element may
920 be different than the URI subscribe to when retrieving this profile.
921 When the user agent retrieves a profile where the profile-uri is
922 different than the subscribe to URI, the user agent SHOULD
923 unsubscribe to the current URI and then subscribe to the new URI.
925 The element is optional and MAY occur only once inside
926 a element. The profile-uri element is specific to the
927 local-network, device, user or application profile in which it
928 occurs. It has no meaning outside of the profile in which it occurs
929 and SHOULD NOT be merged.
931 4.7. The 'profile-credential' Element
933 The element contains the digest authentication
934 information that SHOULD be used for authentication for the profile
935 subscription via SIP or profile retrieval via HTTP, HTTPS, etc. The
936 profile-credential element is optional and MAY occur only once inside
937 a property_set element. The profile-credential element is specific
938 to the local-network, device, user or application profile in which it
939 occurs. It has no meaning outside of the profile in which it occurs
940 and SHOULD NOT be merged. The profile-credential element MUST
941 contain exactly one of each of the elements: realm, auth-user, a1-
942 digest.
944 4.7.1. realm Element
946 The realm element contains the string that defines the realm to which
947 this credential pertains. The value of the realm element is the same
948 as the realm parameter in the [RFC2617] headers: WWW-Authenticate,
949 Authorization and the SIP [RFC3261] headers: Proxy-Authenticate and
950 Proxy-Authorization. If a match of the realm value is found, the
951 user agent uses the values in the auth_user and a1_digest elements
952 contained in the sip_credential element. The exactly one realm
953 element SHOULD be contained in a profile-credential element.
955 4.7.2. auth_user Element
957 The auth_user element contains the string value of the "username"
958 parameter which SHOULD be used in Authorization and Proxy-
959 Authorization request headers when retrying a request that was
960 challenged for authentication. Exactly one auth_user element SHOULD
961 be contained in a profile-credential element.
963 4.7.3. a1_digest Element
965 The a1_digest element contains a string with the value of the A1
966 digest of the username, realm and password as defined in [RFC2617].
967 Exactly one a1_digest element SHOULD be contained in a profile-
968 credential element. The username and realm used to construct the
969 value of the a1_digest element MUST match the values of the realm and
970 auth_user elements contained in the profile-credential element with
971 the a1_digest element.
973 4.8. The 'profile-contact-uri' Element
975 The element contains a contact URI (e.g. a SIP,
976 HTTP URI or email address) under which the issuer of this profile can
977 be reached. The contact element may, for example, contain the
978 address of a support hotline.
980 The element is optional and MAY occur multiple
981 times inside a element. Multiple instances of the
982 profile-contact-uri element allow multiple URI schemes to be provided
983 for contact information. The user agent MAY use the URI contained
984 profile-contact-info element which has a URI scheme that the user
985 agent supports and can make work to provide support help for the
986 profile. The user agent MAY provide the URIs to the user to contact
987 the creator of the profile through other communication channels. The
988 profile-contact-uri element is specific to the local-network, device,
989 user or application profile in which it occurs. It has no meaning
990 outside of the profile in which it occurs and SHOULD NOT be merged.
992 4.9. The 'profile-info' Element
994 The element provides a short textual description of
995 the property that should be intelligible to the human user. This
996 element may, for example, contain information about the nature of
997 this profile, such as "Access Network Profile". The text in the
998 element is in particular be helpful when a user needs
999 to decide whether or not to use a newly downloaded profile or when
1000 problems with a profile (e.g. a policy conflict) occur. A user agent
1001 MAY display this information in these cases.
1003 The element is optional and MAY occur only once inside
1004 a element. Te profile-info element is specific to the
1005 local-network, device, user or application profile in which it
1006 occurs. It has not meaning outside of the profile in which it occurs
1007 and SHOULD NOT be merged.
1009 4.10. Merging Property Sets
1011 A UA may receive property sets from multiple sources, which need to
1012 be merged into a single combined document the UA can work with.
1014 Properties that have a single value (e.g. the maximum bandwidth
1015 allowed) require that a common value is determined for this property
1016 during the merging process. The merging rules for determining this
1017 value need to be defined individually for each element in the schema
1018 definition. Properties that allow multiple values (i.e. property
1019 containers) need to be merged by combining the values from the
1020 different data sets. The following sections describe common merging
1021 algorithms. A data set definition may refer to these algorithms.
1023 4.10.1. Single Numeric Value Merging Algorithm
1025 A general merging rule for elements with numeric values is to select
1026 the largest or the smallest value. For example, a merging rule for a
1027 element would be to select the smallest value from
1028 the values that are in the competing data sets.
1030 4.10.2. Multiple Enumerated Value Merging Algorithm
1032 Multiple values in property containers are merged by combining the
1033 values from each of the competing data sets. This is accomplished by
1034 copying the elements from each property container into the merged
1035 container. Elements with identical values are only copied once. The
1036 'policy' attribute of two elements with the same value is adjusted
1037 during the merging process according to Table 1. If an element
1038 exists only in one property container, then the default policy of the
1039 other container (i.e. the excluded_policy) is used when accessing
1040 Table 1. For example, if an element is disallowed in one data set
1041 and the element is not contained in the other data set but the
1042 default policy is allowed for that data set, then the values
1043 disallowed and allowed are used to access Table 1. Consequently, the
1044 element will be disallowed in the merged data set. Finally, the
1045 excluded_policy attributes of the containers are also merged using
1046 Table 1. In addition to these merging rules, each schema may define
1047 specific merging rules for each property container.
1049 set 1 \ set 2 | allow | disallow
1050 --------------+----------+----------
1051 allow | allow | disallow
1052 disallow | disallow | disallow
1054 Table 1: merging policies.
1056 The following example illustrates the merging process for two data
1057 sets. All elements are merged into one container and the policy
1058 attributes are adjusted according to Table 1. The merged container
1059 has the default policy disallow, which is determined using Table 1.
1060 The entry for PCMA in the merged data set is redundant since it has
1061 the default policy.
1063 Data set 1:
1064
1065 PCMA
1066
1068 Data set 2:
1069
1070 PCMA
1071 G729
1072
1074 Merged data set:
1075
1076 PCMA
1077 G729
1078
1080 Some constellations of policy attributes result in an illegal merged
1081 data set. They constitute a conflict that can not be resolved
1082 automatically. For example, two data sets may define two non-
1083 overlapping sets of allowed audio codecs and both disallow all other
1084 codes. The resulting merged set of codecs would be empty, which is
1085 illegal according to the schema definition of the codecs element. If
1086 the use of these properties is enforced by both networks, the UA may
1087 experience difficulties or may not be able to set up a session at
1088 all.
1090 The combined property set MUST again be valid and well-formed
1091 according to the schema definitions. A conflict occurs if the
1092 combined property set is not a well-formed document after the merging
1093 process is completed.
1095 4.10.3. Closest Value First Merging Algorithm
1097 Some properties require that the values from different data sets are
1098 ordered based on the origin of the data set during the merging
1099 process. Property values that come from a domain close to the user
1100 agent take precedence over values that were in a data set delivered
1101 by a remote domain. This order can be used, for example, to select
1102 the property value from the closest domain. In many cases, this is
1103 the local domain of the user agent. For example, the URI of an
1104 outbound proxy could be merged this way. This order can also be used
1105 to generate an ordered list of property values during the merging
1106 process. For example, multiple values for media intermediaries can
1107 be ordered so that the closest media intermediary is traversed before
1108 the second closest intermediary and so on.
1110 This merging algorithm requires that the source of a data set is
1111 considered.
1113 If property sets are delivered through the configuration framework
1114 [I-D.ietf-sipping-config-framework], the value received through a
1115 subscription using the "local-network" profile-type takes precedence
1116 over values received through other profile-type subscriptions.
1118 OPEN ISSUE: Can we define an order for 'device', 'user', and
1119 'application' profiles?
1121 The session-specific policy mechanism [I-D.hilt-sipping-session-
1122 policy-framework] provides an order among policy servers. This order
1123 is based on the order, in which a SIP message traverses the network,
1124 starting with the closest domain. This order can directly be used to
1125 order property values as described above.
1127 4.11. Common Types
1129 [The schema will also define a set of common types that are used in
1130 defining data sets (e.g. name-addr) in a future version of this
1131 draft.]
1133 5. Defining Data Sets
1135 This section covers several issues that should be take into
1136 consideration when specifying new data set schemas. This is intended
1137 to be a guide to authors writing specifications defining a new data
1138 set schema or extensions to existing ones.
1140 5.1. Namespace
1142 It is RECOMMENDED that a data set defines a new XML namespace
1143 [W3C.REC-xml-names-19990114] to scope all of the properties that are
1144 defined in the name space.
1146 5.2. Property Definitions
1148 The properties defined in a data set schema may be simple (i.e.
1149 having a single value) or they may be complex (i.e. a container with
1150 multiple values). Each property in the data set SHOULD inherit from
1151 the "setting" element. Complex properties and all of their child
1152 elements each should inherit from "setting" as well.
1154 A data set specification should contain a section which defines the
1155 meaning of all of the properties contained in the data set. The
1156 objective is to define the property such that implementers have a
1157 clear definition and semantics to interpret properties in a
1158 consistent way. User agents not only need to use the same profile
1159 content, they need to apply the properties in a consistent way to
1160 achieve true interoperability.
1162 The following information should be defined for each property in a
1163 data set:
1164 o description: describe the meaning and application of the property.
1165 o cardinality: define how many instances of this property element
1166 may occur in a data set (e.g. zero, one or many) as well as its
1167 relationship to any other properties in this or other data sets.
1168 o default value: define the default value of this property if it is
1169 not set. Describe if the default is different if the property is
1170 present and not set vs. completely absent from the data set.
1171 Define if the default varies in relation to another property.
1173 5.3. Merging Data Sets
1175 User agents may receive data sets from multiple sources. They need
1176 to merge these data sets in order to create an overall data set they
1177 can work with. Collisions on data sets may occur if multiple sources
1178 provide different values for the same properties. These collisions
1179 need to be resolved during the merging process.
1181 A data set schema MUST define rules for merging data sets from
1182 different sources for each property that is defined. Considerations
1183 for merging data sets are discussed in Section 4.10. A data set
1184 schema must define if and how these consideration apply and MAY
1185 define alternative merging rules for specific settings. A data set
1186 schema must also identify combinations of properties that constitute
1187 a conflict that can't resolved. It may provide additional guidelines
1188 for the behavior of a user agent in these cases.
1190 6. Candidate Data Sets
1192 The following sections name some of the candidate data sets that are
1193 or may be defined. These data sets can be aggregated to form
1194 profiles appropriate to the capabilities of a user agent
1195 implementation.
1197 o SIP Protocol Data Set: the lowest common denominator set of
1198 properties common to all SIP user agents of any capability. A
1199 schema covering the elements of this data set can be found in
1200 [I-D.petrie-sipping-sip-dataset].
1201 o Media Data Set: this data set contains media related policies. A
1202 schema covering the elements of this data set can be found in
1203 [I-D.ietf-sipping-media-policy-dataset].
1205 o Identity Data Set: AORs and lines (see [I-D.petrie-sipping-
1206 identity-dataset])
1207 o HTTP Protocol Data Set: server settings. Proxy for clients.
1208 o NAT Traversal Data Set: settings for STUN, TURN etc.
1209 o SIP Digit Maps Data Set: [I-D.petrie-sipping-voip-features-
1210 dataset]
1211 o VoIP Features: [I-D.petrie-sipping-voip-features-dataset]
1212 o Address Book:
1213 o Buddy List:
1215 7. Security Considerations
1217 Security is mostly a delivery problem. The delivery framework SHOULD
1218 provide a secure means of delivering the profile data as it may
1219 contain sensitive data that would be undesirable if it were stolen or
1220 sniffed. Storage of the profile on the profile delivery server and
1221 user agent is an implementation problem. The profile delivery server
1222 and the user agent SHOULD provide protection that prevents
1223 unauthorized access of the profile data. The profile delivery server
1224 and the user agent SHOULD enforce the access control policies defined
1225 in the profile data sets if present.
1226 [The point of the access control construct on the data set is to
1227 provide some security policy on the visibility and ability to
1228 change sensitive properties. Does the access control mechanism
1229 also create a security problem where the local network can set or
1230 hide properties from the user?]
1232 Some transport mechanisms for delivery of the profile data do not
1233 provide a secure means of delivery. In addition some user agents may
1234 not have the resources to support the secure mechanism used for
1235 delivery (e.g. TLS).
1237 8. IANA Considerations
1239 [TBD] XML Schema name space registration
1241 9. Change History
1243 9.1. Changes from draft-petrie-sipping-profile-datasets-02
1245 Removed "mandatory" policy attribute value to simplify use and
1246 profile merging issues.
1248 Session Independent Policy draft was split into separate media
1249 dataset draft and policy drafts. Fixed references and information in
1250 this draft to reflect the two drafts.
1252 Added concrete properties contained in elements: profile-uri,
1253 profile-credential, profile-contact-uri and profile-info. Prior to
1254 this draft, there were only abstract elements defined in this draft.
1255 These elements have been added to contain information that is
1256 specific to the profile and are independent of the specific profile
1257 data sets contained in the profile.
1259 Split references into normative and informative sections.
1261 Numerous editorial changes
1263 9.2. Changes from draft-petrie-sipping-profile-datasets-01
1265 Split out the core SIP Protocol dataset into a separate draft.
1267 Schema changes: created setting_container, added q and direction
1268 attributes along with other tweaks to the schema.
1270 Better integration and coordination with [I-D.ietf-sipping-media-
1271 policy-dataset]. The media/codec dataset is now completely contained
1272 in the policy draft.
1274 9.3. Changes from draft-petrie-sipping-profile-datasets-00
1276 Added use case scenarios for codecs, SIP transport protocol and
1277 outbound proxy to better illustrate requirements. Some of the
1278 derived requirements are listed with the use cases.
1280 Added settings element attributes "policy" and "visibility" to
1281 provide merging constraints and access control capability. Removed
1282 the element based merging constraints using the: forbid, set_any,
1283 set_all and set_one elements. This greatly simplifies the degree of
1284 XML operations required to perform the request merging.
1286 Defined default merging policy and profile source precedence along
1287 with the option for different policies to be describe in specific
1288 settings definition documents.
1290 Added example merging with XML profiles from device and user for the
1291 SIP transport protocol.
1293 10. References
1294 10.1. Normative References
1296 [I-D.hilt-sipping-session-policy-framework]
1297 Hilt, V., "A Framework for Session Initiation Protocol
1298 (SIP) Session Policies",
1299 draft-hilt-sipping-session-policy-framework-00 (work in
1300 progress), October 2005.
1302 [I-D.ietf-sipping-config-framework]
1303 Petrie, D., "A Framework for Session Initiation Protocol
1304 User Agent Profile Delivery",
1305 draft-ietf-sipping-config-framework-07 (work in progress),
1306 July 2005.
1308 [I-D.mealling-iana-xmlns-registry]
1309 Mealling, M., "The IETF XML Registry",
1310 draft-mealling-iana-xmlns-registry-05 (work in progress),
1311 June 2003.
1313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1314 Requirement Levels", BCP 14, RFC 2119, March 1997.
1316 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
1317 Leach, P., Luotonen, A., and L. Stewart, "HTTP
1318 Authentication: Basic and Digest Access Authentication",
1319 RFC 2617, June 1999.
1321 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
1322 A., Peterson, J., Sparks, R., Handley, M., and E.
1323 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
1324 June 2002.
1326 [W3C.REC-xml-names-19990114]
1327 Hollander, D., Bray, T., and A. Layman, "Namespaces in
1328 XML", W3C REC REC-xml-names-19990114, January 1999.
1330 [W3C.REC-xmlschema-1]
1331 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
1332 "XML Schema Part 1: Structures", W3C REC-xmlschema-1,
1333 May 2001, .
1335 [W3C.REC-xmlschema-2]
1336 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
1337 W3C REC-xmlschema-2, May 2001,
1338 .
1340 10.2. Informative References
1342 [I-D.ietf-sipping-media-policy-dataset]
1343 Hilt, V., "A User Agent Profile Data Set for Media
1344 Policy", draft-ietf-sipping-media-policy-dataset-00 (work
1345 in progress), October 2005.
1347 [I-D.petrie-sipping-identity-dataset]
1348 Petrie, D., "The Session Initiation Protocol User Agent
1349 Identity Profile Data Set",
1350 draft-petrie-sipping-identity-dataset-00 (work in
1351 progress), October 2005.
1353 [I-D.petrie-sipping-sip-dataset]
1354 Petrie, D., "The Core Session Initiation Protocol User
1355 Agent Profile Data Set",
1356 draft-petrie-sipping-sip-dataset-00 (work in progress),
1357 July 2005.
1359 [I-D.petrie-sipping-voip-features-dataset]
1360 Petrie, D., "The Session Initiation Protocol User Agent
1361 VoIP Features Data Set",
1362 draft-petrie-sipping-voip-features-dataset-00 (work in
1363 progress), October 2005.
1365 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
1367 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
1368 August 1999.
1370 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for
1371 the Use of Extensible Markup Language (XML) within IETF
1372 Protocols", BCP 70, RFC 3470, January 2003.
1374 Appendix A. SIP UA Profile Schema
1376
1377
1380 ]>
1381
1384
1389
1390
1391 Proposed XML metalanguage for the description of
1392 SIP User Agent Profile Data Sets.
1393
1394
1395
1397
1403
1404
1405
1406
1407
1408
1410
1411
1412
1413
1414
1415
1417
1418
1419
1420
1421
1422
1423
1425
1428
1429
1430
1431 The multi_setting_attributes attribute group is
1432 for attributes that are applicable to settings that
1433 may have multiple values in a container.
1435
1436
1437
1438
1439
1440
1441 The q attribute is used to define a preference for a
1442 setting. It can be used to define that one value
1443 of a setting is preferred over another value.
1444
1445
1446
1447
1448
1450
1451
1452
1453 The multi_setting_attributes attribute group is
1454 for attributes that are applicable to settings that
1455 have a directional implication (e.g. incoming or
1456 outgoing).
1457
1458
1459
1460
1461
1462
1463 The direction attribute is used to define
1464 unidirectional settings.
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1478
1483
1484
1485
1486 The property_set element is the root element returned in
1487 response to a request for a profile data set.
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1500
1501
1502
1503
1504
1505
1506
1507
1508
1510
1511
1512 The container_policy attibute is used to define the
1513 policy for settings not explcitly contained in the
1514 container. disallowed means that setting
1515 values not included in the container are considered
1516 to be diallowed. The value of allowed
1517 indicates that values not included in the container
1518 are allowed.
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1532
1533
1535
1536
1537
1538 The 'setting' element is an abstract used as the basis for the
1539 definition of the setting elements in property schemas derived
1540 from this one.
1542 It serves here as a placeholder in constructing the content
1543 models for the container elements used to group settings into
1544 sets.
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554 The policy attribute is used to define the strength to
1555 which a setting should be used. It can also be viewed
1556 as the finality to which a setting may be overrided.
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570 The visibility attribute indicates whether the user
1571 agent should show the setting value(s) to the user.
1572
1573
1574
1575
1576
1577
1578
1579
1581
1582
1583
1584
1585
1586
1588
1590 Appendix B. Acknowledgments
1591 Authors' Addresses
1593 Daniel Petrie
1594 SIPez LLC.
1595 34 Robbins Rd.
1596 Arlington, MA 02476
1597 US
1599 Phone: +1 617 273 4000
1600 Email: dan.ietf AT SIPez DOT com
1601 URI: http://www.SIPez.com/
1603 Scott Lawrence
1604 Pingtel Corp.
1605 400 W. Cummings Park
1606 Suite 2200
1607 Woburn, MA 01801
1608 US
1610 Phone: "Scott Lawrence (+1 781 938 5306)"
1611 Email: slawrence AT pingtel DOT com
1612 URI: http://skrb.org/scott/
1614 Martin Dolly
1615 AT&T Labs
1616 200 Laurel Avenue
1617 Middletowm, NJ 07748
1618 US
1620 Phone:
1621 Email: mdolly AT att DOT com
1622 URI:
1624 Volker Hilt
1625 Bell Labs/Lucent Technologies
1626 101 Crawfords Corner Rd
1627 Holmdel, NJ 07733
1628 USA
1630 Email: volkerh@bell-labs.com
1632 Intellectual Property Statement
1634 The IETF takes no position regarding the validity or scope of any
1635 Intellectual Property Rights or other rights that might be claimed to
1636 pertain to the implementation or use of the technology described in
1637 this document or the extent to which any license under such rights
1638 might or might not be available; nor does it represent that it has
1639 made any independent effort to identify any such rights. Information
1640 on the procedures with respect to rights in RFC documents can be
1641 found in BCP 78 and BCP 79.
1643 Copies of IPR disclosures made to the IETF Secretariat and any
1644 assurances of licenses to be made available, or the result of an
1645 attempt made to obtain a general license or permission for the use of
1646 such proprietary rights by implementers or users of this
1647 specification can be obtained from the IETF on-line IPR repository at
1648 http://www.ietf.org/ipr.
1650 The IETF invites any interested party to bring to its attention any
1651 copyrights, patents or patent applications, or other proprietary
1652 rights that may cover technology that may be required to implement
1653 this standard. Please address the information to the IETF at
1654 ietf-ipr@ietf.org.
1656 Disclaimer of Validity
1658 This document and the information contained herein are provided on an
1659 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1660 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1661 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1662 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1663 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1664 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1666 Copyright Statement
1668 Copyright (C) The Internet Society (2005). This document is subject
1669 to the rights, licenses and restrictions contained in BCP 78, and
1670 except as set forth therein, the authors retain all their rights.
1672 Acknowledgment
1674 Funding for the RFC Editor function is currently provided by the
1675 Internet Society.