idnits 2.17.1 draft-ietf-sipping-media-policy-dataset-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 5, 2010) is 5159 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) ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-10) exists of draft-ietf-sip-session-policy-framework-07 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-17 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group V. Hilt 3 Internet-Draft Bell Labs/Alcatel-Lucent 4 Intended status: Standards Track D. Worley 5 Expires: September 6, 2010 Nortel Networks Corp. 6 G. Camarillo 7 Ericsson 8 J. Rosenberg 9 jdrosen.net 10 March 5, 2010 12 A User Agent Profile Data Set for Media Policy 13 draft-ietf-sipping-media-policy-dataset-09 15 Abstract 17 This specification defines a document format for the media properties 18 of Session Initiation Protocol (SIP) sessions. Examples for media 19 properties are the codecs or media types used in a session. This 20 document format is based on XML and can be used to describe the 21 properties of a specific SIP session or to define policies that are 22 then applied to SIP sessions. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on September 6, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Namespace and MIME Type . . . . . . . . . . . . . . . . . 5 67 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 68 3.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.3.1. The 'visibility' Attribute . . . . . . . . . . . . . . 6 70 3.3.2. The 'policy' Attributes . . . . . . . . . . . . . . . 6 71 3.3.3. The 'excluded-policy' Attributes . . . . . . . . . . . 6 72 3.3.4. The 'direction' Attributes . . . . . . . . . . . . . . 7 73 3.3.5. The 'q' Attribute . . . . . . . . . . . . . . . . . . 7 74 3.4. Merging Property Sets . . . . . . . . . . . . . . . . . . 7 75 3.4.1. Multiple Enumerated Value Merging Algorithm . . . . . 8 76 3.4.2. Closest Value First Merging Algorithm . . . . . . . . 9 77 3.5. The Element . . . . . . . . . . . . . . . . 10 78 4. Session Info Documents . . . . . . . . . . . . . . . . . . . . 10 79 4.1. The Element . . . . . . . . . . . . . . . . 11 80 4.2. Mapping SDP to Session Info Documents . . . . . . . . . . 11 81 5. Session Policy Documents . . . . . . . . . . . . . . . . . . . 12 82 5.1. The Element . . . . . . . . . . . . . . . 12 83 6. Media Property Elements . . . . . . . . . . . . . . . . . . . 12 84 6.1. The Element . . . . . . . . . . . . . . . . 13 85 6.1.1. The Element . . . . . . . . . . . . . . . 13 86 6.2. The Element . . . . . . . . . . . . . . . . . . . 13 87 6.2.1. The Element . . . . . . . . . . . . . . . . . 14 88 6.3. The Element . . . . . . . . . . . . . . . . . . 15 89 6.3.1. The Element . . . . . . . . . . . . . . . . . 15 90 6.4. The Element . . . . . . . . . . . . . . . . . . . 16 91 6.5. The Element . . . . . . . . . . . . . . . 16 92 6.6. The Element . . . . . . . . . . . . . . . 17 93 6.7. The Element . . . . . . . . . . . . 18 94 6.7.1. The Element . . . . . . . . . . . 19 95 6.7.2. The Element . . . . . . . . . . . 20 96 6.7.3. The Element . . . . . . . . . . . 20 97 6.8. The Element . . . . . . . . . . . . . . . . . . 21 98 6.9. The Element . . . . . . . . . . . . . . . . 22 99 6.10. The Element . . . . . . . . . . . . . . . . . . 22 100 6.10.1. The Element . . . . . . . . . . . 22 101 6.10.2. The Element . . . . . . . . . . . . . . . . 23 102 6.10.3. The Element . . . . . . . . . . . . . . . . . . 23 103 6.10.4. The Element . . . . . . . . . . . . . . 23 104 6.10.5. The Element . . . . . . . . . . . . . . . . . 23 105 6.11. Other Session Properties . . . . . . . . . . . . . . . . . 23 106 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 107 7.1. Session Policy Documents . . . . . . . . . . . . . . . . . 24 108 7.2. Session Information Documents . . . . . . . . . . . . . . 24 109 7.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 24 110 7.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 25 111 8. Relax NG Definition . . . . . . . . . . . . . . . . . . . . . 28 112 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 113 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 114 10.1. MIME Registration . . . . . . . . . . . . . . . . . . . . 35 115 10.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 36 116 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 117 11.1. Normative References . . . . . . . . . . . . . . . . . . . 36 118 11.2. Informative References . . . . . . . . . . . . . . . . . . 38 119 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 38 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 122 1. Introduction 124 The Framework for Session Initiation Protocol (SIP) [RFC3261] User 125 Agent Profile Delivery [I-D.ietf-sipping-config-framework] and the 126 Framework for SIP Session Policies 127 [I-D.ietf-sip-session-policy-framework] define mechanisms to convey 128 session policies and configuration information from a network server 129 to a user agent. An important piece of the information conveyed to 130 the user agent relates to the media properties of the SIP sessions 131 set up by the user agent. Examples for these media properties are 132 the codecs and media types used, the media-intermediaries to be 133 traversed or the maximum bandwidth available for media streams. 135 This specification defines a document format for media properties of 136 SIP sessions, the Media Policy Dataset Format (MPDF). This format 137 can be used in two ways: first, it can be used to describe the 138 properties of a given SIP session (e.g., the media types and codecs 139 used). These MPDF documents are called session info documents and 140 they are usually created based on the session description of a 141 session. Second, the MPDF format can be used to define policies for 142 SIP sessions in a session policy document. A session policy document 143 defines properties for a session (e.g., the media types allowed in a 144 session), independent of a specific session description. 146 If used with the Framework for SIP Session Policies 147 [I-D.ietf-sip-session-policy-framework], session info documents are 148 used in conjunction with session-specific policies. A session info 149 document is created by a UA based on the current session description 150 and submitted to the policy server. The policy server examines the 151 session info document, modifies it if necessary (e.g., by removing 152 video streams if video is not permitted) and returns the possibly 153 modified session info document to the UA. Session policy documents 154 on the other hand are used to describe session-independent policies 155 that can be submitted to the UA independent of a specific session. 157 The two types of MPDF documents, session information and session 158 policy documents, share the same set of XML elements to describe 159 session properties. Since these elements are used in different 160 contexts for session info and session policy documents, two different 161 root elements exist for the two document types: is the 162 root element for session information documents and 163 is the root element for session policy documents. 165 A user agent can receive multiple session policy documents from 166 different sources. This can lead to a situation in which the user 167 agent needs to apply multiple policy documents to the same session. 168 This document specifies rules for merging XML elements from multiple 169 sources and applying them to the same session. It should be noted 170 that these merging rules are part of the semantics of the XML 171 element. User agents implement the merging rules as part of 172 implementing the element semantics. As a consequence, it is not 173 possible to build an entity that can mechanically merge two session 174 policy documents without understanding the semantics of all elements 175 in the input documents. 177 Merging is not needed for session information documents since they 178 are created by one source and describe a specific session. 180 2. Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in RFC 2119 [RFC2119]. 186 3. Design Considerations 188 This section discusses design considerations for the Media Policy 189 Dataset Format (MPDF). 191 3.1. Namespace and MIME Type 193 The MPDF format is based on XML [W3C.REC-xml-20040204]. A MPDF 194 document MUST be well-formed and MUST be valid according to schemas, 195 including extension schemas, available to the validator and 196 applicable to the XML document. MPDF documents MUST be based on XML 197 1.0 and MUST be encoded using UTF-8. 199 MPDF makes use of XML namespaces [W3C.REC-xml-names-19990114]. The 200 namespace URIs for schemas defined in this specification are URNs 201 [RFC2141], using the namespace identifier 'ietf' defined by [RFC2648] 202 and extended by [RFC3688]. The namespace URN for the MPDF schema is: 204 urn:ietf:params:xml:ns:mediadataset 206 The MIME type for the Media Policy Dataset Format is: 208 application/media-policy-dataset+xml 210 3.2. Extensibility 212 The MPDF format can be extended using XML extension mechanisms if 213 additional media properties are needed. In particular, elements from 214 different XML namespaces MAY be present within a MPDF document for 215 the purposes of extensibility; elements or attributes from unknown 216 namespaces MUST be ignored. 218 3.3. Attributes 220 The following attributes can be used with elements of the MPDF 221 format. For each MPDF element it is defined, which of these 222 attributes can be used. Attributes that are not defined for an 223 element MUST be ignored. 225 3.3.1. The 'visibility' Attribute 227 The attribute "visibility" specifies whether or not the user agent is 228 permitted to display the property value to the user. This is used to 229 hide setting values that the administrator may not want the user to 230 see or know. The "visibility" attribute has two possible values: 232 o visible: specifies that display of the property value is not 233 restricted. This is the default value of the attribute if it is 234 not specified. 235 o hidden: Specifies that the user agent SHOULD NOT display the 236 property value. Display of the property value may be allowed 237 using special administrative interfaces, but is not appropriate to 238 the ordinary user. 240 3.3.2. The 'policy' Attributes 242 The 'policy' attribute attribute is used to define the constraining 243 properties of an element. It defines how the element value is used 244 by an endpoint (e.g. whether it can or can not be used in a session). 245 The following values are defined for the 'policy' attribute: 247 o allow: the value contained in the element is allowed and SHOULD be 248 used in sessions. This is the default value that is used if the 249 'policy' attribute is omitted. 250 o disallow: the value contained in the element is forbidden and MUST 251 NOT be used in sessions. 253 The policy attribute can be omitted if the default policy 'allow' 254 applies. 256 3.3.3. The 'excluded-policy' Attributes 258 The "setting_container" element has an optional 'excluded-policy' 259 attribute. This attribute specifies the default policy for all 260 values that are not in the container. Elements that are present in 261 the container have their own 'policy' attribute, which defines the 262 policy for that element. The following values are defined for the 263 'excludedPolicy' attribute: 265 o allow: values not listed in the container are allowed and MAY be 266 used in sessions. This is the default value that is used if the 267 'excludedPolicy' attribute is omitted. 268 o disallow: values not listed in the container are forbidden and 269 MUST NOT be used in sessions. 271 The excludedPolicy attribute can be omitted if the default policy 272 'allow' applies. 274 3.3.4. The 'direction' Attributes 276 Some properties are unidirectional and only apply to messages or data 277 streams transmitted into one direction. For example, a property for 278 media streams can be restricted to outgoing media streams only. 279 Unidirectional properties can be expressed by adding a 'direction' 280 attribute to the respective element. 282 The 'direction' attribute can have the following values: 284 o recvonly: the property only applies to incoming messages/streams. 285 o sendonly: the property only applies to outgoing messages/streams. 286 o sendrecv: the property applies to messages/streams in both 287 directions. This is the default value that is used if the 288 'direction' attribute is omitted. 290 3.3.5. The 'q' Attribute 292 It should be possible to express a preference for a certain value, if 293 multiple values are allowed within a property. For example, it 294 should be possible to express that the codecs G.711 and G.729 are 295 allowed, but G.711 is preferred. Preferences can be expressed by 296 adding a 'q' attribute to a property element. Elements derived from 297 the "setting" element for which multiple occurrences and values are 298 allowed SHOULD have a "q" attribute if the order is significant. 299 Typically these elements are contained in an element derived from the 300 "setting_container" element. The 'q' attribute is only meaningful if 301 the 'policy' attribute set to 'allowed'. It must be ignored in all 302 other cases. 304 An element with a higher 'q' value is preferred over one with a lower 305 'q' value. 'q' attribute values range from 0 to 1. The default value 306 is 0.5. 308 3.4. Merging Property Sets 310 A UA may receive property sets from multiple sources, which need to 311 be merged into a single combined document the UA can work with. 313 Properties that have a single value (e.g. the maximum bandwidth 314 allowed) require that a common value is determined for this property 315 during the merging process. The merging rules for determining this 316 value need to be defined individually for each element in the schema 317 definition. Properties that allow multiple values (i.e. property 318 containers) need to be merged by combining the values from the 319 different data sets. The following sections describe common merging 320 algorithms. The definition of an MPDF element can refer to these 321 algorithms. 323 OPEN ISSUE: Can we define an order for 'device', 'user', and 324 'application' profiles to simplify merging? 326 3.4.1. Multiple Enumerated Value Merging Algorithm 328 Multiple values in property containers are merged by combining the 329 values from each of the competing data sets. This is accomplished by 330 copying the elements from each property container into the merged 331 container. Elements with identical values are only copied once. The 332 'policy' attribute of two elements with the same value is adjusted 333 during the merging process according to Table 1. If an element 334 exists only in one property container, then the default policy of the 335 other container (i.e. the excludedPolicy) is used when accessing 336 Table 1. For example, if an element is disallowed in one data set 337 and the element is not contained in the other data set but the 338 default policy is allowed for that data set, then the values 339 disallowed and allowed are used to access Table 1. Consequently, the 340 element will be disallowed in the merged data set. Finally, the 341 excludedPolicy attributes of the containers are also merged using 342 Table 1. In addition to these merging rules, each schema may define 343 specific merging rules for each property container. 345 set 1 \ set 2 | mandatory | allow | disallow 346 --------------+-----------+-----------+----------- 347 mandatory | mandatory | mandatory | conflict! 348 allow | mandatory | allow | disallow 349 disallow | conflict! | disallow | disallow 351 Table 1: merging policies. 353 The following example illustrates the merging process for two data 354 sets. All elements are merged into one container and the policy 355 attributes are adjusted according to Table 1. The merged container 356 has the default policy disallow, which is determined using Table 1. 357 The entry for PCMA in the merged data set is redundant since it has 358 the default policy. 360 Data set 1: 361 362 363 audio/PCMA 364 365 367 Data set 2: 368 369 370 audio/PCMA 371 372 373 audio/G729 374 375 377 Merged data set: 378 379 380 audio/PCMA 381 382 383 audio/G729 384 385 387 Some constellations of policy attributes result in an illegal merged 388 data set. They constitute a conflict that can not be resolved 389 automatically. For example, two data sets may define two non- 390 overlapping sets of allowed audio codecs and both disallow all other 391 codes. The resulting merged set of codecs would be empty, which is 392 illegal according to the schema definition of the codecs element. If 393 the use of these properties is enforced by both networks, the UA may 394 experience difficulties or may not be able to set up a session at 395 all. 397 The combined property set MUST again be valid and well-formed 398 according to the schema definitions. A conflict occurs if the 399 combined property set is not a well-formed document after the merging 400 process is completed. 402 3.4.2. Closest Value First Merging Algorithm 404 Some properties require that the values from different data sets are 405 ordered based on the origin of the data set during the merging 406 process. Property values that come from a domain close to the user 407 agent take precedence over values that were in a data set delivered 408 by a remote domain. This order can be used, for example, to select 409 the property value from the closest domain. In many cases, this is 410 the local domain of the user agent. For example, the URI of an 411 outbound proxy could be merged this way. This order can also be used 412 to generate an ordered list of property values during the merging 413 process. For example, multiple values for media intermediaries can 414 be ordered so that the closest media intermediary is traversed before 415 the second closest intermediary and so on. 417 This merging algorithm requires that the source of a data set is 418 considered. 420 If property sets are delivered through the configuration framework 421 [I-D.ietf-sipping-config-framework], the value received through a 422 subscription using the "local-network" profile-type takes precedence 423 over values received through other profile-type subscriptions. 425 The session-specific policy mechanism 426 [I-D.ietf-sip-session-policy-framework] provides an order among 427 policy servers. This order is based on the order, in which a SIP 428 message traverses the network, starting with the closest domain. 429 This order can directly be used to order property values as described 430 above. 432 3.5. The Element 434 The root element of a property set is it is the 435 container that is provided to the user agent. The elements contained 436 within a contain the specific properties which are to 437 be applied to the user agent. 439 The element is the root element for Session Info and 440 Session Policy documents. 442 4. Session Info Documents 444 Session info documents describe key properties of a SIP session such 445 as the media streams used in the session. Session info documents are 446 typically created based on an SDP [RFC4566] session description or an 447 SDP offer/answer pair [RFC3264]. 449 Session info documents can be used for session-specific policies 450 [I-D.ietf-sip-session-policy-framework]. In this usage, a UA creates 451 a session info document based on its SDP description(s) and sends 452 this document to the policy server. The policy server modifies this 453 document according to the policies that apply to the described 454 session and returns a version of the session info document that is 455 compliant to all policies. For example, if video streams are not 456 permissible under current policies and the UA submits a session info 457 document that contains a video stream, the policy server will remove 458 the video stream from the XML markup and return the modified session 459 info document to the UA. 461 Session info documents use the element. 463 A policy server can completely reject a session by returning an 464 session info document with an empty element: 466 <\session-info> 468 4.1. The Element 470 The element describes the properties of a specific SIP 471 session. The element MAY occur multiple times inside 472 a element. 474 The element MAY contain one optional , 475 and multiple (including zero) , , 476 , and elements as 477 well as elements from other namespaces. The MPDF elements are 478 defined in Section 6. 480 4.2. Mapping SDP to Session Info Documents 482 If a UA has an SDP offer as well as an answer [RFC3264] and wants to 483 create a session info document, the UA MUST use the answer to fill in 484 the elements of the session info document except for the remote-host- 485 port and local-host-port elements, which are taken from the remote 486 and local session description respectively. The local session 487 description is the one created locally by the UA (i.e., the offer if 488 the UA has initiated the offer/answer exchange). The remote session 489 description is the one received from the remote UA. 491 The following rules describe the creation of session info documents 492 based on SDP description(s) for a few exemplary elements. Other 493 elements are created following the same principles. 495 A UA MUST create a separate element for each m= line in an 496 SDP description. The UA MUST insert the media type from the m= line 497 into a element and MUST create a element for 498 each codec listed in the m= line. 500 The UA MUST create a element for each stream using 501 the port taken from the m= line and the address from the 502 corresponding c= line of the local session description. The UA MUST 503 create a element using the port and address from 504 the m= and c= lines for the same stream taken from the remote session 505 description if this session description is available. 507 The mapping from a session info document to a SDP description follows 508 the same rules in the reverse direction. 510 5. Session Policy Documents 512 Session policy documents describe a policy for SIP sessions. Session 513 policy documents are independent of a specific session description 514 and express general policies for SIP sessions. A session policy 515 document is used to determine if a SIP session is policy conformant 516 and to modify this session, if needed, according to the described 517 policies. 519 Session policy documents can be used to encode session-independent 520 policies [I-D.ietf-sip-session-policy-framework]. In this usage, a 521 policy server creates a session policy document and passes this 522 document to a UA. The UA applies the policies defined to the SIP 523 sessions it is establishing. For example, a session policy document 524 can contain an element that prohibits the use of video. To set up a 525 session that is compliant to this policy, a UA does not include the 526 media type video in its SDP offer or answer. 528 Session policy documents use the element. 530 5.1. The Element 532 The element describes a policy that applies to SIP 533 sessions. The element MAY occur multiple times 534 inside a element. 536 The element MAY contain one optional and 537 element and multiple (including zero) , 538 , , , and 539 elements as well as elements from other namespaces. The MPDF 540 elements are defined in Section 6. 542 6. Media Property Elements 544 This section describes XML elements that are used in session info and 545 session policy documents to encode the media properties of SIP 546 sessions. 548 6.1. The Element 550 The element is a container that is used to define the 551 set of media types (e.g., audio, video) that can or cannot be used in 552 a session. A specific media type is included in the set by adding 553 the corresponding element to this container. 555 The element can only be used in session policy document 556 (i.e., inside the container). 558 This element MAY have the following attributes (see Section 3.3): 559 direction, visibility, excluded-policy. 561 Multiple elements MAY only be present in a container 562 element if each applies to a different set of streams (e.g., one 563 element for incoming and one for outgoing streams). 564 The element MUST contain one or more 565 elements. 567 Merging of session-policy documents: containers are 568 merged using the "Multiple Enumerated Value Merging Algorithm" 569 Section 3.4. 571 6.1.1. The Element 573 The element identifies a specific media type. The value 574 of this element MUST be the name of a IANA registered media type (see 575 RFC4566 [RFC4566]), such as 'audio', 'video', 'text', or 576 'application'. 578 This element MAY have the following attribute (see Section 3.3): q. 580 If used inside a element, this element MAY have the 581 following additional attribute (see Section 3.3): policy. Media 582 types that have the policy 'allowed' MAY be used and media types with 583 the policy 'disallowed' MUST NOT be used. 585 6.2. The Element 587 The element is a container that is used to define the set of 588 codecs that may or may not be used in a session. A policy MUST allow 589 the use of at least one codec per media type. A specific codec is 590 included in the set by adding the corresponding element to 591 this container. 593 The element can only be used in a session policy document 594 (i.e., inside the container). 596 The element MAY have the following attributes (see 597 Section 3.3): direction, visibility, excluded-policy. 599 Multiple elements MAY only be present in a container element 600 if each applies to a different set of streams (e.g., one 601 element for incoming and one for outgoing streams). The 602 element MUST contain one or more elements. 604 Merging of session-policy documents: containers are 605 merged using the "Multiple Enumerated Value Merging Algorithm" 606 Section 3.4. 608 6.2.1. The Element 610 The element identifies a specific codec. The content of this 611 element MUST be a registered MIME type [RFC4855] using media type and 612 subtype (e.g., audio/PCMA [RFC4856] or video/H263 [RFC4629]) and 613 possibly additional registered MIME type parameters. 615 The element MAY have the following attribute (see 616 Section 3.3): q. 618 If used inside a element, the element MAY 619 have the following additional attribute (see Section 3.3): policy. 620 Codecs that have the policy 'allowed' MAY be used and codecs with the 621 policy 'disallowed' MUST NOT be used. 623 The element MUST contain one element and MAY 624 contain multiple optional elements. 626 6.2.1.1. The Element 628 The element contains a MIME type that identifies a codec. 629 The value of this element MUST be a combination of a registered MIME 630 media type and subtype [RFC4855] separated by a "/" (e.g., audio/ 631 PCMA, audio/G726-16 [RFC4856] or video/H263 [RFC4629]). 633 6.2.1.2. The Element 635 The element may be needed for some codecs to 636 identify a particular encoding or profile. The value of this element 637 MUST be a name-value pair containing the name and the value of a 638 registered MIME type parameter for the codec [RFC4855]. The name and 639 value are separated by a "=". For example, the parameter "profile=0" 640 can be used to specify a specific profile for the codec "video/ 641 H263-2000" [RFC4629]. 643 6.3. The Element 645 The element is a container that is used to describe the 646 media streams used in a session. A element can contain 647 multiple elements. Each element describes the 648 properties (e.g., media type, codecs and IP addresses and ports) of a 649 single media stream. 651 The element is only defined for session information 652 documents (i.e., in a container). 654 The element MUST contain one or more elements. 656 6.3.1. The Element 658 The element describes a specific media stream. It contains 659 the media type, codecs and the hostname(s) or IP address(es) and 660 port(s) of this stream. 662 The hostname(s) or IP address(es) and port number(s) of a stream 663 correspond to the ones listed in the session description(s). A UA 664 that generates element MUST insert the hostname/port found 665 in the local session description for this media stream into the 666 local-host-port element. The UA MUST insert the hostname/port of the 667 remote session description into the remote-host-port element, if the 668 remote session description is available to the UA. If not, the UA 669 generates a stream element that only contains the local-host-port 670 element. 672 This element MAY have the following attributes (see Section 3.3): 673 direction, label. 675 The label attribute is used to identify a specific media stream in a 676 session description. The value of the label attribute is a token. 677 The token can be chosen freely, however, it MUST be unique among all 678 element in a session-info document. If a label attribute 679 [RFC4574] is present in the SDP description, its value MUST be 680 carried over to the label attribute of the corresponding 681 element. 683 The element MUST contain one element, one or 684 more elements and one element. The 685 element MAY contain one element. 687 6.3.1.1. The Element 689 The element contains the hostname or IP address and 690 the port number of the media stream in the local session description. 692 The hostname or IP address is separated from the port by a ":". An 693 example is: "host.example.com:49562". 695 The hostname or IP address of element is found in the c= element for 696 the stream in the local SDP description. The port number is found in 697 the m= element. 699 6.3.1.2. The Element 701 The element is structured exactly as the element. However, it identifies the hostname or IP 703 address and port number of the media stream in the remote session 704 description. 706 6.4. The Element 708 The element defines the overall maximum bandwidth in 709 kilobits per second an entity can/will use for media streams at any 710 point in time. It defines an upper limit for the total bandwidth an 711 entity can/will use for the transmission of media streams. The limit 712 corresponds to the sum of the maximum session bandwidth of all 713 sessions a UA may set up in parallel. 715 The bandwidth limit given in the element includes the 716 bandwidth needed for lower-layer transport and network protocols 717 (e.g., UDP and IP). 719 The element MAY have the following attribute (see 720 Section 3.3): direction. 722 If used in a element, the element MAY have 723 the following additional attribute (see Section 3.3): visibility. 725 If the element occurs multiple times in a container element, 726 each instance MUST apply to a different set of media streams (i.e., 727 one element for outgoing and one for incoming streams). 729 Merging of session-policy documents: the lowest max-bw value is 730 used. 732 6.5. The Element 734 The element defines the maximum bandwidth in 735 kilobits per second an entity can/will use for media streams in the 736 described session. It defines an upper limit for the total bandwidth 737 of a single session. This limit corresponds to the sum of the 738 maximum stream bandwidth of all media streams in a session. 740 The bandwidth limit given in the element includes 741 the bandwidth needed for lower-layer transport and network protocols 742 (e.g., UDP and IP). 744 The value of the element is equivalent to the CT 745 bandwidth in the b= line of an SDP [RFC4566] announcement. 747 The element MAY have the following attribute (see 748 Section 3.3): direction. 750 If used in a element, the element 751 MAY have the following additional attribute (see Section 3.3): 752 visibility. 754 If the element occurs multiple times in a container 755 element, each instance MUST apply to a different set of media streams 756 (i.e., one element for outgoing and one for incoming 757 streams). 759 Merging of session-policy documents: the lowest max-session-bw 760 value is used. 762 6.6. The Element 764 The element defines the maximum bandwidth in kilobits 765 per second an entity can/will use for each media stream in the 766 described session. 768 The bandwidth limit given in the element includes the 769 bandwidth needed for lower-layer transport and network protocols 770 (e.g., UDP and IP). 772 The value of the element is equivalent to the AS 773 bandwidth in the b= line of an SDP [RFC4566] announcement. 775 The element MAY have the following attribute (see 776 Section 3.3): direction, media-type. 778 If used in a element, the element 779 MAY have the following additional attribute (see Section 3.3): 780 visibility. 782 If used in a element, the element MAY 783 have the following additional attribute: label. 785 The media-type attribute is used to define that the 786 element only applies to streams of a certain media type. For 787 example, it may only apply to audio streams. The value of the 788 'media-type' attribute MUST be the name of a IANA registered media 789 type (see RFC4566 [RFC4566]), such as 'audio', 'video', 'text', or 790 'application'. 792 The label attribute is used to define a bandwidth limit for a 793 specific media stream. The use of this attribute requires that the 794 element that represents the media stream to which this 795 bandwidth limit applies also has a label attribute. A 796 element with a label attribute applies only to the 797 stream element that has a label attribute with the same value. If no 798 matching element exists, then the element 799 MUST be ignored. 801 If the element occurs multiple times in a container 802 element, each instance MUST apply to a different set of media streams 803 (i.e., one element for outgoing and one for incoming 804 streams). 806 Merging of session-policy documents: the lowest max-stream-bw 807 value is used. 809 6.7. The Element 811 The element expresses a policy for routing a 812 media stream through a media intermediary. The purpose of the 813 element is to tell the UA to send a media 814 stream through one (or a chain of) media intermediaries. Instead of 815 sending the media directly to its final destination, the UA specifies 816 a source route, which touches each intermediary and then reaches the 817 final recipient. If there are N hops, including the final recipient, 818 there needs to be a way for the media stream to specify N 819 destinations. 821 The element is a container that lists all 822 media intermediaries to be traversed. Media intermediaries should be 823 traversed in the order in which they appear in this list. The 824 topmost entry should be traversed first, the last entry should be 825 traversed last. 827 Different types of intermediaries exist. These intermediaries are 828 not necessarily interoperable and it may not be possible to chain 829 them in an arbitrary order. A element SHOULD 830 therefore only contain intermediary elements of the same type. 832 This element MAY have the following attributes (see Section 3.3): 833 direction. 835 Multiple elements MAY only be present in a 836 container if each applies to a different set of streams (e.g., one 837 element for incoming and one for outgoing 838 streams). The element MUST contain one or 839 more elements defining a specific media intermediary, such as or . 842 Merging of session-policy documents: the intermediaries defined in 843 all policies are traversed. In general, local intermediaries 844 should be traversed before remote intermediaries. During the 845 merging process, element values from 846 different servers are ordered using the "Closest Value First 847 Merging Algorithm" Section 3.4. The intermediaries should be 848 traversed in this order. 850 Note: it is not intended that the element 851 replaces connectivity discovery mechanisms such as ICE. Instead 852 of finding media relays that provide connectivity, this element 853 defines a policy for media intermediaries that should be 854 traversed. The set of intermediaries defined in the element and the ones discovered through ICE may 856 overlap but don't have to. 858 6.7.1. The Element 860 A fixed intermediary relies on pre-configured forwarding rules. The 861 user agent simply sends media to the first media intermediary listed. 862 It can assume that this media intermediary has been pre-configured 863 with a forwarding rule for the media stream and knows where to 864 forward the packets to. The configuration of forwarding rules in the 865 intermediary must be done through other means. 867 The contents of a element MUST be echoed to all 868 policy servers that provide policies for a session. I.e., if 869 multiple policy servers provide policies for the same session, this 870 element needs to be forwarded to all of them, possibly in a second 871 round of session-specific policy subscriptions as described in 872 [I-D.ietf-sip-session-policy-framework] in section Contacting the 873 Policy Server. 875 The element MUST contain one 876 element and MAY contain multiple optional elements. 878 6.7.1.1. The Element 880 The element contains the hostname or IP address and 881 port number of a media intermediary. The UA uses this hostname/IP 882 address and port to send its media streams to the intermediary. The 883 hostname or IP address is separated from the port by a ":". 885 If a protocol uses multiple subsequent ports (e.g., RTP), the lowest 886 port number SHOULD be included in the element. All 887 additional port numbers SHOULD be identified in 888 elements. 890 6.7.1.2. The Element 892 If a protocol uses multiple subsequent ports (e.g., RTP), the lowest 893 port number SHOULD be included in the element. All 894 additional port numbers SHOULD be identified in 895 elements. 897 6.7.2. The Element 899 The TURN [I-D.ietf-behave-turn] protocol provides a mechanism for 900 inserting a relay into the media path. Although the main purpose of 901 TURN is NAT traversal, it is possible for a TURN relay to perform 902 other media intermediary functionalities. The user agent establishes 903 a binding on the TURN server and uses this binding to transmit and 904 receive media. 906 The element MUST contain one 907 element and MAY contain multiple optional elements 908 and zero or one each of the , , and 909 elements. If no element is present, UDP is assumed. 911 6.7.2.1. The Element 913 The element contains the shared secret needed to 914 authenticate at the media intermediary. 916 6.7.2.2. The element 918 The element contains the user ID needed to authenticate to the 919 media intermediary. 921 6.7.2.3. The Element 923 The element contains the name of the transport to be used 924 for communicating with the TURN server. This document defines the 925 values "tcp" and "udp" for use in the element. Other 926 specifications may define additional values. 928 6.7.3. The Element 930 The MSRP Relay Extensions [RFC4976] define a means for incorporating 931 relays into the media path of an MSRP [RFC4975] session. MSRP is 932 explicitly designed for a variety of purposes, including policy 933 enforcement. 935 The element MUST contain one element, 936 and may contain zero or one each of the and 937 elements. 939 6.7.3.1. The Element 941 The element contains a URI that indicates the MSRP server 942 to use for an intermediary. The UA uses this URI to authenticate 943 with the MSRP relay, and then uses the URI it learns through that 944 authentication process for any MSRP media it sends or receives. Only 945 URIs with a scheme of "msrps:" are valid in the element. 947 6.8. The Element 949 The element contains an Differentiated Services Codepoint 950 (DSCP) [RFC2474] value that should be used to populate the IP DS 951 field of media packets. The contains an integer value 952 that represents a 6 bit field and therefore ranges from 0 to 63. 954 This element MAY have the following attributes (see Section 3.3): 955 direction, media-type. 957 If used in a element, the element MAY 958 have the following additional attribute (see Section 3.3): 959 visibility. 961 The media-type attribute is used to define that element 962 only applies to streams of a certain media type. For example, it may 963 only apply to audio streams. The value of the 'media-type' attribute 964 MUST be the name of a IANA registered media type (see RFC4566 965 [RFC4566]), such as 'audio', 'video', 'text', or 'application'. 967 The element is optional and MAY occur multiple times 968 inside a container. If the element occurs multiple times, 969 each instance MUST apply to a different media stream (i.e., one element for audio and one for video streams). 972 Merging of session-policy documents: the domain that is first 973 traversed by the media stream has precedence and its DSCP value is 974 used. During the merging process, element values from 975 different servers are ordered using the "Closest Value First 976 Merging Algorithm" Section 3.4. The DSCP value from the closest 977 server is used. 979 6.9. The Element 981 Domains often require that a user agent only uses ports in a certain 982 range for media streams. The element defines a policy 983 for the ports a user agent can use for media. The value of this 984 element consists of a start port and an end port separated by a "-". 985 The start/end port is the first/last port that can be used. 987 This element MAY have the following attributes (see Section 3.3): 988 visibility. 990 The element is only defined for session policy 991 documents (i.e., in a container). 993 Merging of session-policy documents: the domain that is first 994 traversed by the media stream has precedence and its local ports 995 value is used. During the merging process, element 996 values from different servers are ordered using the "Closest Value 997 First Merging Algorithm" Section 3.4. The value from the closest 998 server is used. 1000 6.10. The Element 1002 The element provides context information about a session 1003 policy or session information document. 1005 The element MAY contain multiple and one 1006 element. 1008 If used in a element, the element MAY also 1009 contain a element. 1011 If used in a element, the element MAY also 1012 contain a and a element. 1014 Merging of session-policy documents: the element is not 1015 subject to merging. 1017 6.10.1. The Element 1019 The element contains the URI of the policy server 1020 that has issued this policy. 1022 The element is only defined inside a element. 1025 6.10.2. The Element 1027 The element contains a contact address (e.g., a SIP URI or 1028 email address) under which the issuer of this document can be 1029 reached. 1031 6.10.3. The Element 1033 The element provides a short textual description of the policy 1034 or session that should be intelligible to the human user. 1036 6.10.4. The Element 1038 The element identifies the request-URI the dialog 1039 initiating request of a session is sent to. 1041 The element is only defined inside a 1042 element. 1044 6.10.5. The Element 1046 The element provides a mechanism for a policy server to 1047 return an opaque token to a UA. This is sometimes needed to ensure 1048 that all requests for a session are routed to the same policy server. 1049 The use of this token is described in the Framework for SIP Session 1050 Policies [I-D.ietf-sip-session-policy-framework]. 1052 The element is only defined inside a element. 1054 6.11. Other Session Properties 1056 A number of additional elements have been proposed for a media 1057 property language. These elements are deemed to be outside the scope 1058 of this format. However, they may be defined in extensions of MPDF 1059 or other profile data sets. 1061 o maximum number of streams 1062 o maximum number of sessions 1063 o maximum number of streams per session 1064 o external address and port 1065 o media transport protocol 1066 o outbound proxy 1067 o SIP methods 1068 o SIP option tags 1069 o SIP transport protocol 1070 o body disposition 1071 o body format 1072 o body encryption 1074 7. Examples 1076 7.1. Session Policy Documents 1078 The following example describes a session policy document that allows 1079 the use of audio and video and prohibits the use of other media 1080 types. It allows the use of any codec except G.723 and G.729. 1082 1083 1084 1085 policy@biloxi.example.com 1086 sip:policy_manager@example.com 1087 Access network policies 1088 1089 1090 audio 1091 video 1092 1093 1094 1095 audio/G729 1096 1097 1098 audio/G723 1099 1100 1101 1102 1104 7.2. Session Information Documents 1106 The following examples contain session descriptions and the session 1107 information documents that represent these sessions. 1109 7.2.1. Example 1 1111 In this example, a session info document is created based on one 1112 session description. This session info document would be created, 1113 for example, by a UA that has composed an offer and is now contacting 1114 a policy server. 1116 Local SDP session description: 1118 v=0 1119 o=alice 2890844526 2890844526 IN IP4 host.somewhere.example 1120 s= 1121 c=IN IP4 host.somewhere.example 1122 t=0 0 1123 m=audio 49562 RTP/AVP 0 1 3 1124 a=rtpmap:0 PCMU/8000 1125 a=rtpmap:1 1016/8000 1126 a=rtpmap:3 GSM/8000 1127 m=video 51234 RTP/AVP 31 34 1128 a=rtpmap:31 H261/90000 1129 a=rtpmap:34 H263/90000 1131 MPDF document: 1133 1134 1135 1136 sip:alice@somewhere.example 1137 session information 1138 1139 1140 1141 audio 1142 audio/PCMU 1143 audio/1016 1144 audio/GSM 1145 host.somewhere.example:49562 1146 1147 1148 video 1149 video/H261 1150 video/H263 1151 host.somewhere.example:51234 1152 1153 1154 1155 1157 7.2.2. Example 2 1159 In this example, a session info document is created that represents 1160 two session descriptions (i.e., an offer and answer). This session 1161 info document would be created, for example, by a UA that has 1162 received an answer from another UA and is now contacting a policy 1163 server. 1165 Local SDP session description: 1167 v=0 1168 o=alice 2890844526 2890844526 IN IP4 host.somewhere.example 1169 s= 1170 c=IN IP4 host.somewhere.example 1171 t=0 0 1172 m=audio 49562 RTP/AVP 0 1 3 1173 a=rtpmap:0 PCMU/8000 1174 a=rtpmap:1 1016/8000 1175 a=rtpmap:3 GSM/8000 1176 m=video 51234 RTP/AVP 31 34 1177 a=rtpmap:31 H261/90000 1178 a=rtpmap:34 H263/90000 1180 Remote SDP session description: 1182 v=0 1183 o=bob 2890844730 2890844730 IN IP4 host.anywhere.example 1184 s= 1185 c=IN IP4 host.anywhere.example 1186 t=0 0 1187 m=audio 52124 RTP/AVP 0 3 1188 a=rtpmap:0 PCMU/8000 1189 a=rtpmap:3 GSM/8000 1190 m=video 50286 RTP/AVP 31 1191 a=rtpmap:31 H261/90000 1193 MPDF document that represents the local and the remote session 1194 description: 1196 1197 1198 1199 sip:alice@somewhere.example 1200 session information 1201 1202 1203 1204 audio 1205 audio/PCMU 1206 audio/GSM 1207 host.somewhere.example:49562 1208 host.anywhere.example:52124 1209 1210 1211 video 1212 video/H261 1213 host.somewhere.example:51234 1214 host.anywhere.example:50286 1215 1216 1217 1218 1220 The following MPDF document is a modified version of the above 1221 document, which can be returned by a policy server. This document 1222 reflects a policy that defines a maximum session bandwidth of 192 1223 kbit and a maximum bandwidth for the H261 video stream of 128 kbit. 1225 1226 1227 1228 sip:alice@somewhere.example 1229 modified session information 1230 1231 1232 1233 audio 1234 audio/PCMU 1235 audio/GSM 1236 host.somewhere.example:49562 1237 host.anywhere.example:52124 1238 1239 1240 video 1241 video/H261 1242 host.somewhere.example:51234 1243 host.anywhere.example:50286 1244 1245 1246 128 1247 192 1248 1249 1251 8. Relax NG Definition 1253 ?xml version="1.0"?> 1254 1258 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1421 1422 1423 1424 1425 1426 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1477 1478 1479 1480 1481 1482 1483 1484 1485 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1545 1546 1547 1548 1549 1551 1552 1553 1554 1555 1557 1559 9. Security Considerations 1561 Session policy information can be sensitive information. The 1562 protocol used to distribute session policy information SHOULD ensure 1563 privacy, message integrity and authentication. Furthermore, the 1564 protocol SHOULD provide access controls which restrict who can see 1565 who else's session policy information. 1567 10. IANA Considerations 1569 This document registers a new MIME type, application/ 1570 media-policy-dataset+xml, and a new XML namespace. 1572 10.1. MIME Registration 1574 MIME media type name: application 1576 MIME subtype name: media-policy-dataset+xml 1578 Mandatory parameters: none 1580 Optional parameters: Same as charset parameter application/xml as 1581 specified in RFC 3023 [RFC3023]. 1583 Encoding considerations: Same as encoding considerations of 1584 application/xml as specified in RFC 3023 [RFC3023]. 1586 Security considerations: See Section 10 of RFC 3023 [RFC3023] and 1587 Section 9 of this specification. 1589 Interoperability considerations: none. 1591 Published specification: This document. 1593 Applications which use this media type: This document type has been 1594 used to convey media policy information between SIP user agents and a 1595 domain. 1597 Additional Information: 1599 Magic Number: None 1601 File Extension: .mpf or .xml 1603 Macintosh file type code: "TEXT" 1605 Personal and email address for further information: Volker Hilt, 1606 1608 Intended usage: COMMON 1610 Author/Change controller: The IETF. 1612 10.2. URN Sub-Namespace Registration 1614 This section registers a new XML namespace, as per the guidelines in 1615 [RFC3688] 1617 URI: The URI for this namespace is 1618 urn:ietf:params:xml:ns:mediadataset. 1620 Registrant Contact: IETF, SIPPING working group, , 1621 Volker Hilt, 1623 XML: 1625 BEGIN 1626 1627 1629 1630 1631 1633 Media Policy Dataset Namespace 1634 1635 1636

Namespace for Media Policy Datasets

1637

urn:ietf:params:xml:ns:mediadataset

1638

See RFCXXXX.

1639 1640 1641 END 1643 11. References 1645 11.1. Normative References 1647 [I-D.ietf-behave-turn] 1648 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 1649 Relays around NAT (TURN): Relay Extensions to Session 1650 Traversal Utilities for NAT (STUN)", 1651 draft-ietf-behave-turn-16 (work in progress), July 2009. 1653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1654 Requirement Levels", BCP 14, RFC 2119, March 1997. 1656 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1658 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1659 "Definition of the Differentiated Services Field (DS 1660 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1661 December 1998. 1663 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1664 Types", RFC 3023, January 2001. 1666 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1667 with Session Description Protocol (SDP)", RFC 3264, 1668 June 2002. 1670 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1671 January 2004. 1673 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1674 Description Protocol", RFC 4566, July 2006. 1676 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1677 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1679 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1680 Formats", RFC 4855, February 2007. 1682 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1683 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1685 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1686 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1687 September 2007. 1689 [W3C.REC-xml-20040204] 1690 Maler, E., Sperberg-McQueen, C., Paoli, J., Yergeau, F., 1691 and T. Bray, "Extensible Markup Language (XML) 1.0 (Third 1692 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1693 20040204, February 2004, 1694 . 1696 [W3C.REC-xml-names-19990114] 1697 Bray, T., Hollander, D., and A. Layman, "Namespaces in 1698 XML", World Wide Web Consortium FirstEdition REC-xml- 1699 names-19990114, January 1999, 1700 . 1702 11.2. Informative References 1704 [I-D.ietf-sip-session-policy-framework] 1705 Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework 1706 for Session Initiation Protocol (SIP) Session Policies", 1707 draft-ietf-sip-session-policy-framework-07 (work in 1708 progress), February 2010. 1710 [I-D.ietf-sipping-config-framework] 1711 Channabasappa, S., "A Framework for Session Initiation 1712 Protocol User Agent Profile Delivery", 1713 draft-ietf-sipping-config-framework-17 (work in progress), 1714 February 2010. 1716 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1717 August 1999. 1719 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1720 A., Peterson, J., Sparks, R., Handley, M., and E. 1721 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1722 June 2002. 1724 [RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. 1725 Even, "RTP Payload Format for ITU-T Rec", RFC 4629, 1726 January 2007. 1728 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 1729 the RTP Profile for Audio and Video Conferences", 1730 RFC 4856, February 2007. 1732 Appendix A. Acknowledgements 1734 Many thanks to Allison Mankin, Dan Petrie, Martin Dolly, Adam Roach 1735 and Ben Campbell for the discussions and suggestions. Many thanks to 1736 Roni Even and Mary Barnes for reviewing the draft and to Jari 1737 Urpalainen for helping with the Relax NG schema. 1739 Authors' Addresses 1741 Volker Hilt 1742 Bell Labs/Alcatel-Lucent 1743 791 Holmdel-Keyport Rd 1744 Holmdel, NJ 07733 1745 USA 1747 Email: volkerh@bell-labs.com 1749 Dale R. Worley 1750 Nortel Networks Corp. 1751 600 Technology Park Dr. 1752 Billerica, MA 01821 1753 US 1755 Email: dworley@nortel.com 1757 Gonzalo Camarillo 1758 Ericsson 1759 Hirsalantie 11 1760 Jorvas 02420 1761 Finland 1763 Email: Gonzalo.Camarillo@ericsson.com 1765 Jonathan Rosenberg 1766 jdrosen.net 1767 Monmouth, NJ 1768 USA 1770 Email: jdrosen@jdrosen.net