idnits 2.17.1 draft-ietf-mmusic-sdpng-00.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 6 instances of too long lines in the document, the longest one being 17 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. 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 (April 19, 2001) is 8398 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: '2' is defined on line 741, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 748, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 752, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 755, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 758, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 761, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (ref. '1') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 1889 (ref. '2') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1890 (ref. '3') (Obsoleted by RFC 3551) ** Downref: Normative reference to an Informational RFC: RFC 2703 (ref. '6') ** 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') Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 2 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: October 18, 2001 Bormann 5 TZI, Universitaet Bremen 6 April 19, 2001 8 Session Description and Capability Negotiation 9 draft-ietf-mmusic-sdpng-00.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 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any 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/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 18, 2001. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 This document defines a language for describing multimedia sessions 40 with respect to configuration parameters and capabilities of end 41 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 confctrl@isi.edu and/or the authors. 48 Document Revision 50 $Revision: 1.8 $ 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology and System Model . . . . . . . . . . . . . . . . 5 56 3. SDPng . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 3.1 Conceptual Outline . . . . . . . . . . . . . . . . . . . . . 8 58 3.1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 8 59 3.1.2 Components & Configurations . . . . . . . . . . . . . . . . 10 60 3.1.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . 11 61 3.1.4 Session . . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 3.2 Syntax Proposal . . . . . . . . . . . . . . . . . . . . . . 12 63 3.3 External Definition Packages . . . . . . . . . . . . . . . . 14 64 3.3.1 Profile Definitions . . . . . . . . . . . . . . . . . . . . 15 65 3.3.2 Library Definitions . . . . . . . . . . . . . . . . . . . . 15 66 3.4 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 18 68 References . . . . . . . . . . . . . . . . . . . . . . . . . 19 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 70 Full Copyright Statement . . . . . . . . . . . . . . . . . . 21 72 1. Introduction 74 Multiparty multimedia conferencing is one application that requires 75 the dynamic interchange of end system capabilities and the 76 negotiation of a parameter set that is appropriate for all sending 77 and receiving end systems in a conference. For some applications, 78 e.g. for loosely coupled conferences, it may be sufficient to simply 79 have session parameters be fixed by the initiator of a conference. 80 In such a scenario no negotiation is required because only those 81 participants with media tools that support the predefined settings 82 can join a media session and/or a conference. 84 This approach is applicable for conferences that are announced some 85 time ahead of the actual start date of the conference. Potential 86 participants can check the availability of media tools in advance 87 and tools like session directories can configure media tools on 88 startup. This procedure however fails to work for conferences 89 initiated spontaneously like Internet phone calls or ad-hoc 90 multiparty conferences. Fixed settings for parameters like media 91 types, their encoding etc. can easily inhibit the initiation of 92 conferences, for example in situations where a caller insists on a 93 fixed audio encoding that is not available at the callee's end 94 system. 96 To allow for spontaneous conferences, the process of defining a 97 conference's parameter set must therefore be performed either at 98 conference start (for closed conferences) or maybe (potentially) 99 even repeatedly every time a new participant joins an active 100 conference. The latter approach may not be appropriate for every 101 type of conference without applying certain policies: For 102 conferences with TV-broadcast or lecture characteristics (one main 103 active source) it is usually not desired to re-negotiate parameters 104 every time a new participant with an exotic configuration joins 105 because it may inconvenience existing participants or even exclude 106 the main source from media sessions. But conferences with equal 107 "rights" for participants that are open for new participants on the 108 other hand would need a different model of dynamic capability 109 negotiation, for example a telephone call that is extended to a 110 3-parties conference at some time during the session. 112 SDP [1] allows to specify multimedia sessions (i.e. conferences, 113 "session" as used here is not to be confused with "RTP session"!) 114 by providing general information about the session as a whole and 115 specifications for all the media streams (RTP sessions and others) 116 to be used to exchange information within the multimedia session. 118 Currently, media descriptions in SDP are used for two purposes: 120 o to describe session parameters for announcements and invitations 121 (the original purpose of SDP) 123 o to describe the capabilities of a system (and possibly provide a 124 choice between a number of alternatives). Note that SDP was not 125 designed to facilitate this. 127 A distinction between these two "sets of semantics" is only made 128 implicitly. 130 In the following we first introduce a model for session description 131 and capability negotiation and define some terms that are later used 132 to express some requirements. Note that this list of requirements is 133 possibly incomplete. The purpose of this document is to initiate the 134 development of a session description and capability negotiation 135 framework. 137 2. Terminology and System Model 139 Any (computer) system has, at a time, a number of rather fixed 140 hardware as well as software resources. These resources ultimately 141 define the limitations on what can be captured, displayed, rendered, 142 replayed, etc. with this particular device. We term features enabled 143 and restricted by these resources "system capabilities". 145 Example: System capabilities may include: a limitation of the 146 screen resolution for true color by the graphics board; available 147 audio hardware or software may offer only certain media encodings 148 (e.g. G.711 and G.723.1 but not GSM); and CPU processing power 149 and quality of implementation may constrain the possible video 150 encoding algorithms. 152 In multiparty multimedia conferences, participants employ different 153 "components" in conducting the conference. 155 Example: In lecture multicast conferences one component might be 156 the voice transmission for the lecturer, another the transmission 157 of video pictures showing the lecturer and the third the 158 transmission of presentation material. 160 Depending on system capabilities, user preferences and other 161 technical and political constraints, different configurations can be 162 chosen to accomplish the "deployment" of these components. 164 Each component can be characterized at least by (a) its intended use 165 (i.e. the function it shall provide) and (b) a one or more possible 166 ways to realize this function. Each way of realizing a particular 167 function is referred to as a "configuration". 169 Example: A conference component's intended use may be to make 170 transparencies of a presentation visible to the audience on the 171 Mbone. This can be achieved either by a video camera capturing 172 the image and transmitting a video stream via some video tool or 173 by loading a copy of the slides into a distributed electronic 174 whiteboard. For each of these cases, additional parameters may 175 exist, variations of which lead to additional configurations (see 176 below). 178 Two configurations are considered different regardless of whether 179 they employ entirely different mechanisms and protocols (as in the 180 previous example) or they choose the same and differ only in a 181 single parameter. 183 Example: In case of video transmission, a JPEG-based still image 184 protocol may be used, H.261 encoded CIF images could be sent as 185 could H.261 encoded QCIF images. All three cases constitute 186 different configurations. Of course there are many more detailed 187 protocol parameters. 189 Each component's configurations are limited by the participating 190 system's capabilities. In addition, the intended use of a component 191 may constrain the possible configurations further to a subset 192 suitable for the particular component's purpose. 194 Example: In a system for highly interactive audio communication 195 the component responsible for audio may decide not to use the 196 available G.723.1 audio codec to avoid the additional latency but 197 only use G.711. This would be reflected in this component only 198 showing configurations based upon G.711. Still, multiple 199 configurations are possible, e.g. depending on the use of A-law 200 or u-Law, packetization and redundancy parameters, etc. 202 In this system model, we distinguish two types of configurations: 204 o potential configurations 205 (a set of any number of configurations per component) indicating 206 a system's functional capabilities as constrained by the intended 207 use of the various components; 209 o actual configurations 210 (exactly one per instance of a component) reflecting the mode of 211 operation of this component's particular instantiation. 213 Example: The potential configuration of the aforementioned video 214 component may indicate support for JPEG, H.261/CIF, and 215 H.261/QCIF. A particular instantiation for a video conference may 216 use the actual configuration of H.261/CIF for exchanging video 217 streams. 219 In summary, the key terms of this model are: 221 o A multimedia session (streaming or conference) consists of one or 222 more conference components for multimedia "interaction". 224 o A component describes a particular type of interaction (e.g. 225 audio conversation, slide presentation) that can be realized by 226 means of different applications (possibly using different 227 protocols). 229 o A configuration is a set of parameters that are required to 230 implement a certain variation (realization) of a certain 231 component. There are actual and potential configurations. 233 * Potential configurations describe possible configurations that 234 are supported by an end system. 236 * An actual configuration is an "instantiation" of one of the 237 potential configurations, i.e. a decision how to realize a 238 certain component. 240 In less abstract words, potential configurations describe what a 241 system can do ("capabilities") and actual configurations describe 242 how a system is configured to operate at a certain point in time 243 (media stream spec). 245 To decide on a certain actual configuration, a negotiation process 246 needs to take place between the involved peers: 248 1. to determine which potential configuration(s) they have in 249 common, and 251 2. to select one of this shared set of common potential 252 configurations to be used for information exchange (e.g. based 253 upon preferences, external constraints, etc.). 255 In SAP [9] -based session announcements on the Mbone, for which SDP 256 was originally developed, the negotiation procedure is non-existent. 257 Instead, the announcement contains the media stream description sent 258 out (i.e. the actual configurations) which implicitly describe what 259 a receiver must understand to participate. 261 In point-to-point scenarios, the negotiation procedure is typically 262 carried out implicitly: each party informs the other about what it 263 can receive and the respective sender chooses from this set a 264 configuration that it can transmit. 266 Capability negotiation must not only work for 2-party conferences 267 but is also required for multi-party conferences. Especially for the 268 latter case it is required that the process of determining the 269 subset of allowable potential configurations is deterministic to 270 reduce the number of required round trips before a session can be 271 established. 273 In the following, we elaborate on requirements for an SDPng 274 specification, subdivided into general requirements and requirements 275 for session descriptions, potential and actual configurations as 276 well as negotiation rules. 278 3. SDPng 280 This section outlines a proposed solution for describing 281 capabilities that meets most of the above requirements. Note that at 282 this early point in time not all of the details are completely 283 filled in; rather, the focus is on the concepts of such a capability 284 description and negotiation language. 286 3.1 Conceptual Outline 288 Our concept for the description language follows the system model 289 introduced in the beginning of this document. We use a rather 290 abstract language to avoid misinterpretations due to different 291 intuitive understanding of terms as far as possible. 293 Our concept of a capability description language addresses various 294 pieces of a full description of system and application capabilities 295 in four separate "sections": 297 Definitions (elementary and compound) 299 Potential or Actual Configurations 301 Constraints 303 Session attributes 305 3.1.1 Definitions 307 The definition section specifies a number of basic abstractions that 308 are later referenced to avoid repetitions in more complex 309 specifications and allow for a concise representation. Definition 310 elements are labelled with an identifier by which they may be 311 referenced. They may be elementary or compound (i.e. combinations of 312 elementary entities). Examples of definitions of that sections 313 include (but are not limited to) codec definitions, redundancy 314 schemes, transport mechanisms and payload formats. 316 Elementary definition elements do not reference other elements. Each 317 elementary entity only consists of one of more attributes and their 318 values. Default values specified in the definition section may be 319 overridden in descriptions for potential (and later actual) 320 configurations. The concrete mechanisms for overriding definitions 321 are still to be defined. 323 For the moment, elementary elements are defined for media types 324 (i.e. codecs) and for media transports. For each transport and for 325 each codec to be used, the respective attributes need to be defined. 326 This definition may either be provided within the "Definition" 327 section itself or in an external document (similar to the 328 audio-video profile or an IANA registry that define payload types 329 and media stream identifiers. 331 Examples for elementary definitions: 333 335 337 The element type "audio-codec" is used in these examples to define 338 audio codec configurations. The configuration parameters are given 339 as attribute values. 341 Compound elements combine a number of elementary and/or other 342 compound elements for more complex descriptions. This mechanism can 343 be used for simple standard configurations such as G.711 over 344 RTP/AVP as well as to express more complex coding schemes including 345 e.g. FEC schemes, redundancy coding, and layered coding. Again, such 346 definitions may be standardized and externalized so that there is no 347 need to repeat them in every specification. 349 An example for the definition of a audio-redundancy format: 351 352 353 355 In this example, the element type "audio-red" is used to define a 356 redundant audio configuration that is labelled "red-pcm-gsm-fec" for 357 later referencing. In the definition itself, the element type "use" 358 is used to reference other definitions. 360 Definitions may have default values specified along with them for 361 each attribute. Some of these default values may be overridden so 362 that a codec definition can easily be re-used in a different context 363 (e.g. by specifying a different sampling rate) without the need for 364 a large number of base specifications. 366 This approach allows to have simple as well as more complex 367 definitions which are commonly used be available in an extensible 368 set of reference documents. Section 3.3 specifies the mechanisms for 369 external references. 371 Note: For negotiation between endpoints, it may be helpful to define 372 two modes of operation: explicit and implicit. Implicit 373 specifications may refer to externally defined entities to minimize 374 traffic volume, explicit specifications would list all external 375 definitions used in a description in the "Definitions" section. 376 Again, please see Section 3.3 for complete discussion of external 377 definitions. 379 3.1.2 Components & Configurations 381 The "Configurations" section contains all the components that 382 constitute the multimedia conference (IP telephone call, multiplayer 383 gaming session etc.). For each of these components, the potential 384 and, later, the actual configurations are given. Potential 385 configurations are used during capability exchange and/or 386 negotiation, actual configurations to configure media streams after 387 negotiation or in session announcements (e.g. via SAP). A potential 388 and the actual configuration of a component may be identical. 390 Each component is labelled with an identifier so that it can be 391 referenced, e.g. to associate semantics with a particular media 392 stream. For such a component, any number of configurations may be 393 given with each configuration describing an alternate way to realize 394 the functionality of the respective component. 396 Each configuration (potential as well as actual) is labelled with an 397 identifier. A configuration combines one or more (elementary and/or 398 compound) entities from the "Definitions" section to describe a 399 potential or an actual configuration. Within the specification of 400 the configuration, default values from the referenced entities may 401 be overwritten. 403 404 405 406 407 408 239.239.239.239 30000 409 410 411 413 414 415 416 239.239.239.239 30000 417 418 419 420 421 423 For example, an IP telephone call may require just a single 424 component id=interactive-audio with two possible ways of 425 implementing it. The two corresponding configurations are 426 "AVP-audio-0" without modification, the other ("AVP-audio-11") uses 427 linear 16-bit encoding. Typically, transport address parameters such 428 as the port number would also be provided. In this example, this 429 information is given by the "addr" element. 431 During/after the negotiation phase, an actual configuration is 432 chosen out of a number of alternative potential configurations, the 433 actual configuration may refer to the potential configuration just 434 by its "id", possibly allowing for some parameter modifications. 435 Alternatively, the full actual configuration may be given. 437 3.1.3 Constraints 439 Definitions specify media, transport, and other capabilities, 440 whereas configurations indicate which combinations of these could be 441 used to provide the desired functionality in a certain setting. 443 There may, however, be further constraints within a system (such as 444 CPU cycles, DSP available, dedicated hardware, etc.) that limit 445 which of these configurations can be instantiated in parallel (and 446 how many instances of these may exist). We deliberately do not 447 couple this aspect of system resource limitations to the various 448 application semantics as the constraints exist across application 449 boundaries. Also, in many cases, expressing such constraints is 450 simply not necessary (as many uses of the current SDP show), so 451 additional overhead can be avoided where this is not needed. 453 Therefore, we introduce a "Constraints" section to contain these 454 additional limitations. Constraints refer to potential 455 configurations and to entity definitions and express and use simple 456 logic to express mutual exclusion, limit the number of 457 instantiations, and allow only certain combinations. The following 458 example shows the definition of a constraints that restricts the 459 maximum number of instantiation of two alternatives (that would have 460 to be defined in the configuration section before) when they are 461 used in parallel: 463 464 465 466 467 469 As the example shows, contraints are defined by defining limits on 470 simultaneous instantiations of alternatives. They are not defined by 471 expressing abstract endsystem resources, such as CPU speed or memory 472 size. 474 By default, the "Constraints" section is empty (or missing) which 475 means that no further restrictions apply. 477 3.1.4 Session 479 The "Session" section is used to describe general meta-information 480 parameters of the communication relationship to be invoked or 481 modified. It contains most (if not all) of the general parameters of 482 SDP (and thus will easily be usable with SAP for session 483 announcements). 485 In addition to the session description parameters, the "Session" 486 section also ties the various components to certain semantics. If, 487 in current SDP, two audio streams were specified (possibly even 488 using the same codecs), there was little way to differentiate 489 between their uses (e.g. live audio from an event broadcast vs. the 490 commentary from the TV studio). 492 This section also allows to tie together different media streams or 493 provide a more elaborate description of alternatives (e.g. subtitles 494 or not, which language, etc.). 496 497 SDPng test 498 joe@example.com 499 A test conference 500 501 Video stream for the different speakers 502 503 505 Further uses are envisaged but need to be defined in future versions 506 of this document. 508 3.2 Syntax Proposal 510 In order to allow for the possibility to validate session 511 descriptions and in order to allow for structured extensibility it 512 is proposed to rely on a syntax framework that provides concepts as 513 well as concrete procedures for document validation and extending 514 the set of allows syntax elements. 516 SGML/XML technologies allow for the preparation of Document Type 517 Definitions (DTDs) that can define the allowed content models for 518 the elements of conforming documents. Documents can be formally 519 validated against a given DTD to check their conformance and 520 correctness. For XML, mechanisms have been defined that allow for 521 structured extensibility of a model of allowed syntax: XML Namespace 522 and XML Schema. 524 XML Schema mechanisms allows to constrain the allowed document 525 content, e.g. for documents that contain structured data and also 526 provide the possibility that document instances can conform to 527 several XML Schema definitions at the same time, while allowing 528 Schema validators to check the conformance of these documents. 530 Extensions of the session description language, say for allowing to 531 express the parameters of a new media type, would require the 532 creation of a corresponding XML schema definition that contains the 533 specification of element types that can be used to describe 534 configurations of components for the new media type. Session 535 description documents have to reference the non-standard Schema 536 module, thus enabling parsers and validators to identify the 537 elements of the new extension module and to either ignore them (if 538 they are not supported) or to consider them for processing the 539 session/capability description. 541 It is important to note that the functionality of validating 542 capability and session description documents is not necessarily 543 required to generate or process them. For example, endpoints would 544 be configured to understand only those parts of description 545 documents that are conforming to the baseline specification and 546 simply ignore extensions they cannot support. The usage of XML and 547 XML Schema is thus rather motivated by the need to allow for 548 extensions being defined and added to the language in a structured 549 way that does not preclude the possibility to have applications to 550 identify and process the extensions elements they might support. The 551 baseline specification of XML Schema definitions and profiles must 552 be well-defined and targeted to the set of parameters that are 553 relevant for the protocols and algorithms of the Internet Multimedia 554 Conferencing Architecture, i.e. transport over RTP/UDP/IP, the audio 555 video profile of RFC1890 etc. 557 The example below shows how the definition of codecs, 558 transport-variants and configuration of components could be 559 realized. Please note that this is not a complete example and that 560 identifiers have been chosen arbitrarily. 562 563 565 567 569 570 571 572 573 574 575 576 577 578 239.239.239.239 30000 579 580 581 583 584 585 586 239.239.239.239 30000 587 588 589 590 591 593 594 595 596 597 599 600 SDPng test 601 joe@example.com 602 A test conference 603 604 Video stream for the different speakers 605 606 608 The example does also not include specifications of XML Schema 609 definitions or references to such definitions. This will be provided 610 in a future version of this draft. 612 A real-world capability description would likely be shorter than the 613 presented example because the codec and transport definitions can be 614 factored-out to profile definition documents that would only be 615 referenced in capability description documents. 617 3.3 External Definition Packages 618 3.3.1 Profile Definitions 620 In order to allow for extensibility it must be possible to define 621 extensions to the basic SDPng configuration options. 623 For example if some application requires the use of a new esoteric 624 transport protocol endpoints must be able describe their 625 configuration with respect to the parameters of that transport 626 protocol. The mandatory and optional parameters that can be 627 configured and negotiated when using the transport protocol will be 628 specified in a definition document. Such a definition document is 629 called a "profile". 631 A profile contains rules that specify how SDPng is used to describe 632 conferences or endsystem capabilities with respect to the parameters 633 of the profile. The concrete properties of the profile definitions 634 mechanism are still to be defined. 636 An example of such a profile would be the RTP profile that defines 637 how to specify RTP parameters. Another example would be the audio 638 codec profiles that defines how specify audio codec parameters. 640 SDPng document can reference profiles and provide concrete 641 definitions, for example the definition for the GSM audio codec. 642 (This would be done in the "Definitions" section of a SDPng 643 document.) A SDPng document that references a profile and provides 644 concrete defintions of configurations can be validated against the 645 profile definition. 647 3.3.2 Library Definitions 649 While profile definitions specify the allowed parameters for a given 650 profile SDPng definition sections refer to profile definitions and 651 define concrete configurations based on a specific profile. 653 In order to such definitions to be imported into SDPng documents, 654 there will be the notion of "SDPng libraries". A library is a set of 655 definitions that is conforming to a certain profile definition (or 656 to more than one profile definition -- this needs to be defined). 658 The purpose of the library concept is to allow certain common 659 definitions to be factored-out so that not every SDPng document has 660 to include the basic definitions, for example the PCMU codec 661 definition. SDP [1] uses a similar concept by relying on the well 662 known static payload types (defined in RFC1890 [3]) that are also 663 just referenced but never defined in SDP documents. 665 An SPDng document that references definitions from an external 666 library has to declare the use of the external library. The external 667 library, being a set of configuration definitions for a given 668 profile, again needs to declare the use of the profile that it is 669 conformant to. 671 There are different possibilities of how profiles definitions and 672 libraries can be used in SDPng documents: 674 o In an SPDng document a profile definition can be referenced and 675 all the configuration definitions are provided within the 676 document itself. The SDPng document is self-contained with 677 respect to the definitions it uses. 679 o In an SPDng document the use of an external library can be 680 declared. The library references a profile definition and the 681 SDPng document references the library. There are two alternatives 682 how external libraries can be referenced: 684 by name: Referencing libraries by names implies the use of a 685 registration authority where definitions and reference names 686 can be registered with. It is conceivable that the most common 687 SDPng definitions be registered that way and that there will 688 be a baseline set of definitions that minimal implementations 689 must understand. Secondly, a registration procedure will be 690 defined, that allows vendors to register frequently used 691 definitions with a registration authority (e.g., IANA) and to 692 declare the use of registered definition packages in 693 conforming SDPng documents. Of course, care should be taken 694 though not to make the external references too complex and 695 thus require too much a priori knowledge in a protocol engine 696 implementing SDPng. Relying on this mechanism in general is 697 also problematic because it impedes the extensiblity, because 698 it requires implementors to provide support for new extensions 699 in their products before they can interoperate. Registration 700 is not useful for spontaneous or experimental extensions that 701 are defined in an SDPng library. 703 by address: An alternative to referencing libraries by name is to 704 declare the use of an external library by providing an 705 address, i.e., an URL, that specifies where the library can be 706 obtained. While is allows the use of arbitrary third-party 707 libraries that can extend the basic SDPng set of configuration 708 options in many ways there are problems if the referenced 709 libraries cannot be accessed by all communication partners. 711 o Because of these problematic properties of external libraries, 712 the final SDPng specification will have to provide a set of 713 recommendations under which circumstances the different 714 mechanisms of externalizing definitions should be used. 716 3.4 Mappings 718 A mapping needs to be defined in particular to SDP that allows to 719 translate final session descriptions (i.e. the result of capability 720 negotiation processes) to SDP documents. In principle, this can be 721 done in a rather schematic fashion. 723 Furthermore, to accommodate SIP-H.323 gateways, a mapping from SDPng 724 to H.245 needs to be specified at some point. 726 4. Open Issues 728 Overriding 730 Sytnax for referencing profiles and libraries 732 Registry (reuse of SDP mechanisms and names etc.) 734 Negotiation 736 References 738 [1] Handley, M. and V. Jacobsen, "SDP: Session Description 739 Protocol", RFC 2327, April 1998. 741 [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen, 742 "RTP: A Transport Protocol for Real-Time Applications", RFC 743 1889, January 1996. 745 [3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences 746 with Minimal Control", RFC 1890, January 1996. 748 [4] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, 749 M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP 750 Payload for Redundant Audio Data", RFC 2198, September 1997. 752 [5] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 753 2533, March 1999. 755 [6] Klyne, G., "Protocol-independent Content Negotiation 756 Framework", RFC 2703, September 1999. 758 [7] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for 759 Generic Forward Error Correction", RFC 2733, December 1999. 761 [8] Perkins, C. and O. Hodson, "Options for Repair of Streaming 762 Media", RFC 2354, June 1998. 764 [9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 765 Protocol", RFC 2974, October 2000. 767 Authors' Addresses 769 Dirk Kutscher 770 TZI, Universitaet Bremen 771 Bibliothekstr. 1 772 Bremen 28359 773 Germany 775 Phone: +49.421.218-7595 776 Fax: +49.421.218-7000 777 EMail: dku@tzi.uni-bremen.de 778 Joerg Ott 779 TZI, Universitaet Bremen 780 Bibliothekstr. 1 781 Bremen 28359 782 Germany 784 Phone: +49.421.201-7028 785 Fax: +49.421.218-7000 786 EMail: jo@tzi.uni-bremen.de 788 Carsten Bormann 789 TZI, Universitaet Bremen 790 Bibliothekstr. 1 791 Bremen 28359 792 Germany 794 Phone: +49.421.218-7024 795 Fax: +49.421.218-7000 796 EMail: cabo@tzi.org 798 Full Copyright Statement 800 Copyright (C) The Internet Society (2001). All Rights Reserved. 802 This document and translations of it may be copied and furnished to 803 others, and derivative works that comment on or otherwise explain it 804 or assist in its implmentation may be prepared, copied, published 805 and distributed, in whole or in part, without restriction of any 806 kind, provided that the above copyright notice and this paragraph 807 are included on all such copies and derivative works. However, this 808 document itself may not be modified in any way, such as by removing 809 the copyright notice or references to the Internet Society or other 810 Internet organizations, except as needed for the purpose of 811 developing Internet standards in which case the procedures for 812 copyrights defined in the Internet Standards process must be 813 followed, or as required to translate it into languages other than 814 English. 816 The limited permissions granted above are perpetual and will not be 817 revoked by the Internet Society or its successors or assigns. 819 This document and the information contained herein is provided on an 820 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 821 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 822 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 823 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 824 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 826 Acknowledgement 828 Funding for the RFC editor function is currently provided by the 829 Internet Society.