idnits 2.17.1 draft-camarillo-rai-media-policy-dataset-04.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 : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2012) is 4230 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) -- Obsolete informational reference (is this intentional?): RFC 4583 (Obsoleted by RFC 8856) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAI V. Hilt 3 Internet-Draft Bell Labs/Alcatel-Lucent 4 Intended status: Standards Track G. Camarillo 5 Expires: March 29, 2013 Ericsson 6 J. Rosenberg 7 jdrosen.net 8 D. Worley 9 Avaya Inc. 10 September 25, 2012 12 A User Agent Profile Data Set for Media Policy 13 draft-camarillo-rai-media-policy-dataset-04 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 March 29, 2013. 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 between SDP and Session Info Documents . . . . . . 8 71 4.2. The Element . . . . . . . . . . . . . . . . 10 72 4.3. The Element . . . . . . . . . . . . . . . . . . 10 73 4.3.1. The Element . . . . . . . . . . . . . . . . . 10 74 4.4. The Element . . . . . . . . . . . . 11 75 4.4.1. The Element . . . . . . . . . . . 12 76 4.4.2. The Element . . . . . . . . . . . 13 77 4.4.3. The Element . . . . . . . . . . . 13 78 5. Session Policy Documents . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . 16 83 5.2. The Element . . . . . . . . . . . . . . . 16 84 5.3. The Element . . . . . . . . . . . . 16 85 5.4. The Element . . . . . . . . . . . . 17 86 5.5. The Element . . . . . . . . . . . . . . . 17 87 5.6. The Element . . . . . . . . . . . . . . 18 88 5.7. The Element . . . . . . . . . . . . . . . . 18 89 6. Common Media Policy Dataset Elements . . . . . . . . . . . . . 19 90 6.1. The Element . . . . . . . . . . . . . . . . . 19 91 6.2. The Element . . . . . . . . . . . . . . . . . . . 19 92 6.2.1. The Element . . . . . . . . . . . 19 93 6.2.2. The Element . . . . . . . . . . . . . 20 94 6.3. The Element . . . . . . . . . . . . . . . . . . . 20 95 6.4. The Element . . . . . . . . . . . . . . . 20 96 6.5. The Element . . . . . . . . . . . . . . . 21 97 6.6. The Element . . . . . . . . . . . . . . . . . . 22 98 6.7. The Element . . . . . . . . . . . . . . . . . . 22 99 6.7.1. The Element . . . . . . . . . . . 23 100 6.7.2. The Element . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . . . 37 113 10.1. Media Type Registration . . . . . . . . . . . . . . . . . 38 114 10.2. RELAX NG Schema Registration . . . . . . . . . . . . . . . 38 115 10.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 39 116 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 117 11.1. Normative References . . . . . . . . . . . . . . . . . . . 39 118 11.2. Informative References . . . . . . . . . . . . . . . . . . 41 119 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 41 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 122 1. Introduction 124 The Framework for Session Initiation Protocol (SIP) [RFC3261] User 125 Agent Profile Delivery [RFC6080] and the Framework for SIP Session 126 Policies [I-D.ietf-sip-session-policy-framework] define mechanisms to 127 convey session policies and configuration information from a network 128 server to a user agent. An important piece of the information 129 conveyed to the user agent relates to the media properties of the SIP 130 sessions set up by the user agent. Examples for these media 131 properties are the codecs and media types used, the media- 132 intermediaries to be traversed, or the maximum bandwidth available 133 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 session policy documents to the same 168 session. This standard specifies merging rules for those XML 169 elements that can be present in session policy documents. It should 170 be noted that these merging rules are part of the semantics of a 171 session policy XML element. User agents implement the merging rules 172 as part of implementing the element semantics. As a consequence, it 173 is not possible to build an entity that can mechanically merge two 174 session policy documents without understanding the semantics of all 175 elements in the input documents. 177 Merging rules are not needed for elements of session information 178 documents since they are created by one source and describe a 179 specific session. 181 2. Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC 2119 [RFC2119]. 187 3. Media Policy Dataset Format 189 This section discusses fundamental properties of the Media Policy 190 Dataset Format (MPDF). 192 3.1. Namespace and Media Type 194 The MPDF format is based on XML [W3C.REC-xml-20081126]. A MPDF 195 document MUST be well-formed and MUST be valid according to schemas, 196 including extension schemas, available to the validator and 197 applicable to the XML document. MPDF documents MUST be based on XML 198 1.0 and MUST be encoded using UTF-8. 200 MPDF makes use of XML namespaces [W3C.REC-xml-names-19990114]. The 201 namespace URIs for elements defined in this specification are URNs 202 [RFC2141], using the namespace identifier 'ietf' defined by [RFC2648] 203 and extended by [RFC3688]. The namespace URN for the MPDF schema is: 205 urn:ietf:params:xml:ns:mediadataset 207 The media type for the Media Policy Dataset Format is: 209 application/media-policy-dataset+xml 211 3.2. Extensibility 213 The MPDF format can be extended using XML extension mechanisms if 214 additional media properties are needed. In particular, elements from 215 different XML namespaces MAY be present within a MPDF document for 216 the purposes of extensibility; elements or attributes from unknown 217 namespaces MUST be ignored. 219 3.3. Attributes 221 The following attributes can be used with elements of the MPDF 222 format. The specification of each MPDF element lists which of these 223 attributes can be used. If an element bears an attribute which may 224 not be used with it, the user agent MUST ignore the attribute. 226 3.3.1. The 'visibility' Attribute 228 The attribute 'visibility' specifies whether or not the user agent is 229 advised to display the property value to the user. This is used to 230 hide setting values that the administrator may not want the user to 231 see or know. The 'visibility' attribute has two possible values: 233 o visible: specifies that display of the property value is not 234 restricted. This is the default value of the attribute if it is 235 not specified. 236 o hidden: Specifies that the user agent is not advised to display 237 the property value. Display of the property value may be allowed 238 using special administrative interfaces, but is not appropriate 239 for the ordinary user. 241 3.3.2. The 'direction' Attributes 243 Some properties are unidirectional and only apply to messages or data 244 streams transmitted into one direction. For example, a property for 245 media streams can be restricted to outgoing media streams only. 246 Unidirectional properties can be expressed by adding a 'direction' 247 attribute to the respective element. 249 The 'direction' attribute can have the following values: 251 o recvonly: the property only applies to incoming streams. 252 o sendonly: the property only applies to outgoing streams. 253 o sendrecv: the property applies to streams in both directions. 254 This is the default value that is used if the 'direction' 255 attribute is omitted. 257 3.3.3. The 'q' Attribute 259 It is possible to express a preference for a certain value relative 260 to the other values within a set of multiple values that are allowed 261 within a property. For example, it is possible to express that the 262 codecs G.711 and G.729 are allowed, but G.711 is preferred. 263 Preferences are be expressed by adding a 'q' attribute to a property 264 element. The 'q' attribute is only allowed in elements that specify 265 allowed values (as opposed to elements that specify forbidden 266 values). 268 The value of the 'q' attribute is a decimal number within the range 0 269 to 1, inclusive, with two or less decimal places. An element with a 270 higher 'q' value is preferred over one with a lower 'q' value. 272 3.3.4. The 'media-type' Attribute 274 The media-type attribute is used to define that an element only 275 applies to streams of a certain media type, as defined in Section 276 8.2.1 of [RFC4566]. For example, it may only apply to audio streams. 277 The value of the 'media-type' attribute MUST be the media type, such 278 as 'audio', 'video', 'text', or 'application'. 280 3.3.5. The 'label' Attribute 282 The label attribute is used to identify a specific media stream. The 283 value of the label attribute is a token, whose syntax is defined in 284 [RFC4566]. The token can be chosen freely, however, it MUST be 285 unique among all elements in a session-info document. 287 3.3.6. The 'enabled' Attribute 289 The 'enabled' attribute specifies whether or not the user agent is 290 allowed to establish a media stream. This boolean attribute has two 291 possible values: 293 o yes: specifies that the media stream can be established. This is 294 the default value of the attribute if it is not specified. 295 o no: specifies that the user agent MUST NOT establish the media 296 stream. 298 4. Session Info Documents 300 Session info documents describe key properties of a SIP session such 301 as the media streams used in the session. Session info documents are 302 typically created based on an SDP [RFC4566] session description or an 303 SDP offer/answer pair [RFC3264]. 305 Session info documents can be used for session-specific policies 306 [I-D.ietf-sip-session-policy-framework]. In this usage, a UA creates 307 a session info document based on its SDP description(s) and sends 308 this document to the policy server. The policy server modifies this 309 document according to the policies that apply to the described 310 session and returns a version of the session info document that is 311 compliant to the policies. For example, if video streams are not 312 permissible under current policies and the UA submits a session info 313 document that contains a video stream, the policy server will disable 314 (i.e., enabled="no") the video stream in the session info document 315 that it returns to the UA. 317 Session info documents use the root element. They use 318 elements described in this section and common elements described in 319 Section 6. 321 Elements that are only present in session info documents do not 322 require merging rules. If used in the context of session-specific 323 policies, session info documents are sent to one policy server at a 324 time only, therefore a UA does not need to merge multiple session 325 info documents into one. A policy server needs to modify a session 326 info document it has received according to its policies. The 327 modification of session info documents is determined by the local 328 policies of the policy server and is, thus, outside the scope of this 329 standard. 331 A policy server can completely reject a session by returning an 332 session info document with an empty element: 334 336 4.1. Mapping between SDP and Session Info Documents 338 This section specifies how to map information in an SDP session 339 description or an SDP offer/answer pair [RFC3264] to session info 340 documents. It also specifies how to map a session info document into 341 an SDP description. Note that these mapping rules do not include 342 rules for all elements that need to be present in a session info 343 document or in an SDP description. That is, some of those elements 344 are generated following their associated general rules (e.g., the 345 general rules to generate SDP v= and t= lines). 347 A UA with an SDP session description that needs to create a session 348 info document uses the data in the session description and maps it 349 following the rules below. A UA with an SDP offer/answer pair that 350 needs to create a session info document uses the data that has been 351 agreed in the offer/answer exchange. 353 A UA MUST create a separate element for each m= line in an 354 SDP description or SDP offer/answer pair; the order of the 355 elements corresponds to the order of the m= lines. For an SDP 356 description, the UA MUST insert the media type from the m= line into 357 a element and MUST create a element for each 358 codec listed in the m= line. For an SDP offer/answer pair, the UA 359 MUST insert a element for each of the codecs that were agreed 360 upon for the particular stream in the offer/answer exchange. The 361 elements MUST have 'q' attributes with values that decrease 362 with the order the codecs are given in the m= line. (Other than the 363 ordering restriction, the particular values used are not specified by 364 this document.) 366 The UA MUST create a element for each stream using 367 the port taken from the m= line and the address from the 368 corresponding c= line of the local session description. The UA 369 SHOULD create a element using the port and address 370 from the m= and c= lines for the same stream taken from the remote 371 session description if this session description is available. (The 372 local SDP is the one sent by the UA; the remote SDP is the one 373 received from the remote UA.) 375 The contains information that may be considered 376 sensitive from a privacy stand point. A UA configured not to 377 disclose that information would not include the 378 element in its session info documents. 380 The numeric value in a "b=CT:..." attribute in a session description 381 is used to set the content of a element with the direction 382 attribute value corresponding to which SDP contains the b= attribute. 384 The numeric value in a "b=AS:..." attribute at the session level in a 385 session description is used to set the content of a 386 element with the direction attribute value corresponding to the SDP 387 which contains the b= attribute. 389 The numeric value in a "b=AS:..." attribute at the media level in a 390 media description is used to set the content of a 391 element child of the appropriate element, with the direction 392 attribute value corresponding to the SDP which contains the b= 393 attribute. 395 An "a=label:..." attribute [RFC4574] is used to set the 'label' 396 attribute of the appropriate element. 398 The mapping from a session info document to a SDP description follows 399 the same rules in the reverse direction. 401 For any particular m= line, the codecs MUST be listed in decreasing 402 order of the values of the 'q' attributes of the corresponding 403 elements. 405 4.2. The Element 407 The element describes the properties of a specific SIP 408 session. The element MAY contain the optional 409 and elements, and multiple (including zero) 410 , , , 411 and elements, as well as elements from other namespaces. 413 4.3. The Element 415 The element is a container that is used to describe the 416 media streams used in a session. A element contains zero 417 or more elements. Each element describes the 418 properties (e.g., media type, codecs and IP addresses and ports) of a 419 single media stream. 421 4.3.1. The Element 423 The element describes a specific media stream. It contains 424 the media type, codecs and the hostname(s) or IP address(es) and 425 port(s) of this stream. 427 The hostname(s) or IP address(es) and port number(s) of a stream 428 correspond to the ones listed in the session description(s). A UA 429 that generates a element MUST insert the hostname/port found 430 in the local session description for this media stream into the 431 local-host-port element. The UA SHOULD insert the hostname/port of 432 the remote session description into the remote-host-port element, if 433 the remote session description is available to the UA. If not, the 434 UA generates a stream element that only contains the local-host-port 435 element. 437 This element MAY have the direction, label, and enabled attributes 438 (see Section 3.3). 440 The 'label' attribute is used to identify a specific media stream. 441 The value of the label attribute is a token that is unique among all 442 elements in a session-info document and whose syntax is 443 defined in [RFC4566]. 445 The 'enabled' attribute specifies whether or not the user agent is 446 allowed to establish a media stream. 448 The element MUST contain one element, one or 449 more elements and one element. The 450 element MUST contain zero or one 451 elements. 453 4.3.1.1. The Element 455 The element contains the hostname or IP address and 456 the receiving port number of the media stream in the local session 457 description. The hostname or IP address is separated from the port 458 by a ":". An example is: "host.example.com:49562". 460 The hostname or IP address of element is found in the c= element for 461 the stream in the local SDP description. The port number is found in 462 the m= element. 464 4.3.1.2. The Element 466 The element is structured exactly as the element. However, it identifies the hostname or IP 468 address and receiving port number of the media stream in the remote 469 session description. 471 4.4. The Element 473 The element expresses a policy for routing 474 media streams through media intermediaries. The purpose of the 475 element is to tell the UA to send media 476 streams through a chain of media intermediaries. The manner in which 477 the UA arranges for a media stream to pass through the intermediaries 478 depends on the type of intermediary. 480 The element is a container that lists all 481 media intermediaries to be traversed. Media intermediaries should be 482 traversed in the order in which they appear in this list. The 483 topmost entry should be traversed first, the last entry should be 484 traversed last. 486 Different types of intermediaries exist. These intermediaries are 487 not necessarily interoperable and it may not be possible to chain 488 them in an arbitrary order. A element SHOULD 489 therefore only contain intermediary elements of the same type. 491 This element MAY have the direction attribute (see Section 3.3). 493 Multiple elements MUST NOT be present in a 494 container unless each applies to a different set of streams (e.g., 495 one element for incoming and one for outgoing 496 streams). The element MUST contain one or 497 more elements defining a specific media intermediary, such as or . 500 Note: it is not intended that the element 501 replaces connectivity discovery mechanisms such as ICE. Instead 502 of finding media relays that provide connectivity, this element 503 defines a policy for media intermediaries that should be 504 traversed. The set of intermediaries defined in the element and the ones discovered through ICE may 506 overlap but don't have to. 508 4.4.1. The Element 510 A fixed intermediary relies on pre-configured forwarding rules. The 511 user agent simply sends media to the first media intermediary listed. 512 It can assume that this media intermediary has been pre-configured 513 with a forwarding rule for the media stream and knows where to 514 forward the packets to. The configuration of forwarding rules in the 515 intermediary must be done through other means. 517 The contents of a element MUST be echoed to all 518 policy servers that provide policies for a session. I.e., if 519 multiple policy servers provide policies for the same session, this 520 element needs to be forwarded to all of them, possibly in a second 521 round of session-specific policy subscriptions as described in 522 [I-D.ietf-sip-session-policy-framework] in section Contacting the 523 Policy Server. 525 The element MUST contain one 526 element and MAY contain multiple optional elements. 528 4.4.1.1. The Element 530 The element contains the hostname or IP address and 531 port number of a media intermediary. The UA uses this hostname/IP 532 address and port to send its media streams to the intermediary. The 533 hostname or IP address is separated from the port by a ":". 535 If a protocol uses multiple subsequent ports (e.g., RTP), the lowest 536 port number SHOULD be included in the element. All 537 additional port numbers SHOULD be identified in 538 elements. 540 4.4.1.2. The Element 542 If a protocol uses multiple subsequent ports (e.g., RTP), the lowest 543 port number SHOULD be included in the element. All 544 additional port numbers SHOULD be identified in 545 elements. 547 4.4.2. The Element 549 The TURN [RFC5766] protocol provides a mechanism for inserting a 550 relay into the media path. Although the main purpose of TURN is NAT 551 traversal, it is possible for a TURN relay to perform other media 552 intermediary functionalities. The user agent establishes a binding 553 on the TURN server and uses this binding to transmit and receive 554 media. 556 The element MUST contain one 557 element and MAY contain multiple optional elements 558 and zero or one each of the , , and 559 elements. If no element is present, UDP is assumed. 561 4.4.2.1. The Element 563 The element contains the shared secret needed to 564 authenticate at the media intermediary. 566 4.4.2.2. The element 568 The element contains the user ID needed to authenticate to the 569 media intermediary. 571 4.4.2.3. The Element 573 The element contains the name of the transport to be used 574 for communicating with the TURN server. This document defines the 575 values "tcp" and "udp" for use in the element. Other 576 specifications may define additional values. 578 4.4.3. The Element 580 The MSRP Relay Extensions [RFC4976] define a means for incorporating 581 relays into the media path of an MSRP [RFC4975] session. MSRP is 582 explicitly designed for a variety of purposes, including policy 583 enforcement. 585 The element MUST contain one element, 586 and may contain zero or one each of the and 587 elements. 589 4.4.3.1. The Element 591 The element contains a URI that indicates the MSRP server 592 to use for an intermediary. The UA uses this URI to authenticate 593 with the MSRP relay, and then uses the URI it learns through that 594 authentication process for any MSRP media it sends or receives. The 595 URIs in the element MUST have a scheme of "msrps:". 597 5. Session Policy Documents 599 Session policy documents describe policies for SIP sessions. Session 600 policy documents are independent of any specific session description 601 and express general policies for SIP sessions. A session policy 602 document is used to determine if a SIP session is policy conformant 603 and can be used to modify the session, if needed, to conform to the 604 described policies. 606 Session policy documents can be used to encode session-independent 607 policies [I-D.ietf-sip-session-policy-framework]. In this usage, a 608 policy server creates a session policy document and passes this 609 document to a UA. The UA applies the policies defined to the SIP 610 sessions it is establishing. For example, a session policy document 611 can contain an element that prohibits the use of video. To set up a 612 session that is compliant to this policy, a UA does not include the 613 media type video in its SDP offer or answer. 615 Session policy documents use the root element. They 616 use elements described in this section and common elements described 617 in Section 6. 619 5.1. Merging Session Policies 621 A UA may receive session policy documents from multiple sources; 622 multiple session policy documents can be merged into a single session 623 policy document which expresses the logical AND of the policies. 625 5.1.1. Single Value Selection 627 Properties that have a single value (e.g., the maximum bandwidth 628 allowed) require that a common value is determined for this property 629 during the merging process. The merging rules for determining this 630 value need to be defined individually for each element in the schema 631 definition (e.g., select the lowest maximum bandwidth). 633 5.1.2. Merging Sets 635 The , , 636 and are containers that contain a set of media- 637 types/codecs. The values defined in these containers MUST be merged 638 to determine the set of media-types/codecs that are permissible in a 639 session. Note that for a particular codec, the 640 element (see Section 6.2.2) allows identifying a particular encoding 641 or profile of the codec. Therefore, when the 642 element is present, what is allowed or excluded is the particular 643 encoding or profile. Other encodings or profiles of the same codec 644 are unaffected. 646 To merge the media-types-* and codecs-* containers a UA MUST apply 647 all containers it has received one after the other to the set of 648 media-types/codecs it supports. After applying media-types-*/ 649 codecs-* elements, the UA has the list of media-types/codecs that are 650 allowed in a session. The containers MAY be applied in any order. 651 However, each time a container is applied to the set of media-types/ 652 codecs allowed, this set MUST stay the same or be reduced. Media- 653 types/codecs cannot be added during this process. 655 The following example illustrates the merging process for two data 656 sets. In this example, the UA supports the following set of audio 657 codecs: PCMA, PCMU and G729. After applying session policy document 658 1, the UA removes PCMA as it is disallowed by this policy. The 659 remaining set of codecs is: PCMU and G729. Session policy document 2 660 disallows all codecs that are not listed. After applying this 661 policy, the set of codecs allowed is: G729. 663 Session Policy Document 1: 664 665 audio/PCMA 666 668 Session Policy Document 2: 669 670 audio/PCMA 671 audio/G729 672 674 It is possible that two session policy documents define non- 675 overlapping sets of allowed media-types or codecs. The resulting 676 merged set would be empty, which is illegal according to the schema 677 definition of the media-types/codecs element. This constitutes a 678 conflict that cannot be resolved automatically. If these properties 679 are enforced by both networks, the UA will not be able to set up a 680 session. 682 The combined set of media-types/codecs MUST again be valid and well- 683 formed according to the schema definitions. A conflict occurs if the 684 combined property set is not a well-formed document after the merging 685 process is completed. 687 5.1.3. Local Policy Server Selection 689 Some properties require that only values from the local policy server 690 are used. The local policy server is the policy server that is in 691 the local domain of the user agent. 693 If policy documents are delivered through the configuration framework 694 [RFC6080], the value received through a subscription using the 695 "local-network" profile-type SHOULD used. Values received through 696 other profile-type subscriptions SHOULD be discarded. 698 If policy documents are delivered through the session-specific policy 699 mechanism [I-D.ietf-sip-session-policy-framework] the value received 700 from the policy server identified by the Local Policy Server URI 701 SHOULD used. Values received from other policy servers SHOULD be 702 discarded. 704 5.2. The Element 706 The element describes a policy that applies to SIP 707 sessions. The element MAY contain the optional 708 and elements and multiple (including zero) 709 , , , 710 , , , and 711 elements as well as elements from other namespaces. 713 5.3. The Element 715 The element is a container that is used to 716 define the set of media types (e.g., audio, video) that are allowed 717 in a session. All media types that are not listed in this container 718 are not permitted in a session. A specific media type is allowed by 719 adding the corresponding element to this container. 721 This element MAY have the direction and visibility attributes (see 722 Section 3.3). 724 Multiple elements MUST NOT be present in a 725 container element unless each applies to a different set of streams 726 (e.g., one element for incoming and one for 727 outgoing streams). The element MUST contain 728 zero or more elements. 730 A element MUST NOT be used in a container that 731 contains a element. 733 Merging of session-policy documents: containers 734 are merged as described in "Merging Sets" Section 5.1.2. 736 5.4. The Element 738 The element is a container that is used to 739 define the set of media types (e.g., audio, video) that are not 740 permitted in a session. All media types that are not listed in this 741 container are allowed and can be used in a session. A specific media 742 type is excluded from a session by adding the corresponding element to this container. 745 This element MAY have the direction and visibility attributes (see 746 Section 3.3). 748 Multiple elements MUST NOT be present in a 749 container element unless each applies to a different set of streams 750 (e.g., one element for incoming and one for 751 outgoing streams). The element MUST contain 752 zero or more elements. 754 A element MUST NOT be used in a container that 755 contains a element. 757 Merging of session-policy documents: 758 containers are merged as described in "Merging Sets" Section 5.1.2. 760 5.5. The Element 762 The element is a container that is used to define 763 the set of codecs that may be used in a session. All codecs not 764 listed in the element are disallowed and MUST NOT be 765 used in a session. A policy MUST allow the use of at least one codec 766 per media type. A specific codec is allowed by adding the 767 corresponding element to this container. 769 The element MAY have the direction and visibility 770 attributes (see Section 3.3). 772 Multiple elements MUST NOT be present in a container 773 element unless each applies to a different set of streams (e.g., one 774 element for incoming and one for outgoing streams). 775 The element MUST contain zero or more 776 elements. 778 A element MUST NOT be used in a container that 779 contains a element. 781 Merging of session-policy documents: containers are 782 merged as described in "Merging Sets" Section 5.1.2. 784 5.6. The Element 786 The element is a container that is used to define 787 the set of codecs that are disallowed in a session. All codecs not 788 listed in the element are permitted and MAY be used 789 in a session. A specific codec is disallowed by adding the 790 corresponding element to this container. 792 The element MAY have the direction and visibility 793 attributes (see Section 3.3). 795 Multiple elements MUST NOT be present in a 796 container element unless each applies to a different set of streams 797 (e.g., one element for incoming and one for 798 outgoing streams). The element MUST contain zero 799 or more elements. 801 A element MUST NOT be used in a container that 802 contains a element. 804 Merging of session-policy documents: containers are 805 merged as described in "Merging Sets" Section 5.1.2. 807 5.7. The Element 809 Domains often require that a user agent only uses ports in a certain 810 range for media streams. The element defines a policy 811 for the ports a user agent can use for media. The value of this 812 element consists of the decimal representation of a start port number 813 and an end port number, separated by a "-". The start/end port 814 numbers are the first/last port numbers that can be used, that is, 815 the range is inclusive. The start/end port numbers must be in the 816 range 1 to 65535 (inclusive). 818 As with other policy elements, there are values of the 819 element that allow no sessions. This happens if the start port 820 number is greater than the end port number. 822 The default value for is "1-65535". 824 This element MAY have the visibility attributes (see Section 3.3). 826 Merging of session-policy documents: the permitted ranges specified 827 by the two policies are set-intersected. If the resulting set is 828 empty, the resulting element value MUST be any allowed 829 value with a start port number greater than the end port number. 831 6. Common Media Policy Dataset Elements 833 This section describes common XML elements that are used in session 834 info and session policy documents to encode the media properties of 835 SIP sessions. 837 6.1. The Element 839 The element identifies a specific media type. The value 840 of this element MUST be the name of a media type, as defined in 841 Section 8.2.1 of [RFC4566], such as 'audio', 'video', 'text', or 842 'application'. 844 This element MAY have the q attribute (see Section 3.3). 846 If used in a session policy document inside a 847 element, the media types defined MAY be used in a session. If used 848 in a session policy document inside a element, 849 the media types defined MUST NOT be used in a session. 851 6.2. The Element 853 The element identifies a specific codec. The content of this 854 element MUST be a media type and subtype (e.g., audio/PCMA [RFC4856] 855 or video/H263 [RFC4629]), possibly with parameters. 857 The element MAY have the q attribute (see Section 3.3). 859 If used in a session policy document inside a 860 element, the codec defined MAY be used in a session. If used in a 861 session policy document inside a element, the codec 862 defined MUST NOT be used in a session. 864 The element MUST contain one element and 865 MAY contain multiple optional elements. 867 6.2.1. The Element 869 The element contains a media type and subtype 870 that identifies a media format [RFC4566] (e.g., a codec). For audio 871 and video streams, the value of this element MUST be a media type and 872 subtype that is registered as an RTP Payload Type [RFC4855] separated 873 by a "/" (e.g., audio/PCMA, audio/G726-16 [RFC4856] or video/H263 874 [RFC4629]). For other media types, SDP sometimes encodes the actual 875 media format as part of the transport protocol field (e.g., TCP/MSRP 876 [RFC4975] and TCP/TLS/BFCP [RFC4583]). In these cases, this element 877 MUST contain the media type and the media format part (e.g., message/ 878 msrp and application/bfcp). 880 6.2.2. The Element 882 The element may be needed for some codecs to 883 identify a particular encoding or profile. The value of this element 884 MUST be a name-value pair containing the name and the value of a 885 media type parameter for the codec [RFC4855]. The name and value are 886 separated by a "=". For example, the parameter "profile=0" can be 887 used to specify a specific profile for the codec "video/H263-2000" 888 [RFC4629]. 890 6.3. The Element 892 The element defines the overall maximum bandwidth in 893 kilobits per second (i.e., 1024 bits per second) an entity can/will 894 use for media streams at any point in time. It defines an upper 895 limit for the total bandwidth an entity can/will use for the 896 transmission of media streams. The limit corresponds to the sum of 897 the maximum session bandwidth of all sessions a UA may set up in 898 parallel. 900 The bandwidth limit given in the element includes the 901 bandwidth needed for lower-layer transport and network protocols 902 (e.g., UDP and IP). 904 The element MAY have the direction attribute (see 905 Section 3.3). 907 If used in a element, the element MAY also 908 have the visibility attribute (see Section 3.3). 910 If the element occurs multiple times in a container element, 911 each instance MUST apply to a different set of media streams (i.e., 912 one element for outgoing and one for incoming streams). 914 Merging of session-policy documents: the lowest max-bw value MUST be 915 used. 917 6.4. The Element 919 The element defines the maximum bandwidth in 920 kilobits per second (i.e., 1024 bits per second) an entity can/will 921 use for media streams in the described session. It defines an upper 922 limit for the total bandwidth of a single session. This limit 923 corresponds to the sum of the maximum stream bandwidth of all media 924 streams in a session. 926 The bandwidth limit given in the element includes 927 the bandwidth needed for lower-layer transport and network protocols 928 (e.g., UDP and IP). 930 The element MAY have the direction attribute (see 931 Section 3.3). 933 If used in a element, the element 934 MAY also have the visibility attribute (see Section 3.3). 936 If the element occurs multiple times in a container 937 element, each instance MUST apply to a different set of media streams 938 (i.e., one element for outgoing and one for incoming 939 streams). 941 Merging of session-policy documents: the lowest max-session-bw value 942 MUST be used. 944 6.5. The Element 946 The element defines the maximum bandwidth in kilobits 947 per second (i.e., 1024 bits per second) an entity can/will use for 948 each media stream in the described session. 950 The bandwidth limit given in the element includes the 951 bandwidth needed as encapsulated in IP (i.e., the RTP, UDP, and IP 952 overheads are included). 954 The element MAY have the direction and media-type 955 attributes (see Section 3.3). 957 If used in a element, the element 958 MAY also have the visibility attribute (see Section 3.3). 960 If used in a element, the element MAY 961 also have the label attribute. 963 The media-type attribute is used to define that the 964 element only applies to streams of a certain media type (e.g., audio 965 streams). 967 The element is used to define a bandwidth limit for a 968 specific media stream. The use of this attribute requires that the 969 element that represents the media stream to which this 970 bandwidth limit applies also has a 'label' attribute. A 971 element with a 'label' attribute applies only to the 972 stream element that has a 'label' attribute with the same value. If 973 no matching element exists, then the element 974 MUST be ignored. 976 If the element occurs multiple times in a container 977 element, each instance MUST apply to a different set of media streams 978 (i.e., one element for outgoing and one for incoming 979 streams). 981 Merging of session-policy documents: the lowest max-stream-bw value 982 MUST be used. 984 6.6. The Element 986 The element contains an Differentiated Services Codepoint 987 (DSCP) [RFC2474] value that should be used to populate the IP DS 988 field of media packets. The contains a decimal integer 989 value that represents a 6 bit field and therefore ranges from 0 to 990 63. 992 This element MAY have the direction and media-type attributes (see 993 Section 3.3)). 995 If used in a element, the element MAY 996 also have the visibility attribute (see Section 3.3). 998 The media-type attribute is used to specify that the 999 element only applies to streams of a certain media type (e.g., audio 1000 streams). 1002 The element is optional and MAY occur multiple times 1003 inside a container. If the element occurs multiple times, 1004 each instance MUST apply to a different media stream (i.e., one element for audio and one for video streams). 1007 Merging of session-policy documents: the local domain of the user 1008 agent has precedence over other domains and its DSCP value MUST be 1009 used. During the merging process, element values from 1010 local policy server selected as described in "Local Policy Server 1011 Selection" Section 5.1.3 are used. 1013 6.7. The Element 1015 The element provides context information about a session 1016 policy or session information document. 1018 The element MAY contain multiple and one 1019 element. It can also contain optional and 1020 elements. 1022 If used in a element, the element MAY also 1023 contain a element. 1025 Merging of session-policy documents: the resulting element 1026 MUST be determined by local policy. 1028 6.7.1. The Element 1030 The element contains the URI (including the URI 1031 scheme)of the policy server that has issued this policy. 1033 6.7.2. The Element 1035 The element contains a URI which is a contact address 1036 (e.g., a SIP URI or mailto URI) by which a human representative of 1037 the issuer of this document can be reached. 1039 6.7.3. The Element 1041 The element provides a short textual description of the policy 1042 or session that should be intelligible to the human user. 1044 6.7.4. The Element 1046 The element contains the request-URI (including the URI 1047 scheme) of the dialog-initiating request of the session. 1049 The element is only permitted inside 1050 documents and, thus, MUST NOT be included in session policy 1051 documents. 1053 6.7.5. The Element 1055 The element provides a mechanism for a policy server to 1056 return an opaque string to a UA. Such a string is sometimes needed 1057 to construct a Policy-Id header which ensures that all policy 1058 requests concerning a single session are routed to the same policy 1059 server. The use of this token is described in the Framework for SIP 1060 Session Policies [I-D.ietf-sip-session-policy-framework]. The token 1061 value MUST consist of ASCII characters in the range U+0020 to U+007E 1062 (note that the token value is encodable as a SIP URI parameter 1063 value). 1065 6.8. Other Session Properties 1067 A number of additional elements have been proposed for a media 1068 property language. These elements are deemed to be outside the scope 1069 of this format. However, they may be defined in extensions of MPDF 1070 or other profile data sets. 1072 o maximum number of streams 1073 o maximum number of sessions 1074 o maximum number of streams per session 1075 o external address and port 1076 o media transport protocol 1077 o outbound proxy 1078 o SIP methods 1079 o SIP option tags 1080 o SIP transport protocol 1081 o body disposition 1082 o body format 1083 o body encryption 1085 7. Examples 1087 7.1. Session Policy Documents 1089 The following example describes a session policy document that allows 1090 the use of audio and video and prohibits the use of other media 1091 types. It allows the use of any codec except G.723 and G.729. 1093 1094 1095 sips:policy@biloxi.example.com 1096 sip:policy_manager@example.com 1097 Access network policies 1098 1099 1100 audio 1101 video 1102 1103 1104 audio/G729 1105 audio/G723 1106 1107 1109 7.2. Session Information Documents 1111 The following examples contain session descriptions and the session 1112 information documents that represent these sessions. 1114 7.2.1. Example 1 1116 In this example, a session info document is created based on one 1117 session description. This session info document would be created, 1118 for example, by a UA that has composed an offer and is now contacting 1119 a policy server. 1121 Local SDP session description: 1123 v=0 1124 o=alice 2890844526 2890844526 IN IP4 host.somewhere.example 1125 s= 1126 c=IN IP4 host.somewhere.example 1127 t=0 0 1128 m=audio 49562 RTP/AVP 0 1 3 1129 a=rtpmap:0 PCMU/8000 1130 a=rtpmap:1 1016/8000 1131 a=rtpmap:3 GSM/8000 1132 m=video 51234 RTP/AVP 31 34 1133 a=rtpmap:31 H261/90000 1134 a=rtpmap:34 H263/90000 1136 MPDF document: 1138 1139 1140 sip:alice@somewhere.example 1141 session information 1142 1143 1144 1145 audio 1146 audio/PCMU 1147 audio/1016 1148 audio/GSM 1149 host.somewhere.example:49562 1150 1151 1152 video 1153 video/H261 1154 video/H263 1155 host.somewhere.example:51234 1156 1157 1158 1160 7.2.2. Example 2 1162 In this example, a session info document is created that represents 1163 two session descriptions (i.e., an offer and answer). This session 1164 info document would be created, for example, by a UA that has 1165 received an answer from another UA and is now contacting a policy 1166 server. 1168 Local SDP session description: 1170 v=0 1171 o=alice 2890844526 2890844526 IN IP4 host.somewhere.example 1172 s= 1173 c=IN IP4 host.somewhere.example 1174 t=0 0 1175 m=audio 49562 RTP/AVP 0 1 3 1176 a=rtpmap:0 PCMU/8000 1177 a=rtpmap:1 1016/8000 1178 a=rtpmap:3 GSM/8000 1179 m=video 51234 RTP/AVP 31 34 1180 a=rtpmap:31 H261/90000 1181 a=rtpmap:34 H263/90000 1183 Remote SDP session description: 1185 v=0 1186 o=bob 2890844730 2890844730 IN IP4 host.anywhere.example 1187 s= 1188 c=IN IP4 host.anywhere.example 1189 t=0 0 1190 m=audio 52124 RTP/AVP 0 3 1191 a=rtpmap:0 PCMU/8000 1192 a=rtpmap:3 GSM/8000 1193 m=video 50286 RTP/AVP 31 1194 a=rtpmap:31 H261/90000 1196 MPDF document that represents the local and the remote session 1197 description: 1199 1200 1201 sip:alice@somewhere.example 1202 session information 1203 1204 1205 1206 audio 1207 audio/PCMU 1208 audio/GSM 1209 host.somewhere.example:49562 1210 host.anywhere.example:52124 1211 1212 1213 video 1214 video/H261 1215 host.somewhere.example:51234 1216 host.anywhere.example:50286 1217 1218 1219 1221 The following MPDF document is a modified version of the above 1222 document, which can be returned by a policy server. This document 1223 reflects a policy that defines a maximum session bandwidth of 192 1224 kbit and a maximum bandwidth for the H261 video stream of 128 kbit. 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 1250 8. Relax NG Definition 1252 1253 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 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 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1326 1327 1328 1329 1330 1331 1332 1333 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 1365 1366 1367 1368 1369 1370 1371 1372 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1434 1435 1436 1437 1438 1439 1441 1442 1443 1444 1445 1446 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1497 1498 1499 1500 1501 1502 1503 1504 1505 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1553 1554 1555 1556 1557 1558 1559 1560 1561 1563 1564 1566 1567 1568 1569 hidden 1570 visible 1571 1572 1573 1575 1576 1577 1578 sendonly 1579 recvonly 1580 sendrecv 1581 1582 1583 1585 1586 1587 1588 1589 1591 1592 1593 1594 1595 1597 1598 1599 1600 1601 1603 1604 1605 1606 1607 1609 1610 1611 1612 1613 1614 visibility 1615 direction 1616 q 1617 media-type 1618 label 1619 enabled 1620 1621 1622 1623 1624 1626 1627 1628 1629 1630 context 1631 streams 1632 max-bw 1633 max-session-bw 1634 max-stream-bw 1635 media-intermediaries 1636 qos-dscp 1637 local-ports 1638 media-types-allowed 1639 media-types-excluded 1640 media-type 1641 codecs-allowed 1642 codecs-excluded 1643 1644 1645 1646 1647 1649 1650 1651 1652 1653 1654 1655 1656 1657 1659 1660 1661 1662 1663 1665 1667 9. Security Considerations 1669 Section 5 of [I-D.ietf-sip-session-policy-framework] discusses 1670 security aspects related to the transfer of session policy 1671 information between user agents and policy servers, including their 1672 authentication and the use of TLS between them. In particular, a UA 1673 needs to check the server's certificate and only accept policies from 1674 severs the UA is configured to accept policies from. Section 7 of 1675 RFC 3470 [RFC3470] provides general security considerations regarding 1676 the transport of XML documents in network protocols. Session info 1677 and session policy information can be sensitive information. The 1678 protocol used to distribute session info and session policy documents 1679 SHOULD ensure authentication and confidentiality, and message 1680 integrity. The use of [I-D.ietf-sipping-policy-package] to 1681 distribute session info and session policy document meets these 1682 requirements. 1684 An attacker could attempt to modify session policy documents that 1685 were sent to a client so that their processing by the client would be 1686 more costly (e.g., in terms of merging policies). The attacker could 1687 also attempt to create its own fake policy documents and send them to 1688 the client with the same purpose or in order to get the client to 1689 comply with those fake policies as part of a Denial of Service (DoS) 1690 attack. The protocol used to distribute session policy documents 1691 SHOULD ensure authentication and privacy, and message integrity. The 1692 use of [I-D.ietf-sipping-policy-package] to distribute session policy 1693 document meets these requirements. 1695 The element can contain a shared secret needed to 1696 authenticate at a media intermediary. The privacy of documents 1697 containing this element MUST be preserved when they are sent between 1698 a server and a UA. When [I-D.ietf-sipping-policy-package] is used to 1699 distribute these documents, encryption as defined in [RFC3261] (i.e., 1700 TLS or S/MIME) MUST be used 1702 10. IANA Considerations 1704 This document registers a new media type (application/ 1705 media-policy-dataset+xml), a new RLAX NG schema, and a new XML 1706 namespace. 1708 10.1. Media Type Registration 1710 Media type name: application 1712 Media subtype name: media-policy-dataset+xml 1714 Mandatory parameters: none 1716 Optional parameters: Same as charset parameter application/xml as 1717 specified in RFC 3023 [RFC3023]. 1719 Encoding considerations: Same as encoding considerations of 1720 application/xml as specified in RFC 3023 [RFC3023]. 1722 Security considerations: See Section 10 of RFC 3023 [RFC3023] and 1723 Section 9 of this specification. 1725 Interoperability considerations: none. 1727 Published specification: This document. 1729 Applications which use this media type: This document type has been 1730 used to convey media policy information between SIP user agents and a 1731 domain. 1733 Additional Information: 1735 Magic Number: None 1737 File Extension: .mpf or .xml 1739 Macintosh file type code: "TEXT" 1741 Personal and email address for further information: Volker Hilt, 1742 1744 Intended usage: COMMON 1746 Author/Change controller: The IETF. 1748 10.2. RELAX NG Schema Registration 1750 This specification registers a schema. The schema can be found as 1751 the sole content of Section 8. 1753 URI: urn:ietf:params:xml:schema:mediadataset 1755 Registrant Contact: IETF RAI area , Volker Hilt 1756 1758 RELAX NG Schema: The RELAX NG schema to be registered is contained in 1759 Section Section 8. 1761 10.3. URN Sub-Namespace Registration 1763 This section registers a new XML namespace, as per the guidelines in 1764 [RFC3688] 1766 URI: The URI for this namespace is 1767 urn:ietf:params:xml:ns:mediadataset. 1769 Registrant Contact: IETF, SIPPING working group, , 1770 Volker Hilt, 1772 XML: 1774 BEGIN 1775 1776 1778 1779 1780 1782 Media Policy Dataset Namespace 1783 1784 1785

Namespace for Media Policy Datasets

1786

urn:ietf:params:xml:ns:mediadataset

1787

See RFCXXXX.

1788 1789 1790 END 1792 11. References 1794 11.1. Normative References 1796 [I-D.ietf-sipping-policy-package] 1797 Camarillo, G. and V. Hilt, "A Session Initiation Protocol 1798 (SIP) Event Package for Session-Specific Session 1799 Policies.", draft-ietf-sipping-policy-package-08 (work in 1800 progress), March 2010. 1802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1803 Requirement Levels", BCP 14, RFC 2119, March 1997. 1805 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1807 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1808 "Definition of the Differentiated Services Field (DS 1809 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1810 December 1998. 1812 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1813 Types", RFC 3023, January 2001. 1815 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1816 with Session Description Protocol (SDP)", RFC 3264, 1817 June 2002. 1819 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1820 January 2004. 1822 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1823 Description Protocol", RFC 4566, July 2006. 1825 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1826 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1828 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1829 Formats", RFC 4855, February 2007. 1831 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1832 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1834 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1835 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1836 September 2007. 1838 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1839 Relays around NAT (TURN): Relay Extensions to Session 1840 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1842 [W3C.REC-xml-20081126] 1843 Sperberg-McQueen, C., Yergeau, F., Bray, T., Paoli, J., 1844 and E. Maler, "Extensible Markup Language (XML) 1.0 (Fifth 1845 Edition)", World Wide Web Consortium Recommendation REC- 1846 xml-20081126, November 2008, 1847 . 1849 [W3C.REC-xml-names-19990114] 1850 Hollander, D., Bray, T., and A. Layman, "Namespaces in 1851 XML", World Wide Web Consortium FirstEdition REC-xml- 1852 names-19990114, January 1999, 1853 . 1855 11.2. Informative References 1857 [I-D.ietf-sip-session-policy-framework] 1858 Camarillo, G., Rosenberg, J., and V. Hilt, "A Framework 1859 for Session Initiation Protocol (SIP) Session Policies", 1860 draft-ietf-sip-session-policy-framework-10 (work in 1861 progress), February 2011. 1863 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1864 August 1999. 1866 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1867 A., Peterson, J., Sparks, R., Handley, M., and E. 1868 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1869 June 2002. 1871 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 1872 the Use of Extensible Markup Language (XML) 1873 within IETF Protocols", BCP 70, RFC 3470, January 2003. 1875 [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format 1876 for Binary Floor Control Protocol (BFCP) Streams", 1877 RFC 4583, November 2006. 1879 [RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. 1880 Even, "RTP Payload Format for ITU-T Rec", RFC 4629, 1881 January 2007. 1883 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 1884 the RTP Profile for Audio and Video Conferences", 1885 RFC 4856, February 2007. 1887 [RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session 1888 Initiation Protocol User Agent Profile Delivery", 1889 RFC 6080, March 2011. 1891 Appendix A. Acknowledgements 1893 Many thanks to Allison Mankin, Dan Petrie, Martin Dolly, Adam Roach 1894 and Ben Campbell for the discussions and suggestions. Many thanks to 1895 Roni Even, Mary Barnes, Yaron Sheffer, Pete McCann, and Henry S. 1896 Thompson for reviewing the draft and to Jari Urpalainen for helping 1897 with the Relax NG schema. 1899 Authors' Addresses 1901 Volker Hilt 1902 Bell Labs/Alcatel-Lucent 1903 791 Holmdel-Keyport Rd 1904 Holmdel, NJ 07733 1905 USA 1907 Email: volkerh@bell-labs.com 1909 Gonzalo Camarillo 1910 Ericsson 1911 Hirsalantie 11 1912 Jorvas 02420 1913 Finland 1915 Email: Gonzalo.Camarillo@ericsson.com 1917 Jonathan Rosenberg 1918 jdrosen.net 1919 Monmouth, NJ 1920 USA 1922 Email: jdrosen@jdrosen.net 1924 Dale R. Worley 1925 Avaya Inc. 1926 600 Technology Park Dr. 1927 Billerica, MA 01821 1928 US 1930 Email: dworley@avaya.com