idnits 2.17.1 draft-ietf-sipping-profile-datasets-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- 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 (March 8, 2009) is 5528 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) == Outdated reference: A later version (-10) exists of draft-ietf-sip-session-policy-framework-05 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-15 ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) == Outdated reference: A later version (-16) exists of draft-ietf-sipping-media-policy-dataset-07 -- Obsolete informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING M. Dolly 3 Internet-Draft AT&T 4 Intended status: Standards Track D. Petrie 5 Expires: September 9, 2009 SIPez LLC 6 D. Worley (Editor) 7 Nortel Networks 8 March 8, 2009 10 A Schema and Guidelines for Defining Session Initiation Protocol User 11 Agent Profile Datasets 12 draft-ietf-sipping-profile-datasets-03.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 9, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document defines the requirements and a format for SIP user 51 agent profile data. An overall schema is specified for the 52 definition of profile datasets. The schema also provides for 53 expressing constraints for how multiple sources of profile data are 54 to be combined. This document provides a guide to considerations, 55 policies and syntax for defining datasets to be included in profile 56 data. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Requirement Descriptions . . . . . . . . . . . . . . . . . 6 65 4.1.1. Implementer Extensibility . . . . . . . . . . . . . . 6 66 4.1.2. Flexible Capabilities . . . . . . . . . . . . . . . . 7 67 4.1.3. Access Control . . . . . . . . . . . . . . . . . . . . 7 68 4.1.4. Data Constraints and Range Definition . . . . . . . . 7 69 4.1.5. Support of User, Device, Local Network Sources . . . . 7 70 4.1.6. The Ability to Specify Policy . . . . . . . . . . . . 8 71 4.1.7. XML . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 5. Overall Dataset Schema . . . . . . . . . . . . . . . . . . . . 8 73 5.1. Data Primitives . . . . . . . . . . . . . . . . . . . . . 9 74 5.2. Use of Namespaces . . . . . . . . . . . . . . . . . . . . 9 75 5.3. The 'propertySet' Element . . . . . . . . . . . . . . . . 10 76 5.4. The Abstract 'setting_container' Element . . . . . . . . . 10 77 5.5. The Abstract 'setting' Element . . . . . . . . . . . . . . 10 78 5.5.1. The 'visibility' Attribute . . . . . . . . . . . . . . 11 79 5.5.2. The 'policy' Attributes . . . . . . . . . . . . . . . 11 80 5.5.3. The 'excludedPolicy' Attributes . . . . . . . . . . . 11 81 5.5.4. The 'direction' Attribute . . . . . . . . . . . . . . 12 82 5.5.5. The 'q' Attribute . . . . . . . . . . . . . . . . . . 12 83 5.6. The 'profileUri' Element . . . . . . . . . . . . . . . . . 13 84 5.7. The 'profileCredential' Element . . . . . . . . . . . . . 13 85 5.7.1. realm Element . . . . . . . . . . . . . . . . . . . . 13 86 5.7.2. authUser Element . . . . . . . . . . . . . . . . . . . 14 87 5.7.3. a1Digest Element . . . . . . . . . . . . . . . . . . . 14 88 5.7.4. password Element . . . . . . . . . . . . . . . . . . . 14 89 5.8. The 'profileContactUri' Element . . . . . . . . . . . . . 14 90 5.9. The 'profileInfo' Element . . . . . . . . . . . . . . . . 15 91 5.10. Example Profile Dataset . . . . . . . . . . . . . . . . . 15 92 5.11. Merging Property Sets . . . . . . . . . . . . . . . . . . 16 93 5.11.1. Single Numeric Value Merging Algorithm . . . . . . . . 17 94 5.11.2. Multiple Enumerated Value Merging Algorithm . . . . . 17 95 5.11.3. Closest Value First Merging Algorithm . . . . . . . . 18 96 5.12. Common Types . . . . . . . . . . . . . . . . . . . . . . . 19 97 6. Defining Data Sets . . . . . . . . . . . . . . . . . . . . . . 19 98 6.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 19 99 6.2. Property Definitions . . . . . . . . . . . . . . . . . . . 19 100 6.3. Merging Data Sets . . . . . . . . . . . . . . . . . . . . 20 101 7. Candidate Data Sets . . . . . . . . . . . . . . . . . . . . . 20 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 104 9.1. Content-type registration for 105 'application/uaprofile+xml' . . . . . . . . . . . . . . . 21 106 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 107 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 108 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 109 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 110 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 111 Appendix A. Relax NG SIP UA Profile Schema . . . . . . . . . . . 25 112 Appendix B. Use Cases . . . . . . . . . . . . . . . . . . . . . . 30 113 B.1. Outbound Proxy Setting . . . . . . . . . . . . . . . . . . 30 114 B.2. Codec Settings . . . . . . . . . . . . . . . . . . . . . . 31 115 B.2.1. Codec Setting Not Set . . . . . . . . . . . . . . . . 31 116 B.2.2. Codec Set in Device Profile . . . . . . . . . . . . . 31 117 B.2.3. Set in Device and User Profiles . . . . . . . . . . . 31 118 B.2.4. Set in Device and Local Profiles . . . . . . . . . . . 32 119 B.2.5. Set in Device, User and Local Profiles . . . . . . . . 32 120 B.2.6. Example Derived Requirements . . . . . . . . . . . . . 33 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 123 1. Introduction 125 The SIP User Agent Profile Delivery Framework 126 [I-D.ietf-sipping-config-framework] and the Framework for SIP Session 127 Policies [I-D.ietf-sip-session-policy-framework] specify how SIP user 128 agents locate and retrieve profile data specific to the user, the 129 device, and the local network. It is important for SIP User Agents 130 to be able to obtain and use these multiple sources of profile data 131 in order to support a wide range of applications without undue 132 complexity. 134 While these frameworks define the mechanisms for transmitting profile 135 data, they do not define a format for the actual profile data. This 136 document defines the requirements, the default/mandatory to support 137 content type for [I-D.ietf-sipping-config-framework] , a high level 138 schema for, and guide to how these datasets can be defined. The goal 139 is to enable any SIP user agent to obtain profile data and be 140 functional in a new environment independent of the implementation or 141 model of user agent. The nature of having profile data from three 142 potential sources requires the definition of policies on how to apply 143 the data in an interoperable way across implementations which may 144 have widely varying capabilities. 146 The ultimate objective of the framework described here, together with 147 the SIP User Agent Profile delivery framework, is to a start up 148 experience requiring minimal user intervention. One should be able 149 to take a new SIP user agent out of the box, plug it in or install 150 the software and have it get its profiles without human intervention 151 other than security measures. This is necessary for cost effective 152 deployment of large numbers of user agents. 154 2. Terminology 156 "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119." [RFC2119]. 160 This document uses the terms "profile" and "device" as defined in 161 [I-D.ietf-sipping-config-framework]: 163 profile - a set of configuration data intended to configure a 164 specific device or devices and obtained from a specific source 165 (e.g., user, device, local network or other). Has a concrete 166 representation as an XML document. 168 profile type - a particular category of Profile data in regard to 169 its source (e.g., user, device, local network or other). 171 In addition, this document defines the following terms: 173 profile schema - a definition of a set of possible profiles that are 174 seen as alternative configuration data for a set of UAs. Has a 175 specific XML namespace and a concrete representation in XML Schema 176 Language and/or in Relax NG schema language. 177 profile meta - schema: the schema of the XML namespace 178 "urn:ietf:params:xml:ns:uaprof", from which are derived the 179 various profile schemas 180 user profile - the profile that applies to a specific user. The 181 user profile is that set of profile data the user wants to 182 associate with a given device (e.g. ringtones used when someone 183 calls them, the user's shortcuts) and relate to the user's 184 identity 185 device profile - data profile that applies to a specific device. 186 This is the data that is bound to the device itself independent of 187 the user that is bound to the device. It relates to specific 188 capabilities of the device and/or preferences of the owner of the 189 device. 190 local network profile - data that applies to the user agent in the 191 context of the local network. This is best illustrated by roaming 192 applications; a new device appears in the local network (or a 193 device appears in a new network, depending on the point of view). 194 The local network profile includes settings and perhaps policies 195 that allow the user agent to function in the local network (e.g. 196 how to traverse NAT or firewall, bandwidth constraints). 197 merging - the operation of resolving overlapping settings from 198 multiple profiles. Overlap occurs when the same property occurs 199 in multiple profiles (e.g. device, user, local network). 200 working profile - the set of property values utilized in a SIP User 201 Agent; logically constructed by merging the profiles from the 202 relevant sources 203 property - a named configurable characteristic of a user agent; a 204 named datum within a profile schema. A given property has a well- 205 defined range of possible values. A given property may be defined 206 to have a range of values, allow for simultaneous use of many 207 values (as in a list of allowed possibilities), or a set of 208 related values that collectively form a single profile information 209 item. 210 dataset - a collection of properties. 211 setting - the binding of a specific value or set of values to a 212 given property. 214 Thus, a profile schema defines a dataset, and a profile is a set of 215 settings that conforms to a particular profile schema. 217 3. Overview 219 In this document requirements are specified for containing and 220 expressing profile data for use on SIP user agents. Though much of 221 this can be considered independent of SIP there is one primary 222 requirement that is not well satisfied through more generic profile 223 data mechanisms. SIP User Agent set up requires the agent to merge 224 settings, which may overlap, from potentially three different sources 225 (see [I-D.ietf-sipping-config-framework] ); each source must not only 226 be able to provide profile information, but also express policies 227 regarding how the profile settings may be combined with that from 228 other sources. 230 A schema and syntax is defined in this document to specify properties 231 that may be aggregated to construct profiles. The general design 232 philosophy is that many small datasets provide flexibility to the 233 implementer to support the aggregated set that best matches the 234 capability of the user agent. The actual properties are not defined 235 in this document and will be the subject of derived drafts. However, 236 some examples are provided in Appendix B to illustrate the proposed 237 mechanisms and to validate the requirements. 239 This document defines a set of considerations, syntax and policies 240 that must be specified when defining datasets. These are to help 241 authors of dataset specifications to define datasets that will work 242 in the overall schema defined in this document. The actual 243 specification of these datasets is outside the scope of this 244 document. 246 4. Design Considerations 248 The following section defines some of the design considerations that 249 were taken into account when defining the schema, syntax and policies 250 for generating and applying profile data. 252 4.1. Requirement Descriptions 254 4.1.1. Implementer Extensibility 256 It does not serve user agent administrators to have to require a 257 coordinated and orchestrated upgrade of every user agent and 258 corresponding profile delivery servers for a new capability to be 259 supported. Datasets MUST be extensible without breaking the user 260 agents that support that dataset. This may require the user agents 261 to ignore parts of the extended dataset that it does not support. It 262 may also be possible to tag the extensions with minimum version 263 numbers to facilitate the user agents decision making. 265 4.1.2. Flexible Capabilities 267 Since user agents vary greatly in their capabilities, it MUST be 268 possible for the implementer to tailor the datasets to the 269 capabilities of the user agent device. This implies that the profile 270 is built up of a series of small datasets based upon the capabilities 271 of the user agent. The user agents MAY ignore datasets for 272 capabilities they do not support. This allows the profile delivery 273 server to be agnostic of device capabilities. It is however the 274 implementer's choice to customize the delivered profile to the device 275 capabilities. 277 4.1.3. Access Control 279 There are likely to be properties in various profile datasets that 280 the Operators and Administrators do not want the users to sometimes 281 not be able to modify or even see. It MUST be possible to disallow 282 the user from modifying a property. It MUST be possible to obfuscate 283 the user from seeing a property or its setting. This access control 284 information SHOULD be optional for a given property.This is supported 285 by the admin value of the visibility attribute. 287 4.1.4. Data Constraints and Range Definition 289 Property values are likely to have an allowed set of values under 290 most circumstances rather than completely unconstrained in their 291 values. It MUST be possible for the schema to specify constraints on 292 a property value, viz, as a range or as a set of discrete values. 293 These constraints SHOULD be optional to the dataset and SHOULD be 294 expressible independent of the property itself. 296 4.1.5. Support of User, Device, Local Network Sources 298 [I-D.ietf-sipping-config-framework] specifies a mechanism where the 299 user agent retrieves profile data from as many as three different 300 sources. The separation of the user profile facilitates a hotelling 301 capability and the ability to easily re-assign a user to a different 302 device. The separation of the local network profile facilitates 303 properties specific to operating in the local network in a roaming 304 scenario (e.g. outbound proxy or NAT traversal properties). The 305 device profile facilitates device capability based properties as well 306 as a means for the device owner or manager to impose policy. 308 While increasing the complexity of the user agent in that it must 309 aggregate and consolidate separate profiles into one working profile, 310 constraining the properties of the various profiles to be mutually 311 exclusive, or constraining even the merging rules would severely 312 restrict functionality. 314 Profile merging rules are associated with individual datasets or even 315 associated with individual properties inside a dataset. A profile 316 MUST have a merging algorithm defined. An individual property inside 317 MAY contain a merging rule, in which case this merging rule is 318 specific to the property. If however, there is no merging rule 319 associated with a property, but the profile dataset in its entirety 320 has a merging rule, this merging rule MUST be applied to each of the 321 properties that form part of the profile. 323 A few of the more commonly used merging algorithms are defined in 324 this document. Most settings are likely to use the common set 325 defined in this document. However authors of profile datasets may 326 define new algorithms for merging dataset properties (see 327 Section 5.11 and Section 6.3 ). 329 4.1.6. The Ability to Specify Policy 331 Local Network Operators may wish to impose policy on users and 332 devices on their network such as constraining codecs, media streams, 333 outbound proxy or emergency services. It MUST be possible to impose 334 policy in any of the profile sources that constrains, overwrites or 335 modifies properties provided in datasets from other sources. 337 4.1.7. XML 339 XML is perhaps not really a requirement, but a solution base upon 340 requirements. However it is hard to ignore the desire to utilize 341 readily available tools to manage and manipulate profile data such as 342 XSLT, XPATH and XCAP. The requirement that should be considered when 343 defining the schema and syntax is that many user agents have limited 344 resources for supporting advanced XML operation. The simplest XML 345 construct possible should be used, that support the required 346 functionality. It is not a requirement that user agents validate the 347 profile XML document. This relieves the requirement that the Relax 348 NG schema defined in this and other datasets documents be enforced on 349 the user agent. The Relax NG schema should not be used to strictly 350 validate profile XML documents. Unknown elements and attributes 351 should be ignored to allow extensions to be supported. Strict 352 enforcement of the Relax NG schema would make it very difficult to 353 deploy new user agents without lock step upgrades of the profile 354 delivery server. Guidelines for the Use of Extensible Markup 355 Language (XML) within IETF Protocols [RFC3470] provides useful 356 information in this regard. 358 5. Overall Dataset Schema 360 Notifiers and Subscribers of the event package defined in 362 [I-D.ietf-sipping-config-framework] SHOULD support the content-type: 363 application/uaprofile+xml. The Notifier SHOULD indicate all of the 364 dataset schemas that is supports by listing all of the MIME types for 365 the supported datasets in the SUBSCRIBE request header: Accept. This 366 document defines an Relax NG Schema for that content-type with the 367 namespace: urn:ietf:params:xml:ns:uaprof, for SIP Profile Datasets 368 that provides: 369 o a base element type "setting" from which all settings in other 370 schema definitions inherit (this allows other definitions to 371 specify the content models for ways of combining settings; it is 372 analogous to a C++ virtual base class). 373 o Attributes to the "setting" element that define constraints and 374 other properties used to impose policy that apply to the element 375 value. These attributes are inherited by elements that are 376 derived from the abstract settings element. 377 o A root element for all property sets (the outermost container). 379 The full text of the schema is in Appendix A ; the following 380 describes the usage of the schema in defining properties and 381 combining them to construct the working profile of a User Agent. 383 5.1. Data Primitives 385 Each property in a profile data set is defined using XML Schema 386 Datatypes [W3C.REC-xmlschema-2] and Relax NG Schema. A property is 387 modeled by an XML element derived from the "setting" element in the 388 SIP Profile Data Set Schema. The element content is the setting 389 value. 391 Properties consisting of one single value can be expressed using a 392 single XML element. Properties that may consist of multiple values 393 require the use of container elements. A container element is 394 defined for such a property. This container can contain multiple XML 395 elements, which each defines a possible value for that property (see 396 examples in Section 5.5.2 ). 398 When constructing a property set, the creator of a profile may not be 399 able to know all of the capabilities of the User Agent that will 400 receive that property set. The creator of profile constraints or 401 policies should be aware that a user agent may ignore properties that 402 are unsupported or do not apply to its capabilities. 404 5.2. Use of Namespaces 406 XML namespaces [W3C.REC-xml-names-19990114] provide a means to 407 uniquely identify the elements and datatypes defined in a data set. 408 It is therefore RECOMMENDED that each data set specifies its own 409 namespace. The namespace URIs SHOULD be URNs [RFC2141] , using the 410 namespace identifier 'ietf' defined by [RFC2648] and extended by 411 [RFC3688] . The core schema defined in this document defines the 412 namespace: "urn:ietf:params:xml:ns:uaprof". Profile datasets that 413 extend this schema SHOULD define a new namespace by appending a ":" 414 and a unique name to the "urn:ietf:params:xml:ns:uaprof" namespace. 415 These namespaces MUST be registered with IANA. 417 5.3. The 'propertySet' Element 419 The root element of a property set is "propertySet"; it is the 420 container that is provided to the user agent. The elements contained 421 within a propertySet contain the specific properties which are to be 422 applied to the user agent. The properties may be simple types with a 423 single value, complex types or container elements with a list of 424 properties. 426 5.4. The Abstract 'setting_container' Element 428 The "setting_container" element is the abstract element in which a 429 list of properties which allow multiple values may be contained. 430 Elements derived from the "setting_container" element may contain 431 zero or more elements derived from the "setting" element. The 432 "setting_container" element has an "excludedPolicy" attribute. 434 5.5. The Abstract 'setting' Element 436 The setting element is the abstract element from which all profile 437 properties or settings shall inherit. 439 The setting element has a number of attributes that provide 440 functionalities, which are generally useful for many properties. 441 These attributes are inherited by properties that are derived from 442 the settings element. This enables the re-use of common 443 functionalities and ensures a common syntax for these elements across 444 different data sets. The following functionalities are provided by 445 attributes of the settings element: 447 o Property Access Control: 'visibility' attribute 448 o Policies: 'policy' attribute 450 Additional attributes are defined in the schema that may used in 451 elements derived from "setting". By default these attributes cannot 452 be set. These attribute must be explicitly added to elements derived 453 from the "setting" element: 455 o Unidirectional Properties: 'direction' attribute 456 o Preferences: 'q' attribute 458 5.5.1. The 'visibility' Attribute 460 The attribute "visibility" is defined on the "setting" element to 461 specify whether or not the user agent is permitted to display the 462 property value to the user. This is used to hide setting values that 463 the profile administrator may not want the user to see or know. The 464 "visibility" attribute has two possible values: 466 o user: Specifies that display of the property value is not 467 restricted to the user. This is the default value of the 468 attribute if it is not specified. 469 o admin: Specifies that the user agent SHOULD NOT display the 470 property value. Display of the property value may be allowed 471 using special administrative interfaces, but is not appropriate to 472 the ordinary user. 474 5.5.2. The 'policy' Attributes 476 The setting element has an optional 'policy' attribute. The policy 477 attribute is used to define the constraining properties of an 478 element. It defines how the element value is used by an endpoint 479 (e.g. whether it can or can not be used in a session). The following 480 values are defined for the 'policy' attribute: 482 o allow: the value contained in the element is allowed and SHOULD be 483 used in sessions. This is the default value that is used if the 484 'policy' attribute is omitted. 485 o disallow: the value contained in the element is forbidden and 486 SHOULD NOT be used in sessions. 488 The policy attribute can be omitted if the default policy 'allow' 489 applies. 491 The policy attribute is used only inside containers. 493 5.5.3. The 'excludedPolicy' Attributes 495 The "setting_container" element has an optional 'excludedPolicy' 496 attribute. This attribute specifies the default policy for all 497 values that are not in the container. Elements that are present in 498 the container have their own 'policy' attribute, which defines the 499 policy for that element. The following values are defined for the 500 'excludedPolicy' attribute: 502 o allow: values not listed in the container are allowed and MAY be 503 used in sessions. This is the default value that is used if the 504 'excludedPolicy' attribute is omitted. 505 o disallow: values not listed in the container are forbidden and 506 MUST NOT be used in sessions. 508 The excludedPolicy attribute can be omitted if the default policy 509 'allow' applies. The following example shows a policy that allows 510 the media type audio and disallows all other media types in sessions 511 (effectively, this construct requires the use of audio): 513 514 audio 515 517 5.5.4. The 'direction' Attribute 519 Some properties are unidirectional and only apply to messages or data 520 streams transmitted into one direction. For example, a property for 521 media streams can be restricted to outgoing media streams only. 522 Unidirectional properties can be expressed by adding a 'direction' 523 attribute to the respective element. 525 The 'direction' attribute can have the following values: 527 o recvonly: the property only applies to incoming messages/streams. 528 o sendonly: the property only applies to outgoing messages/streams. 529 o sendrecv: the property applies to messages/streams in both 530 directions. This is the default value that is used if the 531 'direction' attribute is omitted. 533 5.5.5. The 'q' Attribute 535 It should be possible to express a preference for a certain value, if 536 multiple values are allowed within a property. For example, it 537 should be possible to express that the codecs G.711 and G.729 are 538 allowed, but G.711 is preferred. Preferences can be expressed by 539 adding a 'q' attribute to a property element. Elements derived from 540 the "setting" element for which multiple occurrences and values are 541 allowed SHOULD have a "q" attribute if the order is significant. 542 Typically these elements are contained in an element derived from the 543 "setting_container" element. The 'q' attribute is only meaningful if 544 the 'policy' attribute set to 'allowed'. It must be ignored in all 545 other cases. 547 An element with a higher 'q' value is preferred over one with a lower 548 'q' value. 'q' attribute values range from 0 to 1. The default value 549 is 0.5. 551 5.6. The 'profileUri' Element 553 The element contains the URI of this profile on the 554 profile server. The value contained in the profileUri element may be 555 different than the URI subscribe to when retrieving this profile. 556 When the user agent retrieves a profile where the profileUri is 557 different than the subscribe to URI, the user agent SHOULD 558 unsubscribe to the current URI and then subscribe to the new URI. 560 The element is optional and MAY occur only once inside a 561 element. The profileUri element is specific to the 562 local-network, device or user profile in which it occurs. It has no 563 meaning outside of the profile in which it occurs and SHOULD NOT be 564 merged. 566 5.7. The 'profileCredential' Element 568 The element contains the digest authentication 569 information that SHOULD be used for authentication for the profile 570 subscription via SIP or profile retrieval via HTTP, HTTPS, etc. The 571 profileCredential element is optional and MAY occur only once inside 572 a propertySet element. The profileCredential element is specific to 573 the local-network, device or user profile in which it occurs. It has 574 no meaning outside of the profile in which it occurs and SHOULD NOT 575 be merged. The profileCredential element MUST contain exactly one of 576 each of the elements: realm, authUser and one of either a1Digest or 577 password. 579 5.7.1. realm Element 581 The realm element contains the string that defines the realm to which 582 this credential pertains. The value of the realm element is the same 583 as the realm parameter in the [RFC2617] headers: WWW-Authenticate, 584 Authorization and the SIP [RFC3261] headers: Proxy-Authenticate and 585 Proxy-Authorization. If a match of the realm value is found, the 586 user agent uses the values in the authUser and a1Digest elements 587 contained in the profileCredential element. Exactly one realm 588 element MUST be contained in a profileCredential element. A wildcard 589 of "*" MAY be used as the realm value in which case the user agent 590 MUST calculate the A1 DIGEST for the realm given in the 591 authentication challenge. If the wildcard is given for the realm, 592 the clear text form of the password contained in the password element 593 MUST also be used. 595 5.7.2. authUser Element 597 The authUser element contains the string value of the "username" 598 parameter which SHOULD be used in Authorization and Proxy- 599 Authorization request headers when retrying a request that was 600 challenged for authentication. Exactly one authUser element SHOULD 601 be contained in a profileCredential element. 603 5.7.3. a1Digest Element 605 The a1Digest element contains a string with the value of the A1 606 digest of the username, realm and password as defined in [RFC2617] . 607 At most one a1Digest element MUST be contained in a profileCredential 608 element. The a1Digest element MUST NOT exist in a profileCredential 609 element containing a password element. The username and realm used 610 to construct the value of the a1Digest element MUST match the values 611 of the realm and authUser elements contained in the profileCredential 612 element with the a1Digest element. 614 5.7.4. password Element 616 The password element contains the clear text password for use with 617 DIGEST Authentication [RFC2617] . At most one password MUST be 618 contained in a profileCredential element. The password element MUST 619 NOT exist in a profileCredential element containing a a1Digest 620 element. The user agent uses this password along with the realm and 621 authUser elements to calculate the A1 digest used for DIGEST 622 Authentication. 624 5.8. The 'profileContactUri' Element 626 The element contains a contact URI (e.g. a SIP, 627 HTTP URI or email address) under which the issuer of this profile can 628 be reached. The contact element may, for example, contain the 629 address of a support hotline. 631 The element is optional and MAY occur multiple 632 times inside a element. Multiple instances of the 633 profileContactUri element allow multiple URI schemes to be provided 634 for contact information. The user agent MAY use the URI contained 635 profile-contact-info element which has a URI scheme that the user 636 agent supports and can make work to provide support help for the 637 profile. The user agent MAY provide the URIs to the user to contact 638 the creator of the profile through other communication channels. The 639 profileContactUri element is specific to the local-network, device or 640 user profile in which it occurs. It has no meaning outside of the 641 profile in which it occurs and SHOULD NOT be merged. 643 5.9. The 'profileInfo' Element 645 The element provides a short textual description of the 646 property that should be intelligible to the human user. This element 647 may, for example, contain information about the nature of this 648 profile, such as "Access Network Profile". The text in the 649 element is in particular be helpful when a user needs 650 to decide whether or not to use a newly downloaded profile or when 651 problems with a profile (e.g. a policy conflict) occur. A user agent 652 MAY display this information in these cases. 654 The element is optional and MAY occur only once inside 655 a element. The profileInfo element is specific to the 656 local-network, device or user profile in which it occurs. It has not 657 meaning outside of the profile in which it occurs and SHOULD NOT be 658 merged. 660 5.10. Example Profile Dataset 662 The following XML example shows a SIP Profile Dataset with example 663 extension setting elements: ddd, foo, bar, boo, containerElement and 664 setting container elements: myContainer, myContainer1, myContainer2 665 and container3. 667 668 669 sip:a1b2c3d4e5f6@example.com 670 671 example.com 672 fred 673 b6b577fd12aa7e1df8d60735ef56fc2e 674 675 676 tel:+16175551212 677 sip:411@example.com 678 679 http:example.com/sipProfile.html 680 681 682 This is an example profile from example.com 683 684 fff 685 687 688 690 691 692 aaa 693 bbb 694 ccc 695 696 ggg 697 698 699 700 701 702 111 703 222 704 333 705 706 708 5.11. Merging Property Sets 710 A UA may receive property sets from multiple sources, which need to 711 be merged into a single combined document the UA can work with. 713 Properties that have a single value (e.g. the maximum bandwidth 714 allowed) require that a common value is determined for this property 715 during the merging process. The merging rules for determining this 716 value need to be defined individually for each element in the schema 717 definition. Properties that allow multiple values (i.e. property 718 containers) need to be merged by combining the values from the 719 different data sets. The following sections describe recommended 720 common merging algorithms. A data set definition may refer to these 721 algorithms. 723 5.11.1. Single Numeric Value Merging Algorithm 725 A general merging rule for elements with numeric values is to select 726 the largest or the smallest value. For example, a merging rule for a 727 element would be to select the smallest value from 728 the values that are in the competing data sets. 730 5.11.2. Multiple Enumerated Value Merging Algorithm 732 Multiple values in property containers are merged by combining the 733 values from each of the competing data sets. This is accomplished by 734 copying the elements from each property container into the merged 735 container. Elements with identical values are only copied once. The 736 'policy' attribute of two elements with the same value is adjusted 737 during the merging process according to Table 1. If an element 738 exists only in one property container, then the default policy of the 739 other container (i.e. the excludedPolicy) is used when accessing 740 Table 1. For example, if an element is disallowed in one data set 741 and the element is not contained in the other data set but the 742 default policy is allowed for that data set, then the values 743 disallowed and allowed are used to access Table 1. Consequently, the 744 element will be disallowed in the merged data set. Finally, the 745 excludedPolicy attributes of the containers are also merged using 746 Table 1. In addition to these merging rules, each schema may define 747 specific merging rules for each property container. 749 set 1 \ set 2 | allow | disallow 750 --------------+----------+---------- 751 allow | allow | disallow 752 disallow | disallow | disallow 754 Table 1: merging policies. 756 The following example illustrates the merging process for two data 757 sets. All elements are merged into one container and the policy 758 attributes are adjusted according to Table 1. The merged container 759 has the default policy disallow, which is determined using Table 1. 760 The entry for PCMA in the merged data set is redundant since it has 761 the default policy. 763 Data set 1: 764 765 PCMA 766 768 Data set 2: 769 770 PCMA 771 G729 772 774 Merged data set: 775 776 PCMA 777 G729 778 780 Some constellations of policy attributes result in an illegal merged 781 data set. They constitute a conflict that can not be resolved 782 automatically. For example, two data sets may define two non- 783 overlapping sets of allowed audio codecs and both disallow all other 784 codes. The resulting merged set of codecs would be empty, which is 785 illegal according to the schema definition of the codecs element. If 786 the use of these properties is enforced by both networks, the UA may 787 experience difficulties or may not be able to set up a session at 788 all. 790 The combined property set MUST again be valid and well-formed 791 according to the schema definitions. A conflict occurs if the 792 combined property set is not a well-formed document after the merging 793 process is completed. 795 5.11.3. Closest Value First Merging Algorithm 797 Some properties require that the values from different data sets are 798 ordered based on the origin of the data set during the merging 799 process. Property values that come from a domain close to the user 800 agent take precedence over values that were in a data set delivered 801 by a remote domain. This order can be used, for example, to select 802 the property value from the closest domain. In many cases, this is 803 the local domain of the user agent. For example, the URI of an 804 outbound proxy could be merged this way. This order can also be used 805 to generate an ordered list of property values during the merging 806 process. For example, multiple values for media intermediaries can 807 be ordered so that the closest media intermediary is traversed before 808 the second closest intermediary and so on. 810 This merging algorithm requires that the source of a data set is 811 considered. 813 If property sets are delivered through the configuration framework 814 [I-D.ietf-sipping-config-framework] , the value received through a 815 subscription using the "local-network" profile-type takes precedence 816 over values received through other profile-type subscriptions, 817 followed by device and then user profile-types. 819 The session-specific policy mechanism 820 [I-D.ietf-sip-session-policy-framework] provides an order among 821 policy servers. This order is based on the order, in which a SIP 822 message traverses the network, starting with the closest domain. 823 This order can directly be used to order property values as described 824 above. 826 5.12. Common Types 828 The schema also defines a set of common types that are used in 829 defining data sets (e.g. DataIpPort). [Need to document common 830 types.] 832 6. Defining Data Sets 834 This section covers several issues that should be take into 835 consideration when specifying new data set schemas. This is intended 836 to be a guide to authors writing specifications defining a new data 837 set schema or extensions to existing ones. 839 6.1. Namespace 841 It is RECOMMENDED that a data set defines a new XML namespace 842 [W3C.REC-xml-names-19990114] to scope all of the properties that are 843 defined in the name space. 845 6.2. Property Definitions 847 The properties defined in a data set schema may be simple (i.e. 848 having a single value) or they may be complex (i.e. a container with 849 multiple values). Each property in the data set SHOULD inherit from 850 the "setting" element. Complex properties and all of their child 851 elements each should inherit from "setting" as well. 853 A data set specification should contain a section which defines the 854 meaning of all of the properties contained in the data set. The 855 objective is to define the property such that implementers have a 856 clear definition and semantics to interpret properties in a 857 consistent way. User agents not only need to use the same profile 858 content, they need to apply the properties in a consistent way to 859 achieve true interoperability. 861 The following information should be defined for each property in a 862 data set: 863 o description: describe the meaning and application of the property. 864 o cardinality: define how many instances of this property element 865 may occur in a data set (e.g. zero, one or many) as well as its 866 relationship to any other properties in this or other data sets. 867 o default value: define the default value of this property if it is 868 not set. Describe if the default is different if the property is 869 present and not set vs. completely absent from the data set. 870 Define if the default varies in relation to another property. 872 6.3. Merging Data Sets 874 User agents may receive data sets from multiple sources. They need 875 to merge these data sets in order to create an overall data set they 876 can work with. Collisions on data sets may occur if multiple sources 877 provide different values for the same properties. These collisions 878 need to be resolved during the merging process. 880 A data set schema MUST define rules for merging data sets from 881 different sources for each property that is defined. Recommendations 882 for merging data sets are discussed in Section 5.11 . A data set 883 schema must define if and how these recommendations apply and MAY 884 define alternative merging rules for specific settings. A data set 885 schema must also identify combinations of properties that constitute 886 a conflict that can't resolved. It may provide additional guidelines 887 for the behavior of a user agent in these cases. 889 7. Candidate Data Sets 891 The following sections name some of the candidate data sets that are 892 or may be defined. These data sets can be aggregated to form 893 profiles appropriate to the capabilities of a user agent 894 implementation. 896 o SIP Protocol Data Set: the lowest common denominator set of 897 properties common to all SIP user agents of any capability. A 898 schema covering the elements of this data set can be found in 899 [I-D.petrie-sipping-sip-dataset] . 900 o Media Data Set: this data set contains media related policies. A 901 schema covering the elements of this data set can be found in 902 [I-D.ietf-sipping-media-policy-dataset] . 903 o Identity Data Set: AORs and lines (see 904 [I-D.petrie-sipping-identity-dataset] ) 905 o HTTP Protocol Data Set: server settings. Proxy for clients. 906 o NAT Traversal Data Set: settings for STUN, TURN etc. 907 o SIP Digit Maps Data Set: 908 [I-D.petrie-sipping-voip-features-dataset] 909 o VoIP Features: [I-D.petrie-sipping-voip-features-dataset] 911 8. Security Considerations 913 Security is mostly a delivery problem. The delivery framework SHOULD 914 provide a secure means of delivering the profile data as it may 915 contain sensitive data that would be undesirable if it were stolen or 916 sniffed. Storage of the profile on the profile delivery server and 917 user agent is an implementation problem. The profile delivery server 918 and the user agent SHOULD provide protection that prevents 919 unauthorized access of the profile data. The profile delivery server 920 and the user agent SHOULD enforce the access control policies defined 921 in the profile data sets if present. 922 The point of the access control construct on the data set is to 923 provide some security policy on the visibility and ability to 924 change sensitive properties. 926 Some transport mechanisms for delivery of the profile data do not 927 provide a secure means of delivery. In addition some user agents may 928 not have the resources to support the secure mechanism used for 929 delivery (e.g. TLS). 931 9. IANA Considerations 933 XML name space registration: urn:ietf:params:xml:ns:uaprof 935 9.1. Content-type registration for 'application/uaprofile+xml' 937 To: ietf-types@iana.org 938 Subject: Registration of MIME media type application/uaprofile+xml 939 MIME media type name: application 940 MIME subtype name: uaprofile+xml 941 Required parameters: (none) 942 Optional parameters: charset Indicates the character encoding of 943 enclosed XML. Default is UTF-8. 944 Encoding considerations: Uses XML, which can employ 8-bit 945 characters, depending on the character encoding used. See RFC 946 3023 [RFC3023], section 3.2. 947 Security considerations: This content type is designed to carry SIP 948 user agent profile data, which may be considered private 949 information. Appropriate precautions should be adopted to limit 950 disclosure of this information. 951 Interoperability considerations: This content type provides a common 952 format for exchange of SIP user agent profile information. 953 Published specification: RFC XXXX (Note to RFC Editor: Please fill 954 in XXXX with the RFC number of this specification) 955 Applications which use this media type: SIP user agents and profile 956 delivery servers. 957 Additional information: Magic number(s): File extension(s): 958 Macintosh File Type Code(s): 959 Person & email address to contact for further information: Sam 960 Ganesan EMail: sam.ganesan@motorola.com com 961 Intended usage: LIMITED USE 962 Author/Change controller: This specification is a proposed work item 963 of the IETF SIPPING working group, with mailing list address: 964 sipping@ietf.org 965 Other information: This media type is a specialization of 966 application/xml [RFC3023], and many of the considerations 967 described there also apply to application/uaprof+xml. 969 10. Contributors 971 Sumanth Channabasappa 972 CableLabs 973 858 Coal Creek Circle 974 Louisville, CO 80027 975 US 977 Email: sumanth@cablelabs.com 979 Sam Ganesan 980 Motorola 981 80 Central Street 982 Boxborough, MA 01719 983 US 984 Email: sam.ganesan@motorola.com 986 Volker Hilt 987 Bell Labs/Alcatel-Lucent 988 791 Holmdel-Keyport Rd 989 Holmdel, NJ 07733 990 US 992 Email: volkerh@bell-labs.com 994 11. Acknowledgments 996 The WG version of the document is based on an individual draft 997 authored by Dan Petrie, Scott Lawrence, Martin Dolly and Volker Hilt. 998 It has been reviewed by many members of the SIPPING WG. In 999 particular, we thank Henning Schulzrinne, Henry Sinnreich, Christian 1000 Stredicke for feedback on early versions of the document. We also 1001 thank Mary Barnes for her reviews and assistance with the current 1002 version of the document. 1004 12. References 1006 12.1. Normative References 1008 [I-D.ietf-sip-session-policy-framework] 1009 Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework 1010 for Session Initiation Protocol (SIP) Session Policies", 1011 draft-ietf-sip-session-policy-framework-05 (work in 1012 progress), November 2008. 1014 [I-D.ietf-sipping-config-framework] 1015 Channabasappa, S., "A Framework for Session Initiation 1016 Protocol User Agent Profile Delivery", 1017 draft-ietf-sipping-config-framework-15 (work in progress), 1018 February 2008. 1020 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1021 Requirement Levels", BCP 14, RFC 2119, March 1997. 1023 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1024 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1025 Authentication: Basic and Digest Access Authentication", 1026 RFC 2617, June 1999. 1028 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1029 Types", RFC 3023, January 2001. 1031 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1032 A., Peterson, J., Sparks, R., Handley, M., and E. 1033 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1034 June 2002. 1036 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1037 January 2004. 1039 [W3C.REC-xml-names-19990114] 1040 Hollander, D., Bray, T., and A. Layman, "Namespaces in 1041 XML", W3C REC REC-xml-names-19990114, January 1999. 1043 [W3C.REC-xmlschema-1] 1044 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1045 "XML Schema Part 1: Structures", W3C REC-xmlschema-1, 1046 May 2001, . 1048 [W3C.REC-xmlschema-2] 1049 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", 1050 W3C REC-xmlschema-2, May 2001, 1051 . 1053 12.2. Informative References 1055 [I-D.ietf-sipping-media-policy-dataset] 1056 Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent 1057 Profile Data Set for Media Policy", 1058 draft-ietf-sipping-media-policy-dataset-07 (work in 1059 progress), March 2009. 1061 [I-D.petrie-sipping-identity-dataset] 1062 Petrie, D., Channabasappa, S., and S. Ganesan, "The 1063 Session Initiation Protocol User Agent Identity Profile 1064 Data Set", draft-petrie-sipping-identity-dataset-02 (work 1065 in progress), November 2007. 1067 [I-D.petrie-sipping-sip-dataset] 1068 Channabasappa, S. and S. Ganesan, "The Core Session 1069 Initiation Protocol User Agent Protocol Data Set", 1070 draft-petrie-sipping-sip-dataset-03 (work in progress), 1071 November 2007. 1073 [I-D.petrie-sipping-voip-features-dataset] 1074 Petrie, D., Channabasappa, S., and S. Ganesan, "The 1075 Session Initiation Protocol User Agent VoIP Features Data 1076 Set", draft-petrie-sipping-voip-features-dataset-02 (work 1077 in progress), November 2007. 1079 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1081 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1082 August 1999. 1084 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 1085 the Use of Extensible Markup Language (XML) 1086 within IETF Protocols", BCP 70, RFC 3470, January 2003. 1088 Appendix A. Relax NG SIP UA Profile Schema 1090 1091 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 [0-9,a-f]{32,32} 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 sip:.* 1222 1223 1224 sips:.* 1225 1226 1227 1228 1229 1230 1231 "?.*"?<?sip:.* 1232 1233 1234 "?.*"?<?sips:.* 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 allow 1270 disallow 1271 1272 1273 1274 1275 1276 1277 user 1278 admin 1279 1280 1281 1282 1283 1284 1285 1286 sendrecv 1287 sendonly 1288 recvonly 1289 1290 1291 1292 1293 1294 1295 1296 0 1297 1 1298 1299 1300 1301 1302 1303 1 1304 65535 1305 1306 1307 1308 1309 1310 UDP 1311 TCP 1312 TLS 1313 DTLS 1314 SCTP 1315 1316 1317 1319 Appendix B. Use Cases 1321 In the following use case scenarios the device profile is provided by 1322 the device owner/manager. The owner/manager may be a service 1323 provider, an enterprise or a user administering the device setup. 1324 The user is assumed to be the end user operating the user agent. In 1325 the scenarios that the user profile is provided, the user profile 1326 contains user specific properties that the end user has set directly 1327 or indirectly through an administration process. The local network 1328 profiles represent the suggested policy behavior that the local 1329 network operator would like user agents to adhere to 1330 [I-D.ietf-sip-session-policy-framework] . From a security 1331 perspective, the local network operator cannot trust the user agent 1332 to follow the local network profile policy. The local network 1333 operator must use a means external to the user agent to enforce these 1334 policies. The local network profile is intended to express to the 1335 user agent, the policies that the user agent should follow if the 1336 user agent wants to function properly in the local network. 1338 Two different use cases are developed and discussed below. Similar 1339 use cases can be developed for individual datasets. For example, 1340 analysis of Transport protocol settings for SIP can be carried out in 1341 exactly the same fashion as the codec use case described below and a 1342 set of derived requirements to drive the schema for the associated 1343 datset can be arrived at. 1345 B.1. Outbound Proxy Setting 1347 In the case of the outbound proxy, it is unlikely that the user would 1348 want to influence the outbound proxy for SIP signaling. The device 1349 owner/manager or the local network operator are likely to want to set 1350 the outbound proxy property. The device profile may define an 1351 outbound proxy so that the device owner/manager can monitor all 1352 signaling. The local network operator also defines an outbound proxy 1353 because the proxy allows the SIP signaling to get through a NAT or 1354 firewall. 1356 Two possible solutions to this problem are listed. 1357 o Define a policy where the local network profile overrides the 1358 device profile. In this approach the local network profile wins. 1359 o Aggregate the outbound proxies. In this scenario SIP messages 1360 would be sent with a pre-populated route set that had two hops. 1361 First the outbound proxy set in the local network profile, then 1362 the outbound proxy set in the device profile. 1364 The aggregation approach is closest to solving the requirements to 1365 the use case above. By aggregating the two outbound proxies, the 1366 local network provided outbound proxy allows the signaling to get out 1367 of the local network and the device profile provided outbound proxy 1368 is able to monitor all SIP signaling from the user agent. 1370 B.2. Codec Settings 1372 Use cases for the codec properties are likely one of the more 1373 complicated sets of properties with respect to merging and 1374 constraining across more than one profile. There are reasonable 1375 scenarios where requirements can be rationalized that the device, 1376 user and local network profiles may each wish to express preferences 1377 and constraints on permitted codecs. Without getting into details or 1378 syntax of the codec properties, it is assumed that codec properties 1379 will need to express a codec definition and a preference order. This 1380 is the order that these codecs will be put in SDP for codec 1381 negotiation purposes. 1383 The following scenarios illustrate some possible combinations of 1384 sources of codec properties from the device, user and local network 1385 profiles. 1387 B.2.1. Codec Setting Not Set 1389 In the scenario where a device has no profiles or the profiles 1390 contain no codec properties, the device will enable a default set and 1391 preference order of codecs, which could be a subset of the codecs the 1392 device is capable of supporting. The default set and preference 1393 order of codecs is a implemention specific. 1395 B.2.2. Codec Set in Device Profile 1397 This scenario assumes that the device profile is the only source of 1398 codec properties. 1400 The codecs in the device profile may differ from the set of codecs 1401 supported by the device, due to administrative constraints on codec 1402 usage. 1404 In this scenario the device profile data will dictate the ordered 1405 list of codecs to be applied. The use agent will ignore codec types 1406 included in the profile that the user agent does not support. 1408 B.2.3. Set in Device and User Profiles 1410 This scenario covers the case where both the device profile and the 1411 user profile provide an ordered list of codecs. The user may prefer 1412 a higher quality codec to be used, if available. Thereby the user 1413 profile data may provide an ordered list of codecs to be applied. 1414 The device profile also specifies a list of codecs and a default 1415 preference order. 1417 The merging of the data sources is as follows: 1418 o The ordering of the codecs will be determined from the user 1419 profile data, which overrides the codec preference ordering from 1420 the device profile data. 1421 o The set of codecs that may be applied, are the codecs listed in 1422 the user data constrained by the list of codecs from the device 1423 profile data. 1425 The case in which none of the codecs in the resulting merged profile 1426 datasets are supported by the device, the profile data constitutes a 1427 misconfiguration between device and user profiles. It may not be 1428 possible to successfully establish a session in this case. It is 1429 suggested that the user agent provide feedback to the user indicating 1430 the misconfiguration. The user agent may also attempt to function in 1431 the network by ignoring one or more of the profile constraints. 1433 B.2.4. Set in Device and Local Profiles 1435 In this scenario both the local network profile and the device 1436 profile each provide an ordered set of codecs. Both the local 1437 network operator and the device provider may feel the need to 1438 constrain and order the set of codecs used. This scenario is very 1439 much alike to the previous scenario and may be resolved using a 1440 similar method. However, it likely that the local network codec 1441 preferences will override and constrain the device profile, given the 1442 caveat that in the circumstances where the resulting ordered set of 1443 codecs is an empty set. In this case there is a misconfiguration/ 1444 incompatibility between the device profile and the local network 1445 profile with regard to the codecs, which may render the device non 1446 functional. The user agent may attempt to function in the network by 1447 ignoring one or more of the profile constraints. 1449 B.2.5. Set in Device, User and Local Profiles 1451 In this scenario all profiles namely, device, user and local network 1452 profiles, provide an ordered set of codecs as preferences. For 1453 example, these may be the result of device capabilities, user's 1454 preference for higher quality media and the network providers desire 1455 to constrain bandwidth usage and or enforce uniformity of codec 1456 usage. The data sources could be merged as follows: 1457 o The ordering of the codecs will be determined from the user 1458 profile data, which overrides the ordering from the device profile 1459 data. 1460 o The set of codecs that may be used are the codecs listed in the 1461 device profile data, constrained by the list of codecs from the 1462 user profile data and further constrained by the list of codecs 1463 from the local network profile data. 1465 A resulting null set of codecs would imply a misconfiguration and may 1466 prevent the device from functioning under these circumstances. The 1467 user agent may also attempt to function in the network by ignoring 1468 one or more of the profile constraints. 1470 B.2.6. Example Derived Requirements 1472 An example set of derived requirements for the codec definition is 1473 presented here. These requirements in turn would drive the profile 1474 definition for codec usage. 1475 1. The list of codecs in the device profile data that get applied is 1476 the subset of the codecs supported by the device. Codecs listed 1477 in profiles that are not supported by the device are ignored. 1478 2. The device profile data will have a default ordered list of 1479 codecs, which implies a preference order to be used in the sdp 1480 offer. 1481 3. The user profile data may provide an ordered list of user 1482 preferred codecs. The ordering of the codecs in the user profile 1483 data will override the ordering of the codecs in the device 1484 profile data. The user list of codecs may further constrain the 1485 list of codecs to be used. 1486 4. The local network profile data may provide a list of codecs 1487 supported. This list will further constrain the list of codecs 1488 that may be offered. 1489 5. The application profile data containing codec data will be 1490 ignored. 1491 6. The profiles need the ability to express codecs that may be used 1492 and codecs that should not be used. 1494 Authors' Addresses 1496 Martin Dolly 1497 AT&T 1498 200 Laurel Ave. 1499 Middletown, NJ 1500 US 1502 Phone: 1503 Email: mdolly@att.com 1504 URI: 1506 Daniel Petrie 1507 SIPez LLC 1508 34 Robbins Rd. 1509 Arlington, MA 02476 1510 US 1512 Phone: +1 617 273 4000 1513 Email: dan.ietf AT SIPez DOT com 1514 URI: http://www.SIPez.com/ 1516 Dale R. Worley 1517 Nortel Networks Corp. 1518 600 Technology Park Dr. 1519 Billerica, MA 01821 1520 US 1522 Phone: +1 978 288 5505 1523 Email: dworley@nortel.com 1524 URI: http://www.nortel.com