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).