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