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.