idnits 2.17.1 draft-ietf-sipping-session-indep-policy-01.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.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1100. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1077. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1084. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1090. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 9) being 74 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 170 has weird spacing: '...otified if...' == 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 (October 24, 2004) is 7117 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-20 -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2141 (ref. '5') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '6') == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-04 == Outdated reference: A later version (-05) exists of draft-petrie-sipping-profile-datasets-00 ** Obsolete normative reference: RFC 3265 (ref. '9') (Obsoleted by RFC 6665) -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Session Initiation Proposal V. Hilt 3 Investigation Working Group Bell Labs/Lucent Technologies 4 Internet-Draft G. Camarillo 5 Expires: April 24, 2005 Ericsson 6 J. Rosenberg 7 Cisco Systems 8 October 24, 2004 10 Session-Independent Session Initiation Protocol (SIP) Policies - 11 Mechanism and Policy Schema 12 draft-ietf-sipping-session-indep-policy-01 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 24, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). 45 Abstract 47 This draft specifies an XML schema for profile data for SIP 48 session-policies. It defines a delivery mechanism for SIP 49 session-policies that are independent of a specific 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 3.2 Notifier Behavior . . . . . . . . . . . . . . . . . . . . 6 58 4. Session Policy Schemas . . . . . . . . . . . . . . . . . . . . 6 59 4.1 Specifying Constraints . . . . . . . . . . . . . . . . . . 6 60 4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . 7 61 4.3 General Policy Schema . . . . . . . . . . . . . . . . . . 7 62 4.3.1 Elements and Attributes . . . . . . . . . . . . . . . 8 63 4.4 Media Policy Schema . . . . . . . . . . . . . . . . . . . 9 64 4.4.1 Elements and Attributes . . . . . . . . . . . . . . . 9 65 4.4.2 Conflict Resolution . . . . . . . . . . . . . . . . . 11 66 4.4.3 Example . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.5 Protocol Policy Schema . . . . . . . . . . . . . . . . . . 12 68 4.5.1 Elements and Attributes . . . . . . . . . . . . . . . 12 69 4.5.2 Conflict Resolution . . . . . . . . . . . . . . . . . 14 70 4.5.3 Example . . . . . . . . . . . . . . . . . . . . . . . 15 71 4.6 Media Routing Policy Schema . . . . . . . . . . . . . . . 15 72 4.6.1 Elements and Attributes . . . . . . . . . . . . . . . 16 73 4.6.2 Conflict Resolution . . . . . . . . . . . . . . . . . 17 74 4.6.3 Example . . . . . . . . . . . . . . . . . . . . . . . 17 75 5. Schema Definitions . . . . . . . . . . . . . . . . . . . . . . 18 76 5.1 General Policy Schema . . . . . . . . . . . . . . . . . . 18 77 5.2 Media Policy Schema . . . . . . . . . . . . . . . . . . . 18 78 5.3 Protocol Policy Schema . . . . . . . . . . . . . . . . . . 19 79 5.4 Media Routing Policy Schema . . . . . . . . . . . . . . . 20 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 85 Intellectual Property and Copyright Statements . . . . . . . . 24 87 1. Introduction 89 Some domains have policies in place, which impact the sessions 90 established using the Session Initiation Protocol (SIP) [10]. These 91 policies are often needed to support the network infrastructure or 92 the execution of services. For example, wireless networks usually 93 have limited resources for media traffic. During periods of high 94 activity, a wireless network provider may want to restrict codec 95 usage on the network to lower rate codecs. 97 In another example, a SIP user agent is using a network which 98 connects to the public Internet through a firewall at the network 99 edge. The provider would like to tell the user agent to direct the 100 media streams to the appropriate open ip/ports on that firewall. 101 Knowing this policy enables these user agents to setup sessions with 102 user agents on the public Internet. 104 In a third example, a domain A has a limited bandwidth pipe to 105 another domain B. The pipe is realized through two routers that are 106 managed. Domain A would like to direct each call to one of the 107 routers based on their capacity. With session policies, the domain 108 can inform the user agent about the route with the most capacity 109 available. 111 Domains sometimes enforce policies they have in place. For example, 112 a domain might have a configuration in which all packets containing a 113 certain audio codec are dropped. Unfortunately, enforcement 114 mechanisms usually do not inform the user about the policies they are 115 enforcing and silently keep the user from doing anything against 116 them. This may lead to the malfunctioning of devices that is 117 incomprehensible to the user. With session policies, the user knows 118 about the restricted codecs and can use a different codec or simply 119 connect to a domain with less stringent policies. Session policies 120 provide an important combination of consent coupled with enforcement. 121 That is, the user becomes aware of the policy and needs to act on it, 122 but the provider still retains the right to enforce the policy. 124 Some policies are created specifically for a certain session. Such 125 policies usually require that the user agent provides information 126 about the session to the network and receives policies that are 127 tailored to this session. Session-specific policies can be set up 128 using the framework for session-specific policies [3]. 130 Session policies are often independent of a certain session and 131 generally apply to the sessions that are set up by a user agent. In 132 principle, these policies could also be set up on a 133 session-to-session basis. However, it is much more efficient to 134 enable user agents to obtain the policies relevant for them and to 135 inform the user agents about changes in these policies. This draft 136 defines a mechanism for delivering session-independent policies to 137 user agents. 139 This draft also defines XML schemas for session policies. It defines 140 a general session policy schema acting as a framework for session 141 policies. It also defines schemas for media policies, protocol 142 policies and media routing policies. Policy instance documents can 143 be delivered to user agents as session-independent policies using the 144 mechanisms below or as session-specific policies [3]. 146 Note: The difference between session-independent and 147 session-specific policies needs more discussion here. 149 2. Terminology 151 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 152 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 153 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 154 described in BCP 14, [1] and indicate requirement levels for 155 compliant implementations. 157 3. Session-Independent Policy Mechanism 159 This draft defines a mechanism for the delivery of 160 session-independent policies to UAs. Session-independent policies 161 can be part of the device configuration and reside on the same 162 configuration server. They can be delivered to UAs in conjunction 163 with the device configuration. Session-independent policies may also 164 be independent of other configuration information and reside on 165 different servers. 167 This mechanism enables UAs to indicate their support for session 168 policies and to receive policies from different policy servers. A UA 169 subscribes to session-independent policies. It receives these 170 policies when the subscription is established and is notified if 171 updates to session policies become available. The 172 session-independent policy mechanism is based on the Framework for 173 SIP User Agent Profile Delivery [7] and RFC3265 [9]. 175 3.1 Subscriber Behavior 177 A UA can express interest in session-independent policies by 178 subscribing to session policies a policy server. If the UA has 179 already received the URIs of all relevant session policy documents 180 (e.g., through configuration) it SHOULD use these URIs to create a 181 subscription as defined in [7]. 183 Session-independent policies are frequently provided to a UA by the 184 following two network domains: the domain a user registers at (i.e., 185 the domain in the address-of-record (AoR)) and the domain the UA is 186 physically connected to. The AoR-domain may, for example, provide 187 policies that are needed for services the user has subscribed. The 188 domain that provides the physical network connection may hand have 189 policies helping to maintain the functionality of the network, e.g., 190 by limiting the bandwidth a single UA can consume. A UA can 191 subscribe to these two domains without having previous knowledge 192 about the policy server URI by using the profile-types "user" and 193 "local" defined in [7]. Since a UA has no way of knowing whether a 194 domain has a policy server, it SHOULD attempt to subscribe to these 195 two profile-types if the following events occur: 197 o One (or more) AoRs registered by the UA change. This might be due 198 to a change in the AoR of an existing user or a user is added 199 to/removed from the set of users of a device. The UA SHOULD 200 subscribe each AoR that as changed using the "user" as well as the 201 "local" profile-type. It SHOULD terminate all subscriptions for 202 AoRs not in use any more. 203 o The domain the UA is connected to changes. The UA SHOULD create a 204 subscription for each AoR it maintains using the "local" 205 profile-type. It SHOULD terminate all existing subscriptions for 206 the "local" profile-type. 208 If a subscriber is unable to successfully establish a subscription, 209 it SHOULD NOT attempt to re-try this particular subscription at a 210 later point, unless one of the above events occurs again. This is to 211 limit the number of SUBSCRIBE requests sent within domains that do 212 not support session-policies. 214 A subscriber compliant to this specification MUST indicate its 215 support for session policies by adding the MIME types of supported 216 session policy formats to the Accept header of the SUBSCRIBE request. 217 This specification defines the new MIME type 218 "application/session-policy+xml". All UAs compliant to this 219 specification MUST support this MIME type and MUST include it in the 220 Accept header of SUBSCRIBE requests. 222 OPEN ISSUE: The subscriber also needs to be able to indicate 223 support for a certain XML schema, i.e., an XML namespace! 225 A subscriber may receive a 406 in response to a SUBSCRIBE request. 226 This indicates that the notifier requires the support of a session 227 policy format that was not in the Accept header of the SUBSCRIBE 228 request. This means that the notifier has session policies that are 229 required in the network but not supported by the subscriber. As a 230 consequence, the subscriber may experience difficulties when setting 231 up a session without these policies. 233 3.2 Notifier Behavior 235 A network may have session policies in place that must be supported 236 by a UA. UAs that do not support these policies may experience 237 problems when setting up a session. For example, a network may have 238 a policy enabling firewall traversal. 240 A UA lists all the session policy formats it supports in the Accept 241 header of a SUBSCRIBE request. If the notifier receives a SUBSCRIBE 242 request that does not contain the MIME types of all policy formats 243 required in the network, it MUST reject the request with a 406 244 response. A policy format is required, if the network has policy 245 documents in this format and these documents contain constraints that 246 must be applied by the UA. The notifier SHOULD NOT return a 406 if 247 an unsupported format only contains optional policies. 249 4. Session Policy Schemas 251 The schemas for session policies defined in this document extend the 252 schema for user agent profile data sets [8]. This simplifies the 253 processing of policy data and other user agent configuration data and 254 enables them to share the delivery mechanisms and to co-exist in the 255 same instance documents. 257 This draft specifies a general schema for session policies, which 258 covers the common aspects of session policies. It acts as a 259 framework schema for session policies. Based on this framework, 260 specific session policy schemas can be defined. This draft defines 261 policy schemas for media policies, protocol policies and media 262 routing policies. It is expected that other session policy schemas 263 will be defined in the future. 265 This specification makes use of XML namespaces. The namespace URIs 266 for schemas defined in this specification are URNs [5], using the 267 namespace identifier 'ietf' defined by RFC 2648 [6] and extended by 268 [4]. 270 4.1 Specifying Constraints 272 Policies are defined by using the constraint elements defined in [8]. 273 The specification of constraints is centered around the concept of a 274 working profile. A working profile is the set of properties a UA is 275 actually using during operation. The following sections defines how 276 session policies constraints influence the working profile of a UA. 278 forbid - the values of elements contained inside of a forbid element 279 MUST NOT be used in the working profile. If a policy element 280 value in a forbid element is in the working profile, it MUST be 281 removed. For example, the forbid element may contain the name of 282 codecs that are prohibited in the local local network. The forbid 283 element can contain empty policy elements. This means that all 284 possible values for that element MUST be removed from the working 285 profile. For example, a element in the forbid container 286 indicates that all codecs must be removed from the working 287 profile. Specific codecs can be added to the working profile 288 again by listing them in a set_all, set_one or set_any element 289 inside the same the same property_set. Policy element values that 290 were removed in one property_set can't be added again by a 291 different property_set. This would constitute a policy conflict 292 between the two property_sets. 293 set_all - the set_all element contains policy element values that 294 MUST be present in the working profile of a UA. They MUST be 295 added to the working profile if they are supported by the UA and 296 not forbidden by another property_set. A policy conflict occurs 297 if they can't be added to the working profile. 298 set_one - the semantics of the set_one element is similar to the 299 set_all element except that the set_one element may contain 300 alternative policy element and the UA MUST apply the first policy 301 element that does not cause conflicts. 302 set_any - the set_any element contains policy element values that 303 SHOULD be added to the working profile if they are supported by 304 the UA and do not conflict with other policies. 306 A UA MUST process the forbid element before processing the set_all, 307 set_one, and set_any elements within a property_set. 309 Note: The structure of the schema and the way constraints are 310 specified has changed significantly since the last revision. The 311 goal was to better align with the profile data set framework and 312 to simplify the specification of policies. 314 4.2 Extensibility 316 Other elements from different namespaces MAY be present within an 317 element of a policy schema for the purposes of extensibility; 318 elements or attributes from unknown namespaces MUST be ignored. 320 4.3 General Policy Schema 322 The general session policy schema defines the elements and attributes 323 that are common to all session policy schemas. All session policy 324 documents MUST import this schema. 326 The namespace of the general session policy schema is: 327 urn:ietf:params:xml:ns:sessionpolicy 329 This document specifies a MIME type for policy instance documents. 330 The new MIME type is: 331 application/session-policy+xml 333 4.3.1 Elements and Attributes 335 The following elements are defined in the session policy schema. 336 They are optional elements that MAY appear once inside a settings 337 element [8]. They do not refer to a particular property set and 338 therefore appear outside of a property_set element. 340 4.3.1.1 Version 342 The version element allows the recipient to properly order setting 343 instances. Versions start at 0, and increment by one for each new 344 document sent to a subscriber. Versions are scoped within a 345 subscription. Versions MUST be representable using a 32 bit integer. 347 4.3.1.2 Domain 349 The domain element contains a URI that identifies the domain to which 350 this setting instance belongs to. 352 4.3.1.3 Entity 354 The entity element contains a URI that identifies the user or device 355 whose policy information is reported in this setting instance. If 356 this element is not present, the setting applies to all entities on a 357 device. 359 4.3.1.4 Include Target 361 The includeTarget element contains a URI that identifies the remote 362 target of a dialog. A setting which in which this element is 363 contained applies to all dialogs which have this URI as their remote 364 target. Missing URI elements MUST match to any value. For example, 365 a URI without a user name matches to all users in this domain. 367 4.3.1.5 Exclude Target 369 The excludeTarget element contains a URI that identifies the remote 370 target of a dialog. The setting in which this element is contained 371 applies to all dialogs which do not have this URI as the remote 372 target. Missing URI elements MUST match to any value. For example, 373 a URI without a user name matches to all users in this domain. 375 4.3.1.6 Info 377 The info element provides a short textual description of the setting 378 that should be intelligible to the human user. 380 4.4 Media Policy Schema 382 The media policy schema defines the elements and attributes needed to 383 describe the characteristics of media streams. 385 The namespace of the media policy schema is: 386 urn:ietf:params:xml:ns:mediapolicy 388 4.4.1 Elements and Attributes 390 The following elements and attributes are defined in the media policy 391 schema. 393 4.4.1.1 Media 395 The media element defines a media policy. A media element MAY appear 396 zero, one or multiple times in a constraint element. 398 The media element has the following sub-elements. 400 4.4.1.1.1 Max Bandwidth 402 The maxBandwidth element defines the maximum bandwidth in kilobits 403 per second an entity can count on. 405 The maxBandwidth element is optional and can only appear once within 406 a media element. All subsequent instances MUST be ignored. It has 407 no meaning and MUST be ignored if it is inside a forbid constraint. 409 4.4.1.1.2 Maxno Streams 411 The maxnoStreams element defines the maximum number of streams an 412 entity is allowed to handle at the same time. 414 The maxnoStreams element is optional and can only appear once within 415 a media element. All subsequent instances MUST be ignored. It has 416 no meaning and MUST be ignored if it is inside a forbid constraint. 418 4.4.1.1.3 Maxno Sessions 420 The maxnoSessions element defines the maximum number of sessions an 421 entity is allowed to establish at the same time. 423 The maxnoSessions element is optional and can only appear once within 424 a media element. All subsequent instances MUST be ignored. It has 425 no meaning and MUST be ignored if it is inside a forbid constraint. 427 4.4.1.1.4 Maxno Streams Session 429 The maxnoStreamsSession element defines the maximum number of streams 430 an entity is allowed to establish within a session. 432 The maxnoStreamsSession element is optional and can only appear once 433 within a media element. All subsequent instances MUST be ignored. 434 It has no meaning and MUST be ignored if it is inside a forbid 435 constraint. 437 4.4.1.1.5 Max Bandwidth Session 439 The maxBandwidthSession element defines the maximum bandwidth in 440 kilobits per second available to the entity within one session. 442 The maxBandwidthSession element is optional and can only appear once 443 within a media element. All subsequent instances MUST be ignored. 444 It has no meaning and MUST be ignored if it is inside a forbid 445 constraint. 447 4.4.1.1.6 Max Bandwidth Stream 449 The maxBandwidthStream element defines the maximum bandwidth in 450 kilobits per second available to the entity for one stream. 452 The maxBandwidthStream element is optional and can only appear once 453 within a media element. All subsequent instances MUST be ignored. 454 It has no meaning and MUST be ignored if it is inside a forbid 455 constraint. 457 4.4.1.1.7 Type 459 The type element identifies a media type. The value of this element 460 MUST be the name of a IANA registered media type (see [2]), such as 461 "audio", "video", "text", or "application". 463 The type element is optional and MAY appear multiple times within a 464 media element. 466 4.4.1.1.8 Codec 468 The codec element identifies a media codec. The value of this 469 element MUST be the name of a registered MIME type for a encoding 470 (see [2]), such as "PCMA", "G729", or "H263". 472 The codec element is optional and MAY appear multiple times within a 473 media element. 475 4.4.1.1.9 Transport 477 The transport element identifies a transport protocol for media 478 streams. The value of this element MUST be the name of a IANA 479 registered protocol (see [2]), such as "udp", "RTP/AVP", or 480 "RTP/SAVP". 482 The transport element has an optional attribute: 484 type - the type attribute identifies the media type to which the 485 transport element applies to. The value of this attribute MUST be 486 a legal type element value. 488 The transport element is optional and MAY appear multiple times 489 within a media element. 491 4.4.1.1.10 Direction 493 The direction element identifies a media stream direction. The value 494 of this element MUST be "sendrec", "sendonly", or "recvonly". 496 The direction element has an optional attribute: 498 type - the type attribute identifies the media type to which the 499 direction element applies to. The value of this attribute MUST be 500 a legal type element value. 502 The direction element is optional and MAY appear multiple times 503 within a media element. 505 4.4.2 Conflict Resolution 507 The UA SHOULD alert the user in case a media policy conflicts with 508 another policy. 510 OPEN ISSUE: Can we be more specific what to do if a conflict 511 occurs in the general case? 513 4.4.3 Example 515 The following example describes a policy that limits the number of 516 streams a UA can create to 4. It only allows audio streams and 517 prohibits the use of the PCMU and PCMA codecs. It requires the UA to 518 support RTP/AVP as a transport and optionally allows RTP/SAVP but no 519 other transport protocols. Audio streams can only be sent. 521 522 523 524 525 PCMU 526 PCMA 527 528 529 530 531 532 4 533 audio 534 RTP/AVP 535 sendonly 536 537 538 539 540 RTP/SAVP 541 542 543 545 4.5 Protocol Policy Schema 547 The protocol policy schema defines the elements and attributes needed 548 to describe protocol characteristics. 550 The namespace of the protocol policy schema is: 551 urn:ietf:params:xml:ns:protocolpolicy 553 4.5.1 Elements and Attributes 555 The following elements and attributes are defined in the protocol 556 policy schema. 558 4.5.1.1 Protocol 560 The protocol element defines a protocol policy. Each protocols 561 element contains the policy related to the usage of a particular 562 protocol. A protocol element MAY appear zero, one or multiple times 563 in a constraint element. 565 The protocol element has an optional attribute: 567 name - the name attribute identifies the name of the protocol, to 568 which the policy of the protocol element is referring to. 570 Each protocol element has the following sub-elements. 572 4.5.1.1.1 Proxy 574 The proxy element identifies the URI of a proxy. The proxy values 575 MUST be used to create a route set. 577 The proxy element is optional and may appear multiple times inside a 578 protocol element. Multiple appearances of this element are ordered. 579 It has no meaning and MUST be ignored if it is inside a forbid 580 constraint. 582 4.5.1.1.2 Method 584 The method element identifies a method. The value of this element 585 MUST be the name of a valid method within the protocol identified by 586 in the protocol element. 588 The method element is optional and MAY appear multiple times within a 589 protocol element. 591 4.5.1.1.3 Option Tag 593 The optionTag element identifies an optionTag. The value of this 594 element MUST be the name of an option tag registered for the protocol 595 identified by in the protocol element in the IANA registry. 597 The optionTag element is optional and MAY appear multiple times 598 within a protocol element. 600 4.5.1.1.4 Transport 602 The transport element identifies a transport protocol for the 603 protocol identified by the protocol element. The value of this 604 element MUST identify a valid transport for the given protocol. For 605 SIP, the value MUST a value that is registered for the transport 606 header field parameter, such as "TCP", "UDP", or "SCTP". 608 The transport element is optional and MAY appear multiple times 609 within a protocol element. 611 4.5.1.1.5 Body-disposition 613 The body-disposition element identifies a body-disposition. The 614 value of this element MUST be a name registered in the IANA registry 615 for Content-Dispositions. 617 The body-disposition element is optional and MAY appear multiple 618 times within a protocol element. 620 4.5.1.1.6 Body-format Element 622 A body-format element identifies a body-format. The value of this 623 element MUST be the name of a MIME type registered in the IANA 624 registry. 626 The body-format element has an optional attribute: 628 body-disposition - the body-disposition attribute identifies the body 629 disposition used with this body-format. The value of this 630 attribute MUST be a value legal for the body-disposition element. 632 The body-format element is optional and MAY appear multiple times 633 within a protocol element. 635 4.5.1.1.7 Body-encryption 637 The body-encryption indicates whether or not encryption is allowed 638 for a particular body disposition. This element MUST NOT have a 639 value. 641 The body-encryption element has the following optional attributes: 643 body-disposition - the body-disposition attribute identifies the body 644 disposition this encryption setting applies to. The value of this 645 attribute MUST be a value legal for the body-disposition element. 646 body-format - the body-format attribute identifies the body format to 647 which this encryption setting applies to. The value of this 648 attribute MUST be a value legal for the body-format element. 650 The body-encryption element is optional and MAY appear multiple times 651 within a protocol element. 653 4.5.2 Conflict Resolution 655 The UA SHOULD alert the user in case a protocol policy conflicts with 656 another policy. 658 OPEN ISSUE: Can we be more specific what to do if a conflict 659 occurs in the general case? 661 4.5.3 Example 663 The following example describes a policy saying that use of the 664 MESSAGE method is prohibited in the network. It states that the use 665 of the option tag 100rel is required and preconditions are allowed. 666 Other option tags are not allowed in the network. The only MIME type 667 for message bodies allowed is "application/sdp" with the 668 body-disposition "session". Encryption is not allowed for bodies 669 with body-disposition "session". 671 672 673 674 MESSAGE 675 676 677 678 679 680 681 682 100rel 683 application/sdp 684 685 686 687 688 preconditions 689 690 691 693 4.6 Media Routing Policy Schema 695 The media routing schema defines the elements and attributes needed 696 to describe address and ports of a media stream. This schema can be 697 used to route the media stream through a NAT, a firewall or a media 698 relay. 700 The namespace of the protocol policy schema is: 701 urn:ietf:params:xml:ns:mediaroutingpolicy 703 OPEN ISSUE: This schema probably needs to go into a separate draft 704 along with some text about the mechanics. 706 4.6.1 Elements and Attributes 708 The following elements and attributes are defined in the protocol 709 policy schema. 711 4.6.1.1 Media Routing 713 The mediaRouting element defines a media routing policy. A media 714 routing element MAY appear zero, one or multiple times in a 715 constraint element. 717 Each protocol element has the following sub-elements. 719 4.6.1.1.1 Address 721 The address element contains the destination address of a media 722 stream, i.e., the address that is contained in an SDP announcement 723 for a media stream. 725 The address element MUST have the following attribute: 727 direction - the direction attribute identifies the direction of a 728 media stream. The value of this element MUST be "send" or "recv". 729 It determines whether the element applies to the session 730 description offer or answer. 732 The address element is optional and MAY appear at most once within a 733 media routing element. 735 4.6.1.1.2 Port 737 The port element identifies the destination port of a media stream, 738 i.e., the address that is contained in an SDP announcement for a 739 media stream. 741 The address element MUST have the following attribute: 743 direction - the direction attribute identifies the direction of a 744 media stream. The value of this element MUST be "send" or "recv". 745 It determines whether the element applies to the session 746 description offer or answer. 748 The port element is optional and MAY appear multiple times within a 749 media routing element. 751 4.6.1.1.3 Port Range 753 The portRange element identifies a range of ports that apply to the 754 destination of a media stream. This can, for example, be used to 755 determine the range of ports that can be used for media streams in 756 SDP announcements. 758 The address element MUST have the following attribute: 760 direction - the direction attribute identifies the direction of a 761 media stream. The value of this element MUST be "send" or "recv". 762 It determines whether the element applies to the session 763 description offer or answer. 765 The portRange element is optional and MAY appear multiple times 766 within a media routing element. It has the following two 767 sub-elements. 769 4.6.1.1.3.1 Start Port 771 The startPort element identifies the lowest port number that belongs 772 to the port range. 774 The startPort element MUST appear exactly once inside a port range 775 element. 777 4.6.1.1.3.2 End Port 779 The endPort element identifies the highest port number that belongs 780 to the port range. 782 The endPort element MUST appear exactly once inside a port range 783 element. 785 4.6.2 Conflict Resolution 787 The UA SHOULD alert the user in case a media route policy conflicts 788 with another policy. 790 OPEN ISSUE: Can we be more specific what to do if a conflict 791 occurs in the general case? 793 4.6.3 Example 795 The following example describes a policy that instructs the UA to use 796 the address 123.124.125.126 and a port in the range of 8000 - 9000 in 797 the session descriptions it creates. This information can assist a 798 UA, for example, to traverse a NAT. 800 801 802 803
123.124.125.126
804 805 8000 806 9000 807 808 809 810 812 5. Schema Definitions 814 5.1 General Policy Schema 816 [TBD.] 818 5.2 Media Policy Schema 820 821 827 829 830 831 833 835 837 839 841 843 845 847 849 851 852 854 855 856 857 858 859 860 862 863 864 865 866 867 868 870 871 872 873 874 875 876 878 880 5.3 Protocol Policy Schema 882 883 889 891 892 893 895 897 899 901 903 905 907 908 909 911 912 913 914 916 917 918 920 921 922 923 925 927 928 929 931 933 5.4 Media Routing Policy Schema 935 936 942 944 946 947 948 950 952 954 955 957 958 959 960 962 963 964 966 967 968 970 972 973 975 977 978 979 980 981 982 984 986 6. Security Considerations 988 Session policy information can be sensitive information. The 989 protocol used to distribute it SHOULD ensure privacy, message 990 integrity and authentication. Furthermore, the protocol SHOULD 991 provide access controls which restrict who can see who else's session 992 policy information. 994 7. IANA Considerations 996 [TBD.] 998 8 References 1000 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1001 Levels", BCP 14, RFC 2119, March 1997. 1003 [2] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session 1004 Description Protocol", draft-ietf-mmusic-sdp-new-20 (work in 1005 progress), September 2004. 1007 [3] Hilt, V., Camarillo, G. and J. Rosenberg, "A Framework for 1008 Session-Specific Session Policies in the Session Initiation 1009 Protocol (SIP)", October 2004. 1011 [4] Mealling, M., "The IETF XML Registry", 1012 draft-mealling-iana-xmlns-registry-05 (work in progress), June 1013 2003. 1015 [5] Moats, R., "URN Syntax", RFC 2141, May 1997. 1017 [6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1018 August 1999. 1020 [7] Petrie, D., "A Framework for Session Initiation Protocol User 1021 Agent Profile Delivery", draft-ietf-sipping-config-framework-04 1022 (work in progress), July 2004. 1024 [8] Petrie, D., "A Schema for Session Initiation Protocol User 1025 Agent Profile Data Sets", 1026 draft-petrie-sipping-profile-datasets-00 (work in progress), 1027 July 2004. 1029 [9] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1030 Notification", RFC 3265, June 2002. 1032 [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1033 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1035 Session Initiation Protocol", RFC 3261, June 2002. 1037 Authors' Addresses 1039 Volker Hilt 1040 Bell Labs/Lucent Technologies 1041 101 Crawfords Corner Rd 1042 Holmdel, NJ 07733 1043 USA 1045 EMail: volkerh@bell-labs.com 1047 Gonzalo Camarillo 1048 Ericsson 1049 Hirsalantie 11 1050 Jorvas 02420 1051 Finland 1053 EMail: Gonzalo.Camarillo@ericsson.com 1055 Jonathan Rosenberg 1056 Cisco Systems 1057 600 Lanidex Plaza 1058 Parsippany, NJ 07054 1059 USA 1061 EMail: jdrosen@dynamicsoft.com 1063 Appendix A. Acknowledgements 1065 Many thanks to Allison Mankin for the discussions and the suggestions 1066 for this draft. 1068 Intellectual Property Statement 1070 The IETF takes no position regarding the validity or scope of any 1071 Intellectual Property Rights or other rights that might be claimed to 1072 pertain to the implementation or use of the technology described in 1073 this document or the extent to which any license under such rights 1074 might or might not be available; nor does it represent that it has 1075 made any independent effort to identify any such rights. Information 1076 on the procedures with respect to rights in RFC documents can be 1077 found in BCP 78 and BCP 79. 1079 Copies of IPR disclosures made to the IETF Secretariat and any 1080 assurances of licenses to be made available, or the result of an 1081 attempt made to obtain a general license or permission for the use of 1082 such proprietary rights by implementers or users of this 1083 specification can be obtained from the IETF on-line IPR repository at 1084 http://www.ietf.org/ipr. 1086 The IETF invites any interested party to bring to its attention any 1087 copyrights, patents or patent applications, or other proprietary 1088 rights that may cover technology that may be required to implement 1089 this standard. Please address the information to the IETF at 1090 ietf-ipr@ietf.org. 1092 Disclaimer of Validity 1094 This document and the information contained herein are provided on an 1095 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1096 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1097 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1098 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1099 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1100 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1102 Copyright Statement 1104 Copyright (C) The Internet Society (2004). This document is subject 1105 to the rights, licenses and restrictions contained in BCP 78, and 1106 except as set forth therein, the authors retain all their rights. 1108 Acknowledgment 1110 Funding for the RFC Editor function is currently provided by the 1111 Internet Society.