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