idnits 2.17.1 draft-ietf-mmusic-sdpng-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 20 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** There are 272 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 400: '...ions. Specific procedures that MUST be...' RFC 2119 keyword, line 581: '...ns. This section MUST be present in an...' RFC 2119 keyword, line 584: '...ng. This section is OPTIONAL for SDPng...' RFC 2119 keyword, line 590: '... section MUST be present in any SDPn...' RFC 2119 keyword, line 593: '... This section is OPTIONAL for SDPng de...' (84 more instances...) 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 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 27, 2003) is 7485 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: '3' is defined on line 1388, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1392, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1395, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1399, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1402, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1412, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1416, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1420, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1427, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 2327 (ref. '2') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2733 (ref. '6') (Obsoleted by RFC 5109) ** Downref: Normative reference to an Informational RFC: RFC 2354 (ref. '7') ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 2279 (ref. '16') (Obsoleted by RFC 3629) Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 mmusic Kutscher 3 Internet-Draft Ott 4 Expires: April 26, 2004 Bormann 5 TZI, Universitaet Bremen 6 October 27, 2003 8 Session Description and Capability Negotiation 9 draft-ietf-mmusic-sdpng-07.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 26, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document defines a language for describing multimedia sessions 40 with respect to configuration parameters and capabilities of 41 end-systems. 43 This document is a product of the Multiparty Multimedia Session 44 Control (MMUSIC) working group of the Internet Engineering Task 45 Force. Comments are solicited and should be addressed to the working 46 group's mailing list at mmusic@ietf.org and/or the authors. 48 Document Revision 49 $Revision: 6.18 $ 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Terminology and System Model . . . . . . . . . . . . . . . . 6 55 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10 56 3.1 Outline of the Negotiation Process . . . . . . . . . . . . . 10 57 3.2 Capability Types . . . . . . . . . . . . . . . . . . . . . . 12 58 3.3 Application-specific Vocabulary . . . . . . . . . . . . . . 14 59 4. SDPng Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 60 4.1 SDPng Base Syntax . . . . . . . . . . . . . . . . . . . . . 15 61 4.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 17 62 4.2.1 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 63 4.2.2 Token Sets . . . . . . . . . . . . . . . . . . . . . . . . . 18 64 4.2.3 Numerical Values . . . . . . . . . . . . . . . . . . . . . . 18 65 4.2.4 Numerical Ranges . . . . . . . . . . . . . . . . . . . . . . 18 66 4.2.5 Sample SDPng cap Element . . . . . . . . . . . . . . . . . . 19 67 4.2.6 Referencing Capability Elements . . . . . . . . . . . . . . 20 68 4.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 20 69 4.4 Configurations . . . . . . . . . . . . . . . . . . . . . . . 22 70 4.5 Constraints . . . . . . . . . . . . . . . . . . . . . . . . 24 71 4.6 Session Information . . . . . . . . . . . . . . . . . . . . 24 72 4.7 Summary of SDPng XML-Syntax . . . . . . . . . . . . . . . . 24 73 5. Specification of the Capability Negotiation . . . . . . . . 26 74 5.1 Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 26 75 5.2 RFC2533 Negotiation . . . . . . . . . . . . . . . . . . . . 28 76 5.2.1 Translating SDPng to RFC 2533 Expressions . . . . . . . . . 28 77 5.2.2 Applying RFC 2533 Canonicalization . . . . . . . . . . . . . 31 78 5.2.3 Integrating Feature Sets into SDPng . . . . . . . . . . . . 31 79 5.2.4 Processing Negotiation Results . . . . . . . . . . . . . . . 32 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33 81 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 34 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 83 References . . . . . . . . . . . . . . . . . . . . . . . . . 36 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 85 A. Formal Syntax Specifications . . . . . . . . . . . . . . . . 38 86 A.1 SDPng Base DTD . . . . . . . . . . . . . . . . . . . . . . . 38 87 A.2 SDPng XML-Schema Specification . . . . . . . . . . . . . . . 38 88 B. Sample Package Definitions . . . . . . . . . . . . . . . . . 45 89 B.1 Sample RTP Package Definition . . . . . . . . . . . . . . . 45 90 B.2 Sample Audio Package Definition . . . . . . . . . . . . . . 46 91 B.3 Sample Video Package Definition . . . . . . . . . . . . . . 46 92 C. Sample SDPng Description . . . . . . . . . . . . . . . . . . 48 93 D. Use of SDPng in Conjunction with other IETF Signaling 94 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 52 95 D.1 The Session Announcement Protocol (SAP) . . . . . . . . . . 52 96 D.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . . 53 97 D.3 Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . . 58 98 D.4 Media Gateway Control Protocol (MEGACOP) . . . . . . . . . . 59 99 E. Change History . . . . . . . . . . . . . . . . . . . . . . . 61 100 Intellectual Property and Copyright Statements . . . . . . . 64 102 1. Introduction 104 Multiparty multimedia conferencing is one of the applications that 105 require dynamic interchange of end-system capabilities and the 106 negotiation of a parameter set that is appropriate for all sending 107 and receiving end-systems in a conference. For some applications, 108 e.g. for loosely coupled conferences or for broadcast scenarios, it 109 may be sufficient to simply have session parameters be fixed by the 110 initiator of a conference. In such a scenario no negotiation is 111 required because only those participants with media tools that 112 support the predefined settings can join a media session and/or a 113 conference. 115 This approach is applicable for conferences that are announced some 116 time ahead of the actual start date of the conference. Potential 117 participants can check the availability of media tools in advance and 118 tools such as session directories can configure media tools upon 119 startup. This procedure however fails to work for conferences 120 initiated spontaneously including Internet phone calls or ad-hoc 121 multiparty conferences. Fixed settings for parameters such as media 122 types, their encoding etc. can easily inhibit the initiation of 123 conferences, for example in situations where a caller insists on a 124 fixed audio encoding that is not available at the callee's 125 end-system. 127 To allow for spontaneous conferences, the process of defining a 128 conference's parameter set must therefore be performed either at 129 conference start (for closed conferences) or maybe (potentially) even 130 repeatedly every time a new participant joins an active conference. 131 The latter approach may not be appropriate for every type of 132 conference without applying certain policies: For conferences with 133 TV-broadcast or lecture characteristics (one main active source) it 134 is usually not desired to re-negotiate parameters every time a new 135 participant with an exotic configuration joins because it may 136 inconvenience existing participants or even exclude the main source 137 from media sessions. But conferences with equal "rights" for 138 participants that are open for new participants on the other hand 139 would need a different model of dynamic capability negotiation, for 140 example a telephone call that is extended to a 3-parties conference 141 at some time during the session. 143 SDP [2] allows to specify multimedia sessions (i.e. conferences, 144 "session" as used here is not to be confused with "RTP session"!) by 145 providing general information about the session as a whole and 146 specifications for all the media streams (RTP sessions and others) to 147 be used to exchange information within the multimedia session. 149 Currently, media descriptions in SDP are used for two purposes: 151 o to describe session parameters for announcements and invitations 152 (the original purpose of SDP) and 154 o to describe the capabilities of a system and possibly provide a 155 choice between a number of alternatives (which SDP was not 156 designed for). 158 A distinction between these two "sets of semantics" is only made 159 implicitly. 161 This document is based upon a set of requirements specified in a 162 companion document [1]. In the following, we first introduce a model 163 for session description and capability negotiation as well as the 164 basic terms used throughout this specification (Section 2). In 165 Section 3, we provide an overview of options for capability 166 negotiation. Next, we outline the concept for the concepts underlying 167 SDPng and introduce the syntactical components step by step in 168 Section 4. 170 Appendix A provide formal specifications of SDPng such as XML DTD and 171 Schema definitions, Appendix D describes the usage of SDPng in 172 conjunction with IETF control protocol for multimedia communication 173 and Appendix E lists the change history. 175 2. Terminology and System Model 177 Any (computer) system has, at a time, a number of rather fixed 178 hardware as well as software resources. These resources ultimately 179 define the limitations on what can be captured, displayed, rendered, 180 replayed, etc. with this particular device. We term features enabled 181 and restricted by these resources "system capabilities". 183 Example: System capabilities may include: a limitation of the 184 screen resolution for true color by the graphics board; available 185 audio hardware or software may offer only certain media encodings 186 (e.g. G.711 and G.723.1 but not GSM); and CPU processing power and 187 quality of implementation may constrain the possible video 188 encoding algorithms. 190 In multiparty multimedia conferences, participants employ different 191 "components" in conducting the conference. 193 Example: In lecture multicast conferences one component might be 194 the voice transmission for the lecturer, another the transmission 195 of video pictures showing the lecturer and the third the 196 transmission of presentation material. 198 Depending on system capabilities, user preferences and other 199 technical and political constraints, different configurations can be 200 chosen to accomplish the use of these components in a conference. 202 Each component can be characterized at least by (a) its intended use 203 (i.e. the function it shall provide) and (b) one or more possible 204 ways to realize this function. Each way of realizing a particular 205 function is referred to as a "configuration". 207 Example: A conference component's intended use may be to make 208 transparencies of a presentation visible to the audience on the 209 Mbone. This can be achieved either by a video camera capturing the 210 image and transmitting a video stream via some video tool or by 211 loading a copy of the slides into a distributed electronic 212 white-board. For each of these cases, additional parameters may 213 exist, variations of which lead to additional configurations (see 214 below). 216 Two configurations are considered different regardless of whether 217 they employ entirely different mechanisms and protocols (as in the 218 previous example) or they choose the same and differ only in a single 219 parameter. 221 Example: In case of video transmission, a JPEG-based still image 222 protocol may be used, H.261 encoded CIF images could be sent, as 223 could H.261 encoded QCIF images. All three cases constitute 224 different configurations. Of course there are many more detailed 225 protocol parameters. 227 Each component's configurations are limited by the participating 228 system's capabilities. In addition, the intended use of a component 229 may constrain the possible configurations further to a subset 230 suitable for the particular component's purpose. 232 Example: In a system for highly interactive audio communication 233 the component responsible for audio may decide not to use the 234 available G.723.1 audio codec to avoid the additional latency but 235 only use G.711. This would be reflected in this component only 236 showing configurations based upon G.711. Still, multiple 237 configurations are possible, e.g. depending on the use of A-law or 238 u-Law, packetization and redundancy parameters, etc. 240 In modeling multimedia sessions, we distinguish two types of 241 configurations: 243 o potential configurations 244 (a set of any number of configurations per component) indicating a 245 system's functional capabilities as constrained by the intended 246 use of the various components; 248 o actual configurations 249 (exactly one per instance of a component) reflecting the mode of 250 operation of this component's particular instantiation. 252 Example: The potential configuration of the aforementioned video 253 component may indicate support for JPEG, H.261/CIF, and H.261/ 254 QCIF. A particular instantiation for a video conference may use 255 the actual configuration of H.261/CIF for exchanging video 256 streams. 258 In summary, the key terms of this model are: 260 o A multimedia session (streaming or conference) consists of one or 261 more conference components for multimedia "interaction". 263 o A component describes a particular type of interaction (e.g. audio 264 conversation, slide presentation) that can be realized by means of 265 different applications (possibly using different protocols). 267 o A configuration is a set of parameters that are required to 268 implement a certain variation (realization) of a certain 269 component. There are actual and potential configurations. 271 * Potential configurations describe possible configurations that 272 are supported by an end-system. 274 * An actual configuration is an "instantiation" of one of the 275 potential configurations, i.e. a decision how to realize a 276 certain component. 278 In less abstract words, potential configurations describe what a 279 system can do ("capabilities") and actual configurations describe 280 how a system is configured to operate at a certain point in time 281 (media stream spec). 283 To decide on a certain actual configuration, a negotiation process 284 needs to take place between the involved peers: 286 1. to determine which potential configuration(s) they have in 287 common, and 289 2. to select one of this shared set of common potential 290 configurations to be used for information exchange (e.g. based 291 upon preferences, external constraints, etc.). 293 Note that the meaning of the term "actual configuration" is highly 294 application-specific. For example, for audio transport using RTP, an 295 actual configuration is equivalent to a payload format (potentially 296 plus format parameters), whereas for other applications it may be a 297 MIME type. 299 In SAP-based [8] session announcements on the Mbone, for which SDP 300 was originally developed, the negotiation procedure is non-existent. 301 Instead, the announcement contains the media stream description sent 302 out (i.e. the actual configurations) which implicitly describe what a 303 receiver must understand to participate. 305 In point-to-point scenarios, the negotiation procedure is typically 306 carried out implicitly: each party informs the other about what it 307 can receive and the respective sender chooses from this set a 308 configuration that it can transmit. 310 Capability negotiation must not only work for 2-party conferences but 311 is also required for multi-party conferences. Especially for the 312 latter case it is required that the process to determine the subset 313 of allowable potential configurations is deterministic to reduce the 314 number of required round trips before a session can be established. 315 For instance, in order to be used with SIP, the capability 316 negotiation is required to work with the offer/answer model that is 317 for session initiation with SIP -- limiting the negotiation to 318 exactly one round trip. 320 The requirements for the SDPng specification, subdivided into general 321 requirements and requirements for session descriptions, potential and 322 actual configurations as well as negotiation rules, are captured in a 323 companion document [1]. 325 The following list explains some terms used in this document: 327 Actual Configuration 328 An actual configuration is an "instantiation" of one of the 329 potential configurations, i.e. a decision how to realize a certain 330 component. 332 Component 333 A component describes a particular type of interaction (e.g. audio 334 conversation, slide presentation) that can be realized by means of 335 different applications (possibly using different protocols). 337 Package 338 A package is application specific data schema for expressing 339 potential and actual configurations. For example, an audio package 340 specifies the data schema for audio codecs. 342 Potential Configuration 343 Potential configurations describe possible configurations that are 344 supported by an end-system ("capabilities"). 346 3. Overview 348 SDPng is a description language for both potential configurations 349 (i.e. capabilities) of participants in multimedia conferences and for 350 actual configurations (i.e. final specifications of parameters). 351 Capability negotiation is the process of generating a usable set of 352 potential configurations and finally an actual configuration from a 353 set of potential configurations provided by each potential 354 participant in a multimedia conference. 356 SDPng itself is an application-independent framework that defines a 357 description syntax and processing rules that are applied to the 358 capability negotiation process. The rules specify how to process two 359 or more capability description in general in order to obtain an 360 interworking configuration. 362 A capability description for an endpoint is a set of individual 363 capabilities, each of which provides a fixed type, e.g., a numeric 364 value or a list value. The set of types and the corresponding 365 negotiation rules are defined in this memo. 367 In the following, we provide an overview of the negotiation process 368 in Section 3.1 and describe the different capability types and the 369 corresponding negotiation rules in Section 3.2. 371 3.1 Outline of the Negotiation Process 373 SDPng supports the specification of endpoint capabilities and defines 374 a negotiation process: In a negotiation process, capability 375 descriptions are exchanged between participants. These descriptions 376 are processed in a "collapsing" step which results in a set of 377 commonly supported potential configurations. In a second step, the 378 final actual configuration is determined that is used for a 379 conference. This section specifies the usage of SDPng for capability 380 negotiation. It defines the collapsing algorithm and the procedures 381 for exchanging SDPng documents in a negotiation phase. 383 The description language and the rules for the negotiation phase that 384 are defined here are (in general) independent of the means by which 385 descriptions are conveyed during a negotiation phase (a reliable 386 transport service with causal ordering is assumed). There are however 387 properties and requirements of call signaling protocols that have 388 been considered to allow for a seamless integration of the 389 negotiation into the call setup process. For example, in order to be 390 usable with SIP, it must be possible to negotiate the conference 391 configuration within the two-way-handshake of the call setup phase. 392 In order to use SDPng instead of SDP according to the offer/answer 393 model defined in [13] it must be possible to determine an actual 394 configuration in a single request/response cycle. 396 Conceptually, the negotiation process comprises the following 397 individual steps (considering two parties, A and B, where A tries to 398 invite B to a conference). Please note that this describes the steps 399 of the negotiation process conceptually -- it does not specify 400 requirements for implementations. Specific procedures that MUST be 401 followed by implementations are given below. 403 1. A determines its potential configurations for the components that 404 should be used in the conference (e.g. "interactive audio" and 405 "shared whiteboard") and sends a corresponding SDPng instance to 406 B. This SDPng instances is denoted "CAP(A)". 408 2. B receives A's SDPng instance and analyzes the set of components 409 in the description. For each component that B wishes to support 410 it generates a list of potential configurations corresponding to 411 B's capabilities, denoted "CAP(B)". 413 3. B applies the collapsing function and obtains a list of potential 414 configurations that both A and B can support, denoted 415 "CAP(A)xCAP(B) = CAP(AB)". 417 4. B sends CAP(B) to A. 419 5. A also applies the collapsing function and obtains "CAP(AB)". At 420 this step, both A and B know the capabilities of each other and 421 the potential configurations that both can support. 423 6. In order to obtain an actual configuration from the potential 424 configuration that has been obtained, both participants have to 425 pick a subset of the potential configurations that should 426 actually be used in the conference and generate the actual 427 configuration. It should be noted that it depends on the specific 428 application whether each component must be assigned exactly one 429 actual configuration or whether it is allowed to list multiple 430 actual configurations. In this model we assume that A selects the 431 actual configuration, denoted CFG(AB). 433 7. A augments CFG(AB) with the transport parameters it intends to 434 use, e.g., on which endpoint addresses A wishes to receive data, 435 obtaining CFG_T(A). A sends CFG_T(A) to A. 437 8. B receives CFG_T(A) and adds its own transport parameters, 438 resulting in CFG_T(AB). CFG_T(AB) contains the selected actual 439 configurations and the transport parameters of both A and B (plus 440 any other SDPng data, e.g., meta-information on the conference). 441 CFG_T(AB) is the complete conference description. Both A and B 442 now have the following information: 444 CAP(A) A's supported potential configurations 446 CAP(B) B's supported potential configurations 448 CAP(AB) The set of potential configurations supported by both A 449 and B. 451 CFG(AB) The set of actual configurations to be used. 453 CFG_T(AB) The set of actual configurations to be used augmented 454 with all required parameters. 456 Note that the model presented here results in four SDPng messages. As 457 an optimization, this procedure can be abbreviated to two exchanges 458 by including the transport (and other) parameters into the potential 459 configurations. A embeds its desired transport parameters into the 460 list of potential configurations and B also sends all required 461 parameters in the response together with B's potential 462 configurations. Both A and B can then derive CFG_T(AB). Transport 463 parameters are usually not negotiable, therefor they have to be 464 distinguished from other configuration information. 466 The SDPng capability negotiation process is specified in Section 5. 468 3.2 Capability Types 470 The capability negotiation process relies on a fixed set of 471 processing rules for different types of capabilities. The following 472 types are defined: 474 1. Tokens (text strings) 476 Example: 478 PCMU 480 Processing rule: 481 Ascertain identity 483 2. Token lists 485 Example: 487 8000 16000 488 Processing rule: 489 Determine common subset 491 3. Numbers 493 Example: 495 497 Processing rule: 498 Ascertain equality 500 4. Numerical ranges 502 Example: 504 506 Processing rule: 507 Determine common subrange 509 SDPng distinguishes between optional and mandatory capability 510 definitions, with different processing rules for the negotiation 511 process. Optional definitions are used for capabilities that can be 512 provided by an entity but do not have to be supported by all 513 participants. For example, an audio codec could provide optional 514 codec parameters. The use of these parameters needs to be declared by 515 a session description, but if the parameter is not understood by all 516 implementations, a session can be established nevertheless. As a 517 result, the failure of a single processing step for a definition that 518 has been marked as "optional" does not lead to a failure of the 519 capability negotiation as a whole. 521 A mandatory capability on the other hand has to be supported by all 522 participants. For example, the specification of an audio codec for an 523 audio capability is mandatory, and for obtaining an interoperable 524 configuration, all participants must support the same audio codec or 525 set of audio codecs. 527 In addition to capabilities, a SDPng description can also provide 528 parameters that are not negotionable, e.g., transport parameters. In 529 SDPng, there is a distinction between capability definitions (that 530 are subject to a negotiation process) and parameters that are 531 specified by each participant. In a description of alternative 532 configurations for a specific component, capabilities and parameters 533 can be referred to and describe the configurations. 535 3.3 Application-specific Vocabulary 537 While the SDPng specification defines the fundamental definition 538 types, processing rules and the syntax definition for SDPng 539 descriptions, it does not define any application-specific vocabulary. 540 Application-specific vocabulary is defined in SDPng packages. An 541 SDPng package defines a schema for application specific capability 542 and parameter descriptions. Based on the description types specified 543 by the SDPng base specification, a package definition specifies the 544 capability and parameter definitions allowed for a specific 545 application, the types of definitions and additional attributes, 546 e.g., whether a definition element is optional with respect to the 547 capability negotiation or not. 549 The SDPng base specification does define some fundamental 550 requirements for definition elements that are specified in package 551 definitions, for example XML attributes for elements. Appendix A.2 552 provides an XML Schema definition that specifies some base types that 553 to be used for package definitions. 555 In order to allow for an application independent processing of SDPng 556 description documents, SDPng descriptions are standalone, i.e., the 557 package definition is not required to process a corresponding SDPng 558 document. All information, e.g., the type of definitions and 559 additional attributes are contained in the SDPng document itself. An 560 SDPng implementation can thus be processed without access to the 561 package definition. 563 4. SDPng Syntax 565 This section specifies the SDPng base syntax. An SDPng description is 566 an XML document consisting of up to five parts: 568 Capabilities 570 Definitions 572 Configurations 574 Constraints 576 Session Information 578 The Capabilities section provides a list of individual capabilities. 579 In a capability negotiation process, these capabilities are matched 580 against corresponding definitions of other participants' capability 581 descriptions. This section MUST be present in any SDPng description. 583 The Definitions section provides definitions of commonly used 584 parameters for later referencing. This section is OPTIONAL for SDPng 585 descriptions. 587 The Configurations section provides the description of the different 588 conference components (applications in a conference). Each component 589 description can provide a list of alternative configurations. This 590 section MUST be present in any SDPng description. 592 The Constraints section provides contraints on combinations of 593 configurations. This section is OPTIONAL for SDPng descriptions. 595 The Session Information section provides meta information on the 596 conferences and on individual components. This section is OPTIONAL 597 for SDPng documents. 599 4.1 SDPng Base Syntax 601 An SDPng description is an XML document. The document root element 602 MUST be an element of type "sdpng". The XML vocabulary for the SDPng 603 base specification resides in the XML namespace "http://www.iana.org/ 604 sdpng". The root element of an SDPng description MUST define an XML 605 default namespace "http://www.iana.org/sdpng". In addition, the 606 "sdpng" element MUST map the namespace prefix "sdpng" to the 607 namespace name "http://www.iana.org/sdpng". The "sdpng" element type 608 provides the child elements "cap", "def", "cfg", "constraints", and 609 "info" for the different sections of the SDPng description. The 610 default namespace is also applied to these elements. 612 The encoding of the XML document MUST be UTF-8 (RFC2279, [16]). 614 The following figure depicts the overall SDPng document structure. 616 617 619 620 [...] 621 622 623 [...] 624 625 626 [...] 627 628 629 [...] 630 631 632 [...] 633 634 636 Appendix A.1 provides a XML DTD that defines a corresponding document 637 type. 639 Note that the elements for the optional sections "Definitions", 640 "Contraints", and "Session-Level Information" are OPTIONAL. 642 Application-specific vocabulary resides in its own namespace. For 643 each namespace name of an SDPng package, a namespace prefix MUST be 644 declared in the start tag of the "sdpng" element. The following 645 figure depicts the declaration of namespace prefixes for two package 646 namespaces: 648 649 653 [...] 654 656 4.2 Capabilities 658 A section for capability descriptions is an XML element that can 659 provide a list of child elements. The element type is called "cap"(in 660 the "sdpng" namespace). Each child element represents an individual 661 capability. 663 Each capability element MUST provide an attribute "name". The value 664 of this attribute SHOULD be composed of a prefix (representing a 665 namespace-name) and a unique name for the corresponding capability 666 within that namespace. The namespace-name designates a namespace for 667 the source of the capability definition, e.g., for the participant of 668 a conference. If a prefix is specified, it MUST be separated by a 669 colon (':') from the name. The namespace MUST be declared in the 670 respective element or in ancestor elements, e.g., the root "sdpng" 671 element. The following figure depicts a capability element inside a 672 "cap" element. Note that the child elements of "audio:codec" and the 673 other sections of the SDPng description are not shown. 675 676 678 679 680 [One or more feature elements] 681 683 [...] 684 685 687 Each capability element provides a set of features. Each feature is 688 represented by a child element. The element types are defined in 689 package definitions. XML Namespaces are used to disambiguate element 690 types and to allow for extensibility. Each feature element can 691 provide a "range" of values -- not only a single value. For example, 692 a feature element can specify a set of supported alternative values 693 for a given property, e.g., for the sampling rate of an audio codec. 694 SDPng provides two different ways for representing "value ranges": A 695 feature element can specify a set of tokens or a numerical range. 697 Each feature that is represented by an XML feature element has a 698 well-defined type that is specified in the package definition. The 699 type determines the representation of the element values so that type 700 information is encoded implicitly in the description document. Each 701 feature element MAY provide an attribute "status". If this attribute 702 is present it MUST provide one of the following values: 704 opt: 705 This element describes an optional feature (as described by 706 Section 3.2). 708 The three different features types (as described in Section 3.2) are 709 represented as described in the following sections. Section 4.2.5 710 provides a complete example. 712 4.2.1 Tokens 714 Token elements provide a single token as element content. The token 715 is of type Nmtoken (name token) as defined by [9]. The following 716 example depicts a feature element of type token. 718 PCMU 720 Boolean values SHOULD be represented as token elements with a values 721 of either "true" or "false". 723 4.2.2 Token Sets 725 Token set elements provide a token list as element content. The token 726 is of type Nmtokens (name tokens) as defined by [9]. The following 727 example depicts a feature element of type token set. 729 8000 16000 731 4.2.3 Numerical Values 733 Elements for numbers provide an attribute "val" with a numerical 734 value. The following example depicts a feature element of type 735 numerical value. 737 739 4.2.4 Numerical Ranges 741 Elements for numerical ranges can provide an attribute "min" and an 742 attribute "max". Both attributes provide a numerical value. At least 743 one of these attributes MUST be present. The following example 744 depicts a feature element of type numerical range. 746 748 4.2.5 Sample SDPng cap Element 750 751 753 754 755 PCMU 756 1 2 757 8000 16000 758 759 760 true 761 762 764 [...] 765 766 768 Capability elements MAY also provide elements from different XML 769 namespaces. For example, a video-codec capability MAY be described 770 with elements declaring general video capabilities, and this element 771 MAY provide a list of additional codec specific feature elements, as 772 depicted in the following example: 774 775 777 778 779 H.263+ 780 QCIF 781 782 foo 783 bar 784 786 [...] 787 788 790 4.2.6 Referencing Capability Elements 792 The capablity elements of a "cap" element can be referenced in later 793 sections of the SDPng document. The fundamental model is that 794 capability elements specify individual capabilities (without 795 transport and other non-negotionable parameters) and that these 796 elements are later augmented in Definitions and Configurations 797 sections. 799 When referencing a capability element, e.g., the element video:codec, 800 the same element name (general identifier) is used. The referencing 801 element MUST provide an attribute "ref", and the value of this 802 attribute SHOULD provide the value of the attribute "name" of the 803 referenced element. 805 The referencing element MAY also provide additional feature elements 806 (that have not been provided by the referenced capability element). 807 The referencing element MAY also provide feature elements that have 808 already been provided by the referenced element. 810 The referencing element MAY provide an attribute "name". The 811 semantics of a reference are defined in the corresponding sections 812 where references to definitions are used, i.e., in Section 4.3 and in 813 Section 4.4. 815 Section 5.2.4 provides implementation requirements for dealing with 816 references to capability elements after a capability negotiation 817 process. 819 4.3 Definitions 821 The Definitions section is an optional section that can provide 822 definitions of fixed parameters that are not negotionable such as 823 transport parameters. An SDPng description document MAY provide a 824 "def" element that can provide a set of definitions as child 825 elements. 827 Each child element of a "def" element provides an element type 828 specified in a package definition. Such child elements are referred 829 to as "definition elements". Definition elements can provide a set of 830 child elements, each of which specifies a specific configuration 831 value. Syntactically, these child elements MUST be "feature elements" 832 as specified in Section 4.2. Child elements of a definition element 833 MUST be of type Token or of type Numerical Value. A definition 834 element MUST provide an attribute "name" that is used to specify a 835 unique name in the scope of the current SDPng description. A 836 definition element MAY provide an attribute "ref" that is used to 837 reference a capability element as specified in Section 4.2. 839 The following example depicts a def element with one definition 840 element of type "rtp:udp". This element is used to specify fixed 841 parameters of an RTP session -- the allowable parameters would have 842 been specified in a corresponding SDPng RTP package. 844 845 848 849 [...] 850 [...] 851 853 854 855 ::1 856 9456 857 1 858 859 861 862 [...] 863 864 865 [...] 866 867 868 [...] 869 871 873 A definition element SHOULD reference a capability element provided 874 in the "cap" element, as depicted in the example. In the example, the 875 definition named "rtp-cfg1" provides RTP transport parameters and 876 references the RTP capability named "rtp:rtpudpip6". The semantics of 877 referencing the capability element are as follows: 879 o An implementation MUST process the newly defined element by 880 adopting the individual feature elements of the referenced 881 capability element. 883 o For feature elements that are present in both the capability 884 element and the description element, the feature elements of the 885 definition element take precedence over the feature elements of 886 the capability element. 888 Please note the implementation requirements for dealing with 889 references to capability elements after a capability negotiation 890 process provided in Section 5.2.4. 892 4.4 Configurations 894 The Configurations section lists all the components that constitute 895 the multimedia application (IP telephone call, real-time streaming 896 application, multi-player gaming session etc.). For each of these 897 components, the actual configurations are given. 899 An SDPng document MUST provide a "cfg" element that represents the 900 Configurations section. The "cfg" element provides one or more 901 "component" element describing alternative configurations for the 902 component. The "cfg" element SHOULD provide at least one "component" 903 element. Each "component" element MUST provide an attribute "name" 904 that identifies the component uniquely in the scope of the SDPng 905 description. 907 Each "component" element MUST provide one or more "alt" element, each 908 of which describes an alternative configuration for the component. 909 Each "alt" element MUST provide an attribute "name" that provides a 910 unique identification for the alternative in the scope of the SDPng 911 description. In addition, each "alt" element MUST also provide an 912 attribute "media" for specifying the media type for this particular 913 alternative. Currently defined values for this attribute are "audio", 914 "video", "application", "data", and "control". The semantics of these 915 values are described in [2]. 917 Each "alt" element MUST provide one or more XML elements that 918 describe the configuration parameters for the particular alternative 919 configuration. The elements are defined by SDPng package 920 specification and definition from different packages can be mixed. 921 The type of the elements and their order is application dependent. 923 Each definition element that is contained in an "alt" element SHOULD 924 provide an attribute "ref". The "ref" attribute is used to specify a 925 reference to a capability element (from a "cap" section) or to a 926 definition element (from a "def" section). The value of an "ref" 927 element MUST provide the value of a "name" attribute of an existing 928 capability or definition element. A definition element MAY provide 929 child elements (for the specification of additional feature and 930 configuration parameters) but it MAY also be an empty element. The 931 semantics of referencing the capability element are as follows: 933 o An implementation MUST process the newly defined element by 934 adopting the individual feature elements of the referenced 935 capability or definition element. 937 o For feature elements that are present in both the capability/ 938 definition element and the current definition element, the feature 939 elements of the current definition element take precedence over 940 the feature elements of the referenced element. 942 Please note the implementation requirements for dealing with 943 references to capability elements after a capability negotiation 944 process provided in Section 5.2.4. 946 The following example depicts the description of a single 947 configuration for a component named "interactive-audio". The 948 description of the configuration references the "avp:pcmu" audio 949 codec definition from the "cap" element and the "rtp-cfg1" RTP 950 session definition from the "def" element. In this example, both 951 elements of the "alt" element are empty elements that adopt the 952 specified values from the referenced elements. 954 955 958 959 [...] 960 [...] 961 963 964 965 ::1 966 9456 967 1 968 969 971 972 973 974 975 976 977 979 980 981 [...] 982 983 984 [...] 985 987 989 4.5 Constraints 991 The Constraints section allows to express constraints on the 992 combination of configurations that apply across different components. 994 The "constraints" element of an SDPng description is OPTIONAL. 996 The usage of constraints will be specified in a separate document. 998 4.6 Session Information 1000 The Session Information section is represented by an "info" element 1001 and is intended for meta information on the conference itself and on 1002 the individual components. 1004 The "info" element is OPTIONAL and, if it is present, it MAY provide 1005 a list of information elements. The element types are specified in 1006 package definitions. 1008 4.7 Summary of SDPng XML-Syntax 1010 The SDPng base specification defines the following XML element types 1011 that reside in the SDPng namespace designated by the namespace name 1012 "http://www.iana.org/sdpng": 1014 o sdpng 1016 o cap 1018 o def 1020 o cfg 1022 o component 1024 o alt 1025 o constraints 1027 o info 1029 Appendix A.1 provides an XML DTD that specifies the content model of 1030 the SDPng base elements. 1032 5. Specification of the Capability Negotiation 1034 The SDPng specification defines the syntax and the semantics of 1035 capability descriptions. The algorithms that are used for processing 1036 descriptions and for comparing capability descriptions from different 1037 participants are application specific. 1039 In this section, we specify two alternative algorithms for 1040 implementations: A model that is based on the SDP offer/answer scheme 1041 (Section 5.1 and a model that is based on the feature matching 1042 algorithm that is specified in RFC 2533 [15] (Section 5.2). 1044 5.1 Offer/Answer 1046 The offer/answer model allows communicating peers to determine a 1047 (common) mode of operation to exchange media streams in a single 1048 round-trip. Basically, the offerer proposes a set of components, 1049 providing one or more alternatives ("potential configurations") for 1050 each of these. From this offer, the answerer learns which components 1051 may be used and which configurations are applicable to realize these 1052 components. The answerer indicates which components it supports 1053 (e.g. receiving a offer including audio and video, it may disallow 1054 the video session and go with an audio-only conversation) and also 1055 provides possible configurations to implement those components. 1056 Along with the media types and codec parameters, offerer and answerer 1057 specify which transport addresses to use and, in case of RTP, which 1058 payload types they want to use for sending. Offerer and answerer 1059 agree on a common set of media streams ("components") and on a 1060 possible set of codecs for each of these ("configurations") as well 1061 as the transport addresses and other parameters to be used. However, 1062 they do not fix a certain configuration (unless only a single one is 1063 exchanged in each direction). Instead, for each selected media 1064 stream, either peer may choose and dynamically switch to any of the 1065 configurations indicated by the other side in the respective offer or 1066 answer. 1068 For using SDPng with the offer/answer model (RFC 3264), the basic 1069 defined in RFC 3264 for generating offers and answers apply. The 1070 following considerations specifically apply when using offer/answer 1071 with SDPng (instead of SDP) documents: 1073 o For each component to be used, all necessary parameters MUST be 1074 given for at least one configuration per component, i.e. transport 1075 addresses and payload formats MUST be specified along with the 1076 capabilities. 1078 o Matching of components is done based upon their identification in 1079 the session part of the SDPng document using predefined 1080 identifiers for certain session types. 1081 For simple sessions, where applications can implicitly derive the 1082 semantics of the the offered components, no such explicit mapping 1083 is necessary. In this case, i.e. if the entire "" element 1084 or the respective elements in the "" element are absent, the 1085 order of appearance in the SDPng document is relevant as it is 1086 with SDP. 1088 o For each component, the answerer performs a capability matching 1089 process as per then application's requirements 1090 For all components that are acceptable, the answerer determines 1091 whether or not to accept the offer. 1092 If the answerer decides to accept the offer for a certain 1093 component, it MUST accept at least one of the potential 1094 configurations for the respective component. It SHOULD indicate 1095 this by setting the "status" attribute of the component and of the 1096 selected configuration(s) to "active" (but it MAY also omit the 1097 status attribute in both cases). 1098 It is RECOMMENDED that the answerer selects exactly one 1099 configuration for each component as "active". 1101 o The answerer MAY refuse individual configurations for a component 1102 from the offer in two ways. 1103 If the configuration shall not be used at all during a session, 1104 e.g. because the answerer does not support it or because the 1105 answere does not want to use this configuration at all, the 1106 answerer MUST set the "status" attribute of the respective 1107 component to "unused". In this case, the answerer MAY omit all 1108 the elements contained in the respective configuration's elements. 1109 This is equivalent to setting the port parameter to "0" in SDP. 1110 If a configuration shall be accepted (i.e. the respective 1111 capability shall be indicated) but no media session shall be 1112 instantiated (not even on hold!), the answerer MUST set the 1113 "status" attribute of the respective configuration to "available" 1114 and omit all media-session-specific parameters the configuration. 1116 o The answerer MAY refuse entire components that the offerer has 1117 included in two ways. 1118 If a component shall not be used at all during a session -- e.g. 1119 because the answerer does not support any of the configurations 1120 listed or because the answere does not want to use this component 1121 at all -- the answerer MUST set the "status" attribute of the 1122 respective component's to "unused". In this case, the answerer 1123 MAY omit all the elements contained in the respective component 1124 elements. This is equivalent to setting the port parameter to "0" 1125 in SDP. 1126 If a component shall be accepted (i.e. the respective capability 1127 shall be indicated) but no media session shall be instantiated 1128 (not even on hold!), the answerer MUST set the "status" attribute 1129 of the respective component to "available", omit all 1130 media-session-specific parameters from all acceptable 1131 configurations for the respective component. 1133 o For each component, the alternative potential configurations MUST 1134 be listed in the order of preference. 1135 Within a configuration, alternatives (e.g. different codecs) MUST 1136 also be listed in the order of preference. 1137 The considerations of RFC 3264 to simply arriving at symmetric 1138 codec use apply. 1140 If a component shall be put on hold, the status attribute of the 1141 component MUST be set to "sendonly", "recvonly", or "inactive", as 1142 appropriate. In this case, the status attributes of all the 1143 contained configurations that were previously active MUST be set to 1144 indicate "sendonly", "recvonly", or "inactive", as appropriate. The 1145 rules from RFC 3264 for putting media streams on hold SHALL apply. 1147 5.2 RFC2533 Negotiation 1149 SDPng potential configurations can be processed using the RFC 2533 1150 algorithm as defined in [15]. This involves the following steps: 1152 Translating SDPng capability descriptions to RFC 2533 feature set 1153 expressions; 1155 Applying the RFC 2533 feature match algorithm; and 1157 Integrating the resulting feature set expressions into the SDPng 1158 selection of conference configurations. 1160 5.2.1 Translating SDPng to RFC 2533 Expressions 1162 SDPng capability descriptions can be translated to RFC 2533 feature 1163 sets in a straightforward way, because SDPng uses a subset of the 1164 mechanisms provided by RFC 2533 with a different syntax. 1166 Each capability is represented as an XML element with a set of child 1167 elements. We first describe how to translate a single capability 1168 element into a RFC 2533 feature set, and then consider the 1169 combination of multiple capability elements. 1171 Basically, all attributes of an SDPng capability element and its 1172 child elements MUST be transformed to an RFC 2533 expression, whereas 1173 each child element MUST be translated to a feature predicate. The 1174 resulting feature predicates are combined using the '&' (AND) 1175 operator. The name attributes MUST NOT be considered. 1177 Each predicate MUST be encapsulated by brackets ('(', ')'). The value 1178 or value range of each feature element is taken as a feature 1179 predicate value. Each feature element name is directly adopted as a 1180 feature tag, including the namespace name. 1182 The SDPng data types map to RFC 2533 feature types as follows: 1184 Token 1185 A token MUST be directly adopted as an RFC 2533 token. 1187 Token set 1188 A token set MUST be adopted as an RFC 2533 set (a comma-separated 1189 token list inside square brackets, such as 1190 "video:channels=[1,2]"). 1192 Number 1193 A single number in a "val" attribute of a feature elements of type 1194 number MUST be adopted as an RFC 2533 number. 1196 Numerical Ranges 1197 A numerical range MUST be transformed to a feature set expression 1198 with two feature predicates that are combined using the "&" (AND) 1199 operator. The first predicate specifies the lower limit and the 1200 second predicate specified the upper limit. 1201 For example, the element would be 1202 transformed to the following feature set: 1204 (& (bitrate>=64) (bitrate<=128)) 1206 A numerical range without a lower limit MUST be transformed to a 1207 corresponding predicate with a '<=' operator and a numerical range 1208 without a upper limit MUST be transformed to a corresponding 1209 predicate with a '>=' operator. 1210 For example, the element would be transformed 1211 to the following feature set: 1213 (bitrate<=128) 1215 The following sample SDPng potential configuration would be 1216 transformed as follows: 1218 Original SDPng expression: 1220 1221 QCIF 1222 1223 foo 1224 bar 1225 1227 Transforming feature elements to feature predicates: 1229 (& (video:resolution=QCIF) (video:frame-rate<=24) 1230 (h263plus:A=foo) (h263plus:B=bar)) 1232 RFC 2533 uses the syntax rules of RFC 2506 [17] for feature tags. 1233 Note that in example above, the namespace name is not used for 1234 feature tags, instead we use the namespace prefix (for abbreviation). 1235 It should be noted, that implementations MUST replace the namespace 1236 prefix of SDPng elements with the namespace name when performing the 1237 translation to an RFC 2533 expression. The following figure depicts 1238 an corresponding expression for the previous example: 1240 (& (http://www.iana.org/sdpng/video:resolution=QCIF) 1241 (http://www.iana.org/sdpng/video:frame-rate<=24) 1242 (http://www.example.com/h263plus:A=foo) 1243 (http://www.example.com/h263plus:B=bar)) 1245 For this example, we assume that the prefix "video" has been assigned 1246 to the namespace name "http://www.iana.org/sdpng/video" and that the 1247 prefix "h263plus" has been assigned to the namespace name "http:// 1248 www.example.com/h263plus". In the following examples, we will use the 1249 abbreviated form (using the namespace prefix only). 1251 Multiple independent capability elements MUST each be transformed 1252 using the specification above and then combined into a single RFC 1253 2533 feature set by connecting the individual feature sets using the 1254 '|' (OR) operator. For example, the following sample SDPng potential 1255 configuration would be transformed as follows: 1257 1258 PCMU 1259 1 2 1260 8000 16000 1261 1263 1264 QCIF 1265 1266 foo 1267 bar 1268 1270 Transforming feature elements to feature predicates: 1272 (| 1273 (& (video:encoding=PCMU) (video:channels=[1,2]) 1274 (video:sampling=[8000,16000])) 1275 (& (video:resolution=QCIF) (video:frame-rate<=24) 1276 (h263plus:A=foo) (h263plus:B=bar)) 1277 ) 1279 5.2.2 Applying RFC 2533 Canonicalization 1281 After transforming different SDPng capability descriptions from 1282 different participants into their equivalent RFC 2533 form, the 1283 following steps MUST be performed to calculate the common subset of 1284 capabilities: 1286 1. The individual feature sets MUST be combined into a single 1287 expression by creating a conjunction of the feature sets, i.e., 1288 the feature sets MUST be connected by the '&' (AND) operator. 1290 2. The resulting expression MUST be reduced to disjunctive normal 1291 form, i.e., the canonical from as specified by RFC 2533 [15]. 1293 5.2.3 Integrating Feature Sets into SDPng 1295 A feature set that has been created by combining multiple independent 1296 feature sets and by reducing the result for canonical form does not 1297 indicate directly which of the capability elements belong to the 1298 common subset of capabilities. SDPng uses the following approach: 1299 After a "collapsing process" that has determined the commonly 1300 supported capabilities, the resulting RFC 2533 expression is compared 1301 to the original SDPng capability description. For this purpose, each 1302 SDPng capability element is transformed to an RFC 2533 expression and 1303 matched against the negotiation result (by constructing a conjunction 1304 of the two feature sets). If the resulting canonical disjunctive form 1305 is non-empty, the respective capability element represents a commonly 1306 supported capability and can be adopted for the conference 1307 configuration. 1309 A future version of this document will specify how to adopt 1310 individual values from the negotiation result for the SDPng 1311 capability element. 1313 The following steps MUST be performed to determine whether an 1314 individual capability element (e.g., from one of the contributing 1315 SDPng capability descriptions) belongs to the result feature set. 1317 Let R be the result feature set obtained from the canonicalization as 1318 specified in Section 5.2.2. 1320 1. For each capability element, generate the equivalent RFC 2533 1321 feature set by applying the steps specified in Section 5.2.1. Let 1322 C be the resulting feature set. 1324 2. Combine R and C into a single feature set by building a 1325 conjunction of the two feature sets (& R C). Let the result be 1326 the feature set T. 1328 3. Reduce T to disjunctive normal form by applying the 1329 canonicalization as defined in RFC 2533 [15]. 1331 4. If the remaining disjunction is non-empty, the constraints 1332 specified by capability element (the origin of C) can be 1333 satisfied by R, i.e., C represents a commonly supported 1334 capability. 1336 5.2.4 Processing Negotiation Results 1338 The capability negotiation results in an updated list of capability 1339 elements of the SDPng "cap" element. The capability elements describe 1340 the commonly supported capabilities. Capabilities that are not 1341 supported by all end-systems have been removed. 1343 Definition elements (inside the SDPng "def" element) and 1344 configuration descriptions (inside the SDPng "alt" element) that 1345 reference capability elements that have been removed after the 1346 negotiation process, MUST be removed as well. Configuration 1347 description (inside the SDPng "alt" element) that reference 1348 non-existing definition elements (inside the SDPng "def" element") 1349 MUST also be removed. 1351 6. IANA Considerations 1353 The IANA should set up a registry for XML namespaces for SDPng and 1354 SDPng package definitions. 1356 The SDP parameter registry (http://www.iana.org/assignments/ 1357 sdp-parameters) should be converted to SDPng package definitions. 1359 7. Open Issues 1361 Revise usage of terminology (potential configuration, actual 1362 configuration) 1364 Do we need an explicit mechanism to declare the used packages? 1365 E.g., 1367 Data model for audio package: sampling-rate vs. RTP clock rate 1369 Bib. references: distinguish normative and informational 1371 A registry (reuse of SDP mechanisms and names etc.) needs to be 1372 set up (IANA considerations). 1374 8. Acknowledgements 1376 The authors would like to thank Teodora Guenkova, Goran Petrovic and 1377 Markus Nosse for their feedback and detailed comments. 1379 References 1381 [1] Kutscher, D., Ott, J., Bormann, C. and I. Curcio, "Requirements 1382 for Session Description and Capability Negotiation", Internet 1383 Draft draft-ietf-mmusic-sdpng-req-01.txt, April 2001. 1385 [2] Handley, M. and V. Jacobsen, "SDP: Session Description 1386 Protocol", RFC 2327, April 1998. 1388 [3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1389 "RTP: A Transport Protocol for Real-Time Applications", RFC 1390 3550, July 2003. 1392 [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 1393 Conferences with Minimal Control", RFC 3551, July 2003. 1395 [5] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, 1396 M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP 1397 Payload for Redundant Audio Data", RFC 2198, September 1997. 1399 [6] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for 1400 Generic Forward Error Correction", RFC 2733, December 1999. 1402 [7] Perkins, C. and O. Hodson, "Options for Repair of Streaming 1403 Media", RFC 2354, June 1998. 1405 [8] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 1406 Protocol", RFC 2974, October 2000. 1408 [9] World Wide Web Consortium (W3C), "Extensible Markup Language 1409 (XML) 1.0 (Second Edition)", Status W3C Recommendation, Version 1410 http://www.w3.org/TR/2000/REC-xml-20001006, October 2000. 1412 [10] World Wide Web Consortium (W3C), "Namespaces in XML", Status 1413 W3C Recommendation, Version http://www.w3.org/TR/1999/ 1414 REC-xml-names-19990114, January 1999. 1416 [11] World Wide Web Consortium (W3C), "XML Schema Part 1: 1417 Structures", Version http://www.w3.org/TR/2001/ 1418 REC-xmlschema-1-20010502/, Status W3C Recommendation, May 2001. 1420 [12] World Wide Web Consortium (W3C), "XML Schema Part 2: 1421 Datatypes", Version http://www.w3.org/TR/2001/ 1422 REC-xmlschema-2-20010502/, Status W3C Recommendation, May 2001. 1424 [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1425 SDP", RFC 3264, June 2002. 1427 [14] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the 1428 Use of Extensible Markup Language (XML) within IETF Protocols", 1429 BCP 70, RFC 3470, January 2003. 1431 [15] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 1432 2533, March 1999. 1434 [16] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1435 2279, January 1998. 1437 [17] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag 1438 Registration Procedure", BCP 31, RFC 2506, March 1999. 1440 Authors' Addresses 1442 Dirk Kutscher 1443 TZI, Universitaet Bremen 1444 Bibliothekstr. 1 1445 Bremen 28359 1446 Germany 1448 Phone: +49.421.218-7595, sip:dku@tzi.org 1449 Fax: +49.421.218-7000 1450 EMail: dku@tzi.uni-bremen.de 1452 Joerg Ott 1453 TZI, Universitaet Bremen 1454 Bibliothekstr. 1 1455 Bremen 28359 1456 Germany 1458 Phone: +49.421.201-7028, sip:jo@tzi.org 1459 Fax: +49.421.218-7000 1460 EMail: jo@tzi.uni-bremen.de 1462 Carsten Bormann 1463 TZI, Universitaet Bremen 1464 Bibliothekstr. 1 1465 Bremen 28359 1466 Germany 1468 Phone: +49.421.218-7024, sip:cabo@tzi.org 1469 Fax: +49.421.218-7000 1470 EMail: cabo@tzi.org 1472 Appendix A. Formal Syntax Specifications 1474 A.1 SDPng Base DTD 1476 The following DTD specifies the SDPng base syntax. DTDs are not 1477 XML-Namespace aware, therefore the following DTD is for informational 1478 purposes only. Moreover, the content models for the element types 1479 "cap" and "def" have to be empty in this DTD as the specific element 1480 types for the allowed child elements are not defined by the base 1481 specification but by independent package definitions. Common 1482 requirements for these element types such as the "name" attribute 1483 cannot be expressed with XML DTDs. 1485 1487 1489 1491 1493 1494 1499 1500 1504 A.2 SDPng XML-Schema Specification 1506 1514 1521 1522 1523 1524 1525 1526 1528 1530 1531 1532 1533 1535 1540 1541 1542 1543 1544 1545 1546 1548 1553 1554 1555 1556 1557 1558 1559 1561 1566 1567 1568 1569 1570 1571 1572 1574 1579 1580 1581 1582 1583 1584 1585 1587 1592 1593 1594 1595 1597 1602 1603 1604 1605 1607 1612 1613 1614 1615 1616 1618 1623 1624 1625 1626 1627 1629 1631 1632 1633 1635 1636 1638 1639 1641 1643 1644 1645 1647 1648 1649 1650 1652 1654 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1670 1671 1673 1674 1676 1678 1679 1680 1681 1682 1683 1684 1686 1688 1689 1690 1691 1692 1693 1695 1697 1699 1700 1701 1702 1703 1704 1705 1707 1709 1710 1711 1712 1713 1714 1715 1716 1717 1719 1720 1721 1722 1723 1724 1725 1726 1728 1730 1731 1732 1733 1734 1735 1736 1738 1739 1740 1741 1742 1743 1744 1745 1747 1749 Appendix B. Sample Package Definitions 1751 B.1 Sample RTP Package Definition 1753 1761 1763 1764 1765 1766 1767 1768 1769 1770 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1786 1788 1790 B.2 Sample Audio Package Definition 1792 1800 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1814 1816 1818 B.3 Sample Video Package Definition 1820 1828 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1847 1849 1851 Appendix C. Sample SDPng Description 1853 1855 1866 1867 1868 PCMU 1869 1 1870 8000 1871 1872 1873 GSM 1874 1 1875 8000 1876 1877 1878 G723 1879 1 1880 8000 1881 1882 1883 DVI4 1884 1 1885 8000 11025 16000 22050 1886 1887 1888 LPC 1889 1 1890 8000 1891 1892 1893 G722 1894 1 1895 8000 1896 1897 1898 L16 1899 1 2 1900 44100 1901 1902 1903 QCELP 1904 1 1905 8000 1906 1907 1908 CN 1909 1 1910 8000 1911 1912 1913 MPA 1914 1 1915 32000 44100 48000 1916 1917 1918 G728 1919 1 1920 8000 1921 1922 1923 G728 1924 1 1925 8000 1926 1927 1928 G726-40 1929 1 1930 8000 1931 1932 1933 G726-32 1934 1 1935 8000 1936 1937 1938 G726-24 1939 1 1940 8000 1941 1942 1943 G726-16 1944 1 1945 8000 1946 1947 1948 G729D 1949 1 1950 8000 1951 1952 1953 G729E 1954 1 1955 8000 1956 1957 1958 GSM-EFR 1959 1 1960 8000 1961 1962 1963 L8 1964 1 2 1965 8000 16000 1966 1967 1968 RED 1969 1 2 1970 8000 16000 1971 1972 1973 RED 1974 1 1975 var 1976 1978 1979 CelB 1980 4 6 8 12 16 20 24 30 1981 1983 1984 IP6 1985 1987 1988 1989 1990 ::1 1991 9546 1992 1993 1994 1995 1996 1997 1998 1999 0 2000 2001 2002 2003 2004 2006 Appendix D. Use of SDPng in Conjunction with other IETF Signaling 2007 Protocols 2009 This appendix is included temporarily and for informational purposes 2010 only. Ultimately, it is up to each existing and evolving application 2011 protocol to specify its use of SDPng. 2013 The SDPng model provides the notion of Components to indicate the 2014 intended types of collaboration between the users in e.g. a 2015 teleconferencing scenario. 2017 Three different abstractions are defined that are used for describing 2018 the properties of a specific Component: 2020 o a Capability refers to the fact that one of the involved parties 2021 supports one particular way of exchanging media -- defined in 2022 terms of transport, codec, and other parameters -- as part of the 2023 media session. 2025 o a Potential Configuration denotes a set of matching Capabilities 2026 from all those involved parties that may be used for one 2027 particular Component. 2029 o an Actual Configuration indicates the Potential Configuration(s) 2030 and its associated media session parameters which was/were chosen 2031 by the involved parties to instantiate a certain Component. 2033 As mentioned before, this abstract notion of the interactions between 2034 a number of communicating systems needs to be mapped to the 2035 application scenarios of SDPng in conjunction with the various IETF 2036 signaling protocols, including (but not limited to) SAP, SIP, RTSP, 2037 and MEGACO. 2039 In general, this section provides recommendations and possible 2040 scenarios for the use of SDPng within specific protocols and 2041 applications. Is does not specify normative requirements. 2043 D.1 The Session Announcement Protocol (SAP) 2045 SAP is used to disseminate a previously created (and typically fixed) 2046 session description to a potentially large audience. An interested 2047 member of the audience will use the SDPng description contained in 2048 SAP to join the announced media sessions. 2050 This means that a SAP announcement contains the Actual Configurations 2051 of all Components that are part of the overall teleconference or 2052 broadcast. 2054 A SAP announcement may contain multiple Actual Configurations for the 2055 same Component. In this case, the "same" (i.e. semantically 2056 equivalent) media data from one configuration must be available from 2057 each of the Actual Configurations. 2059 Each receiver of a SAP announcement with SDPng compares its locally 2060 stored Capabilities to realize a certain Component against the Actual 2061 Configurations contained in the announcement. If the intersection 2062 yields one or more Potential Configurations for the receiver, it 2063 chooses the one it sees fit best. If the intersection is empty, the 2064 receiver cannot participate in the announced session. 2066 SAP may be substituted by HTTP (in the general case, at least), SMTP, 2067 NNTP, or other IETF protocols suitable for conveying a media 2068 description from one entity to one or more other without the intend 2069 for further negotiation of the session parameters. 2071 SAP makes extensive use of the SDP session level attributes to 2072 provide a (limited) set of descriptive metadata for the session, 2073 including scheduling and subject information. Quite a bit of this 2074 information is application-specific and is therefore not defined in 2075 the baseline SDPng spec. 2077 D.2 Session Initiation Protocol (SIP) 2079 SIP is used to establish and modify multimedia sessions, and SDPng 2080 may be carried at least in SIP INVITE, ACK and UPDATE messages as 2081 well as in a number of responses. From dealing with legacy SDP (and 2082 its essential non-suitability for capability negotiation), a 2083 particular use and interpretation of SDP has been defined for SIP, 2084 generalized in the offer/answer model documented in RFC 3264. 2086 One of the important flexibilities introduced by SIP's usage of SDP 2087 is that a sender can change dynamically between all codecs that a 2088 receiver has indicated support (and has provided an address) for. 2089 Codec changes are not signaled out-of-band but only indicated by the 2090 payload type within the media stream. From this arises one important 2091 consequence to the conceptual view of a Component within SDPng. 2093 There is no clear distinction between Potential and Actual 2094 Configurations. There need not be a single Actual Configuration 2095 chosen at setup time within the SIP signaling. Instead, a number of 2096 Potential Configurations is signaled in SIP (with all transport 2097 parameters required for carrying media streams) and the Actual 2098 Configuration is only identified by the payload type which is 2099 actually being transmitted at any point in time. 2101 Note that since SDPng does not distinguish between Potential and 2102 Actual Configurations at the syntax, this has no implications on the 2103 SDPng signaling itself. 2105 SIP relies on an "offer/answer" model for the exchange of capability 2106 and configuration information. Either the caller or the callee sends 2107 an initial session description that is processed by the other side 2108 and returned. For capability negotiation, this means that the 2109 negotiation follows a two-stage-process: The "offerer" sends its 2110 capability description to the receiver. The receiver processes the 2111 offerers capabilities and his own capabilities and generates a result 2112 capability description that is sent back to the offerer. Both sides 2113 now know the commonly supported configurations and can initiate the 2114 media sessions. 2116 Because of this strict "offer/answer" model, the offerer must already 2117 send complete configurations (i.e. include transport addresses) along 2118 with the capability descriptions. The answer must also contain 2119 complete configuration parameters. The following figure shows, how 2120 SDPng content can be used in an INVITE request with a correspong 200 2121 OK message. 2123 Simple description document with only one alternative: 2125 F1 INVITE A -> B 2127 INVITE sip:B@example.com SIP/2.0 2128 Via: SIP/2.0/UDP hostA.example.com:5060 2129 From: A 2130 To: B 2131 Call-ID: 1234@hostA.example.com 2132 CSeq: 1 INVITE 2133 Contact: 2134 Content-Type: application/sdpng 2135 Content-Length: 685 2137 2139 2149 2150 2151 PCMU 2152 1 2153 8000 2154 2155 2156 GSM 2157 1 2158 8000 2159 2160 2161 2162 2163 192.168.47.11 2164 51400 2165 2166 2167 2168 2169 2170 2171 2172 0 2173 2174 2175 2176 2177 2178 3 2179 2180 2181 2182 2183 2185 ================================================== 2187 F2 (100 Trying) B -> A 2189 SIP/2.0 100 Trying 2190 Via: SIP/2.0/UDP hostA.example.com:5060 2191 From: A 2192 To: B 2193 Call-ID: 1234@hostA.example.com 2194 CSeq: 1 INVITE 2195 Content-Length: 0 2197 ================================================== 2199 F3 180 Ringing B -> A 2201 SIP/2.0 180 Ringing 2202 Via: SIP/2.0/UDP hostA.example.com:5060 2203 From: A 2204 To: B ;tag=987654 2205 Call-ID: 1234@hostA.example.com 2206 CSeq: 1 INVITE 2207 Content-Length: 0 2209 ================================================== 2211 F4 200 OK B -> A 2213 SIP/2.0 200 OK 2214 Via: SIP/2.0/UDP hostA.example.com:5060 2215 From: A 2216 To: B ;tag=987654 2217 Call-ID: 1234@hostA.example.com 2218 CSeq: 1 INVITE 2219 Contact: 2220 Content-Type: application/sdpng 2221 Content-Length: 479 2223 2225 2236 2237 2238 PCMU 2239 1 2240 8000 2241 2242 2243 GSM 2244 1 2245 8000 2246 2247 2248 2249 2250 192.168.47.12 2251 60006 2252 2253 2254 2255 2256 2257 2258 2259 3 2260 2261 2262 2263 2264 2266 ================================================== 2268 ACK from A to B omitted 2270 In the INVITE message, A sends B a description document that 2271 specifies exactly one component with two alternatives (the PCMU and 2272 GSM audio streams). The alternatives make reference to the 2273 capability section where the two codec types are defined. All 2274 required transport parameters all already contained in the respective 2275 descriptions. The element contains a definition for the RTP 2276 media sessions so that this needs not be repeated in the 2277 configuration of the single component. Note that the semantics of 2278 the component is not explicitly specified (in an element) but 2279 rather implied. 2281 In the 200 OK message, B sends an updated description document to A. 2282 B supports the payload format that A has offered and adds his own 2283 transport parameters to the configuration information, specifying the 2284 endpoint address where B wants to receive media data. In order to 2285 disambiguate its transport configurations from A's, B sets the 2286 attribute "endpoint" to the value "B". The specific value of the 2287 "endpoint" attribute is not important, the only requirements are that 2288 a party that contributes to the session description, must use a 2289 unique name for the endpoint attribute and that a contributing party 2290 must use the same value for the endpoint attributes of all elements 2291 it adds to the session description. 2293 D.3 Real-Time Streaming Protocol (RTSP) 2295 In contrast to SIP, RTSP has, from its intended usage, a clear 2296 distinction between offering a set of Potential Configurations (by 2297 the server) and choosing one out of these (by the client). However, 2298 there is no capability negotiation process involved: the server 2299 provides a complete SDPng document describing all Components making 2300 up a presentation and includes detailed codec and transport 2301 parameters for each of there. The client may only pick one out of 2302 alternatives for each of the offered Components but has no further 2303 option to negotiate parameters in depth. Where some additional 2304 exchange is necesary -- e.g. for the client's transport addresses and 2305 security parameters --, the respective parameters are no encoded in 2306 SDPng; instead, additional RTSP header fields and parameters are 2307 field for this purpose. 2309 Hence, SDPng is only used to describe alternatives to gain access to 2310 streaming media out of which the client has to choose. No 2311 interaction takes place at the SDPng level. 2313 C->M: DESCRIBE rtsp://foo/audio-play RTSP/1.0 2314 CSeq: 1 2316 M->C: RTSP/1.0 200 OK 2317 CSeq: 1 2318 Content-Type: application/sdp 2319 Content-Length: ... 2321 2332 2333 2334 PCMU 2335 1 2336 8000 2337 2338 2339 GSM 2340 1 2341 8000 2342 2343 2344 2345 2346 192.168.47.11 2347 51400 2348 2349 2350 2351 2352 2353 2354 2355 0 2356 2357 2358 2359 2360 2361 3 2362 2363 2364 2365 2366 2368 C->M: SETUP rtsp://foo/audio-play RTSP/1.0 2369 CSeq: 2 2370 Transport: RTP/AVP;unicast;client_port=8000-8001 2372 M->C: RTSP/1.0 200 OK 2373 CSeq: 2 2374 Transport: RTP/AVP;unicast;client_port=8000-8001; 2375 server_port=51400-51401 2376 Session: 12345678 2378 To be continued with PLAY and, after the audio track has completed, 2379 finished with TEARDOWN. 2381 D.4 Media Gateway Control Protocol (MEGACOP) 2383 The MEGACO architecture also follows the SDPng model of a clear 2384 separation between Potential and Actual Configurations. Upon startup, 2385 a Media Gateway (MG) will "register" with its Media Gateway 2386 Controller (MGC) and the latter will audit the MG for its 2387 Capabilities. Those will be provided as Potential Configurations, 2388 possibly with extensive Constraints specifications. Whenever a media 2389 path needs to be set up by the MGC between two MGs or an MG needs to 2390 be reconfigured internally, the MGC will use (updated) Actual 2391 Configurations. 2393 Details and examples to be defined in a separate document. 2395 Appendix E. Change History 2397 draft-ietf-mmusic-sdpng-07.txt 2399 * New document structure: 2401 1. Intro 2403 2. Terminology and System Model 2405 3. Overview 2407 4. SDPng Syntax Specification 2409 5. Negotiation Process 2411 * Changes to Section 3: Describe all concepts 2413 * Section 4 provides complete specification 2415 * Changed XML syntax: Represent tokens and token list as element 2416 content (not attributes) 2418 * a new element "def" for reusable definitions 2420 * Adapted secion 5 accordingly 2422 * Sample DTD, schema definition and same SDPng document in 2423 appendix 2425 * Updated section 5.1 (Offer/Answer) 2427 * Updated appendix D (Use of SDPng in conjunction with other IETF 2428 Signaling Protocols) 2430 draft-ietf-mmusic-sdpng-06.txt 2432 * Removed section on capability negotiation algorithm and section 2433 on formal specification. Added Section 3. 2435 * Removed specification of concrete XML syntax from Section 4. 2436 Added requirements and theoretic considerations. 2438 * Added clarification of term "actual configuration" in Section 2439 2. 2441 * Changed "profile" to "package". 2443 * Added a list of terms with explanation at the end of Section 2. 2445 * Removed audio and RTP packages from appendix. 2447 * Added a section "Syntax Definition". 2449 * Added Section 5 ("Specification of the Capability 2450 Negotiation"). 2452 draft-ietf-mmusic-sdpng-05.txt 2454 * Moved audio and RTP packages to appendix. 2456 * Moved section "Use of SDPng in conjunction with other IETF 2457 Signaling Protocols" to appendix. 2459 * Changed mechanism for references to definitions: Definition 2460 elements provide an attribute "ref" that can be used to 2461 referenced existing definitions. Removed other mechanisms for 2462 referencing (attributes "format" and "transport", element type 2463 "use"). 2465 * Corrections to schema definitions and examples 2467 draft-ietf-mmusic-sdpng-04.txt 2469 * New section on capability negotiation. 2471 * New section on referencing definitions. 2473 * New section on properties. 2475 * New section on definition groups. 2477 draft-ietf-mmusic-sdpng-03.txt 2479 * Extension of the SDPng schema (use of Xlinks etc.) 2481 * Clarification in the text 2483 * Fixed examples 2485 * Added example libraries as appendices 2487 * More details on usage with SIP, including examples. 2489 * Added a section on formal specification mechanisms. 2491 draft-ietf-mmusic-sdpng-01.txt 2493 * renamed section "Syntax Proposal" to "Syntax Definition 2494 Mechanisms". More text on DTD vs. schema. Edited the example 2495 description. 2497 * updated example definitions in section "Definitions" and 2498 "Components & Configurations" 2500 * section "Session Attributes" replaces section "Session" 2502 * new appendix on audio codec definitions 2504 Intellectual Property Statement 2506 The IETF takes no position regarding the validity or scope of any 2507 intellectual property or other rights that might be claimed to 2508 pertain to the implementation or use of the technology described in 2509 this document or the extent to which any license under such rights 2510 might or might not be available; neither does it represent that it 2511 has made any effort to identify any such rights. Information on the 2512 IETF's procedures with respect to rights in standards-track and 2513 standards-related documentation can be found in BCP-11. Copies of 2514 claims of rights made available for publication and any assurances of 2515 licenses to be made available, or the result of an attempt made to 2516 obtain a general license or permission for the use of such 2517 proprietary rights by implementors or users of this specification can 2518 be obtained from the IETF Secretariat. 2520 The IETF invites any interested party to bring to its attention any 2521 copyrights, patents or patent applications, or other proprietary 2522 rights which may cover technology that may be required to practice 2523 this standard. Please address the information to the IETF Executive 2524 Director. 2526 Full Copyright Statement 2528 Copyright (C) The Internet Society (2003). All Rights Reserved. 2530 This document and translations of it may be copied and furnished to 2531 others, and derivative works that comment on or otherwise explain it 2532 or assist in its implementation may be prepared, copied, published 2533 and distributed, in whole or in part, without restriction of any 2534 kind, provided that the above copyright notice and this paragraph are 2535 included on all such copies and derivative works. However, this 2536 document itself may not be modified in any way, such as by removing 2537 the copyright notice or references to the Internet Society or other 2538 Internet organizations, except as needed for the purpose of 2539 developing Internet standards in which case the procedures for 2540 copyrights defined in the Internet Standards process must be 2541 followed, or as required to translate it into languages other than 2542 English. 2544 The limited permissions granted above are perpetual and will not be 2545 revoked by the Internet Society or its successors or assignees. 2547 This document and the information contained herein is provided on an 2548 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2549 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2550 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2551 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2552 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2554 Acknowledgment 2556 Funding for the RFC Editor function is currently provided by the 2557 Internet Society.