idnits 2.17.1 draft-ietf-sipping-media-policy-dataset-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (April 16, 2012) is 4387 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH Working Group V. Hilt 3 Internet-Draft Bell Labs/Alcatel-Lucent 4 Intended status: Standards Track D. Worley 5 Expires: October 18, 2012 Avaya Inc. 6 G. Camarillo 7 Ericsson 8 J. Rosenberg 9 jdrosen.net 10 April 16, 2012 12 A User Agent Profile Data Set for Media Policy 13 draft-ietf-sipping-media-policy-dataset-16 15 Abstract 17 This specification defines an XML document format to describe the 18 media properties of Session Initiation Protocol (SIP) sessions. 19 Examples for media properties are the codecs or media types used in 20 the session. This document also defines an XML document format to 21 describe policies that limit the media properties of SIP sessions. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 18, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Media Policy Dataset Format . . . . . . . . . . . . . . . . . 5 60 3.1. Namespace and Media Type . . . . . . . . . . . . . . . . . 5 61 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 62 3.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.3.1. The 'visibility' Attribute . . . . . . . . . . . . . . 6 64 3.3.2. The 'direction' Attributes . . . . . . . . . . . . . . 6 65 3.3.3. The 'q' Attribute . . . . . . . . . . . . . . . . . . 6 66 3.3.4. The 'media-type' Attribute . . . . . . . . . . . . . . 7 67 3.3.5. The 'label' Attribute . . . . . . . . . . . . . . . . 7 68 3.3.6. The 'enabled' Attribute . . . . . . . . . . . . . . . 7 69 4. Session Info Documents . . . . . . . . . . . . . . . . . . . . 7 70 4.1. Mapping SDP to Session Info Documents . . . . . . . . . . 8 71 4.2. The Element . . . . . . . . . . . . . . . . 9 72 4.3. The Element . . . . . . . . . . . . . . . . . . 9 73 4.3.1. The Element . . . . . . . . . . . . . . . . . 10 74 4.4. The Element . . . . . . . . . . . . 11 75 4.4.1. The Element . . . . . . . . . . . 11 76 4.4.2. The Element . . . . . . . . . . . 12 77 4.4.3. The Element . . . . . . . . . . . 13 78 5. Session Policy Documents . . . . . . . . . . . . . . . . . . . 13 79 5.1. Merging Session Policies . . . . . . . . . . . . . . . . . 14 80 5.1.1. Single Value Selection . . . . . . . . . . . . . . . . 14 81 5.1.2. Merging Sets . . . . . . . . . . . . . . . . . . . . . 14 82 5.1.3. Local Policy Server Selection . . . . . . . . . . . . 15 83 5.2. The Element . . . . . . . . . . . . . . . 16 84 5.3. The Element . . . . . . . . . . . . 16 85 5.4. The Element . . . . . . . . . . . . 16 86 5.5. The Element . . . . . . . . . . . . . . . 17 87 5.6. The Element . . . . . . . . . . . . . . 17 88 5.7. The Element . . . . . . . . . . . . . . . . 18 89 6. Common Media Policy Dataset Elements . . . . . . . . . . . . . 18 90 6.1. The Element . . . . . . . . . . . . . . . . . 18 91 6.2. The Element . . . . . . . . . . . . . . . . . . . 19 92 6.2.1. The Element . . . . . . . . . . . 19 93 6.2.2. The Element . . . . . . . . . . . . . 19 94 6.3. The Element . . . . . . . . . . . . . . . . . . . 19 95 6.4. The Element . . . . . . . . . . . . . . . 20 96 6.5. The Element . . . . . . . . . . . . . . . 20 97 6.6. The Element . . . . . . . . . . . . . . . . . . 21 98 6.7. The Element . . . . . . . . . . . . . . . . . . 22 99 6.7.1. The Element . . . . . . . . . . . 22 100 6.7.2. The Element . . . . . . . . . . . . . . . . 22 101 6.7.3. The Element . . . . . . . . . . . . . . . . . . 23 102 6.7.4. The Element . . . . . . . . . . . . . . 23 103 6.7.5. The Element . . . . . . . . . . . . . . . . . 23 104 6.8. Other Session Properties . . . . . . . . . . . . . . . . . 23 105 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 106 7.1. Session Policy Documents . . . . . . . . . . . . . . . . . 24 107 7.2. Session Information Documents . . . . . . . . . . . . . . 24 108 7.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 24 109 7.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 25 110 8. Relax NG Definition . . . . . . . . . . . . . . . . . . . . . 28 111 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 112 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 113 10.1. Media Type Registration . . . . . . . . . . . . . . . . . 38 114 10.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 39 115 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 116 11.1. Normative References . . . . . . . . . . . . . . . . . . . 39 117 11.2. Informative References . . . . . . . . . . . . . . . . . . 41 118 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 41 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 121 1. Introduction 123 The Framework for Session Initiation Protocol (SIP) [RFC3261] User 124 Agent Profile Delivery [RFC6080] and the Framework for SIP Session 125 Policies [I-D.ietf-sip-session-policy-framework] define mechanisms to 126 convey session policies and configuration information from a network 127 server to a user agent. An important piece of the information 128 conveyed to the user agent relates to the media properties of the SIP 129 sessions set up by the user agent. Examples for these media 130 properties are the codecs and media types used, the media- 131 intermediaries to be traversed, or the maximum bandwidth available 132 for media streams. 134 This specification defines a document format for media properties of 135 SIP sessions: the Media Policy Dataset Format (MPDF). This format 136 can be used in two ways. First, it can be used to describe the 137 properties of a given SIP session (e.g., the media types and codecs 138 used). These MPDF documents are called session info documents and 139 they are usually created based on the session description of a 140 session. Second, the MPDF format can be used to define policies for 141 SIP sessions in a session policy document. A session policy document 142 defines properties for a session (e.g., the media types allowed in a 143 session), independent of a specific session description. 145 If used with the Framework for SIP Session Policies 146 [I-D.ietf-sip-session-policy-framework], session info documents are 147 used in conjunction with session-specific policies. A session info 148 document is created by a UA based on the current session description 149 and submitted to the policy server. The policy server examines the 150 session info document, modifies it if necessary (e.g., by removing 151 video streams if video is not permitted) and returns the possibly 152 modified session info document to the UA. Session policy documents 153 on the other hand are used to describe session-independent policies 154 that can be submitted to the UA independent of a specific session. 156 The two types of MPDF documents, session information and session 157 policy documents, share the same set of XML elements to describe 158 session properties. Since these elements are used in different 159 contexts for session info and session policy documents, two different 160 root elements exist for the two document types: is the 161 root element for session information documents and 162 is the root element for session policy documents. 164 A user agent can receive multiple session policy documents from 165 different sources. This can lead to a situation in which the user 166 agent needs to apply multiple session policy documents to the same 167 session. This standard specifies merging rules for those XML 168 elements that can be present in session policy documents. It should 169 be noted that these merging rules are part of the semantics of a 170 session policy XML element. User agents implement the merging rules 171 as part of implementing the element semantics. As a consequence, it 172 is not possible to build an entity that can mechanically merge two 173 session policy documents without understanding the semantics of all 174 elements in the input documents. 176 Merging rules are not needed for elements of session information 177 documents since they are created by one source and describe a 178 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. Media Policy Dataset Format 188 This section discusses fundamental properties of the Media Policy 189 Dataset Format (MPDF). 191 3.1. Namespace and Media 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 media 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. The specification of each MPDF element lists which of these 222 attributes MAY be used. If an element bears an attribute which may 223 not be used with it, the recipient MUST ignore the attribute. 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 238 for the ordinary user. 240 3.3.2. The 'direction' Attributes 242 Some properties are unidirectional and only apply to messages or data 243 streams transmitted into one direction. For example, a property for 244 media streams can be restricted to outgoing media streams only. 245 Unidirectional properties can be expressed by adding a 'direction' 246 attribute to the respective element. 248 The 'direction' attribute can have the following values: 250 o recvonly: the property only applies to incoming streams. 251 o sendonly: the property only applies to outgoing streams. 252 o sendrecv: the property applies to streams in both directions. 253 This is the default value that is used if the 'direction' 254 attribute is omitted. 256 3.3.3. The 'q' Attribute 258 It is possible to express a preference for a certain value relative 259 to the other values within a set of multiple values that are allowed 260 within a property. For example, it is possible to express that the 261 codecs G.711 and G.729 are allowed, but G.711 is preferred. 262 Preferences are be expressed by adding a 'q' attribute to a property 263 element. As specified for the elements which can have the 'q' 264 attribute, it is only allowed in contexts which specify allowed 265 values (as opposed to contexts which specify forbidden values). 267 The value of the 'q' attribute is a decimal number within the range 0 268 to 1, inclusive. An element with a higher 'q' value is preferred 269 over one with a lower 'q' value. 271 3.3.4. The 'media-type' Attribute 273 The media-type attribute is used to define that an element only 274 applies to streams of a certain media type. For example, it may only 275 apply to audio streams. The value of the 'media-type' attribute MUST 276 be the media type, such as 'audio', 'video', 'text', or 277 'application'. 279 3.3.5. The 'label' Attribute 281 The label attribute is used to identify a specific media stream. The 282 value of the label attribute is a token, whose syntax is defined in 283 [RFC4566]. The token can be chosen freely, however, it MUST be 284 unique among all elements in a session-info document. 286 3.3.6. The 'enabled' Attribute 288 The 'enabled' attribute specifies whether or not the user agent is 289 allowed to establish a media stream. This boolean attribute has two 290 possible values: 292 o yes: specifies that the media stream can be established. This is 293 the default value of the attribute if it is not specified. 294 o no: specifies that the user agent MUST NOT establish the media 295 stream. 297 4. Session Info Documents 299 Session info documents describe key properties of a SIP session such 300 as the media streams used in the session. Session info documents are 301 typically created based on an SDP [RFC4566] session description or an 302 SDP offer/answer pair [RFC3264]. 304 Session info documents can be used for session-specific policies 305 [I-D.ietf-sip-session-policy-framework]. In this usage, a UA creates 306 a session info document based on its SDP description(s) and sends 307 this document to the policy server. The policy server modifies this 308 document according to the policies that apply to the described 309 session and returns a version of the session info document that is 310 compliant to the policies. For example, if video streams are not 311 permissible under current policies and the UA submits a session info 312 document that contains a video stream, the policy server will disable 313 (i.e., enabled="no") the video stream in the session info document 314 that it returns to the UA. 316 Session info documents use the root element. They use 317 elements described in this section and common elements described in 318 Section 6. 320 Elements that are only present in session info documents do not 321 require merging rules. If used in the context of session-specific 322 policies, session info documents are sent to one policy server at a 323 time only, therefore a UA does not need to merge multiple session 324 info documents into one. A policy server needs to modify a session 325 info document it has received according to its policies. The 326 modification of session info documents is determined by the local 327 policies of the policy server and outside the scope of this standard. 329 A policy server can completely reject a session by returning an 330 session info document with an empty element: 332 <\session-info> 334 4.1. Mapping SDP to Session Info Documents 336 If a UA has an SDP offer and answer pair [RFC3264] and wants to 337 create a session info document, the UA uses the answer to fill in the 338 elements of the session info document except for the and elements, which are taken from the remote 340 and local SDP respectively, and the elements, which contain 341 the codecs that appear in both the offer and the answer. (The local 342 SDP is the one sent by the UA; the remote session description is the 343 one received from the remote UA.) 345 The following rules describe the creation of session info documents 346 based on SDP description(s) for a few exemplary elements. Other 347 elements are created following the same principles. 349 A UA MUST create a separate element for each m= line in an 350 SDP description; the order of the elements corresponds to 351 the order of the m= lines. The UA MUST insert the media type from 352 the m= line into a element and MUST create a 353 element for each codec listed in the m= line. The UA MUST insert a 354 element for each of the codecs that appear in both the offer 355 and the answer. The elements MUST have 'q' attributes with 356 values that decrease with the order the codecs are given in the m= 357 line. (Other than the ordering restriction, the particular values 358 used are not specified by this document.) 360 The UA MUST create a element for each stream using 361 the port taken from the m= line and the address from the 362 corresponding c= line of the local session description. The UA MUST 363 create a element using the port and address from 364 the m= and c= lines for the same stream taken from the remote session 365 description if this session description is available. 367 The numeric value in a "b=CT:..." attribute in a session description 368 is used to set the content of a element with the direction 369 attribute value corresponding to which SDP contains the b= attribute. 371 The numeric value in a "b=AS:..." attribute in a session description 372 is used to set the content of a element with the 373 direction attribute value corresponding to the SDP which contains the 374 b= attribute. 376 The numeric value in a "b=AS:..." attribute in a media description is 377 used to set the content of a element child of the 378 appropriate element, with the direction attribute value 379 corresponding to the SDP which contains the b= attribute. 381 An "a=label:..." attribute [RFC4574] is used to set the 'label' 382 attribute of the appropriate element. 384 The mapping from a session info document to a SDP description follows 385 essentially the same rules in the reverse direction. 387 For any particular m= line, the codecs MUST be listed in decreasing 388 order of the values of the 'q' attributes of the corresponding 389 elements. 391 4.2. The Element 393 The element describes the properties of a specific SIP 394 session. The element MAY contain one optional 395 , and multiple (including zero) , , , and 397 elements as well as elements from other namespaces. The MPDF 398 elements are defined in Section 6. 400 4.3. The Element 402 The element is a container that is used to describe the 403 media streams used in a session. A element contains zero 404 or more elements. Each element describes the 405 properties (e.g., media type, codecs and IP addresses and ports) of a 406 single media stream. 408 4.3.1. The Element 410 The element describes a specific media stream. It contains 411 the media type, codecs and the hostname(s) or IP address(es) and 412 port(s) of this stream. 414 The hostname(s) or IP address(es) and port number(s) of a stream 415 correspond to the ones listed in the session description(s). A UA 416 that generates a element MUST insert the hostname/port found 417 in the local session description for this media stream into the 418 local-host-port element. The UA MUST insert the hostname/port of the 419 remote session description into the remote-host-port element, if the 420 remote session description is available to the UA. If not, the UA 421 generates a stream element that only contains the local-host-port 422 element. 424 This element MAY have the direction, label, and enabled attributes 425 (see Section 3.3). 427 The 'label' attribute is used to identify a specific media stream. 428 The value of the label attribute is a token that is unique among all 429 elements in a session-info document and whose syntax is 430 defined in [RFC4566]. If an SDP label attribute [RFC4574] is present 431 in the SDP description, its value MUST be used as the 'label' 432 attribute value of the corresponding element. 434 The 'enabled' attribute specifies whether or not the user agent is 435 allowed to establish a media stream. 437 The element MUST contain one element, one or 438 more elements and one element. The 439 element MAY contain one element. 441 4.3.1.1. The Element 443 The element contains the hostname or IP address and 444 the receiving port number of the media stream in the local session 445 description. The hostname or IP address is separated from the port 446 by a ":". An example is: "host.example.com:49562". 448 The hostname or IP address of element is found in the c= element for 449 the stream in the local SDP description. The port number is found in 450 the m= element. 452 4.3.1.2. The Element 454 The element is structured exactly as the element. However, it identifies the hostname or IP 456 address and receiving port number of the media stream in the remote 457 session description. 459 4.4. The Element 461 The element expresses a policy for routing 462 media streams through media intermediaries. The purpose of the 463 element is to tell the UA to send media 464 streams through a chain of media intermediaries. The manner in which 465 the UA arranges for a media stream to pass through the intermediaries 466 depends on the type of intermediary. 468 The element is a container that lists all 469 media intermediaries to be traversed. Media intermediaries should be 470 traversed in the order in which they appear in this list. The 471 topmost entry should be traversed first, the last entry should be 472 traversed last. 474 Different types of intermediaries exist. These intermediaries are 475 not necessarily interoperable and it may not be possible to chain 476 them in an arbitrary order. A element SHOULD 477 therefore only contain intermediary elements of the same type. 479 This element MAY have the direction attribute (see Section 3.3). 481 Multiple elements MAY only be present in a 482 container if each applies to a different set of streams (e.g., one 483 element for incoming and one for outgoing 484 streams). The element MUST contain one or 485 more elements defining a specific media intermediary, such as or . 488 Note: it is not intended that the element 489 replaces connectivity discovery mechanisms such as ICE. Instead 490 of finding media relays that provide connectivity, this element 491 defines a policy for media intermediaries that should be 492 traversed. The set of intermediaries defined in the element and the ones discovered through ICE may 494 overlap but don't have to. 496 4.4.1. The Element 498 A fixed intermediary relies on pre-configured forwarding rules. The 499 user agent simply sends media to the first media intermediary listed. 501 It can assume that this media intermediary has been pre-configured 502 with a forwarding rule for the media stream and knows where to 503 forward the packets to. The configuration of forwarding rules in the 504 intermediary must be done through other means. 506 The contents of a element MUST be echoed to all 507 policy servers that provide policies for a session. I.e., if 508 multiple policy servers provide policies for the same session, this 509 element needs to be forwarded to all of them, possibly in a second 510 round of session-specific policy subscriptions as described in 511 [I-D.ietf-sip-session-policy-framework] in section Contacting the 512 Policy Server. 514 The element MUST contain one 515 element and MAY contain multiple optional elements. 517 4.4.1.1. The Element 519 The element contains the hostname or IP address and 520 port number of a media intermediary. The UA uses this hostname/IP 521 address and port to send its media streams to the intermediary. The 522 hostname or IP address is separated from the port by a ":". 524 If a protocol uses multiple subsequent ports (e.g., RTP), the lowest 525 port number SHOULD be included in the element. All 526 additional port numbers SHOULD be identified in 527 elements. 529 4.4.1.2. The Element 531 If a protocol uses multiple subsequent ports (e.g., RTP), the lowest 532 port number SHOULD be included in the element. All 533 additional port numbers SHOULD be identified in 534 elements. 536 4.4.2. The Element 538 The TURN [RFC5766] protocol provides a mechanism for inserting a 539 relay into the media path. Although the main purpose of TURN is NAT 540 traversal, it is possible for a TURN relay to perform other media 541 intermediary functionalities. The user agent establishes a binding 542 on the TURN server and uses this binding to transmit and receive 543 media. 545 The element MUST contain one 546 element and MAY contain multiple optional elements 547 and zero or one each of the , , and 548 elements. If no element is present, UDP is assumed. 550 4.4.2.1. The Element 552 The element contains the shared secret needed to 553 authenticate at the media intermediary. 555 4.4.2.2. The element 557 The element contains the user ID needed to authenticate to the 558 media intermediary. 560 4.4.2.3. The Element 562 The element contains the name of the transport to be used 563 for communicating with the TURN server. This document defines the 564 values "tcp" and "udp" for use in the element. Other 565 specifications may define additional values. 567 4.4.3. The Element 569 The MSRP Relay Extensions [RFC4976] define a means for incorporating 570 relays into the media path of an MSRP [RFC4975] session. MSRP is 571 explicitly designed for a variety of purposes, including policy 572 enforcement. 574 The element MUST contain one element, 575 and may contain zero or one each of the and 576 elements. 578 4.4.3.1. The Element 580 The element contains a URI that indicates the MSRP server 581 to use for an intermediary. The UA uses this URI to authenticate 582 with the MSRP relay, and then uses the URI it learns through that 583 authentication process for any MSRP media it sends or receives. The 584 URIs in the element MUST have a scheme of "msrps:". 586 5. Session Policy Documents 588 Session policy documents describe policies for SIP sessions. Session 589 policy documents are independent of any specific session description 590 and express general policies for SIP sessions. A session policy 591 document is used to determine if a SIP session is policy conformant 592 and can be used to modify the session, if needed, to conform to the 593 described policies. 595 Session policy documents can be used to encode session-independent 596 policies [I-D.ietf-sip-session-policy-framework]. In this usage, a 597 policy server creates a session policy document and passes this 598 document to a UA. The UA applies the policies defined to the SIP 599 sessions it is establishing. For example, a session policy document 600 can contain an element that prohibits the use of video. To set up a 601 session that is compliant to this policy, a UA does not include the 602 media type video in its SDP offer or answer. 604 Session policy documents use the root element. They 605 use elements described in this section and common elements described 606 in Section 6. 608 5.1. Merging Session Policies 610 A UA may receive session policy documents from multiple sources; 611 multiple session policy documents can be merged into a single session 612 policy document which expresses the logical AND of the policies. 614 5.1.1. Single Value Selection 616 Properties that have a single value (e.g., the maximum bandwidth 617 allowed) require that a common value is determined for this property 618 during the merging process. The merging rules for determining this 619 value need to be defined individually for each element in the schema 620 definition (e.g., select the lowest maximum bandwidth). 622 5.1.2. Merging Sets 624 The , , 625 and are containers that contain a set of media- 626 types/codecs. The values defined in these containers MUST be merged 627 to determine the set of media-types/codecs that are permissible in a 628 session. Note that for a particular codec, the 629 element (see Section 6.2.2) allows identifying a particular encoding 630 of profile of the codec. Therefore, when the 631 element is present, what is allowed or excluded is the particular 632 encoding or profile. Other encoding or profiles of the same codec 633 are unaffected. 635 To merge the media-types-* and codecs-* containers a UA MUST apply 636 all containers it has received one after the other the set of media- 637 types/codecs it supports. After applying media-types-*/codecs-* 638 elements, the UA has the list of media-types/codecs that are allowed 639 in a session. The containers MAY be applied in any order. However, 640 each time a container is applied to the set of media-types/codecs 641 allowed, this set MUST stay the same or be reduced. Media-types/ 642 codecs cannot be added during this process. 644 The following example illustrates the merging process for two data 645 sets. In this example, the UA supports the following set of audio 646 codecs: PCMA, PCMU and G729. After applying session policy document 647 1, the UA removes PCMA as it is disallowed by this policy. The 648 remaining set of codecs is: PCMU and G729. Session policy document 2 649 disallows all codecs that are not listed. After applying this 650 policy, the set of codecs allowed is: G729. 652 Session Policy Document 1: 653 654 audio/PCMA 655 657 Session Policy Document 2: 658 659 audio/PCMA 660 audio/G729 661 663 It is possible that two session policy documents define non- 664 overlapping sets of allowed media-types or codecs. The resulting 665 merged set would be empty, which is illegal according to the schema 666 definition of the media-types/codecs element. This constitutes a 667 conflict that cannot be resolved automatically. If these properties 668 are enforced by both networks, the UA will not be able to set up a 669 session. 671 The combined set of media-types/codecs MUST again be valid and well- 672 formed according to the schema definitions. A conflict occurs if the 673 combined property set is not a well-formed document after the merging 674 process is completed. 676 5.1.3. Local Policy Server Selection 678 Some properties require that only values from the local policy server 679 are used. The local policy server is the policy server that is in 680 the local domain of the user agent. 682 If policy documents are delivered through the configuration framework 683 [RFC6080], the value received through a subscription using the 684 "local-network" profile-type SHOULD used. Values received through 685 other profile-type subscriptions SHOULD be discarded. 687 If policy documents are delivered through the session-specific policy 688 mechanism [I-D.ietf-sip-session-policy-framework] the value received 689 from the policy server identified by the Local Policy Server URI 690 SHOULD used. Values received from other policy servers SHOULD be 691 discarded. 693 5.2. The Element 695 The element describes a policy that applies to SIP 696 sessions. The element MAY contain one optional 697 and element and multiple (including zero) 698 , , , 699 , , , and 700 elements as well as elements from other namespaces. The 701 MPDF elements are defined in Section 6. 703 5.3. The Element 705 The element is a container that is used to 706 define the set of media types (e.g., audio, video) that are allowed 707 in a session. All media types that are not listed in this container 708 are not permitted in a session. A specific media type is allowed by 709 adding the corresponding element to this container. 711 This element MAY have the direction and visibility attributes (see 712 Section 3.3). 714 Multiple elements MAY only be present in a 715 container element if each applies to a different set of streams 716 (e.g., one element for incoming and one for 717 outgoing streams). The element MUST contain 718 zero or more elements. 720 A element MUST NOT be used in a container that 721 contains a element. 723 Merging of session-policy documents: containers 724 are merged as described in "Merging Sets" Section 5.1.2. 726 5.4. The Element 728 The element is a container that is used to 729 define the set of media types (e.g., audio, video) that are not 730 permitted in a session. All media types that are not listed in this 731 container are allowed and can be used in a session. A specific media 732 type is excluded from a session by adding the corresponding element to this container. 735 This element MAY have the direction and visibility attributes (see 736 Section 3.3). 738 Multiple elements MAY only be present in a 739 container element if each applies to a different set of streams 740 (e.g., one element for incoming and one for 741 outgoing streams). The element MUST contain 742 zero or more elements. 744 A element MUST NOT be used in a container that 745 contains a element. 747 Merging of session-policy documents: 748 containers are merged as described in "Merging Sets" Section 5.1.2. 750 5.5. The Element 752 The element is a container that is used to define 753 the set of codecs that may be used in a session. All codecs not 754 listed in the element are disallowed and MUST NOT be 755 used in a session. A policy MUST allow the use of at least one codec 756 per media type. A specific codec is allowed by adding the 757 corresponding element to this container. 759 The element MAY have the direction and visibility 760 attributes (see Section 3.3). 762 Multiple elements MAY only be present in a container 763 element if each applies to a different set of streams (e.g., one 764 element for incoming and one for outgoing streams). 765 The element MUST contain zero or more 766 elements. 768 A element MUST NOT be used in a container that 769 contains a element. 771 Merging of session-policy documents: containers are 772 merged as described in "Merging Sets" Section 5.1.2. 774 5.6. The Element 776 The element is a container that is used to define 777 the set of codecs that are disallowed in a session. All codes not 778 listed in the element are permitted and MAY be used 779 in a session. A specific codec is disallowed by adding the 780 corresponding element to this container. 782 The element MAY have the direction and visibility 783 attributes (see Section 3.3). 785 Multiple elements MAY only be present in a 786 container element if each applies to a different set of streams 787 (e.g., one element for incoming and one for 788 outgoing streams). The element MUST contain zero 789 or more elements. 791 A element MUST NOT be used in a container that 792 contains a element. 794 Merging of session-policy documents: containers are 795 merged as described in "Merging Sets" Section 5.1.2. 797 5.7. The Element 799 Domains often require that a user agent only uses ports in a certain 800 range for media streams. The element defines a policy 801 for the ports a user agent can use for media. The value of this 802 element consists of the decimal representation of a start port number 803 and an end port number, separated by a "-". The start/end port 804 numbers are the first/last port numbers that can be used, that is, 805 the range is inclusive. The start/end port numbers must be in the 806 range 1 to 65535 (inclusive). 808 As with other policy elements, there are values of the 809 element that allow no sessions. This happens if the start port 810 number is greater than the end port number. 812 The default value for is "1-65535". 814 This element MAY have the visibility attributes (see Section 3.3). 816 Merging of session-policy documents: the permitted ranges specified 817 by the two policies are set-intersected. If the resulting set is 818 empty, the resulting element value MUST be any allowed 819 value with a start port number greater than the end port number. 821 6. Common Media Policy Dataset Elements 823 This section describes common XML elements that are used in session 824 info and session policy documents to encode the media properties of 825 SIP sessions. 827 6.1. The Element 829 The element identifies a specific media type. The value 830 of this element MUST be the name of a media type, such as 'audio', 831 'video', 'text', or 'application'. 833 This element MAY have the q attribute (see Section 3.3). 835 If used in a session policy document inside a 836 element, the media types defined MAY be used in a session. If used 837 in a session policy document inside a element, 838 the media types defined MUST NOT be used in a session. 840 6.2. The Element 842 The element identifies a specific codec. The content of this 843 element MUST be a media type and subtype (e.g., audio/PCMA [RFC4856] 844 or video/H263 [RFC4629]), possibly with parameters. 846 The element MAY have the q attribute (see Section 3.3). 848 If used in a session policy document inside a 849 element, the codec defined MAY be used in a session. If used in a 850 session policy document inside a element, the codec 851 defined MUST NOT be used in a session. 853 The element MUST contain one element and 854 MAY contain multiple optional elements. 856 6.2.1. The Element 858 The element contains a media type and subtype 859 that identifies a codec. The value of this element MUST be a media 860 type and subtype [RFC4855] separated by a "/" (e.g., audio/PCMA, 861 audio/G726-16 [RFC4856] or video/H263 [RFC4629]). 863 6.2.2. The Element 865 The element may be needed for some codecs to 866 identify a particular encoding or profile. The value of this element 867 MUST be a name-value pair containing the name and the value of a 868 media type parameter for the codec [RFC4855]. The name and value are 869 separated by a "=". For example, the parameter "profile=0" can be 870 used to specify a specific profile for the codec "video/H263-2000" 871 [RFC4629]. 873 6.3. The Element 875 The element defines the overall maximum bandwidth in 876 kilobits per second an entity can/will use for media streams at any 877 point in time. It defines an upper limit for the total bandwidth an 878 entity can/will use for the transmission of media streams. The limit 879 corresponds to the sum of the maximum session bandwidth of all 880 sessions a UA may set up in parallel. 882 The bandwidth limit given in the element includes the 883 bandwidth needed for lower-layer transport and network protocols 884 (e.g., UDP and IP). 886 The element MAY have the direction attribute (see 887 Section 3.3). 889 If used in a element, the element MAY also 890 have the visibility attribute (see Section 3.3). 892 If the element occurs multiple times in a container element, 893 each instance MUST apply to a different set of media streams (i.e., 894 one element for outgoing and one for incoming streams). 896 Merging of session-policy documents: the lowest max-bw value MUST be 897 used. 899 6.4. The Element 901 The element defines the maximum bandwidth in 902 kilobits per second an entity can/will use for media streams in the 903 described session. It defines an upper limit for the total bandwidth 904 of a single session. This limit corresponds to the sum of the 905 maximum stream bandwidth of all media streams in a session. 907 The bandwidth limit given in the element includes 908 the bandwidth needed for lower-layer transport and network protocols 909 (e.g., UDP and IP). 911 The element MAY have the direction attribute (see 912 Section 3.3). 914 If used in a element, the element 915 MAY also have the visibility attribute (see Section 3.3). 917 If the element occurs multiple times in a container 918 element, each instance MUST apply to a different set of media streams 919 (i.e., one element for outgoing and one for incoming 920 streams). 922 Merging of session-policy documents: the lowest max-session-bw value 923 MUST be used. 925 6.5. The Element 927 The element defines the maximum bandwidth in kilobits 928 per second an entity can/will use for each media stream in the 929 described session. 931 The bandwidth limit given in the element includes the 932 bandwidth needed as encapsulated in IP (i.e., the RTP, UDP, and IP 933 overheads are included). 935 The element MAY have the direction and media-type 936 attributes (see Section 3.3). 938 If used in a element, the element 939 MAY also have the visibility attribute (see Section 3.3). 941 If used in a element, the element MAY 942 also have the label attribute. 944 The media-type attribute is used to define that the 945 element only applies to streams of a certain media type (e.g., audio 946 streams). 948 The element is used to define a bandwidth limit for a 949 specific media stream. The use of this attribute requires that the 950 element that represents the media stream to which this 951 bandwidth limit applies also has a 'label' attribute. A 952 element with a 'label' attribute applies only to the 953 stream element that has a 'label' attribute with the same value. If 954 no matching element exists, then the element 955 MUST be ignored. 957 If the element occurs multiple times in a container 958 element, each instance MUST apply to a different set of media streams 959 (i.e., one element for outgoing and one for incoming 960 streams). 962 Merging of session-policy documents: the lowest max-stream-bw value 963 MUST be used. 965 6.6. The Element 967 The element contains an Differentiated Services Codepoint 968 (DSCP) [RFC2474] value that should be used to populate the IP DS 969 field of media packets. The contains a decimal integer 970 value that represents a 6 bit field and therefore ranges from 0 to 971 63. 973 This element MAY have the direction and media-type attributes (see 974 Section 3.3)). 976 If used in a element, the element MAY 977 also have the visibility attribute (see Section 3.3). 979 The media-type attribute is used to specify that the 980 element only applies to streams of a certain media type (e.g., audio 981 streams). 983 The element is optional and MAY occur multiple times 984 inside a container. If the element occurs multiple times, 985 each instance MUST apply to a different media stream (i.e., one element for audio and one for video streams). 988 Merging of session-policy documents: the local domain of the user 989 agent has precedence over other domains and its DSCP value MUST be 990 used. During the merging process, element values from 991 local policy server selected as described in "Local Policy Server 992 Selection" Section 5.1.3 are used. 994 6.7. The Element 996 The element provides context information about a session 997 policy or session information document. 999 The element MAY contain multiple and one 1000 element. 1002 If used in a element, the element MAY also 1003 contain a element. 1005 If used in a element, the element MAY also 1006 contain a and a element. 1008 Merging of session-policy documents: the resulting element 1009 MUST be determined by local policy. 1011 6.7.1. The Element 1013 The element contains the URI of the policy server 1014 that has issued this policy. 1016 The element is only permitted inside a element and, thus, MUST NOT be included in any other element. 1019 6.7.2. The Element 1021 The element contains a URI which is a contact address 1022 (e.g., a SIP URI or mailto URI) by which a human representative of 1023 the issuer of this document can be reached. 1025 6.7.3. The Element 1027 The element provides a short textual description of the policy 1028 or session that should be intelligible to the human user. 1030 6.7.4. The Element 1032 The element contains the request-URI of the dialog- 1033 initiating request of the session. 1035 The element is only permitted inside a 1036 element and, thus, MUST NOT be included in any other element. 1038 6.7.5. The Element 1040 The element provides a mechanism for a policy server to 1041 return an opaque string to a UA. Such a string is sometimes needed 1042 to construct a Policy-Id header which ensures that all policy 1043 requests concerning a single session are routed to the same policy 1044 server. The use of this token is described in the Framework for SIP 1045 Session Policies [I-D.ietf-sip-session-policy-framework]. Since the 1046 token value must be encodable as a SIP URI parameter value, it must 1047 consist of ASCII characters, that is, in the range U+0020 to U+007E. 1049 The element is only permitted inside a element 1050 and, thus, MUST NOT be included in any other element. 1052 6.8. Other Session Properties 1054 A number of additional elements have been proposed for a media 1055 property language. These elements are deemed to be outside the scope 1056 of this format. However, they may be defined in extensions of MPDF 1057 or other profile data sets. 1059 o maximum number of streams 1060 o maximum number of sessions 1061 o maximum number of streams per session 1062 o external address and port 1063 o media transport protocol 1064 o outbound proxy 1065 o SIP methods 1066 o SIP option tags 1067 o SIP transport protocol 1068 o body disposition 1069 o body format 1070 o body encryption 1072 7. Examples 1074 7.1. Session Policy Documents 1076 The following example describes a session policy document that allows 1077 the use of audio and video and prohibits the use of other media 1078 types. It allows the use of any codec except G.723 and G.729. 1080 1081 1082 policy@biloxi.example.com 1083 sip:policy_manager@example.com 1084 Access network policies 1085 1086 1087 audio 1088 video 1089 1090 1091 audio/G729 1092 audio/G723 1093 1094 1096 7.2. Session Information Documents 1098 The following examples contain session descriptions and the session 1099 information documents that represent these sessions. 1101 7.2.1. Example 1 1103 In this example, a session info document is created based on one 1104 session description. This session info document would be created, 1105 for example, by a UA that has composed an offer and is now contacting 1106 a policy server. 1108 Local SDP session description: 1110 v=0 1111 o=alice 2890844526 2890844526 IN IP4 host.somewhere.example 1112 s= 1113 c=IN IP4 host.somewhere.example 1114 t=0 0 1115 m=audio 49562 RTP/AVP 0 1 3 1116 a=rtpmap:0 PCMU/8000 1117 a=rtpmap:1 1016/8000 1118 a=rtpmap:3 GSM/8000 1119 m=video 51234 RTP/AVP 31 34 1120 a=rtpmap:31 H261/90000 1121 a=rtpmap:34 H263/90000 1123 MPDF document: 1125 1126 1127 sip:alice@somewhere.example 1128 session information 1129 1130 1131 1132 audio 1133 audio/PCMU 1134 audio/1016 1135 audio/GSM 1136 host.somewhere.example:49562 1137 1138 1139 video 1140 video/H261 1141 video/H263 1142 host.somewhere.example:51234 1143 1144 1145 1147 7.2.2. Example 2 1149 In this example, a session info document is created that represents 1150 two session descriptions (i.e., an offer and answer). This session 1151 info document would be created, for example, by a UA that has 1152 received an answer from another UA and is now contacting a policy 1153 server. 1155 Local SDP session description: 1157 v=0 1158 o=alice 2890844526 2890844526 IN IP4 host.somewhere.example 1159 s= 1160 c=IN IP4 host.somewhere.example 1161 t=0 0 1162 m=audio 49562 RTP/AVP 0 1 3 1163 a=rtpmap:0 PCMU/8000 1164 a=rtpmap:1 1016/8000 1165 a=rtpmap:3 GSM/8000 1166 m=video 51234 RTP/AVP 31 34 1167 a=rtpmap:31 H261/90000 1168 a=rtpmap:34 H263/90000 1170 Remote SDP session description: 1172 v=0 1173 o=bob 2890844730 2890844730 IN IP4 host.anywhere.example 1174 s= 1175 c=IN IP4 host.anywhere.example 1176 t=0 0 1177 m=audio 52124 RTP/AVP 0 3 1178 a=rtpmap:0 PCMU/8000 1179 a=rtpmap:3 GSM/8000 1180 m=video 50286 RTP/AVP 31 1181 a=rtpmap:31 H261/90000 1183 MPDF document that represents the local and the remote session 1184 description: 1186 1187 1188 sip:alice@somewhere.example 1189 session information 1190 1191 1192 1193 audio 1194 audio/PCMU 1195 audio/GSM 1196 host.somewhere.example:49562 1197 host.anywhere.example:52124 1198 1199 1200 video 1201 video/H261 1202 host.somewhere.example:51234 1203 host.anywhere.example:50286 1204 1205 1206 1208 The following MPDF document is a modified version of the above 1209 document, which can be returned by a policy server. This document 1210 reflects a policy that defines a maximum session bandwidth of 192 1211 kbit and a maximum bandwidth for the H261 video stream of 128 kbit. 1213 1214 1215 sip:alice@somewhere.example 1216 modified session information 1217 1218 1219 1220 audio 1221 audio/PCMU 1222 audio/GSM 1223 host.somewhere.example:49562 1224 host.anywhere.example:52124 1225 1226 1227 video 1228 video/H261 1229 host.somewhere.example:51234 1230 host.anywhere.example:50286 1231 1232 1233 128 1234 192 1235 1237 8. Relax NG Definition 1239 1240 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 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 1316 1317 1318 1319 1320 1321 1322 1323 1325 1326 1327 1328 1329 1330 1331 1332 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1346 1347 1348 1349 1350 1351 1352 1353 1355 1356 1357 1358 1359 1360 1361 1362 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1424 1425 1426 1427 1428 1429 1431 1432 1433 1434 1435 1436 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1487 1488 1489 1490 1491 1492 1493 1494 1495 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 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 1544 1545 1546 1547 1548 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1573 1574 1575 1576 hidden 1577 visible 1578 1579 1580 1582 1583 1584 1585 sendonly 1586 recvonly 1587 sendrecv 1588 1589 1590 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1603 1604 1605 1606 1607 1609 1610 1611 1612 1613 1615 1616 1617 1618 1619 1620 visibility 1621 direction 1622 q 1623 media-type 1624 label 1625 enabled 1626 1627 1628 1629 1630 1632 1633 1634 1635 1636 context 1637 streams 1638 max-bw 1639 max-session-bw 1640 max-stream-bw 1641 media-intermediaries 1642 qos-dscp 1643 local-ports 1644 media-types-allowed 1645 media-types-excluded 1646 media-type 1647 codecs-allowed 1648 codecs-excluded 1649 1650 1651 1652 1653 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1670 1672 9. Security Considerations 1674 Session info and session policy information can be sensitive 1675 information. The protocol used to distribute session info and 1676 session policy documents SHOULD ensure privacy, message integrity and 1677 authentication. The use of [I-D.ietf-sipping-policy-package] to 1678 distribute session info and session policy document meets these 1679 requirements. 1681 An attacker could attempt to modify session policy documents that 1682 were sent to a client so that their processing by the client would be 1683 more costly (e.g., in terms of merging policies). The attacker could 1684 also attempt to create its own fake policy documents and send them to 1685 the client with the same purpose or in order to get the client to 1686 comply with those face policies as part of a Denial of Service (DoS) 1687 attack. The protocol used to distribute session policy documents 1688 SHOULD ensure privacy, message integrity and authentication. The use 1689 of [I-D.ietf-sipping-policy-package] to distribute session policy 1690 document meets these requirements. 1692 10. IANA Considerations 1694 This document registers a new media type, application/ 1695 media-policy-dataset+xml, and a new XML namespace. 1697 10.1. Media Type Registration 1699 Media type name: application 1701 Media subtype name: media-policy-dataset+xml 1703 Mandatory parameters: none 1705 Optional parameters: Same as charset parameter application/xml as 1706 specified in RFC 3023 [RFC3023]. 1708 Encoding considerations: Same as encoding considerations of 1709 application/xml as specified in RFC 3023 [RFC3023]. 1711 Security considerations: See Section 10 of RFC 3023 [RFC3023] and 1712 Section 9 of this specification. 1714 Interoperability considerations: none. 1716 Published specification: This document. 1718 Applications which use this media type: This document type has been 1719 used to convey media policy information between SIP user agents and a 1720 domain. 1722 Additional Information: 1724 Magic Number: None 1726 File Extension: .mpf or .xml 1728 Macintosh file type code: "TEXT" 1730 Personal and email address for further information: Volker Hilt, 1731 1733 Intended usage: COMMON 1735 Author/Change controller: The IETF. 1737 10.2. URN Sub-Namespace Registration 1739 This section registers a new XML namespace, as per the guidelines in 1740 [RFC3688] 1742 URI: The URI for this namespace is 1743 urn:ietf:params:xml:schema:mediadataset. 1745 Registrant Contact: IETF, SIPPING working group, , 1746 Volker Hilt, 1748 XML: 1750 BEGIN 1751 1752 1754 1755 1756 1758 Media Policy Dataset Namespace 1759 1760 1761

Namespace for Media Policy Datasets

1762

urn:ietf:params:xml:ns:mediadataset

1763

See RFCXXXX.

1764 1765 1766 END 1768 11. References 1770 11.1. Normative References 1772 [I-D.ietf-sipping-policy-package] 1773 Camarillo, G. and V. Hilt, "A Session Initiation Protocol 1774 (SIP) Event Package for Session-Specific Session 1775 Policies.", draft-ietf-sipping-policy-package-08 (work in 1776 progress), March 2010. 1778 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1779 Requirement Levels", BCP 14, RFC 2119, March 1997. 1781 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1783 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1784 "Definition of the Differentiated Services Field (DS 1785 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1786 December 1998. 1788 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1789 Types", RFC 3023, January 2001. 1791 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1792 with Session Description Protocol (SDP)", RFC 3264, 1793 June 2002. 1795 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1796 January 2004. 1798 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1799 Description Protocol", RFC 4566, July 2006. 1801 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1802 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1804 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1805 Formats", RFC 4855, February 2007. 1807 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1808 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1810 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1811 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1812 September 2007. 1814 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1815 Relays around NAT (TURN): Relay Extensions to Session 1816 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1818 [W3C.REC-xml-20040204] 1819 Yergeau, F., Maler, E., Paoli, J., Sperberg-McQueen, C., 1820 and T. Bray, "Extensible Markup Language (XML) 1.0 (Third 1821 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1822 20040204, February 2004, 1823 . 1825 [W3C.REC-xml-names-19990114] 1826 Hollander, D., Bray, T., and A. Layman, "Namespaces in 1827 XML", World Wide Web Consortium FirstEdition REC-xml- 1828 names-19990114, January 1999, 1829 . 1831 11.2. Informative References 1833 [I-D.ietf-sip-session-policy-framework] 1834 Camarillo, G., Rosenberg, J., and V. Hilt, "A Framework 1835 for Session Initiation Protocol (SIP) Session Policies", 1836 draft-ietf-sip-session-policy-framework-10 (work in 1837 progress), February 2011. 1839 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1840 August 1999. 1842 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1843 A., Peterson, J., Sparks, R., Handley, M., and E. 1844 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1845 June 2002. 1847 [RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. 1848 Even, "RTP Payload Format for ITU-T Rec", RFC 4629, 1849 January 2007. 1851 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 1852 the RTP Profile for Audio and Video Conferences", 1853 RFC 4856, February 2007. 1855 [RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session 1856 Initiation Protocol User Agent Profile Delivery", 1857 RFC 6080, March 2011. 1859 Appendix A. Acknowledgements 1861 Many thanks to Allison Mankin, Dan Petrie, Martin Dolly, Adam Roach 1862 and Ben Campbell for the discussions and suggestions. Many thanks to 1863 Roni Even and Mary Barnes for reviewing the draft and to Jari 1864 Urpalainen for helping with the Relax NG schema. 1866 Authors' Addresses 1868 Volker Hilt 1869 Bell Labs/Alcatel-Lucent 1870 791 Holmdel-Keyport Rd 1871 Holmdel, NJ 07733 1872 USA 1874 Email: volkerh@bell-labs.com 1875 Dale R. Worley 1876 Avaya Inc. 1877 600 Technology Park Dr. 1878 Billerica, MA 01821 1879 US 1881 Email: dworley@avaya.com 1883 Gonzalo Camarillo 1884 Ericsson 1885 Hirsalantie 11 1886 Jorvas 02420 1887 Finland 1889 Email: Gonzalo.Camarillo@ericsson.com 1891 Jonathan Rosenberg 1892 jdrosen.net 1893 Monmouth, NJ 1894 USA 1896 Email: jdrosen@jdrosen.net