idnits 2.17.1 draft-ietf-mmusic-sdpng-req-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 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. 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 (February 19, 2001) is 8468 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 613, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 616, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 620, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 623, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 632, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 643, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 648, 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') -- Possible downref: Normative reference to a draft: ref. '9' -- Possible downref: Normative reference to a draft: ref. '10' ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '11') == Outdated reference: A later version (-05) exists of draft-ietf-avt-rtcp-bw-02 Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 4 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: August 20, 2001 Bormann 5 TZI, Universitaet Bremen 6 February 19, 2001 8 Requirements for Session Description and Capability Negotiation 9 draft-ietf-mmusic-sdpng-req-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 To view the entire list of Internet-Draft Shadow Directories, see 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on August 20, 2001. 31 Copyright Notice 33 Copyright (C) The Internet Society (2001). All Rights Reserved. 35 Abstract 37 This document defines some terminology and lists a set of 38 requirements that are relevant for a framework for session 39 description and endpoint capability negotiation in multiparty 40 multimedia conferencing scenarios. 42 This document is a product of the Multiparty Multimedia Session 43 Control (MMUSIC) working group of the Internet Engineering Task 44 Force. Comments are solicited and should be addressed to the 45 working group's mailing list at confctrl@isi.edu and/or the authors. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 52 4. General Requirements . . . . . . . . . . . . . . . . . . . . 9 53 4.1 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . 9 54 4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 9 55 4.3 Firewall Friendliness . . . . . . . . . . . . . . . . . . . 9 56 4.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 4.5 Text encoding . . . . . . . . . . . . . . . . . . . . . . . 9 58 4.6 Session vs. Media Description . . . . . . . . . . . . . . . 10 59 4.7 Mapping (of a Subset) to SDP . . . . . . . . . . . . . . . . 10 60 5. Session Description Requirements . . . . . . . . . . . . . . 11 61 5.1 Media Description . . . . . . . . . . . . . . . . . . . . . 11 62 5.1.1 Medium Type . . . . . . . . . . . . . . . . . . . . . . . . 11 63 5.1.2 Media Stream Packetization . . . . . . . . . . . . . . . . . 11 64 5.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 5.1.4 QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 5.1.5 Resource Utilization . . . . . . . . . . . . . . . . . . . . 12 67 5.1.6 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 12 68 5.1.7 Other parameters (media-specific) . . . . . . . . . . . . . 13 69 5.1.8 Naming Hierarchy and/or Scoping . . . . . . . . . . . . . . 13 70 5.1.9 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 6. Requirements for Capability Description and Negotiation . . 14 72 6.1 Capability Constraints . . . . . . . . . . . . . . . . . . . 14 73 6.2 Processing Rules . . . . . . . . . . . . . . . . . . . . . . 15 74 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 17 75 8. Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 References . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 78 Full Copyright Statement . . . . . . . . . . . . . . . . . . 21 80 1. Introduction 82 Multiparty multimedia conferencing is one application that requires 83 the dynamic interchange of end system capabilities and the 84 negotiation of a parameter set that is appropriate for all sending 85 and receiving end systems in a conference. For some applications, 86 e.g. for loosely coupled conferences, it may be sufficient to simply 87 have session parameters be fixed by the initiator of a conference. 88 In such a scenario no negotiation is required because only those 89 participants with media tools that support the predefined settings 90 can join a media session and/or a conference. 92 This approach is applicable for conferences that are announced some 93 time ahead of the actual start date of the conference. Potential 94 participants can check the availability of media tools in advance 95 and tools like session directories can configure media tools on 96 startup. This procedure however fails to work for conferences 97 initiated spontaneously like Internet phone calls or ad-hoc 98 multiparty conferences. Fixed settings for parameters like media 99 types, their encoding etc. can easily inhibit the initiation of 100 conferences, for example in situations where a caller insists on a 101 fixed audio encoding that is not available at the callee's end 102 system. 104 To allow for spontaneous conferences, the process of defining a 105 conference's parameter set must therefore be performed either at 106 conference start (for closed conferences) or maybe (potentially) 107 even repeatedly every time a new participant joins an active 108 conference. The latter approach may not be appropriate for every 109 type of conference without applying certain policies: For 110 conferences with TV-broadcast or lecture characteristics (one main 111 active source) it is usually not desired to re-negotiate parameters 112 every time a new participant with an exotic configuration joins 113 because it may inconvenience existing participants or even exclude 114 the main source from media sessions. But conferences with equal 115 ``rights'' for participants that are open for new participants on 116 the other hand would need a different model of dynamic capability 117 negotiation, for example a telephone call that is extended to a 118 3-parties conference at some time during the session. 120 SDP [1] allows to specify multimedia sessions (i.e. conferences, 121 "session" as used here is not to be confused with "RTP session"!) 122 by providing general information about the session as a whole and 123 specifications for all the media streams (RTP sessions and others) 124 to be used to exchange information within the multimedia session. 126 Currently, media descriptions in SDP are used for two purposes: 128 o to describe session parameters for announcements and invitations 129 (the original purpose of SDP) 131 o to describe the capabilities of a system (and possibly provide a 132 choice between a number of alternatives). Note that SDP was not 133 designed to facilitate this. 135 A distinction between these two "sets of semantics" is only made 136 implicitly. 138 In the following we first introduce a model for session description 139 and capability negotiation and define some terms that are later used 140 to express some requirements. Note that this list of requirements is 141 possibly incomplete. The purpose of this document is to initiate the 142 development of a session description and capability negotiation 143 framework. 145 2. Use Cases 147 TBD: use cases 149 3. Terminology 151 Any (computer) system has, at a time, a number of rather fixed 152 hardware as well as software resources. These resources ultimately 153 define the limitations on what can be captured, displayed, rendered, 154 replayed, etc. with this particular device. We term features 155 enabled and restricted by these resources "system capabilities". 157 Example: System capabilities may include: a limitation of the 158 screen resolution for true color by the graphics board; available 159 audio hardware or software may offer only certain media encodings 160 (e.g. G.711 and G.723.1 but not GSM); and CPU processing power 161 and quality of implementation may constrain the possible video 162 encoding algorithms. 164 In multiparty multimedia conferences, participants employ different 165 "components" in conducting the conference. 167 Example: In lecture multicast conferences one component might be 168 the voice transmission for the lecturer, another the transmission 169 of video pictures showing the lecturer and the third the 170 transmission of presentation material. 172 Depending on system capabilities, user preferences and other 173 technical and political constraints, different configurations can be 174 chosen to accomplish the ``deployment'' of these components. 176 Each component can be characterized at least by (a) its intended use 177 (i.e. the function it shall provide) and (b) a one or more possible 178 ways to realize this function. Each way of realizing a particular 179 function is referred to as a "configuration". 181 Example: A conference component's intended use may be to make 182 transparencies of a presentation visible to the audience on the 183 Mbone. This can be achieved either by a video camera capturing 184 the image and transmitting a video stream via some video tool or 185 by loading a copy of the slides into a distributed electronic 186 whiteboard. For each of these cases, additional parameters may 187 exist, variations of which lead to additional configurations (see 188 below). 190 Two configurations are considered different regardless of whether 191 they employ entirely different mechanisms and protocols (as in the 192 previous example) or they choose the same and differ only in a 193 single parameter. 195 Example: In case of video transmission, a JPEG-based still image 196 protocol may be used, H.261 encoded CIF images could be sent as 197 could H.261 encoded QCIF images. All three cases constitute 198 different configurations. Of course there are many more detailed 199 protocol parameters. 201 Each component's configurations are limited by the participating 202 system's capabilities. In addition, the intended use of a component 203 may constrain the possible configurations further to a subset 204 suitable for the particular component's purpose. 206 Example: In a system for highly interactive audio communication 207 the component responsible for audio may decide not to use the 208 available G.723.1 audio codec to avoid the additional latency but 209 only use G.711. This would be reflected in this component only 210 showing configurations based upon G.711. Still, multiple 211 configurations are possible, e.g. depending on the use of A-law 212 or u-Law, packetization and redundancy parameters, etc. 214 In this system model, we distinguish two types of configurations: 216 o potential configurations 217 (a set of any number of configurations per component) indicating 218 a system's functional capabilities as constrained by the intended 219 use of the various components; 221 o actual configurations 222 (exactly one per instance of a component) reflecting the mode of 223 operation of this component's particular instantiation. 225 Example: The potential configuration of the aforementioned video 226 component may indicate support for JPEG, H.261/CIF, and 227 H.261/QCIF. A particular instantiation for a video conference 228 may use the actual configuration of H.261/CIF for exchanging 229 video streams. 231 In summary, the key terms of this model are: 233 o A multimedia session (streaming or conference) consists of one or 234 more conference components for multimedia "interaction". 236 o A component describes a particular type of interaction (e.g. 237 audio conversation, slide presentation) that can be realized by 238 means of different applications (possibly using different 239 protocols). 241 o A configuration is a set of parameters that are required to 242 implement a certain variation (realization) of a certain 243 component. There are actual and potential configurations. 245 * Potential configurations describe possible configurations that 246 are supported by an end system. 248 * An actual configuration is an "instantiation" of one of the 249 potential configurations, i.e. a decision how to realize a 250 certain component. 252 In less abstract words, potential configurations describe what a 253 system can do ("capabilities") and actual configurations describe 254 how a system is configured to operate at a certain point in time 255 (media stream spec). 257 To decide on a certain actual configuration, a negotiation process 258 needs to take place between the involved peers: 260 1. to determine which potential configuration(s) they have in 261 common, and 263 2. to select one of this shared set of common potential 264 configurations to be used for information exchange (e.g. based 265 upon preferences, external constraints, etc.). 267 In SAP [11] -based session announcements on the Mbone, for which SDP 268 was originally developed, the negotiation procedure is non-existent. 269 Instead, the announcement contains the media stream description sent 270 out (i.e. the actual configurations) which implicitly describe what 271 a receiver must understand to participate. 273 In point-to-point scenarios, the negotiation procedure is typically 274 carried out implicitly: each party informs the other about what it 275 can receive and the respective sender chooses from this set a 276 configuration that it can transmit. 278 Capability negotiation must not only work for 2-party conferences 279 but is also required for multi-party conferences. Especially for the 280 latter case it is required that the process of determining the 281 subset of allowable potential configurations is deterministic to 282 reduce the number of required round trips before a session can be 283 established. 285 In the following, we elaborate on requirements for an SDPng 286 specification, subdivided into general requirements and requirements 287 for session descriptions, potential and actual configurations as 288 well as negotiation rules. 290 4. General Requirements 292 Note that the order in which these requirements are presented does 293 not imply their relative importance. 295 4.1 Simplicity 297 The SDPng syntax shall be simple to parse and the protocol rules 298 shall be easy to implement. 300 4.2 Extensibility 302 SDPng shall be extensible in a backward compatible fashion. 303 Extensions should be doable without modifying the SDPng 304 specification itself. The spec should preclude two independent 305 extensions from clashing with each other (e.g. in the naming of 306 attributes). 308 Along with extensibility comes the requirement to identify certain 309 extensions as mandatory in a given context while others as optional. 311 4.3 Firewall Friendliness 313 It should be theoretically possible for firewalls (and other network 314 infrastructure elements) to process announcements etc. that contain 315 SDPng content. The concrete procedures have to be defined but if 316 possible the processing of the SDPng content should be doable 317 without interpretation of the textual descriptions. 319 4.4 Security 321 SDPng should allow independent security attributes for parts of a 322 session description. In particular, signing and/or encrypting parts 323 of a session description should be supported. 325 4.5 Text encoding 327 A concise text representation is desirable in order to enhance 328 portability and allow for simple implementations. At run time, size 329 of encoded packets should be minimized, processing as well. 331 A language that allows specifications to be formally validated is 332 desirable. 334 A tendency to use XML as basis for the specification language has 335 been expressed repeatedly. 337 4.6 Session vs. Media Description 339 In many application scenarios (particularly with SIP and 340 MEGACO/H.248), only media descriptions are needed and there is no 341 need for session description parameters. SDPng should make 342 parameter sets optional where it is conceivable that not all 343 application will need them. 345 4.7 Mapping (of a Subset) to SDP 347 It shall be possible to translate a subset of SDPng into standard 348 SDP session description to enable a certain minimal degree of 349 interoperability between SDP-based and SDPng-based systems. 350 However, as SDPng will provide enhanced functionality compared to 351 SDP, a full mapping to SDP is not possible. 353 Note: Backwards compatibility to the SDP syntax has been discussed 354 and it was found that this is not goal for SDPng, as it is felt that 355 RFC 2327 is too limiting. 357 Since several flavors of SDP have been developed (e.g., the MEGACO 358 WG uses certain non-SDP enhancements) it needs to be discussed which 359 of these flavors need to be considered for some kind of mapping. 361 5. Session Description Requirements 363 For now, we only consider requirements for media (stream) 364 descriptions. 366 5.1 Media Description 368 It must be possible to express the following information with SDPng: 370 5.1.1 Medium Type 372 Payload types and format parameters for audio and video are 373 well-defined and the basic semantics are clear (as defined in 374 RFC1889 [2] and RFC2327 [1]). 376 Format descriptions for text and whiteboard are currently only 377 defined in the context of specific applications, this is probably 378 going to change in the future (not an SDPng work item). 380 Non-standard (in terms of defined as a non-standard payload type) 381 codecs and format parameters can be accomplished by using dynamic 382 payload type mappings. This is a crucial feature of SDP that needs 383 to be preserved for RTP applications. 385 Current SDP only provides a= (a=fmtp) as means to specify codec 386 parameters but actually gives little support on how to do this. 387 Schemes for expressing more sophisticated parameters (e.g. 388 supporting nesting) may be necessary. Nevertheless, it is imperative 389 to keep the overall structure of a codec description manageable. 391 Note that there is a conflict between the desire to be able to use 392 any old SDP and translate it in SDPng and the desire to have a 393 useful structure in the SDPng data. 395 5.1.2 Media Stream Packetization 397 SDPng needs to be able to take care of more sophisticated payload 398 descriptions than simple payload type assignment. Audio/video 399 redundancy coding schemes need to be supported as need other 400 mechanisms for FEC (RFC 2733 [7]) and media stream repair (RFC 2354 401 [8]). Also, layered coding schemes need to be supported. 403 Finally, a separation of the media encoding scheme, the 404 packetization format, and possible repair schemes (and their 405 respective parameters) is required. 407 5.1.3 Transport 409 Since session descriptions are not only used to describe sessions 410 that use IPv4/RTP for media transport it must be possible to specify 411 different transport protocols (and their corresponding mandatory 412 parameters). This means SDPng must support different address 413 formats (IPv4, IPv6, E.164, NSAP, ...), multiplexing schemes (e.g. 414 to identify a channel on a TDM link), and different transport 415 protocol stacks (RTP/UDP/IP, RTP/AAL5/ATM, ...). Potential further 416 parameters and interdependencies for multiplexed transports should 417 be considered. 419 Additionally the requirement for expressing multiple addresses per 420 actual configuration (layered coding support) has emerged, as well 421 as the requirement for expressing multiple addresses per potential 422 configuration (one port per payload type to simplify processing at 423 the receiver). 425 In multi-unicast-scenarios it must be possible to specify more than 426 one transport address for a single media stream in an actual 427 configuration, i.e. by specifying address lists. 429 In "broadcast"- or "lecture"-like sessions source filters might be 430 needed that allow receivers to verify the source and apply filters 431 in multicast sessions. Similarly, for SSM, the transport address 432 includes an (Sender,Group) pair of IP addresses. 434 The definition of codecs and the definitions of transport parameters 435 should be strictly separated from each other. See also Section 436 5.1.9. 438 5.1.4 QoS 440 QoS-Parameters for different protocol domains (e.g. traffic 441 specification and flow specification or TOS bits for IP QoS) need to 442 be specified. draft-ietf-mmusic-sdp-qos-00.txt [10] has provided a 443 proposal for a syntax that can be used with SDP to describe network 444 and security preconditions that have to be met in order to establish 445 a session. 447 5.1.5 Resource Utilization 449 A requirement debated (but not yet agreed upon) was whether abstract 450 terms should be found to describe resource requirements (in terms of 451 CPU cycles, DSPs, etc.) 453 5.1.6 Dependencies 455 Certain codes may depend on other resources being available (e.g. a 456 G.723.1 audio codec may need a DTMF codec as well while a G.711 457 codec does not). Such interdependencies need to be expressed. 459 5.1.7 Other parameters (media-specific) 461 Extension mechanisms that allow to describe arbitrary other 462 parameters of media codecs and formats are mandatory. It is possibly 463 required to distinguish between mandatory and optional extension 464 parameters. 466 In particular, it must be possible to introduce new (optional) 467 parameters for a payload format and have old implementations still 468 parse the parameters correctly. 470 5.1.8 Naming Hierarchy and/or Scoping 472 Parameter names should be constructed in a way to avoid clashes and 473 thereby simplify independent development of e.g. codec parameter 474 descriptions in different groups. 476 5.1.9 Profiles 478 The configuration options for the different aspects of session 479 descriptions (codec definitions, transport parameters etc.) should 480 be defined in different orthogonal profiles in order to allow for 481 combining different aspects to a final description. 483 6. Requirements for Capability Description and Negotiation 485 6.1 Capability Constraints 487 Capability negotiation is used to gain a session description (an 488 actual configuration) that is compatible with the different end 489 system capabilities and user preferences of the potential 490 participants of a conference. 492 A media capability description is the same as a potential 493 configuration, as it contains a set of allowable configurations for 494 different components that could be used to implement the 495 corresponding component. A capability description should allow 496 specifying a number of interdependencies among capabilities. 497 Traditional SDP only supports alternative capabilities and the 498 specification implicitly assumed that all capabilities could be 499 combined and basically used at the same time (looking at the pure 500 session description, at least). 502 Processing power, hardware, link, or other resources may preclude 503 the simultaneous use of certain configurations and/or limit the 504 number of simultaneous instantiations of one or more configurations. 505 This has led to a need to express in more detail constraints on 506 combinations of configurations including the following constraints: 508 o grouping capabilities (-> capability set); 510 o expressing simultaneous capability sets; 512 o expressing alternative capability sets; and 514 o constraining the number of uses of a certain capability (set). 516 It needs to be carefully investigated how much more sophistication 517 (if any) than simply listing alternatives needs to go into a base 518 specification of SDPng (and which extension mechanisms for certain 519 applications or for future revisions should be allowed). 521 Examples are known where complex capability descriptions are 522 available but are simply not used (at least not at the level of 523 sophistication that would be possible). This strongly calls for 524 keeping requirements on capability constraints rather modest (KISS). 526 The description of capabilities and the specification of capacity 527 limits (maximum numbers of instantiations at a time) should be 528 separated. 530 The capabilities should be expressed as limitations on codec 531 support, transport capability restrictions but not implicitely as 532 limitations on machine resources, such as CPU type, clock rates, 533 memory etc., that describe internal limitations in order to infer 534 the supported capabilities. 536 6.2 Processing Rules 538 The processing of potential configurations includes the process of 539 "collapsing" sets of potential configurations offered by 540 participants, i.e. the computation of the intersection of these 541 potential configurations. 543 The processing (i.e. collapsing, forwarding etc.) of different 544 potential configurations in order to find a compatible subset must 545 work without having to know the semantics of the individual 546 parameters. This is a key requirement for extensibility. 548 Additionally it must be possible to make use of different 549 negotiation policies in order to reflect different conference types. 550 For example in a lecture-style conference the policy might be to 551 ensure that a capability collapsing process does not yield an actual 552 configuration that excludes the main source (i.e. the lecturer and 553 her end system) from the conference. 555 Preferences may also be considered in the negotiation process. This 556 may need to be considered at the SDPng level (e.g. to express 557 preferences, priorities). 559 Of course, the negotiation of configurations must not only work in 560 peer-to-peer-conference scenarios but also be usable in multi party 561 scenarios. The collapsing rules should work commutatively, that 562 means if given 3 end systems A,B,C the result for computing the 563 supported configurations should be same when computing A*B*C and 564 A*C*B (let "*" be the collapsing function). 566 Negotiation of capabilities should take no longer than two or three 567 message exchanges. The description format must enable such 568 efficiency. 570 In order to allow for concise capability specification it will 571 probably be required to group descriptions of, say, codecs and to 572 establish a kind of hierarchy that allows to attach a certain 573 attribute or parameter to a whole group of codecs. 575 It might then also be required to have a naming scheme that allows 576 to name definitions in order to be able to later reference them in 577 subsequent definitions. This is useful in situations where some 578 definition extends a previous definition by just one parameter or in 579 situations where codecs are combined, for example for expressing 580 redundancy or layered codings. Different models of re-use are 581 conceivable. 583 7. Open Issues 585 This section contains a list of items that need further discussion 586 and are currently not considered to be requirements: 588 Scheduling: The possibility to express scheduling information such 589 as start time, duration etc. in session descriptions. 591 8. Remarks 593 Explicitly addressing the issue of capability negotiation when 594 drafting the new session description language generates new sets of 595 requirements, some of which might conflict with other important 596 goals, such as simplicity, conciseness and SDP-compatibility. 598 However, we think that it's worthwhile to sketch a reasonably 599 complete and powerful solution first and then later develop a 600 migration path from today's technology instead of imposing 601 limitations at the outset to minimize the possibly necessary 602 changes. 604 References 606 [1] Handley, M. and V. Jacobsen, "SDP: Session Description 607 Protocol", RFC 2327, April 1998. 609 [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen, 610 "RTP: A Transport Protocol for Real-Time Applications", RFC 611 1889, January 1996. 613 [3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences 614 with Minimal Control", RFC 1890, January 1996. 616 [4] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, 617 M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP 618 Payload for Redundant Audio Data", RFC 2198, September 1997. 620 [5] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 621 2533, March 1999. 623 [6] Klyne, G., "Protocol-independent Content Negotiation 624 Framework", RFC 2703, September 1999. 626 [7] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for 627 Generic Forward Error Correction", RFC 2733, December 1999. 629 [8] Perkins, C. and O. Hodson, "Options for Repair of Streaming 630 Media", RFC 2354, June 1998. 632 [9] Camarillo, G., Holler, J. and G. AP Eriksson, "SDP media 633 alignment in SIP", Internet Draft 634 draft-camarillo-sip-sdp-01.txt, November 2000. 636 [10] Rosenberg, J., Schulzrinne, H. and S. Donovan, "Establishing 637 QoS and Security Preconditions for SDP Sessions", Internet 638 Draft draft-ietf-mmusic-sdp-qos-00.txt, June 1999. 640 [11] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 641 Protocol", RFC 2974, October 2000. 643 [12] Kumar, R. and M. Mostafa, "Conventions for the use of the 644 Session Description Protocol (SDP) for ATM Bearer 645 Connections", Internet Draft draft-ietf-mmusic-sdp-atm-05.txt, 646 February 2001. 648 [13] Casner, S., "SDP Bandwidth Modifiers for RTCP Bandwidth", 649 Internet Draft draft-ietf-avt-rtcp-bw-02.txt, November 2000. 651 Authors' Addresses 653 Dirk Kutscher 654 TZI, Universitaet Bremen 655 Bibliothekstr. 1 656 Bremen 28359 657 Germany 659 Phone: +49.421.218-7595 660 Fax: +49.421.218-7000 661 EMail: dku@tzi.org 663 Joerg Ott 664 TZI, Universitaet Bremen 665 Bibliothekstr. 1 666 Bremen 28359 667 Germany 669 Phone: +49.421.201-7028 670 Fax: +49.421.218-7000 671 EMail: jo@tzi.org 673 Carsten Bormann 674 TZI, Universitaet Bremen 675 Bibliothekstr. 1 676 Bremen 28359 677 Germany 679 Phone: +49.421.218-7024 680 Fax: +49.421.218-7000 681 EMail: cabo@tzi.org 683 Full Copyright Statement 685 Copyright (C) The Internet Society (2001). All Rights Reserved. 687 This document and translations of it may be copied and furnished to 688 others, and derivative works that comment on or otherwise explain it 689 or assist in its implmentation may be prepared, copied, published 690 and distributed, in whole or in part, without restriction of any 691 kind, provided that the above copyright notice and this paragraph 692 are included on all such copies and derivative works. However, this 693 document itself may not be modified in any way, such as by removing 694 the copyright notice or references to the Internet Society or other 695 Internet organizations, except as needed for the purpose of 696 developing Internet standards in which case the procedures for 697 copyrights defined in the Internet Standards process must be 698 followed, or as required to translate it into languages other than 699 English. 701 The limited permissions granted above are perpetual and will not be 702 revoked by the Internet Society or its successors or assigns. 704 This document and the information contained herein is provided on an 705 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 706 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 707 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 708 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 709 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 711 Acknowledgement 713 Funding for the RFC editor function is currently provided by the 714 Internet Society.