idnits 2.17.1 draft-ietf-sipping-session-indep-policy-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1060. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1037. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1044. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1050. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 16, 2005) is 6831 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '11' is defined on line 959, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 971, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-24 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2141 (ref. '7') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '8') ** Obsolete normative reference: RFC 3023 (ref. '9') (Obsoleted by RFC 7303) == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-06 == Outdated reference: A later version (-05) exists of draft-petrie-sipping-profile-datasets-02 == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-07 -- Possible downref: Normative reference to a draft: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '16' == Outdated reference: A later version (-03) exists of draft-hilt-sipping-session-spec-policy-01 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group V. Hilt 3 Internet-Draft Bell Labs/Lucent Technologies 4 Expires: January 17, 2006 G. Camarillo 5 Ericsson 6 J. Rosenberg 7 Cisco Systems 8 July 16, 2005 10 Session Initiation Protocol (SIP) Session Policies - Document Format 11 and Session-Independent Delivery Mechanism 12 draft-ietf-sipping-session-indep-policy-03 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 17, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This draft defines a document format for media-related SIP session 46 policies. The format extends the Profile Data Set Schema by 47 specifying a data set for media properties. This draft also defines 48 a delivery mechanism for session policies that is independent of a 49 SIP session. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Session-Independent Policy Mechanism . . . . . . . . . . . . 4 56 3.1 Subscriber Behavior . . . . . . . . . . . . . . . . . . . 4 57 4. Basic Media Policy Format . . . . . . . . . . . . . . . . . 6 58 4.1 Namespace . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . 6 60 4.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.3.1 The 'stream-label' Attribute . . . . . . . . . . . . . 7 62 4.3.2 The 'media-type' Attribute . . . . . . . . . . . . . . 7 63 4.4 Elements . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.4.1 The Element . . . . . . . . . . . . . 8 65 4.4.2 The Element . . . . . . . . . . . . . . . . 8 66 4.4.3 The Element . . . . . . . . . . . . . . . 8 67 4.4.4 The Element . . . . . . . . . . . . . . . . . 9 68 4.4.5 The Element . . . . . . . . . . . . . . . . 9 69 4.4.6 The Element . . . . . . . . . . . . . . . . . . 9 70 4.4.7 The Element . . . . . . . . . . . . . . 9 71 4.4.8 The Element . . . . . . . . . . . . . . . 10 72 4.4.9 The Element . . . . . . . . . . . . . . . . . 10 73 4.4.10 The Element . . . . . . . . . . . . . . . . 11 74 4.4.11 The Element . . . . . . . . . . 11 75 4.4.12 The Element . . . . . . . . . . . . . . . 12 76 4.4.13 The Element . . . . . . . . . . . . 12 77 4.4.14 The Element . . . . . . . . . . . . . . 12 78 4.4.15 The Element . . . . . . . . . . . . 13 79 4.4.16 The Element . . . . . . . . . . . . . . . 13 80 4.4.17 Other Elements . . . . . . . . . . . . . . . . . . . 14 81 4.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 4.6 Schema Definition . . . . . . . . . . . . . . . . . . . . 15 83 5. Security Considerations . . . . . . . . . . . . . . . . . . 19 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 85 6.1 MIME Registration for application/session-policy+xml . . . 19 86 6.2 URN Sub-Namespace Registration for 87 urn:ietf:params:xml:ns:mediadataset . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 7.1 Normative References . . . . . . . . . . . . . . . . . . . 20 91 7.2 Informative References . . . . . . . . . . . . . . . . . . 22 92 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 93 Intellectual Property and Copyright Statements . . . . . . . 24 95 1. Introduction 97 Some domains have policies in place, which impact the sessions 98 established using the Session Initiation Protocol (SIP) [15]. These 99 policies are often needed to support the network infrastructure or 100 for the execution of services. For example, wireless networks 101 usually have limited resources for media traffic. A wireless network 102 provider may therefore restrict the bandwidth that is available to a 103 single user. Knowing about the bandwidth limit enables an user agent 104 to make an informed decision about the number of streams, codecs and 105 media types it can use in a session. 107 In another example, a service provider wants to specifically restrict 108 the set of codecs and media types that can be used in the network. 109 These restrictions may change depending on network conditions. With 110 session policies, the current set of restrictions can be conveyed to 111 user agents to prevent them from inadvertently violating any of the 112 network policies. 114 In a third example, a network provides quality of service (QoS) for 115 media streams through differentiated services. By knowing that 116 differentiated services are available and knowing the service class 117 assigned to media streams, a user agent can mark the packets of media 118 streams accordingly and therefore benefit from the QoS 119 infrastructure. 121 Domains sometimes enforce policies they have in place. For example, 122 a domain might have a configuration in which all packets containing a 123 certain audio codec are dropped. Unfortunately, enforcement 124 mechanisms usually do not inform the user about the policies they are 125 enforcing and silently keep the user from doing anything against 126 them. This may lead to the malfunctioning of devices that is 127 incomprehensible to the user. With session policies, the user knows 128 about the restricted codecs and can use a different codec or simply 129 connect to a domain with less stringent policies. Session policies 130 provide an important combination of consent coupled with enforcement. 131 That is, the user becomes aware of the policy and needs to act on it, 132 but the provider still retains the right to enforce the policy. 134 Session-policies can be set up in two different ways: specifically 135 for a session or independent of a session. Session-specific policies 136 are created for one particular session, usually under consideration 137 of certain aspects of this session (e.g. the IP addresses and ports 138 that are used for media). Since session-specific policies are 139 tailored to a session, they only apply to the session they are 140 created for. These policies require a delivery mechanism that 141 enables the exchange of session policy information at the time a 142 session is established. The framework for session-specific policies 144 [17] defines such a delivery mechanism for session-specific policies. 146 Session-independent policies on the other hand are independent of a 147 specific session and generally apply to the sessions set up by a user 148 agent. In principle, these policies could also be delivered to user 149 agents individually for each session, using the session-specific 150 policy framework. However, since these policies apply to many 151 sessions, it is more efficient to deliver them to user agents only 152 when the user agent is initialized or a policy changes. This draft 153 defines a delivery mechanism for session-independent policies. 155 This draft also defines a document format for media-related session 156 policies. This format is based on XML [16]. It extends the Profile 157 Data Set Schema [13] by specifying a data set for media properties. 158 The format defines a minimal set of media-related properties [18] and 159 is aimed at achieving interoperability between different user agents 160 and profile delivery/policy servers. The format can be extended 161 through the XML extension mechanisms if additional media properties 162 are needed. The XML document format is independent of the delivery 163 mechanism and can be used with session-independent and session- 164 specific session policies. 166 2. Terminology 168 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 169 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 170 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 171 described in BCP 14, [1] and indicate requirement levels for 172 compliant implementations. 174 3. Session-Independent Policy Mechanism 176 Session-independent policies can be delivered to UAs using the 177 mechanism defined in the Framework for SIP User Agent Profile 178 Delivery [12]. Session-independent policies can reside on the same 179 server as other configuration information and they can be delivered 180 to UAs in conjunction with this information. Session-independent 181 policies can also reside on a separate policy server, which is 182 independent of a configuration server. A UA may receive session- 183 independent policies from multiple servers. 185 In this draft, the terms policy server and profile delivery server 186 are used interchangeably. A policy server is a profile delivery 187 server that provides session policies. 189 3.1 Subscriber Behavior 191 A UA can express interest in session-independent policies by 192 subscribing to session policies as described in [12]. If the UA 193 already has the URIs of policy servers (e.g., through provisioning) 194 it may directly use these URIs to subscribe to session-independent 195 policies. 197 Session-independent policies are frequently provided to a UA by the 198 following two network domains: the domain a user registers at (i.e., 199 the domain in the address-of-record (AoR)) and the domain the UA is 200 physically connected to (i.e. the local network domain). A policy 201 server in the AoR-domain may, for example, provide policies needed 202 for services the user has subscribed to. The domain that provides 203 the physical network connection may have policies needed to ensure 204 the operativeness of the network, e.g., by limiting the bandwidth 205 available to a UA. A UA SHOULD attempt to subscribe to the policy 206 servers in both domains. These subscriptions are established using 207 the "user" (for subscriptions to the AoR-domains) and the 208 "localnetwork" (for subscriptions to the network domain) profile- 209 types [12]. 211 A UA SHOULD create a SUBSCRIBE request in the following events: 213 o The UA registers a AoR for the first time or removes a AoR from 214 the set of AoRs it has registered. This occurs, for example, when 215 a UA starts up (and registers AoRs) and when it shuts down (and 216 deregisters AoRs). This event also occurs when a new AoR is added 217 to a UA or a AoR is removed. In these cases, the UA SHOULD 218 establish subscriptions for each new AoR using the "user" and the 219 "localnetwork" profile-types. It SHOULD terminate all 220 subscriptions for the AoRs that have been removed. 221 o The UA changes the domain it is connected to. The UA SHOULD 222 create a new subscription for each AoR using the "localnetwork" 223 profile-type. It SHOULD terminate all existing subscriptions for 224 the "localnetwork" profile-type. It does not need to change the 225 subscriptions for "user" profiles. 227 If a subscriber is unable to establish a subscription, it SHOULD NOT 228 attempt to re-try this subscription, unless one of the above events 229 occurs again. This is to limit the number of SUBSCRIBE requests sent 230 within domains that do not support session-policies. 232 A subscriber compliant to this specification SHOULD indicate its 233 support for session-independent session policies by adding the MIME 234 types of supported session policy formats to the Accept header of the 235 SUBSCRIBE request. This specification defines the new MIME type 236 "application/session-policy+xml", which MUST be supported by UAs 237 compliant to this specification. UAs MAY also indicate support for 238 MIME type extensions (e.g. an additional XML namespace) using [3]. 240 4. Basic Media Policy Format 242 The Basic Media Policy Format (BMPF) is a document format for media- 243 related policies. It extends the Profile Data Set Schema by 244 providing a media data set and is used to define media-related SIP 245 session policies. 247 A BMPF document is an XML [16] document that MUST be well-formed and 248 MUST be valid according to schemas, including extension schemas, 249 available to the validator and applicable to the XML document. BMPF 250 documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. 252 A user agent may receive multiple BMPF documents from different 253 sources. These documents need to merged into a single document the 254 user agent can work with. General rules for merging BMPF documents 255 are described in [13]. Specific merging rules for each of the BMPF 256 elements are described below. 258 4.1 Namespace 260 This specification makes use of XML namespaces [4]. The namespace 261 URIs for schemas defined in this specification are URNs [7], using 262 the namespace identifier 'ietf' defined by [8] and extended by [5]. 263 The namespace URN for the BMPF schema is: 265 urn:ietf:params:xml:ns:mediadataset 267 The MIME type for the Basic Media Policy Format is: 269 application/session-policy+xml 271 ISSUE: a separate MIME type might not be needed for BMPF. The 272 MIME type of the Profile Data Set Schema may be sufficient. We 273 still need a separate namespace. 275 4.2 Extensibility 277 The BMPF format is an extension of the Profile Data Set Schema [13]. 278 Elements from the BMPF namespace can be used in conjunction with 279 elements from other Profile Data Sets. 281 The BMPF format itself can also be extended using XML extension 282 mechanisms. In particular, elements from different XML namespaces 283 MAY be present within a BMPF document for the purposes of 284 extensibility; elements or attributes from unknown namespaces MUST be 285 ignored. 287 4.3 Attributes 289 The following attributes provide common functionalities, which are 290 generally useful for media properties: 292 o Per-stream properties: 'stream-label' attribute 293 o Media-type specific properties: 'media-type' attribute 295 These attributes are defined in addition to the attributes inherited 296 from the Profile Data Set Schema [13]: 298 o Property Access Control: 'visibility' attribute 299 o Policies: 'policy' and 'excluded-policy' attribute 300 o Unidirectional Properties: 'direction' attribute 301 o Preferences: 'q' attribute 303 The use of these attributes is defined individually for each element 304 in the XML format below. 306 4.3.1 The 'stream-label' Attribute 308 Some properties only apply to a specific media stream. The stream to 309 which a property applies to must be identifiable through a label [6]. 310 Per-stream properties can be expressed by adding a 'stream-label' 311 attribute to the respective element. Such a property only applies to 312 the identified stream. If there is no stream with this label, the 313 element must be ignored. 315 Per-stream properties require that the labels of media streams are 316 known to the creator of a document (i.e. the profile delivery/policy 317 server). These labels are, for example, part of the session 318 description. Per-stream properties are therefore typically used for 319 session-specific policies. 321 4.3.2 The 'media-type' Attribute 323 Some properties only apply to streams of a certain media type. For 324 example, a property may only apply to audio streams. Media-type 325 specific properties can be defined by adding a 'media-type' attribute 326 to the respective element. Such a property only applies to media 327 streams of that type. 329 The value of the 'media-type' attribute MUST be the name of a IANA 330 registered media type (see [2]), such as 'audio', 'video', 'text', or 331 'application'. 333 4.4 Elements 335 The following elements are defined for the BMPF format. 337 4.4.1 The Element 339 The element is a container for media policy 340 elements. It MAY occur multiple times inside a [13] 341 element. 343 The element MAY contain one optional 344 element and multiple (including zero) , , 345 , , and elements as 346 well as elements from other namespaces. 348 OPEN ISSUE: the seems to have pretty much the 349 same functionality as the element. Maybe it needs 350 to be removed and the context element needs to go into the Profile 351 Data Set Schema. 353 4.4.2 The Element 355 The element provides context information about this policy. 357 The element is optional in a element. It 358 MAY contain a , , multiple and an 359 element. 361 Merging rule: the element is not subject to merging. 362 Information in the context element may be used to assist the user 363 if a conflict occurs during the merging process. 364 Policies that affect different sessions (i.e. have different 365 values) are not merged. 367 4.4.3 The Element 369 Session-specific policies only apply to one particular session. The 370 element is used to identify this session. If this 371 element is present the element of a 372 container, all properties defined in this container only apply to the 373 identified session. A single document may contain multiple containers, which each contains a different 375 element. This way, session-specific policies for different sessions 376 can be contained in one document. If the user agent does not have a 377 session with this dialog-ID, the content of the respective container MUST be ignored. 380 The element is optional in a element. It MUST 381 contain a and a and MAY contain a 382 element. 384 The element contains the call-ID (as defined in [15]) of 385 the session the policies are for. 387 The element contains the local tag (as defined in [15]) 388 of the session the policies are for. 390 The element contains the remote tag (as defined in [15]) 391 of the session the policies are for. If the remote tag element is 392 omitted, the policies apply to all sessions that have the given 393 call-ID and local tag. 395 Local and remote tags are defined from the viewpoint of the recipient 396 of the document. 398 4.4.4 The Element 400 The element contains a URI that identifies the domain which 401 has issued this policy. 403 The element is optional and MAY occur only once inside a 404 element. 406 4.4.5 The Element 408 The element contains a contact address (e.g. a SIP URI or 409 email address) under which the issuer of this policy can be reached. 411 The element is optional and MAY occur multiple times inside 412 a element. 414 4.4.6 The Element 416 The element provides a short textual description of the policy 417 that should be intelligible to the human user. 419 The element is optional and MAY occur only once inside a 420 element. 422 4.4.7 The Element 424 The element expresses a policy for the use of media 425 types (e.g. audio, video). It defines the media types that must be 426 used, may be used, and must not be used in a session. 428 This element may have the following attributes (see Section 4.3): 430 visibility, excluded-policy, direction. The 'excluded-policy' 431 attribute specifies the default policy for all media types that are 432 not listed inside this element. 434 The element is optional in a element 435 and MAY occur multiple times. Multiple elements MAY 436 only be present if each element applies to a different set of streams 437 (e.g. one for incoming and one for outgoing streams). 438 The MUST contain one or more elements. 440 Merging rule: containers are merged using the 441 "Multiple Enumerated Value Merging Algorithm" defined in [13]. 443 4.4.8 The Element 445 The element defines a policy for the use of the media 446 type identified by this element. The value of this element MUST be 447 the name of a IANA registered media type (see [2]), such as 'audio', 448 'video', 'text', or 'application'. 450 This element may have the following attributes (see Section 4.3): 451 policy, q. Media types that have the policy 'mandatory' MUST be used 452 in a session, media types with the policy 'allowed' MAY be used and 453 media types with the policy 'disallowed' MUST NOT be used. 455 The element is mandatory and MAY occur multiple times 456 inside a element. 458 4.4.9 The Element 460 The element expresses a policy for the use of codecs. A 461 policy can define that a codec must be used, may be used, or must not 462 be used in a session. A policy MUST allow the use of at least one 463 codec and MUST NOT define more than one mandatory codec for a media 464 type. 466 This element may have the following attributes (see Section 4.3): 467 visibility, excluded-policy, direction, stream-label. The 'excluded- 468 policy' attribute specifies the default policy for all codecs that 469 are not listed inside this element. 471 The element is optional in a element and 472 MAY occur multiple times. Multiple elements MAY only be 473 present if each element applies to a different set of streams (e.g. 474 one for incoming and one for outgoing streams). The 475 element MUST contain one or more elements. 477 Merging rule: containers are merged using the "Multiple 478 Enumerated Value Merging Algorithm" defined in [13]. 480 4.4.10 The Element 482 The element defines a policy for the use of the codec 483 identified by this element. The value of this element MUST be the 484 name of a registered MIME type for a encoding (see [2]), such as 485 "PCMA", "G729", or "H263". 487 This element may have the following attributes (see Section 4.3): 488 policy, q. Codecs that have the policy 'mandatory' MUST be used in a 489 session, codecs with the policy 'allowed' MAY be used and codecs with 490 the policy 'disallowed' MUST NOT be used. 492 The element is mandatory and MAY occur multiple times inside 493 a element. 495 4.4.11 The Element 497 The element expresses a policy for routing a 498 media stream through a media intermediary. The purpose of the 499 element is to tell the UA to send the media for 500 a particular stream through an IP address and port on an 501 intermediary. Instead of merely sending the media there, the UA can 502 instead specify a source route, which touches that intermediary, but 503 also any other intermediaries and then the final recipient. Thus, if 504 there are N hops, including the final recipient, there needs to be a 505 way for the media stream to specify N destinations. The way these N 506 destinations should be identified when sending the media stream is 507 expressed using the element. 509 This element may have the following attributes (see Section 4.3): 510 visibility, policy, direction, stream-label. 512 The element is optional in a 513 element and MAY occur multiple times. The order of element instances is significant. It defines the order 515 in which the media intermediaries must be traversed. The UA sends 516 the media stream to the intermediary listed first, then to the 517 intermediary listed next and so on. The element 518 MUST contain one and one element. 520 Merging rule: the intermediaries defined in all policies are 521 traversed. In general, local intermediaries should be traversed 522 before remote intermediaries. During the merging process, element values from different servers are ordered 524 using the "Closest Value First Merging Algorithm" [13]. The 525 intermediaries should be traversed in this order. 527 4.4.12 The Element 529 The element contains a URI that identifies the IP address 530 and port number of a media intermediary. The UA uses this URI to 531 send its media streams to the intermediary. If a protocol uses 532 multiple subsequent ports (e.g. RTP), the lowest port number SHOULD 533 be included in the URI. All additional port numbers SHOULD be 534 identified in elements. 536 The element occurs exactly once inside a element. 539 4.4.13 The Element 541 If a protocol uses multiple subsequent ports (e.g. RTP), the lowest 542 port number SHOULD be included in the element. All 543 additional port numbers SHOULD be identified in 544 elements. 546 The element is optional and MAY occur multiple times 547 inside a element. 549 4.4.14 The Element 551 The element identifies the loose source routing protocol 552 to be used with this intermediary. The value of this element can be 553 one of the following: 555 o ip-in-ip: IP-in-IP tunneling is used to specify the hops of media 556 traversal. The ultimate destination is specified in the 557 destination IP address of the innermost packet. Each subsequent 558 hop results in another encapsulation, with the destination of that 559 hop in the destination IP address of the packet. 560 o ip-loose: IP provides a loose routing mechanism that allows the 561 sender of an IP datagram to specify a set of IP addresses that are 562 to be visited on the way before reaching the final destination. 563 o turn: TURN provides a mechanism for inserting a media relay into 564 the path. Although the main purpose of TURN is NAT traversal, it 565 is possible for a TURN relay to perform other media intermediary 566 functionalities. The user agent establishes a binding on the TURN 567 server and uses this binding to transmit and receive media. 568 o media-specific: media protocols can provide their own loose 569 routing mechanism. If that is the case, the loose routing 570 mechanism of that protocol is used. As an example, SIP provides 571 its own loose routing mechanisms with the Route header. It can be 572 used to direct an instant message using the SIP MESSAGE method 573 through a set of intermediaries. 574 o none: if there is no loose-routing mechanism available, the media 575 is just sent to the first media intermediary listed in the header. 576 Note that this requires the intermediary to know where to forward 577 the packets to. Such a route must be set up in the intermediary 578 through other means. For example, with session-specific policies, 579 the policy server can extract the destination address from the 580 session description. 582 The element occurs exactly once inside a element. 585 4.4.15 The Element 587 The element contains the maximum bandwidth in 588 kilobits per second an entity can use for its media streams. 590 This element may have the following attributes (see Section 4.3): 591 visibility, policy, direction, media-type. 593 The element is optional and MAY occur multiple times 594 inside a element. If it occurs multiple times, each 595 instance MUST apply to different media streams (i.e. one element for outgoing and one for incoming streams). 598 Merging rule: the lowest max-bandwidth value is used. 600 4.4.16 The Element 602 The element contains an Differentiated Services Codepoint 603 (DSCP) [10] that should be used to populate the IP DS field of media 604 packets. The contains an integer value that represents a 605 6 bit field and therefore ranges from 0 to 63. 607 This element may have the following attributes (see Section 4.3): 608 visibility, policy, direction, stream-label, media-type. 610 The element is optional and MAY occur multiple times 611 inside a element. If it occurs multiple times, each 612 instance MUST apply to a different media stream (i.e. one 613 element for audio and one for video streams). 615 Merging rule: the domain that is first traversed by the media 616 stream has precedence and its DSCP value is used. During the 617 merging process, element values from different servers 618 are ordered using the "Closest Value First Merging Algorithm" 619 [13]. The DSCP value from the closest server is used. 621 4.4.17 Other Elements 623 A number of additional elements have been proposed for a policy 624 language. These elements are deemed to be outside the scope of a 625 basic media policy format. However, they may be defined in 626 extensions of BMPF or other profile data sets. 628 o maximum number of streams 629 o maximum number of sessions 630 o maximum number of streams per session 631 o maximum bandwidth per session 632 o maximum bandwidth per stream 633 o external address and port 634 o media transport protocol 635 o outbound proxy 636 o SIP methods 637 o SIP option tags 638 o SIP transport protocol 639 o body disposition 640 o body format 641 o body encryption 643 4.5 Example 645 The following example describes a policy that requires the use of 646 audio, allows the use of video and prohibits the use of other media 647 types. It allows the use of any codec except G.723 and G.729. The 648 policy also inserts a media intermediary into outgoing media streams. 650 651 652 653 example.com 654 sip:policy_manager@example.com 655 Access network policies 656 657 658 audio 659 video 660 661 662 G729 663 G723 664 665 666 192.0.2.0:6000 667 6001 668 ip-in-ip 669 670 671 673 4.6 Schema Definition 675 676 681 682 684 686 687 689 691 692 693 694 696 698 700 702 704 706 707 708 710 711 712 713 715 717 719 721 722 723 725 727 728 729 731 732 733 734 736 738 739 740 742 743 744 745 746 748 750 751 752 754 757 759 760 761 762 763 765 767 768 769 770 771 772 773 774 776 778 779 780 781 782 783 784 785 786 787 788 790 792 793 794 795 797 799 801 802 803 805 807 808 809 810 811 812 813 815 817 818 819 820 821 822 823 825 826 827 828 829 830 831 832 833 835 837 5. Security Considerations 839 Session policy information can be sensitive information. The 840 protocol used to distribute it SHOULD ensure privacy, message 841 integrity and authentication. Furthermore, the protocol SHOULD 842 provide access controls which restrict who can see who else's session 843 policy information. 845 6. IANA Considerations 847 This document registers a new MIME type, application/ 848 session-policy+xml, and registers a new XML namespace. 850 6.1 MIME Registration for application/session-policy+xml 852 MIME media type name: application 854 MIME subtype name: session-policy+xml 856 Mandatory parameters: none 858 Optional parameters: Same as charset parameter application/xml as 859 specified in RFC 3023 [9]. 861 Encoding considerations: Same as encoding considerations of 862 application/xml as specified in RFC 3023 [9]. 864 Security considerations: See Section 10 of RFC 3023 [9] and Section 5 865 of this specification. 867 Interoperability considerations: none. 869 Published specification: This document. 871 Applications which use this media type: This document type has been 872 used to download the session policy of a domain to SIP user agents. 874 Additional Information: 876 Magic Number: None 878 File Extension: .wif or .xml 880 Macintosh file type code: "TEXT" 882 Personal and email address for further information: Volker Hilt, 883 884 Intended usage: COMMON 886 Author/Change controller: The IETF. 888 6.2 URN Sub-Namespace Registration for 889 urn:ietf:params:xml:ns:mediadataset 891 This section registers a new XML namespace, as per the guidelines in 892 [5] 894 URI: The URI for this namespace is 895 urn:ietf:params:xml:ns:mediadataset. 897 Registrant Contact: IETF, SIPPING working group, , 898 Volker Hilt, 900 XML: 902 BEGIN 903 904 906 907 908 910 Session Policy Namespace 911 912 913

Namespace for Session Policy Information

914

urn:ietf:params:xml:ns:mediadataset

915

See RFCXXXX.

916 917 918 END 920 7. References 922 7.1 Normative References 924 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 925 Levels", BCP 14, RFC 2119, March 1997. 927 [2] Handley, M., "SDP: Session Description Protocol", 928 draft-ietf-mmusic-sdp-new-24 (work in progress), February 2005. 930 [3] Hilt, V., Rosenberg, J., and G. Camarillo, "Media Type 931 Extension Negotiation in the Session Initiation Protocol (SIP) 932 Accept Header Field", draft-hilt-sip-ext-neg-00 (work in 933 progress), January 2005. 935 [4] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML", 936 W3C REC REC-xml-names-19990114, January 1999. 938 [5] Mealling, M., "The IETF XML Registry", 939 draft-mealling-iana-xmlns-registry-05 (work in progress), 940 June 2003. 942 [6] Levin, O. and G. Camarillo, "The SDP (Session Description 943 Protocol) Label Attribute", 944 draft-ietf-mmusic-sdp-media-label-01 (work in progress), 945 January 2005. 947 [7] Moats, R., "URN Syntax", RFC 2141, May 1997. 949 [8] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 950 August 1999. 952 [9] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 953 RFC 3023, January 2001. 955 [10] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of 956 the Differentiated Services Field (DS Field) in the IPv4 and 957 IPv6 Headers", RFC 2474, December 1998. 959 [11] Perkins, C., "IP Encapsulation within IP", RFC 2003, 960 October 1996. 962 [12] Petrie, D., "A Framework for Session Initiation Protocol User 963 Agent Profile Delivery", draft-ietf-sipping-config-framework-06 964 (work in progress), February 2005. 966 [13] Petrie, D., Lawrence, S., Dolly, M., and V. Hilt, "A Schema and 967 Guidelines for Defining Session Initiation Protocol User Agent 968 Profile Data Sets", draft-petrie-sipping-profile-datasets-02 969 (work in progress), April 2005. 971 [14] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 972 draft-rosenberg-midcom-turn-07 (work in progress), 973 February 2005. 975 [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 976 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 977 Session Initiation Protocol", RFC 3261, June 2002. 979 [16] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. 980 Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", 981 W3C REC REC-xml-20040204, February 2004. 983 7.2 Informative References 985 [17] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for 986 Session-Specific Session Policies in the Session Initiation 987 Protocol (SIP)", draft-hilt-sipping-session-spec-policy-01 988 (work in progress), October 2004. 990 [18] Rosenberg, J., "Requirements for Session Policy for the Session 991 Initiation Protocol (SIP)", 992 draft-ietf-sipping-session-policy-req-02 (work in progress), 993 July 2004. 995 Authors' Addresses 997 Volker Hilt 998 Bell Labs/Lucent Technologies 999 101 Crawfords Corner Rd 1000 Holmdel, NJ 07733 1001 USA 1003 Email: volkerh@bell-labs.com 1005 Gonzalo Camarillo 1006 Ericsson 1007 Hirsalantie 11 1008 Jorvas 02420 1009 Finland 1011 Email: Gonzalo.Camarillo@ericsson.com 1013 Jonathan Rosenberg 1014 Cisco Systems 1015 600 Lanidex Plaza 1016 Parsippany, NJ 07054 1017 USA 1019 Email: jdrosen@cisco.com 1021 Appendix A. Acknowledgements 1023 Many thanks to Allison Mankin, Dan Petrie and Martin Dolly for the 1024 great discussions and suggestions. A big thanks also to everyone who 1025 contributed by providing feedback on the mailing list and in IETF 1026 meetings. 1028 Intellectual Property Statement 1030 The IETF takes no position regarding the validity or scope of any 1031 Intellectual Property Rights or other rights that might be claimed to 1032 pertain to the implementation or use of the technology described in 1033 this document or the extent to which any license under such rights 1034 might or might not be available; nor does it represent that it has 1035 made any independent effort to identify any such rights. Information 1036 on the procedures with respect to rights in RFC documents can be 1037 found in BCP 78 and BCP 79. 1039 Copies of IPR disclosures made to the IETF Secretariat and any 1040 assurances of licenses to be made available, or the result of an 1041 attempt made to obtain a general license or permission for the use of 1042 such proprietary rights by implementers or users of this 1043 specification can be obtained from the IETF on-line IPR repository at 1044 http://www.ietf.org/ipr. 1046 The IETF invites any interested party to bring to its attention any 1047 copyrights, patents or patent applications, or other proprietary 1048 rights that may cover technology that may be required to implement 1049 this standard. Please address the information to the IETF at 1050 ietf-ipr@ietf.org. 1052 Disclaimer of Validity 1054 This document and the information contained herein are provided on an 1055 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1056 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1057 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1058 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1059 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1060 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1062 Copyright Statement 1064 Copyright (C) The Internet Society (2005). This document is subject 1065 to the rights, licenses and restrictions contained in BCP 78, and 1066 except as set forth therein, the authors retain all their rights. 1068 Acknowledgment 1070 Funding for the RFC Editor function is currently provided by the 1071 Internet Society.