idnits 2.17.1 draft-ietf-mmusic-sdpng-06.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 18 characters in excess of 72. ** There are 13 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 380: '...ons. Specific procedures that MUST be...' RFC 2119 keyword, line 563: '... MUST NOT be considered in a capa...' RFC 2119 keyword, line 566: '...nfigurations. It MUST be ensured that...' RFC 2119 keyword, line 570: '...n potential configuration element MUST...' RFC 2119 keyword, line 578: '... o User agents MUST be able to infer...' (32 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1010 has weird spacing: '...MUST be direc...' -- 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 (March 03, 2003) is 7724 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) -- Looks like a reference, but probably isn't: 'RFC2327' on line 759 == Unused Reference: '3' is defined on line 1351, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1358, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1362, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1366, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1369, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1375, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1379, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1383, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1387, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1391, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1395, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1402, 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 1889 (ref. '3') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1890 (ref. '4') (Obsoleted by RFC 3551) == Outdated reference: A later version (-13) exists of draft-ietf-avt-profile-new-10 -- Possible downref: Normative reference to a draft: ref. '5' ** Obsolete normative reference: RFC 2733 (ref. '7') (Obsoleted by RFC 5109) ** Downref: Normative reference to an Informational RFC: RFC 2354 (ref. '8') ** Downref: Normative reference to an Experimental RFC: RFC 2974 (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' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' == Outdated reference: A later version (-07) exists of draft-hollenbeck-ietf-xml-guidelines-05 Summary: 13 errors (**), 0 flaws (~~), 17 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Kutscher 3 Internet-Draft Ott 4 Expires: September 1, 2003 Bormann 5 TZI, Universitaet Bremen 6 March 03, 2003 8 Session Description and Capability Negotiation 9 draft-ietf-mmusic-sdpng-06.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 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 1, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document defines a language for describing multimedia sessions 41 with respect to configuration parameters and capabilities of end- 42 systems. 44 This document is a product of the Multiparty Multimedia Session 45 Control (MMUSIC) working group of the Internet Engineering Task 46 Force. Comments are solicited and should be addressed to the working 47 group's mailing list at mmusic@ietf.org and/or the authors. 49 Document Revision 50 $Revision: 6.9 $ 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology and System Model . . . . . . . . . . . . . . . . 5 56 3. Capability Negotiation: Overview and Requirements . . . . . 9 57 3.1 Outline of the Negotiation Process . . . . . . . . . . . . . 9 58 3.2 The Negotiation Process . . . . . . . . . . . . . . . . . . 11 59 4. SDPng . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 60 4.1 Conceptual Outline . . . . . . . . . . . . . . . . . . . . . 12 61 4.1.1 Potential Configurations . . . . . . . . . . . . . . . . . . 13 62 4.1.2 Actual Configurations . . . . . . . . . . . . . . . . . . . 15 63 4.1.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . 18 64 4.1.4 Meta Information . . . . . . . . . . . . . . . . . . . . . . 18 65 4.2 Syntax Definition Mechanisms . . . . . . . . . . . . . . . . 18 66 4.3 Referencing Definitions . . . . . . . . . . . . . . . . . . 20 67 4.4 External Definition Packages . . . . . . . . . . . . . . . . 20 68 4.4.1 Package Definitions . . . . . . . . . . . . . . . . . . . . 20 69 4.4.2 Library Definitions . . . . . . . . . . . . . . . . . . . . 21 70 4.5 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . 22 71 5. Syntax Definition . . . . . . . . . . . . . . . . . . . . . 23 72 5.1 Potential Configurations . . . . . . . . . . . . . . . . . . 23 73 6. Specification of the Capability Negotiation . . . . . . . . 26 74 6.1 Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 26 75 6.2 RFC2533 Negotiation . . . . . . . . . . . . . . . . . . . . 27 76 6.2.1 Translating SDPng to RFC 2533 Expressions . . . . . . . . . 27 77 6.2.2 Applying RFC 2533 Canonicalization . . . . . . . . . . . . . 29 78 6.2.3 Integrating Feature Sets into SDPng . . . . . . . . . . . . 30 79 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 31 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 81 References . . . . . . . . . . . . . . . . . . . . . . . . . 33 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 83 A. Use of SDPng in conjunction with other IETF Signaling 84 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 36 85 A.1 The Session Announcement Protocol (SAP) . . . . . . . . . . 36 86 A.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . . 37 87 A.3 Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . . 44 88 A.4 Media Gateway Control Protocol (MEGACOP) . . . . . . . . . . 44 89 B. Change History . . . . . . . . . . . . . . . . . . . . . . . 45 90 Full Copyright Statement . . . . . . . . . . . . . . . . . . 47 92 1. Introduction 94 Multiparty multimedia conferencing is one of the applications that 95 require dynamic interchange of end-system capabilities and the 96 negotiation of a parameter set that is appropriate for all sending 97 and receiving end-systems in a conference. For some applications, 98 e.g. for loosely coupled conferences or for broadcast scenarios, it 99 may be sufficient to simply have session parameters be fixed by the 100 initiator of a conference. In such a scenario no negotiation is 101 required because only those participants with media tools that 102 support the predefined settings can join a media session and/or a 103 conference. 105 This approach is applicable for conferences that are announced some 106 time ahead of the actual start date of the conference. Potential 107 participants can check the availability of media tools in advance and 108 tools such as session directories can configure media tools upon 109 startup. This procedure however fails to work for conferences 110 initiated spontaneously including Internet phone calls or ad-hoc 111 multiparty conferences. Fixed settings for parameters such as media 112 types, their encoding etc. can easily inhibit the initiation of 113 conferences, for example in situations where a caller insists on a 114 fixed audio encoding that is not available at the callee's end- 115 system. 117 To allow for spontaneous conferences, the process of defining a 118 conference's parameter set must therefore be performed either at 119 conference start (for closed conferences) or maybe (potentially) even 120 repeatedly every time a new participant joins an active conference. 121 The latter approach may not be appropriate for every type of 122 conference without applying certain policies: For conferences with 123 TV-broadcast or lecture characteristics (one main active source) it 124 is usually not desired to re-negotiate parameters every time a new 125 participant with an exotic configuration joins because it may 126 inconvenience existing participants or even exclude the main source 127 from media sessions. But conferences with equal "rights" for 128 participants that are open for new participants on the other hand 129 would need a different model of dynamic capability negotiation, for 130 example a telephone call that is extended to a 3-parties conference 131 at some time during the session. 133 SDP [2] allows to specify multimedia sessions (i.e. conferences, 134 "session" as used here is not to be confused with "RTP session"!) by 135 providing general information about the session as a whole and 136 specifications for all the media streams (RTP sessions and others) to 137 be used to exchange information within the multimedia session. 139 Currently, media descriptions in SDP are used for two purposes: 141 o to describe session parameters for announcements and invitations 142 (the original purpose of SDP) and 144 o to describe the capabilities of a system and possibly provide a 145 choice between a number of alternatives (which SDP was not 146 designed for). 148 A distinction between these two "sets of semantics" is only made 149 implicitly. 151 This document is based upon a set of requirements specified in a 152 companion document [1]. In the following, we first introduce a model 153 for session description and capability negotiation as well as the 154 basic terms used throughout this specification (Section 2). In 155 Section 3, we provide an overview of options for capability 156 negotiation. Next, we outline the concept for the concepts 157 underlying SDPng and introduce the syntactical components step by 158 step in Section 4. 160 Appendix B lists the change history. 162 2. Terminology and System Model 164 Any (computer) system has, at a time, a number of rather fixed 165 hardware as well as software resources. These resources ultimately 166 define the limitations on what can be captured, displayed, rendered, 167 replayed, etc. with this particular device. We term features 168 enabled and restricted by these resources "system capabilities". 170 Example: System capabilities may include: a limitation of the 171 screen resolution for true color by the graphics board; available 172 audio hardware or software may offer only certain media encodings 173 (e.g. G.711 and G.723.1 but not GSM); and CPU processing power 174 and quality of implementation may constrain the possible video 175 encoding algorithms. 177 In multiparty multimedia conferences, participants employ different 178 "components" in conducting the conference. 180 Example: In lecture multicast conferences one component might be 181 the voice transmission for the lecturer, another the transmission 182 of video pictures showing the lecturer and the third the 183 transmission of presentation material. 185 Depending on system capabilities, user preferences and other 186 technical and political constraints, different configurations can be 187 chosen to accomplish the use of these components in a conference. 189 Each component can be characterized at least by (a) its intended use 190 (i.e. the function it shall provide) and (b) one or more possible 191 ways to realize this function. Each way of realizing a particular 192 function is referred to as a "configuration". 194 Example: A conference component's intended use may be to make 195 transparencies of a presentation visible to the audience on the 196 Mbone. This can be achieved either by a video camera capturing 197 the image and transmitting a video stream via some video tool or 198 by loading a copy of the slides into a distributed electronic 199 white-board. For each of these cases, additional parameters may 200 exist, variations of which lead to additional configurations (see 201 below). 203 Two configurations are considered different regardless of whether 204 they employ entirely different mechanisms and protocols (as in the 205 previous example) or they choose the same and differ only in a single 206 parameter. 208 Example: In case of video transmission, a JPEG-based still image 209 protocol may be used, H.261 encoded CIF images could be sent, as 210 could H.261 encoded QCIF images. All three cases constitute 211 different configurations. Of course there are many more detailed 212 protocol parameters. 214 Each component's configurations are limited by the participating 215 system's capabilities. In addition, the intended use of a component 216 may constrain the possible configurations further to a subset 217 suitable for the particular component's purpose. 219 Example: In a system for highly interactive audio communication 220 the component responsible for audio may decide not to use the 221 available G.723.1 audio codec to avoid the additional latency but 222 only use G.711. This would be reflected in this component only 223 showing configurations based upon G.711. Still, multiple 224 configurations are possible, e.g. depending on the use of A-law 225 or u-Law, packetization and redundancy parameters, etc. 227 In modeling multimedia sessions, we distinguish two types of 228 configurations: 230 o potential configurations 231 (a set of any number of configurations per component) indicating a 232 system's functional capabilities as constrained by the intended 233 use of the various components; 235 o actual configurations 236 (exactly one per instance of a component) reflecting the mode of 237 operation of this component's particular instantiation. 239 Example: The potential configuration of the aforementioned video 240 component may indicate support for JPEG, H.261/CIF, and 241 H.261/QCIF. A particular instantiation for a video conference may 242 use the actual configuration of H.261/CIF for exchanging video 243 streams. 245 In summary, the key terms of this model are: 247 o A multimedia session (streaming or conference) consists of one or 248 more conference components for multimedia "interaction". 250 o A component describes a particular type of interaction (e.g. 251 audio conversation, slide presentation) that can be realized by 252 means of different applications (possibly using different 253 protocols). 255 o A configuration is a set of parameters that are required to 256 implement a certain variation (realization) of a certain 257 component. There are actual and potential configurations. 259 * Potential configurations describe possible configurations that 260 are supported by an end-system. 262 * An actual configuration is an "instantiation" of one of the 263 potential configurations, i.e. a decision how to realize a 264 certain component. 266 In less abstract words, potential configurations describe what a 267 system can do ("capabilities") and actual configurations describe 268 how a system is configured to operate at a certain point in time 269 (media stream spec). 271 To decide on a certain actual configuration, a negotiation process 272 needs to take place between the involved peers: 274 1. to determine which potential configuration(s) they have in 275 common, and 277 2. to select one of this shared set of common potential 278 configurations to be used for information exchange (e.g. based 279 upon preferences, external constraints, etc.). 281 Note that the meaning of the term "actual configuration" is highly 282 application-specific. For example, for audio transport using RTP, an 283 actual configuration is equivalent to a payload format (potentially 284 plus format parameters), whereas for other applications it may be a 285 MIME type. 287 In SAP-based [9] session announcements on the Mbone, for which SDP 288 was originally developed, the negotiation procedure is non-existent. 289 Instead, the announcement contains the media stream description sent 290 out (i.e. the actual configurations) which implicitly describe what 291 a receiver must understand to participate. 293 In point-to-point scenarios, the negotiation procedure is typically 294 carried out implicitly: each party informs the other about what it 295 can receive and the respective sender chooses from this set a 296 configuration that it can transmit. 298 Capability negotiation must not only work for 2-party conferences but 299 is also required for multi-party conferences. Especially for the 300 latter case it is required that the process to determine the subset 301 of allowable potential configurations is deterministic to reduce the 302 number of required round trips before a session can be established. 303 For instance, in order to be used with SIP, the capability 304 negotiation is required to work with the offer/answer model that is 305 for session initiation with SIP -- limiting the negotiation to 306 exactly one round trip. 308 The requirements for the SDPng specification, subdivided into general 309 requirements and requirements for session descriptions, potential and 310 actual configurations as well as negotiation rules, are captured in a 311 companion document [1]. 313 The following list explains some terms used in this document: 315 Actual Configuration 316 An actual configuration is an "instantiation" of one of the 317 potential configurations, i.e. a decision how to realize a 318 certain component. 320 Component 321 A component describes a particular type of interaction (e.g. 322 audio conversation, slide presentation) that can be realized by 323 means of different applications (possibly using different 324 protocols). 326 Library 327 A library is a application specific collection of potential 328 configuration definition. For example, the RTP-AVP library would 329 include definitions for the audio and video codecs of the RTP 330 audio/video profile (AVP). 332 Package 333 A package is application specific data schema for expressing 334 potential and actual configurations. For example, an audio 335 package specifies the data schema for audio codecs. 337 Potential Configuration 338 Potential configurations describe possible configurations that are 339 supported by an end-system ("capabilities"). 341 3. Capability Negotiation: Overview and Requirements 343 SDPng is a description language for both potential configurations 344 (i.e. capabilities) of participants in multimedia conferences and 345 for actual configurations (i.e. final specifications of parameters). 346 Capability negotiation is the process of generating a usable set of 347 potential configurations and finally an actual configuration from a 348 set of potential configurations provided by each potential 349 participant in a multimedia conference. 351 SDPng supports the specification of endpoint capabilities and defines 352 a negotiation process: In a negotiation process, capability 353 descriptions are exchanged between participants. These descriptions 354 are processed in a "collapsing" step which results in a set of 355 commonly supported potential configurations. In a second step, the 356 final actual configuration is determined that is used for a 357 conference. This section specifies the usage of SDPng for capability 358 negotiation. It defines the collapsing algorithm and the procedures 359 for exchanging SDPng documents in a negotiation phase. 361 The description language and the rules for the negotiation phase that 362 are defined here are (in general) independent of the means by which 363 descriptions are conveyed during a negotiation phase (a reliable 364 transport service with causal ordering is assumed). There are 365 however properties and requirements of call signaling protocols that 366 have been considered to allow for a seamless integration of the 367 negotiation into the call setup process. For example, in order to be 368 usable with SIP, it must be possible to negotiate the conference 369 configuration within the two-way-handshake of the call setup phase. 370 In order to use SDPng instead of SDP according to the offer/answer 371 model defined in [16] it must be possible to determine an actual 372 configuration in a single request/response cycle. 374 3.1 Outline of the Negotiation Process 376 Conceptually, the negotiation process comprises the following 377 individual steps (considering two parties, A and B, where A tries to 378 invite B to a conference). Please note that this describes the steps 379 of the negotiation process conceptually -- it does not specify 380 requirements for implementations. Specific procedures that MUST be 381 followed by implementations are given below. 383 1. A determines its potential configurations for the components that 384 should be used in the conference (e.g. "interactive audio" and 385 "shared whiteboard") and sends a corresponding SDPng instance to 386 B. This SDPng instances is denoted "CAP(A)". 388 2. B receives A's SDPng instance and analyzes the set of components 389 (sdpng:c elements) in the description. For each component that B 390 wishes to support it generates a list of potential configurations 391 corresponding to B's capabilities, denoted "CAP(B)". 393 3. B applies the collapsing function and obtains a list of potential 394 configurations that both A and B can support, denoted 395 "CAP(A)xCAP(B) = CAP(AB)". 397 4. B sends CAP(B) to A. 399 5. A also applies the collapsing function and obtains "CAP(AB)". At 400 this step, both A and B know the capabilities of each other and 401 the potential configurations that both can support. 403 6. In order to obtain an actual configuration from the potential 404 configuration that has been obtained, both participants have to 405 pick a subset of the potential configurations that should 406 actually be used in the conference and generate the actual 407 configuration. It should be noted that it depends on the 408 specific application whether each component must be assigned 409 exactly one actual configuration (one sdpng:alt element) or 410 whether it is allowed to list multiple actual configurations. In 411 this model we assume that A selects the actual configuration, 412 denoted CFG(AB). 414 7. A augments CFG(AB) with the transport parameters it intends to 415 use, e.g., on which endpoint addresses A wishes to receive data, 416 obtaining CFG_T(A). A sends CFG_T(A) to A. 418 8. B receives CFG_T(A) and adds its own transport parameters, 419 resulting in CFG_T(AB). CFG_T(AB) contains the selected actual 420 configurations and the transport parameters of both A and B (plus 421 any other SDPng data, e.g., meta-information on the conference). 422 CFG_T(AB) is the complete conference description. Both A and B 423 now have the following information: 425 CAP(A) A's supported potential configurations 427 CAP(B) B's supported potential configurations 429 CAP(AB) The set of potential configurations supported by both A 430 and B. 432 CFG(AB) The set of actual configurations to be used. 434 CFG_T(AB) The set of actual configurations to be used augmented 435 with all required parameters. 437 In this model, the capability negotiation and configuration exchange 438 process leads to a description that represents a global view of the 439 configuration that should be used. This means, it contains the 440 complete configuration for all participants including per-participant 441 information like transport parameters. 443 Note that the model presented here results in four SDPng messages. 444 As an optimization, this procedure can be abbreviated to two 445 exchanges by including the transport (and other) parameters into the 446 potential configurations. A embeds its desired transport parameters 447 into the list of potential configurations and B also sends all 448 required parameters in the response together with B's potential 449 configurations. Both A and B can then derive CFG_T(AB). Transport 450 parameters are usually not negotiable, therefor they have to be 451 distinguished from other configuration information. 453 Specific procedures for re-negotiation and multi-party negotiation 454 will be defined in a future version of this document. 456 3.2 The Negotiation Process 458 The algorithm for comparing two potential configurations and for 459 obtaining a commonly supported subset is application specific. For 460 some limited application scenarios, a application specific 461 offer/answer process may be employed such as the SDP offer/answer 462 model [16]. 464 More advanced implementations require a generic capability 465 negotiation mechanism that allows for application-independent 466 negotiation of potential configuration with parameters from different 467 application domains. Capability negotiation frameworks such as RFC 468 2533 [18] can be employed for this purpose. In a future version of 469 this document, we will discuss of employing a RFC 2533 based 470 negotiation process for comparing and matching capability 471 descriptions in SDPng documents. 473 4. SDPng 475 This section introduces the underlying concepts of the Session 476 Description Protocol - next generation (SDPng). The focus of this 477 section is on the concepts of the capability description language 478 with a stepwise introduction of the various syntactical elements. 479 Note that this section only provides examples accompanied by 480 explanations. The description elements used in this section are not 481 normative. 483 4.1 Conceptual Outline 485 In Section 2 we have distinguished between potential configurations 486 ("capabilities") and actual configurations ("session descriptions"). 487 SDPng provides the possibility to express potential configurations 488 and actual configurations in one document. A potential configuration 489 list is used to declare capabilities and an actual configuration list 490 is used to declare concrete configurations. 492 Potential configurations are described independently of actual 493 configurations. In a "potential configurations" section, a user 494 agent lists its capabilities as a list of named definitions. For 495 negotiating capabilities from different user agents, the individual 496 definitions are matched in order to determine a commonly supported 497 subset of capabilities. The data schema for potential configurations 498 is defined in "package definitions". An example for an element of a 499 potential configuration would be the definition of a supported audio 500 codec. 502 Actual configurations can refer to capabilities and specify concrete 503 parameters for application protocol sessions, including transport 504 parameters. Actual configurations cannot be negotiated. 506 When defining potential configurations, capabilities are never 507 expressed with respect to other potential configuration elements, 508 e.g., the definition of an audio codec capability does not limit the 509 capability of using other audio codec. Constraints like the 510 simultaneous usage of capabilities can be expressed separately from 511 the capabilities themselves. 513 In addition, information about the communication session itself, such 514 as scheduling, information on the semantics of application protocol 515 sessions and information on the user who has initiated a conference. 516 This information is expressed separately from the definition of 517 potential and actual configurations. 519 These different elements of session description are discussed in 520 detail in the following sections. There are four different elements: 522 Potential Configurations; see Section 4.1.1. 524 Actual Configurations; see Section 4.1.2. 526 Constraints; see Section 4.1.3. 528 Session meta information; see Section 4.1.4. 530 4.1.1 Potential Configurations 532 A "Potential Configurations" section in an SDPng document lists 533 individual capabilities, e.g., codec capabilities. In a capability 534 negotiation process these potential configurations may be compared to 535 the potential configurations that are defined in an SDPng document 536 from another participant. The outline of such a negotiation process 537 is presented in Section 3. 539 Please note, that in the following examples, we use a straw-man 540 syntax in order to discuss the concepts. A final syntax will be 541 formally defined in a future version of this document. 543 These are two examples of elements in a potential configurations 544 section: 546 audio:codec 547 name=audio-basic 548 encoding="PCMU" 549 sampling="8000" 550 channels="[1]" 552 audio:codec 553 name="audio-L16-mono" 554 encoding="L16" 555 sampling="44100" 556 channels="[1,2,4]" 558 The following requirements can be stated for expressing potential 559 configurations: 561 o It must be possible to name potential configuration elements. In 562 the example above, this is achieved by the property "name". Names 563 MUST NOT be considered in a capability negotiation process. 565 o The potential configuration elements are referred to by this name 566 for specifying actual configurations. It MUST be ensured that 567 names that originate from different description documents reside 568 in separate namespaces in order to avoid collisions. 570 o The properties of a given potential configuration element MUST 571 have a well-defined type. For example, codec type names are 572 expressed as strings, and for capability negotiation, two codec 573 names can be processed by applying a string comparison. A maximum 574 frame-rate would be expressed as a number that represents an upper 575 limit, and for capability negotiation, the minimum of two numbers 576 would be used as a commonly supported value for the frame-rate. 578 o User agents MUST be able to infer the type of a given property 579 without referring to an external schema definition, i.e., the type 580 must be specified either implicitly or explicitly. Note, that in 581 the example above, the type is not specified. 583 o In addition to the data type and its value a property can provide 584 other characteristics: Some properties that a package definition 585 defines for a certain application are mandatory, i.e., they must 586 be specified in configuration descriptions. In the example above, 587 this would apply to the encoding, the sampling-rate and the number 588 of channels. For this single potential configuration elements 589 these properties serve as constraints for a negotiation: The 590 capability description matches only those description from other 591 participants that provide the same encoding, the same sampling- 592 rate and either 1,2 or 4 channels. If a description did not 593 provide one of these properties, the negotiation would fail. 594 There are however properties that can represent optional 595 parameters, such as a codec parameter that can optionally be used. 596 If one participant specified such a property and another 597 participant did not, we would expect the resulting configuration 598 to not include that property, however, the negotiation itself 599 should be successful. 601 o Some capabilities such as codec capabilities may be associated 602 with additional constraints, e.g., the directionality of media 603 streams ('send-only', 'receive-only'). It will be defined in a 604 future version of this document whether the directionality is 605 specified as a capability (in a potential configuration) or 606 whether it is rather specified as an attribute of an actual 607 configuration. 609 With these requirements in mind, we add additional characteristics to 610 the properties in potential configuration descriptions (and change 611 the encoding for the second potential configuration element): 613 audio:codec 614 name=audio-basic;type=name 615 encoding="PCMU";type=string 616 sampling="8000";type=maximum-limit 617 channels="[1]";type=set 618 featureX="200";type=maximum-limit;optional 620 audio:codec 621 name="audio-PCMU-44khz";type=name 622 encoding="PCMU";type=string 623 sampling="44100";type=maximum-limit 624 channels="[1,2,4]";type=set 625 featureY="200";type=string;optional 627 Note again, that these descriptions merely present examples in order 628 to present the data model that we use for potential configurations -- 629 this is not the SDPng syntax. In these examples, we have added the 630 optional features 'featureX' and 'featureY'. 632 If we assume, that the two potential configurations are contributions 633 from different participants for a capability negotiation, a resulting 634 potential configuration, after a negotiation process as outlined in 635 Section 3, could look like this: 637 audio:codec 638 encoding="PCMU";type=string 639 sampling="8000";type=maximum-limit 640 channels="[1]";type=set 642 The name cannot be considered for a capability negotiation, the 643 optional properties 'featureX' and 'featureY' have only been provided 644 by one participant each and the other properties have been processed 645 by the negotiation algorithms (that will be specified in a future 646 version of this document in Section 3). 648 So far, we have only considered codec capabilities. Other 649 capabilities would include transport mechanisms, e.g., RTP/UDP/IPv4: 651 rtp-udp:transport 652 name="rtp-udp-ipv4";type=name 653 network="IP4;type=string 655 4.1.2 Actual Configurations 657 The "Actual Configurations" section lists all the components that 658 constitute the multimedia application (IP telephone call, real-time 659 streaming application, multi-player gaming session etc.). For each 660 of these components, the actual configurations are given. Potential 661 configurations are used during capability exchange and/or 662 negotiation, actual configurations to configure media streams after 663 negotiation (e.g. with RTSP) or in session announcements (e.g. via 664 SAP). 666 Each component is labeled with an identifier so that it can be 667 referenced, e.g. to associate semantics with a particular media 668 stream. For such a component, any number of actual configurations 669 may be given with each configuration describing an alternative way to 670 realize the functionality of the respective component. 672 The semantics of this are application dependent. For example, for 673 SIP applications using the SDP offer/answer model, providing multiple 674 alternatives for a component (a media type in SDP) means that the 675 offerer is prepared to receive at any of the specified addresses any 676 of the specified payload formats (for RTP applications). In this 677 example, the order of alternatives is used to specify a preference, 678 i.e., the first alternative is the most preferred one. 680 The following example provides two alternative configurations for a 681 component named "interactive-audio". Each alternative refers to the 682 RTP-transport capability named "rtp-udp-ipv4" and to an audio-codec 683 capability. 685 component 686 name="interactive-audio" 687 alt 688 name="AVP-audio-0" 689 rtp-udp:transport 690 ref="rtp-udp-ipv4" 691 pt="96" 692 direction="send-receive" 693 addr="224.2.0.53" 694 rtp-port="7800" 695 rtcp-port="7801" 696 audio-codec 697 ref="audio-basic" 699 alt 700 name="AVP-audio-11" 701 rtp-udp:transport 702 ref="rtp-udp-ipv4" 703 pt="97" 704 direction="send-receive" 705 addr="224.2.0.53" 706 rtp-port="7800" 707 rtcp-port="7801" 708 audio-codec 709 ref="audio-L16-stereo" 711 For the RTP transport configuration, additional required parameters 712 are provided, such as the payload type number to be used (pt="97"), 713 the IP address and UDP port numbers for RTP and RTCP and the 714 directionality. 716 Note that in the example above, the actual configuration of the RTP 717 transport is identical for both alternatives -- with the exception of 718 the payload type number. In a final solution, this duplication 719 should be avoided by another level of indirection, i.e., by defining 720 these parameters once and referencing this definition where needed. 722 In order to determine the usable actual configurations after a 723 capability negotiation, a user agent has to traverse the references 724 in actual configurations to potential configurations and check 725 whether each capability is still supported after a negotiation 726 process. Only those alternatives that reference supported 727 capabilities can be considered for implementing the given component. 729 The semantics of specifying multiple alternatives for a component are 730 application specific -- for RTP configurations in SDP it means that 731 the endpoint is willing to receive any of the specified formats 732 without further out-of-band signaling and that the first 733 configuration is preferred. 735 4.1.3 Constraints 737 Potential configurations are media, transport, and other 738 capabilities, whereas configurations indicate which combinations of 739 these could be used to provide the desired functionality in a certain 740 setting. 742 There may, however, be further constraints within a system (such as 743 CPU cycles, DSP resources available, dedicated hardware, etc.) that 744 limit which of these configurations can be instantiated in parallel 745 (and how many instances of these may exist). We deliberately do not 746 couple this aspect of system resource limitations to the various 747 application semantics as the constraints may exist across application 748 boundaries. Also, in many cases, expressing such constraints is 749 simply not necessary (as many uses of the current SDP show), so 750 additional overhead can be avoided where this is not needed. 752 The usage of constraints will be specified in a future version of 753 this document. 755 4.1.4 Meta Information 757 The fourth and final section of an SDPng description is used to 758 specify meta information such as session layer attributes. These 759 attributes largely include those defined by SDP [RFC2327] (which are 760 explicitly indicated in the following specification) to describe 761 originator, purpose, and timing of a multimedia session among other 762 characteristics. Furthermore, SDPng includes attributes indicating 763 the semantics of the various Components in a teleconference or other 764 session. 766 A session-level specification for connection information (SDP "c=" 767 line), bandwidth information (SDP "b=" line), and encryption keys 768 (SDP "k=" lines) is deliberately not provided for in SDPng. The 769 relevant information can be specified directly in the Configuration 770 section for individual alternatives. 772 The section for meta information will provide for integrating and re- 773 using existing meta-information frameworks such as MPEG-7. Details 774 will be specified in a future version of this document. 776 4.2 Syntax Definition Mechanisms 778 In this section, we specify the syntax definition mechanisms for 779 SDPng. 781 In order to allow for the possibility to validate session 782 descriptions and in order to allow for structured extensibility, 783 SDPng relies on a syntax framework that provides concepts as well as 784 concrete procedures for document validation and extending the set of 785 allowed syntax elements. 787 SGML/XML technologies allow for the creation of Document Type 788 Definitions (DTDs) that can define the allowed content models for the 789 elements of conforming documents. Documents can be formally 790 validated against a given DTD to check their conformance and 791 correctness. XML DTDs however, cannot easily be extended. It is not 792 possible to alter to content models of element types or to add new 793 element types by third-party definition packages without creating the 794 possibility of name collisions. 796 For SDPng, a mechanism is needed that allows the specification of a 797 base syntax -- for example basic elements for the high level 798 structure of description documents -- while allowing extensions, for 799 example elements and attributes for new transport mechanisms, new 800 media types etc. to be added on demand. Still, it has to be ensured 801 that extensions do not result in name collisions. Furthermore, it 802 must be possible for applications that process descriptions documents 803 to distinguish extensions from base definitions. 805 For XML, mechanisms have been defined that allow for structured 806 extensibility of document schemata: XML Namespace and XML Schema. 808 XML Schema mechanisms allow to constrain the allowed document 809 content, e.g. for documents that contain structured data and also 810 provide the possibility that document instances can conform to 811 several XML Schema definitions at the same time, while allowing 812 Schema validators to check the conformance of these documents. 814 Extensions of the session description language, say for allowing to 815 express the parameters of a new media type, would require the 816 creation of a corresponding XML schema definition that contains the 817 specification of element types that can be used to describe 818 configurations of components for the new media type. Session 819 description documents have to reference the extension Schema module, 820 thus enabling parsers and validators to identify the elements of the 821 new extension module and to either ignore them (if they are not 822 supported) or to consider them for processing the session/capability 823 description. 825 It is important to note that the functionality of validating 826 capability and session description documents is not necessarily 827 required to generate or process them. For example, endpoints would 828 be configured to understand only those parts of description documents 829 that are conforming to the baseline specification and simply ignore 830 extensions they cannot support. The usage of XML and XML Schema is 831 thus rather motivated by the need to allow for extensions being 832 defined and added to the language in a structured way that does not 833 preclude the possibility to have applications to identify and process 834 the extensions elements they might support. The baseline 835 specification of XML Schema definitions and packages must be well- 836 defined and targeted to the set of parameters that are relevant for 837 the protocols and algorithms of the Internet Multimedia Conferencing 838 Architecture, i.e. transport over RTP/UDP/IP, the audio video 839 profile of RFC1890 etc. 841 Section 4.4 describes package definitions and library definition. 843 4.3 Referencing Definitions 845 SDPng provides a referencing concept for definitions. For example, 846 in the specification of an actual configuration, we reference the 847 capabilities of the potential configurations section. 849 The concrete reference mechanism depends on the syntax in use and 850 will be specified in a future version of this document. 852 4.4 External Definition Packages 854 There are two types of external definitions: 856 Package Definitions (Section 4.4.1) define rules, i.e., a data 857 schema, for specifying parameters that are not covered by the base 858 SDPng specification. 860 Library Definitions (Section 4.4.2) contain definitions that can be 861 referenced in SDPng documents. 863 4.4.1 Package Definitions 865 In order to allow for extensibility it must be possible to define 866 extensions to the basic SDPng configuration options. 868 For example, if some application requires the use of a new transport 869 protocol, endpoints must be able to describe their configuration with 870 respect to the parameters of that transport protocol. The mandatory 871 and optional parameters that can be configured and negotiated when 872 using the transport protocol will be specified in a definition 873 document. Such a definition document is called a "package". 875 A package contains rules that specify how SDPng is used to describe 876 conferences or end-system capabilities with respect to the parameters 877 of the package. The specific properties of the package definitions 878 mechanism are still to be defined. 880 An example of such a package would be the RTP package that defines 881 how to specify RTP parameters. Another example would be the audio 882 codec package that defines how specify audio codec parameters. 884 4.4.2 Library Definitions 886 While package definitions specify the allowed parameters for a given 887 profile, SDPng "Definitions" sections refer to package definitions 888 and define concrete configurations based on a specific package. 890 In order for such definitions to be imported into SDPng documents, 891 "SDPng libraries" may be defined and referenced in SDPng documents. 892 A library is a set of definitions that is conforming to one or more 893 package definitions. 895 The purpose of the library concept is to allow certain common 896 definitions to be factored-out so that not every SDPng document has 897 to include the basic definitions, for example the PCMU codec 898 definition. SDP [2] uses a similar concept by relying on the well 899 known static payload types (defined in RFC1890 [4]) that are also 900 just referenced but never defined in SDP documents. 902 An SPDng document that references definitions from an external 903 library has to declare the use of the external library. The external 904 library, being a set of configuration definitions for a given 905 package, again needs to declare the use of the package that it is 906 conforming to. A library itself can make reference to other external 907 libraries. 909 There are different possibilities of how package definitions and 910 libraries can be used in SDPng documents: 912 o In an SPDng document, a package definition can be referenced and 913 all the configuration definitions are provided within the document 914 itself. The SDPng document is self-contained with respect to the 915 definitions it uses. 917 o In an SPDng document, the use of an external library can be 918 declared. The library references a package definition and the 919 SDPng document references the library. There are two alternatives 920 how external libraries can be referenced: 922 by name: Referencing libraries by names implies the use of a 923 registration authority where definitions and reference names 924 can be registered with. It is conceivable that the most common 925 SDPng definitions be registered that way and that there will be 926 a baseline set of definitions that minimal implementations must 927 understand. Secondly, a registration procedure will be 928 defined, that allows vendors to register frequently used 929 definitions with a registration authority (e.g., IANA) and to 930 declare the use of registered definition packages in conforming 931 SDPng documents. Of course, care should be taken not to make 932 the external references too complex and thus require too much a 933 priori knowledge in a protocol engine implementing SDPng. 934 Relying on this mechanism in general is also problematic 935 because it impedes the extensibility, as it requires 936 implementors to provide support for new extensions in their 937 products before they can inter-operate. Registration is not 938 useful for spontaneous or experimental extensions that are 939 defined in an SDPng library. 941 by address: An alternative to referencing libraries by name is to 942 declare the use of an external library by providing an address, 943 i.e., an URL, that specifies where the library can be obtained. 944 While this allows the use of arbitrary third-party libraries 945 that can extend the basic SDPng set of configuration options in 946 many ways, in introduces additional complexity that could 947 result in in higher latency for the processing of a description 948 document with references to external libraries. In addition, 949 there are problems if the referenced libraries cannot be 950 accessed by all communication partners. 952 o Because of these problematic properties of external libraries, the 953 final SDPng specification will have to provide a set of 954 recommendations under which circumstances the different mechanisms 955 of referring to external definitions should be used. 957 4.5 Mappings 959 A mapping needs to be defined in particular to SDP that allows to 960 translate final session descriptions (i.e. the result of capability 961 negotiation processes) to SDP documents. In principle, this can be 962 done in a rather schematic fashion for the base specification and a 963 set of basic packages. 965 In addition, mappings to H.245 will be defined in order to support 966 applications like SIP-H.323 gateways. 968 5. Syntax Definition 970 An SDPng description is an XML document with different element types 971 for the different sections. The SDPng base syntax specification 972 defines this overall document structure. 974 5.1 Potential Configurations 976 A section for potential configurations is an XML element that can 977 provide a list of child elements. Each child element represents an 978 individual capability as described in Section 4.1.1. Each property 979 is represented by an XML attribute. The element types are defined in 980 package definitions. XML Namespaces are used to disambiguate element 981 types and to allow for extensibility. 983 Each element MUST provide an attribute "name". The value of this 984 attribute SHOULD be composed of a prefix (representing a namespace- 985 name) and a unique name for the corresponding capability within that 986 namespace. The namespace-name designates a namespace for the source 987 of the capability definition. If a prefix is specified, it MUST be 988 separated by a colon (':') from the name. 990 Each element represents a "feature set" (using the terminology of 991 [18]). Therefore, each attribute can provide a "range" of values -- 992 not only a single value. For example, an attribute can specify a set 993 of supported alternative values for a given property, e.g., for the 994 sampling rate of an audio codec. SDPng provides two different ways 995 for representing "value ranges": An attribute can specify a set of 996 tokens or a numerical range. 998 Each property that is represented by an XML attribute has a well- 999 defined type that is specified in the package definition. The type 1000 is encoded implicitly in the attribute value (similar to the syntax 1001 in RFC 2533 [18]). The following types are distinguished: 1003 Text strings, tokens 1004 An attribute may provide a token (a symbolic name), e.g., for a 1005 codec name. 1006 An example for a corresponding attribute: 1008 encoding="PCMU" 1010 Token MUST be directly embedded into the attribute content, i.e., 1011 the token is the attribute value. 1012 The complete formal syntax definition of tokens will be provided 1013 in a later version of this document. 1015 Token sets 1016 An attribute can specify a set of tokens (representing a list of 1017 alternative values for a certain property). 1018 An example for a corresponding attribute: 1020 sampling="[8000,16000,44100]" 1022 A token set MUST be specified as a list of tokens that are 1023 separated by commas (',') and are enclosed by square brackets 1024 ('[',']'). 1025 The complete formal syntax definition of token sets will be 1026 provided in a later version of this document. 1028 Numbers and Numerical ranges 1029 An attribute can specify a number or a range (minimum and maximum) 1030 for numbers. 1031 An example for an attribute specifying a number: 1033 bitrate="(64)" 1035 A number MUST be specified as a literal value in brackets ('(', 1036 ')'). 1037 An example for an attribute specifying a numerical range: 1039 bitrate="(64,128)" 1041 A numerical range MUST be specified as a pair of values. The 1042 first value is the minimum value (included in the range) and the 1043 seconds value is the maximum value (included in the range). The 1044 values are separated by a comma (',') and are enclosed in ('(', 1045 ')'). One of the range limits MAY be omitted, i.e., either the 1046 minimum or the maximum value, e.g., if the range has no upper or 1047 lower limit. 1048 An example for an attribute specifying a numerical range without 1049 an upper limit: 1051 bitrate="(64,)" 1053 The complete formal syntax definition of numbers and numerical 1054 ranges (and a definition of the exact number type) will be 1055 provided in a later version of this document. 1057 An example for an XML element describing an individual capability: 1059 1061 Capability elements MAY also provide attribute from different XML 1062 namespaces. For example, a video-codec capability MAY be described 1063 with attributes declaring general video capabilities, and this 1064 element MAY provide a list of additional codec specific attributes, 1065 as depicted in the following example: 1067 1070 The definition of "optional properties" (properties that to do not 1071 constitute a constraint but not optional enhancement -- see Section 1072 4.1.1) will be provided in a future version of this document. 1074 6. Specification of the Capability Negotiation 1076 The SDPng specification defines the syntax and the semantics of 1077 capability declarations (potential configurations). The algorithms 1078 that are used for processing descriptions and for comparing 1079 capability descriptions from different participants are application 1080 specific. 1082 In this section we discuss two alternative algorithms for 1083 implementations: A model that is base on the SDP offer/answer scheme 1084 (Section 6.1 and a model that is based on the feature matching 1085 algorithm that is specified in RFC 2533 [18] (Section 6.2). 1087 6.1 Offer/Answer 1089 The offer/answer model allows to communicating peers to determine a 1090 (common) mode of operation to exchange media streams in a single 1091 round-trip. Basically, the offerer proposes a set of components, 1092 providing one or more alternatives ("potential configurations") for 1093 each of these. From this offer, the answerer learns which components 1094 may be used and which configurations are conceivable to realize these 1095 components. The answerer indicates which components it supports 1096 (e.g. disallow a video session and go with a audio-only 1097 conversation) and also provides possible configurations to implement 1098 those components. Along with the media types and codec parameters, 1099 offerer and answerer specify which transport addresses to use and, in 1100 case of RTP, which payload types they want to use for sending. 1101 Offerer and answerer agree on a common set of media streams 1102 ("components") and on a possible set of codecs ("configurations") as 1103 well as the transport addresses and other parameters to be used. 1104 However, they do not fix a certain configuration (unless only a 1105 single one is exchanged in each direction). Instead, for each 1106 selected media stream, either peer may choose and dynamically switch 1107 to any of the configurations indicated by the other side in the 1108 respective offer or answer. 1110 For using SDPng with the offer/answer model (RFC 3264), the following 1111 considerations apply to the SDPng documents: 1113 o For each component to be used, all necessary parameters for at 1114 least one actual configuration MUST be given, i.e. transport 1115 addresses and payload formats MUST be specified along with the 1116 capabilities. 1118 o Matching of components is done based upon their identification in 1119 the session part of the SDPng document using predefined 1120 identifiers. 1122 o Components that shall not be instantiated (i.e. that are refused 1123 by the answerer) shall either be present but have all parameters 1124 of the actual configuration removed (i.e. no transport addresses, 1125 etc.) if they may be (re-)instantiated at a later stage. Or they 1126 shall be removed entirely from the answer if the respective 1127 component is not supported at all. In the latter case, the 1128 corresponding configurations MUST be removed from both the 1129 configuration section and the session section of the SDPng 1130 document. 1132 o For each component, the alternative potential configurations MUST 1133 be listed in the order of preference. A certain preference 1134 indicator ("q=" value) may be included in a future revision of 1135 this document. The considerations of RFC 3264 to simply arriving 1136 at symmetric codec use apply. 1138 The rules for matching properties and determining answers based upon 1139 the offers are similar to those specified in RFC 3264. 1141 A future revision of this document will define the details for all 1142 the attributes discussed in RFC 3264 that require special 1143 considerations (e.g. the directionality attribute for media 1144 streams). 1146 6.2 RFC2533 Negotiation 1148 SDPng potential configurations can be processed using the RFC 2533 1149 algorithm as defined in [18]. This involves the following steps: 1151 Translating SDPng potential configurations to RFC 2533 feature set 1152 expressions; 1154 Applying the RFC 2533 feature match algorithm; and 1156 Integrating the resulting feature set expressions into the SDPng 1157 selection of actual configurations. 1159 6.2.1 Translating SDPng to RFC 2533 Expressions 1161 SDPng potential configurations can be translated to RFC 2533 feature 1162 sets in a straightforward way, because SDPng uses a subset of the 1163 mechanisms provided by RFC 2533 with a different syntax. 1165 Each capability in an SDPng section for potential configurations is 1166 represented as an XML element with a set of attributes. We first 1167 describe how to translate a single capability element into a RFC 2533 1168 feature set, and then consider the combination of multiple capability 1169 elements. 1171 Basically, all attributes of an SDPng capability element and its 1172 child elements MUST be transformed to a RFC 2533 expression, whereas 1173 each attribute MUST be translated to a feature predicate. The 1174 resulting feature predicate are combined using the '&' (AND) 1175 operator. The name attributes MUST NOT be considered. 1177 Each predicate MUST be encapsulated by brackets ('(', ')'). Each XML 1178 attribute value is taken as a feature predicate value, i.e., the 1179 quote are not considered. Each attribute name is directly adopted as 1180 a 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 a RFC 2533 token. 1187 Token set 1188 A token set MUST be directly adopted as a RFC 2533 set. 1190 Number 1191 A single number in round brackets MUST be adopted as a RFC 2533 1192 number. The brackets MUST be removed. 1194 Numerical Ranges 1195 A numerical range MUST be transformed to a feature set expression 1196 with two feature predicates that are combined using the "&" (AND) 1197 operator. The first predicate specifies the lower limit and the 1198 second predicate specified the upper limit. 1199 For example, the attribute bitrate="(64,128)" would be transformed 1200 to the following feature set: 1202 (& (bitrate>=64) (bitrate<=128)) 1204 A numerical range without a lower limit MUST be transformed to a 1205 corresponding predicate with a '<=' operator and a numerical range 1206 without a upper limit MUST be transformed to a corresponding 1207 predicate with a '>=' operator. 1208 For example, the attribute bitrate="(,128)" would be transformed 1209 to the following feature set: 1211 (bitrate<=128) 1213 The following sample SDPng potential configuration would be 1214 transformed as follows: 1216 Original SDPng expression: 1218 1221 Transforming attributes to feature predicates: 1223 (& (resolution=QCIF) (frame-rate<=24) (h263plus:A=foo) (h263plus:B=bar)) 1225 Note that in example above, the namespace name is not used for 1226 feature tags, instead we use the namespace prefix (for abbreviation). 1227 RFC 2533 uses the syntax rules of RFC 2506 for feature tags. An 1228 additional requirement for transforming fully-qualified attribute 1229 names (including namespace names) to feature tags will be specified 1230 in a future version of this document. 1232 Multiple independent capability elements MUST each be transformed 1233 using the specification above and then combined into a single RFC 1234 2533 feature set by connecting the individual feature sets using the 1235 '|' (OR) operator. For example, the following sample SDPng potential 1236 configuration would be transformed as follows: 1238 1239 1242 Transforming attributes to feature predicates: 1244 (| 1245 (& (encoding=PCMU) (channels=[1,2]) (sampling=[8000,16000])) 1246 (& (resolution=QCIF) (frame-rate<=24) (h263plus:A=foo) (h263plus:B=bar)) 1247 ) 1249 Additional requirements for processing "optional" parameters (see 1250 Section 5) will be specified in a future version of this document. 1252 6.2.2 Applying RFC 2533 Canonicalization 1254 After transforming different SDPng capability descriptions from 1255 different participants into their equivalent RFC 2533 form, the 1256 following steps MUST be performed to calculate the common subset of 1257 capabilities: 1259 1. The individual feature sets MUST be combined into a single 1260 expression by creating conjunction of the feature sets, i.e., the 1261 feature sets MUST be connected by the '&' (AND) operator. 1263 2. The resulting expression MUST be reduced to disjunctive normal 1264 form, i.e., the canonical from as specified by RFC 2533 [18]. 1266 6.2.3 Integrating Feature Sets into SDPng 1268 A feature set that has been created by combining multiple independent 1269 feature sets and by reducing the result for canonical form does not 1270 indicate directly which of the capability elements belong the common 1271 subset of capabilities. The following steps MUST be performed to 1272 determine whether an individual capability element (e.g., from one of 1273 the contributing SDPng capability descriptions) belongs to the result 1274 feature set. 1276 Let R be the result feature set obtained from the canonicalization as 1277 specified in Section 6.2.2. 1279 1. For each capability element, generate the equivalent RFC 2533 1280 feature set by applying the steps specified in Section 6.2.1. 1281 Let C be the resulting feature set. 1283 2. Combine R and C into a single feature set by building a 1284 conjunction of the two feature sets (& R C). Let the result be 1285 the feature set T. 1287 3. Reduce T to disjunctive normal form by applying the 1288 canonicalization as defined in RFC 2533 [18]. 1290 4. If the remaining disjunction is non-empty, the constraints 1291 specified by capability element (the origin of C) can be 1292 satisfied by R, i.e., C represents a commonly supported 1293 capability. 1295 A future version of this document will specify requirements for 1296 exchanging calculated capabilities and for selecting appropriate 1297 actual configurations. 1299 7. Open Issues 1301 Definition of baseline libraries 1303 Libraries provide partially specified definitions, i.e. without 1304 transport parameters. How can SDPng documents reference the 1305 definitions and augment them with specific transport parameters? 1307 Referencing extension packages: XML-Schema does not support the 1308 declaration of multiple schemas via the schemaLocation attribute. 1309 Conceivable solution: When extension packages are used, the SDPng 1310 description is a "multi-part" object, that consists of an 1311 integrating schema definition (that references all necessary 1312 packages and the base definition) and the actual description 1313 document that is a schema instance of the integrating schema. 1315 Uniqueness of attribute values: When libraries are used they will 1316 contain definition elements with "name" attributes for later 1317 referencing. How to avoid name clashes for those identifiers? 1318 When an SDPng document uses libraries from different sources they 1319 could be incompatible because of name collisions. Possible 1320 solution: Prefix such IDs with a namespace name (either explicitly 1321 or implicitly by interpreting applications). The explicit 1322 prefixes have the advantage that no special knowledge would be 1323 required to resolve links at the cost of very long ID values. 1325 A registry (reuse of SDP mechanisms and names etc.) needs to be 1326 set up. 1328 Implicit declaration of SDPng schema and default package 1330 Should overwriting of child elements be allowed for referencing 1331 existing definitions with the "ref" attribute? 1333 We need a package definition language. XML-DTDs or XML-Schema is 1334 not sufficient as we need ways to specify the type (string/symbol, 1335 set, numerical range) and additional attributes (optional). 1337 8. Acknowledgements 1339 The authors would like to thank Teodora Guenkova, Goran Petrovic and 1340 Markus Nosse for their feedback and detailed comments. 1342 References 1344 [1] Kutscher, D., Ott, J., Bormann, C. and I. Curcio, "Requirements 1345 for Session Description and Capability Negotiation", Internet 1346 Draft draft-ietf-mmusic-sdpng-req-01.txt, April 2001. 1348 [2] Handley, M. and V. Jacobsen, "SDP: Session Description 1349 Protocol", RFC 2327, April 1998. 1351 [3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen, 1352 "RTP: A Transport Protocol for Real-Time Applications", RFC 1353 1889, January 1996. 1355 [4] Schulzrinne, H., "RTP Profile for Audio and Video Conferences 1356 with Minimal Control", RFC 1890, January 1996. 1358 [5] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 1359 Conferences with Minimal Control", draft-ietf-avt-profile-new- 1360 10.txt (work in progress), March 2001. 1362 [6] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, 1363 M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP 1364 Payload for Redundant Audio Data", RFC 2198, September 1997. 1366 [7] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for 1367 Generic Forward Error Correction", RFC 2733, December 1999. 1369 [8] Perkins, C. and O. Hodson, "Options for Repair of Streaming 1370 Media", RFC 2354, June 1998. 1372 [9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 1373 Protocol", RFC 2974, October 2000. 1375 [10] World Wide Web Consortium (W3C), "Extensible Markup Language 1376 (XML) 1.0 (Second Edition)", Status W3C Recommendation, Version 1377 http://www.w3.org/TR/2000/REC-xml-20001006, October 2000. 1379 [11] World Wide Web Consortium (W3C), "Namespaces in XML", Status 1380 W3C Recommendation, Version http://www.w3.org/TR/1999/REC-xml- 1381 names-19990114, January 1999. 1383 [12] World Wide Web Consortium (W3C), "XML Inclusions (XInclude) 1384 Version 1.0", Status W3C Candidate Recommendation, Version 1385 http://www.w3.org/TR/2002/CR-xinclude-20020221, February 2002. 1387 [13] World Wide Web Consortium (W3C), "XML Schema Part 1: 1388 Structures", Version http://www.w3.org/TR/2001/REC-xmlschema-1- 1389 20010502/, Status W3C Recommendation, May 2001. 1391 [14] World Wide Web Consortium (W3C), "XML Schema Part 2: 1392 Datatypes", Version http://www.w3.org/TR/2001/REC-xmlschema-2- 1393 20010502/, Status W3C Recommendation, May 2001. 1395 [15] World Wide Web Consortium (W3C), "XML Linking Language (XLink) 1396 Version 1.0", Version http://www.w3.org/TR/2001/REC-xlink- 1397 20010627/, Status W3C Recommendation, June 2001. 1399 [16] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1400 SDP", RFC 3264, June 2002. 1402 [17] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for The 1403 Use of XML within IETF Protocols", draft-hollenbeck-ietf-xml- 1404 guidelines-05.txt (work in progress), June 2002. 1406 [18] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 1407 2533, March 1999. 1409 Authors' Addresses 1411 Dirk Kutscher 1412 TZI, Universitaet Bremen 1413 Bibliothekstr. 1 1414 Bremen 28359 1415 Germany 1417 Phone: +49.421.218-7595, sip:dku@tzi.org 1418 Fax: +49.421.218-7000 1419 EMail: dku@tzi.uni-bremen.de 1421 Joerg Ott 1422 TZI, Universitaet Bremen 1423 Bibliothekstr. 1 1424 Bremen 28359 1425 Germany 1427 Phone: +49.421.201-7028, sip:jo@tzi.org 1428 Fax: +49.421.218-7000 1429 EMail: jo@tzi.uni-bremen.de 1430 Carsten Bormann 1431 TZI, Universitaet Bremen 1432 Bibliothekstr. 1 1433 Bremen 28359 1434 Germany 1436 Phone: +49.421.218-7024, sip:cabo@tzi.org 1437 Fax: +49.421.218-7000 1438 EMail: cabo@tzi.org 1440 Appendix A. Use of SDPng in conjunction with other IETF Signaling 1441 Protocols 1443 The SDPng model provides the notion of Components to indicate the 1444 intended types of collaboration between the users in e.g. a 1445 teleconferencing scenario. 1447 Three different abstractions are defined that are used for describing 1448 the properties of a specific Component: 1450 o a Capability refers to the fact that one of the involved parties 1451 supports one particular way of exchanging media -- defined in 1452 terms of transport, codec, and other parameters -- as part of the 1453 media session. 1455 o a Potential Configuration denotes a set of matching Capabilities 1456 from all those involved parties required to successfully realize 1457 one particular Component. 1459 o an Actual Configuration indicates the Potential Configuration 1460 which was chosen by the involved parties to realize a certain 1461 Component at one particular point in time. 1463 As mentioned before, this abstract notion of the interactions between 1464 a number of communicating systems needs to be mapped to the 1465 application scenarios of SDPng in conjunction with the various IETF 1466 signaling protocols: SAP, SIP, RTSP, and MEGACO. 1468 In general, this section provides recommendations and possible 1469 scenarios for the use of SDPng within specific protocols and 1470 applications. Is does not specify normative requirements. 1472 A.1 The Session Announcement Protocol (SAP) 1474 SAP is used to disseminate a previously created (and typically fixed) 1475 session description to a potentially large audience. An interested 1476 member of the audience will use the SDPng description contained in 1477 SAP to join the announced media sessions. 1479 This means that a SAP announcement contains the Actual Configurations 1480 of all Components that are part of the overall teleconference or 1481 broadcast. 1483 A SAP announcement may contain multiple Actual Configurations for the 1484 same Component. In this case, the "same" (i.e. semantically 1485 equivalent) media data from one configuration must be available from 1486 each of the Actual Configurations. In practice, this limits the use 1487 of multiple Actual Configurations to single-source multicast or 1488 broadcast scenarios. 1490 Each receiver of a SAP announcement with SDPng compares its locally 1491 stored Capabilities to realize a certain Component against the Actual 1492 Configurations contained in the announcement. If the intersection 1493 yields one or more Potential Configurations for the receiver, it 1494 chooses the one it sees fit best. If the intersection is empty, the 1495 receiver cannot participate in the announced session. 1497 SAP may be substituted by HTTP (in the general case, at least), SMTP, 1498 NNTP, or other IETF protocols suitable for conveying a media 1499 description from one entity to one or more other without the intend 1500 for further negotiation of the session parameters. 1502 Example from the SAP spec. to be provided. 1504 A.2 Session Initiation Protocol (SIP) 1506 SIP is used to establish and modify multimedia sessions, and SDPng 1507 may be carried at least in SIP INVITE and ACK messages as well as in 1508 a number of responses. From dealing with legacy SDP (and its 1509 essential non-suitability for capability negotiation), a particular 1510 use and interpretation of SDP has been defined for SIP. 1512 One of the important flexibilities introduced by SIP's usage of SDP 1513 is that a sender can change dynamically between all codecs that a 1514 receiver has indicated support (and has provided an address) for. 1515 Codec changes are not signaled out-of-band but only indicated by the 1516 payload type within the media stream. From this arises one important 1517 consequence to the conceptual view of a Component within SDPng. 1519 There is no clear distinction between Potential and Actual 1520 Configurations. There need not be a single Actual Configuration be 1521 chosen at setup time within the SIP signaling. Instead, a number of 1522 Potential Configurations is signaled in SIP (with all transport 1523 parameters required for carrying media streams) and the Actual 1524 Configuration is only identified by the payload type which is 1525 actually being transmitted at any point in time. 1527 Note that since SDPng does not explicitly distinguish between 1528 Potential and Actual Configurations, this has no implications on the 1529 SDPng signaling itself. 1531 SIP relies on an "offer/answer" model for the exchange of capability 1532 and configuration information. Either the caller or the callee sends 1533 an initial session description that is processed by the other side 1534 and returned. For capability negotiation, this means that the 1535 negotiation follows a two-stage-process: The "offerer" sends its 1536 capability description to the receiver. The receiver processes the 1537 offerers capabilities and his own capabilities and generates a result 1538 capability description that is sent back to the offerer. Both sides 1539 now know the commonly supported configurations and can initiate the 1540 media sessions. 1542 Because of this strict "offer/answer" model, the offerer must already 1543 send complete configurations (i.e. include transport addresses) 1544 along with the capability descriptions. The answer must also contain 1545 complete configuration parameters. The following figure shows, how 1546 SDPng content can be used in an INVITE request with a correspong 200 1547 OK message. 1549 Simple description document with only one alternative: 1551 F1 INVITE A -> B 1553 INVITE sip:B@example.com SIP/2.0 1554 Via: SIP/2.0/UDP hostA.example.com:5060 1555 From: A 1556 To: B 1557 Call-ID: 1234@hostA.example.com 1558 CSeq: 1 INVITE 1559 Contact: 1560 Content-Type: application/sdpng 1561 Content-Length: 685 1563 1564 1567 1568 1569 1570 1572 1573 1574 1575 1576 1577 1579 1580 1581 1582 1583 1584 1586 1587 1589 1590 Telephony media stream 1591 1592 1594 ================================================== 1596 F2 (100 Trying) B -> A 1598 SIP/2.0 100 Trying 1599 Via: SIP/2.0/UDP hostA.example.com:5060 1600 From: A 1601 To: B 1602 Call-ID: 1234@hostA.example.com 1603 CSeq: 1 INVITE 1604 Content-Length: 0 1606 ================================================== 1608 F3 180 Ringing B -> A 1610 SIP/2.0 180 Ringing 1611 Via: SIP/2.0/UDP hostA.example.com:5060 1612 From: A 1613 To: B ;tag=987654 1614 Call-ID: 1234@hostA.example.com 1615 CSeq: 1 INVITE 1616 Content-Length: 0 1618 ================================================== 1620 F4 200 OK B -> A 1622 SIP/2.0 200 OK 1623 Via: SIP/2.0/UDP hostA.example.com:5060 1624 From: A 1625 To: B ;tag=987654 1626 Call-ID: 1234@hostA.example.com 1627 CSeq: 1 INVITE 1628 Contact: 1629 Content-Type: application/sdpng 1630 Content-Length: 479 1632 1633 1636 1637 1638 1639 1641 1642 1643 1644 1645 1646 1648 1650 1651 1652 1653 1654 ================================================== 1656 ACK from A to B omitted 1658 In the INVITE message, A sends B a description document, that 1659 specifies exactly one component with one alternative (the PCMU audio 1660 stream). All required transport parameters all already contained in 1661 the description. The rtp:udp element provides an attribute "role" 1662 with a value of "receive", indicating that the specified endpoint 1663 address is used by the endpoint to receive media data. The element 1664 also provides the attribute "endpoint" with a value of "A", 1665 denominating the endpoint that can receive data on the specified 1666 address. This means, the semantics of specified transport addresses 1667 in configuration descriptions are the same as for SDP (when used with 1668 SIP): An endpoint specifies where it wants to receive data. 1670 In the 200 OK message, B sends an updated description document to A. 1671 For the sake of conciseness, the conf element (containing meta 1672 information about the conference) has been omitted. B supports the 1673 payload format that A has offered and adds his own transport 1674 parameters to the configuration information, specifying the endpoint 1675 address where B wants to receive media data. In order to 1676 disambiguate its transport configurations from A's, B sets the 1677 attribute "endpoint" to the value "B". The specific value of the 1678 "endpoint" attribute is not important, the only requirements are that 1679 a party that contributes to the session description, must use a 1680 unique name for the endpoint attribute and that a contributing party 1681 must use the same value for the endpoint attributes of all elements 1682 it adds to the session description. 1684 The following example shows a capability description that provides 1685 two alternatives for the audio component. 1687 Description document with two alternatives: 1689 F1 INVITE A -> B 1691 INVITE sip:B@example.com SIP/2.0 1692 Via: SIP/2.0/UDP hostA.example.com:5060 1693 From: A 1694 To: B 1695 Call-ID: 1234@hostA.example.com 1696 CSeq: 1 INVITE 1697 Contact: 1698 Content-Type: application/sdpng 1699 Content-Length: 935 1701 1702 1705 1707 1708 1709 1711 1712 1713 1715 1717 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1734 1735 1737 1738 1740 1741 Telephony media stream 1742 1743 1745 ================================================== 1747 F2 (100 Trying) B -> A 1749 SIP/2.0 100 Trying 1750 Via: SIP/2.0/UDP hostA.example.com:5060 1751 From: A 1752 To: B 1753 Call-ID: 1234@hostA.example.com 1754 CSeq: 1 INVITE 1755 Content-Length: 0 1757 ================================================== 1759 F3 180 Ringing B -> A 1761 SIP/2.0 180 Ringing 1762 Via: SIP/2.0/UDP hostA.example.com:5060 1763 From: A 1764 To: B ;tag=987654 1765 Call-ID: 1234@hostA.example.com 1766 CSeq: 1 INVITE 1767 Content-Length: 0 1769 ================================================== 1770 F4 200 OK B -> A 1772 SIP/2.0 200 OK 1773 Via: SIP/2.0/UDP hostA.example.com:5060 1774 From: A 1775 To: B ;tag=987654 1776 Call-ID: 1234@hostA.example.com 1777 CSeq: 1 INVITE 1778 Contact: 1779 Content-Type: application/sdpng 1780 Content-Length: 479 1782 1783 1786 1788 1789 1790 1792 1793 1794 1796 1799 1801 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 ================================================== 1815 ACK from A to B omitted 1816 In the INVITE message, A sends B a description document, that 1817 specifies one component with two alternatives for the audio stream 1818 (PCMU and G.729). Since A wants to use the same transport address 1819 for receiving media data regardless of the payload format, A provides 1820 the transport specification in the def element and references this 1821 definition in the rtp:session elements for both alternatives by using 1822 the attribute "transport". 1824 In the 200 OK message, B sends an updated description document to A. 1825 B does only support PCMU, so it removes the alternative for G.729 1826 from the description. B also defines its transport address in the 1827 def element and references this definition by referencing the rtp:udp 1828 element named "B-rcv". 1830 A.3 Real-Time Streaming Protocol (RTSP) 1832 In contrast to SIP, RTSP has, from its intended usage, a clear 1833 distinction between offering Potential Configurations (typically by 1834 the server) and choosing one out of these (by the client), and, in 1835 some cases; some parameters (such as multicast addresses) may be 1836 dictated by the server. Hence with RTSP, there is a clear 1837 distinguish between Potential Configurations during the negotiation 1838 phase and a finally chosen Actual Configuration according to which 1839 streaming will take place. 1841 Example from the RTSP spec to be provided. 1843 A.4 Media Gateway Control Protocol (MEGACOP) 1845 The MEGACO architecture also follows the SDPng model of a clear 1846 separation between Potential and Actual Configurations. Upon 1847 startup, a Media Gateway (MG) will "register" with its Media Gateway 1848 Controller (MGC) and the latter will audit the MG for its 1849 Capabilities. Those will be provided as Potential Configurations, 1850 possibly with extensive Constraints specifications. Whenever a media 1851 path needs to be set up by the MGC between two MGs or an MG needs to 1852 be reconfigured internally, the MGC will use (updated) Actual 1853 Configurations. 1855 Details and examples to be defined. 1857 Appendix B. Change History 1859 draft-ietf-mmusic-sdpng-06.txt 1861 * Removed section on capability negotiation algorithm and section 1862 on formal specification. Added Section 3. 1864 * Removed specification of concrete XML syntax from Section 4. 1865 Added requirements and theoretic considerations. 1867 * Added clarification of term "actual configuration" in Section 1868 2. 1870 * Changed "profile" to "package". 1872 * Added introducing text to Section 4.1. 1874 * Added a list of terms with explanation at the end of Section 2. 1876 * Removed audio and RTP packages from appendix. 1878 * Added Section 5 ("Syntax Definition"). 1880 * Added Section 6 ("Specification of the Capability 1881 Negotiation"). 1883 draft-ietf-mmusic-sdpng-05.txt 1885 * Moved audio and RTP packages to appendix. 1887 * Moved section "Use of SDPng in conjunction with other IETF 1888 Signaling Protocols" to appendix. 1890 * Changed mechanism for references to definitions: Definition 1891 elements provide an attribute "ref" that can be used to 1892 referenced existing definitions (Section 4.3). Removed other 1893 mechanisms for referencing (attributes "format" and 1894 "transport", element type "use"). 1896 * Corrections to schema definitions and examples 1898 draft-ietf-mmusic-sdpng-04.txt 1900 * New section on capability negotiation. 1902 * New section on referencing definitions (Section 4.3). 1904 * New section on properties. 1906 * New section on definition groups. 1908 draft-ietf-mmusic-sdpng-03.txt 1910 * Extension of the SDPng schema (use of Xlinks etc.) 1912 * Clarification in the text 1914 * Fixed examples 1916 * Added example libraries as appendices 1918 * More details on usage with SIP, including examples. 1920 draft-ietf-mmusic-sdpng-02.txt 1922 * Added a section on formal specification mechanisms. 1924 draft-ietf-mmusic-sdpng-01.txt 1926 * renamed section "Syntax Proposal" to "Syntax Definition 1927 Mechanisms". More text on DTD vs. schema. Edited the example 1928 description. 1930 * updated example definitions in section "Definitions" and 1931 "Components & Configurations" 1933 * section "Session Attributes" replaces section "Session" 1935 * new appendix on audio codec definitions 1937 Full Copyright Statement 1939 Copyright (C) The Internet Society (2003). All Rights Reserved. 1941 This document and translations of it may be copied and furnished to 1942 others, and derivative works that comment on or otherwise explain it 1943 or assist in its implementation may be prepared, copied, published 1944 and distributed, in whole or in part, without restriction of any 1945 kind, provided that the above copyright notice and this paragraph are 1946 included on all such copies and derivative works. However, this 1947 document itself may not be modified in any way, such as by removing 1948 the copyright notice or references to the Internet Society or other 1949 Internet organizations, except as needed for the purpose of 1950 developing Internet standards in which case the procedures for 1951 copyrights defined in the Internet Standards process must be 1952 followed, or as required to translate it into languages other than 1953 English. 1955 The limited permissions granted above are perpetual and will not be 1956 revoked by the Internet Society or its successors or assigns. 1958 This document and the information contained herein is provided on an 1959 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1960 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1961 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1962 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1963 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1965 Acknowledgement 1967 Funding for the RFC Editor function is currently provided by the 1968 Internet Society.