| Network Working Group | C. Jennings |
| INTERNET DRAFT | Cisco Systems |
| <draft-jennings-xcon-media-control-01> | B. Rosen |
| Category: Standards Track | Marconi |
| Expires: December 2004 | June 2004 |
Media Mixer Control for XCON
draft-jennings-xcon-media-control-01
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at <http://www.ietf.org/ietf/1id-abstracts.txt>.
The list of Internet-Draft Shadow Directories can be accessed at <http://www.ietf.org/shadow.html>.
This Internet-Draft will expire in December 2004.
Copyright (C) The Internet Society (2004). All Rights Reserved.
Conference mixers have many controls that change how the media is combined for each participant in the conference. There is a need to describe these to the clients connected to the a centralized conference so that the clients can render a user interface and allow the user to manipulate them.
This work is being discussed on the xcon@ietf.org mailing list.
1
Conventions
2
Introduction to the Problem
2.1
Non Problems
3
Overview
3.1
Semantic information in a Conference
3.2
The Protocol
3.3
Templates
3.4
Parameters
3.5
Controls
3.6
Roles
3.7
Streams
3.8
Streams Lists
4
Introductory Example
4.1
Simple Audio
4.2
Simple Video
5
Names and terminology
5.1
Templates
5.2
Participants
5.3
Streams
5.3.1
Stream Types
5.3.1.1
Audio
5.3.1.2
Video
5.3.1.3
Text
5.3.1.4
Application
5.3.2
Stream URLs
5.3.3
Stream Priority
5.4
Roles
5.5
Controls
5.6
Parameters
6
Solution
6.1
Templates
6.1.1
Parameters
6.1.2
Roles
6.1.3
Streams
6.1.4
Streams Lists
6.1.5
Controls
6.1.6
Conference State
6.1.6.1
Conference State Update
6.1.6.2
Change Notification
6.1.7
Transport Protocol
6.2
Controls
6.2.1
Requirements
6.2.2
Strings
6.2.3
Integer
6.2.4
Boolean
6.2.5
Selection
6.2.6
Multiple Selection
6.2.7
Frame
7
Examples
7.1
Audio Video Presentation
8
Template Registry
9
Comparison to other solutions
10
CPCP vs. MPCP vs. CCP vs. MCP
11
IANA
12
Security
13
Acknowledgments
§
Normative References
§
Informative References
§
Author's Addresses
§
Intellectual Property and Copyright Statements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1].
This work tries to solve the problem of allowing a conference participant to manipulate the media flow in a mixer. It defines a protocol between the end user's software manipulating the conference and the centralized conference mixer. This needs to be rich enough for a mixer to express what information it wants from a mixer yet simple enough to allow the client to render a useful user interface to the user. This work takes into account that real mixers have constraints on what media flows are possible and that UIs have buttons, knobs, etc that users manipulate. The goal is for a conferencing end point made by one vendor to work with mixers or conference systems made by another vendor.
There are several topics that are completely internal to the conference systems and are out of scope for this this work. These include:
When a conference is created, it is instantiated from a template. The template describes what controls are available for the client to manipulate the media. The template can have parameters that are set when it is instantiated to allow one template to describe variations of similar flow models.
This document describes the templates and ways for the client to understand and manipulate the media in the conference. It allows for the following:
The conference has a list of Participants. Each Participant has a set of streams that are being contributed to the confernce and a set of stream sbeing setn to the client. Each Stream has attributes such as name, type, priority and list of contributing participants. Each of thes Stream has Controls that the user of the client program can manipulate. Each conference has a list of sidebars. Each conference has a list of Streams.
The protocol between the client and the conference server allows the client to get the semantic information in the conference, find out when it changes, and make changes to it. It's probably something like XCAP. [TODO add ref]
Templates define a model for the reception, manipulation and transmission of streams. A template provides enough information that the client can intelligently render a useful GUI to the end user to manipulate the model. There is a registry of well known templates, but a conference server can define new ones. A convener can find all the templates a conference server supports and select one to use when creating the conference.
A template for a very basic audio conference, for example, may indicate that there is one audio stream for each participant, and one output mixer stream named "primary". Each participant in the stream has a single binary control called "Mute". There is only one Role that can be used, called "participant".
Parameters are variables in the template that are set when the conference is created. For example, in the audio conference, the maximum number of participants might be a parameter. If the value was set to 10 when the conference is instantiated, then up to 10 participant streams can be accepted into the mixer. The template can indicate the valid range for max number of participants, perhaps from 2 to 128.
Controls are variables participants may manipulate to control the media streams of the conference. Conferences can have controls, participants in a conference can have controls, and streams in a conference can have controls. Controls can also be implicitly created by stream action, for example a selector control based on the loudest speaker. Controls have a name, and a value. Controls are defined in the template.
Participants in a conference can take on multiple different Roles that change what controls they may manipulate and which media streams they have access to. The template defines what Roles are available for the client. Manipulation of Roles in done in CPCP. Some common roles include:
Streams corespond to a given flow of media. They are named and can be selected by a controlls. The conference package is used to understand the relationships between users, dialog or session, and streams.
Lists of stream exist and form virtual streams that can also be displayed. For example there is a virtual streams called "default". This contins the default media mix for the confernce. It is a list and elements can be indexed. For example, the default[0] in a vidoe confernce would likely contains the current speaker and default[1] would contains the previous speaker. The lists become an important concept when the end system which to render media at some location only if the media is not being rendered elsewhere. There are virtual lists for media from the default mix for the confernece, each type of Role, each type of Floor, as welll as confernce templates can define new named virtual streams lists. Streams lists can be indexed by an integer that describes
TODO - have User/Dialog/Stream idea
The client selects the basic audio template that looks like:
<template name="basic-audio">
<parameter type="integer" name="max-participants"
min="2" max="128"/>
<role name="Participant">
<stream type="audio" dir="in" name="default-audio-in" priority="1.0">
</stream>
<stream type="audio" dir="out" name="default-audio-out" priority="1.0">
<control type="boolean" name="mute"/>
</stream>
</role>
</template>
TODO - cpcp is used to create conference.
The client retrieves this template. This templates defines that this confernce has one Role called participant and that this role has a stream list called "defalult-audio-in" and another called "default-audio-out". Alice and Bob join this conference and the conference server tells Bob about the state of the conference media. There is only one role "participant". Each participant contributes one input stream. There is also an output stream per participant. There is a single control, called mute, for each participant.
After Alice and Bob have joined, the conference server informs Bob that the current state of the conference is as shown in the xml below.
TODO - move mute to gain
TODO - add id to things
<conference type="basic-audio" name="Weekly Conference">
<parameter type="integer" name="max-participants"> 10
</parameter>
<role name="Participant"/>
<participant name="Alice" role="Participant">
<stream type="audio" dir="in" name="default-audio-in"
sid="34"
priority="1.0"/>
<stream type="audio" dir="out" name="default-audio-out"
sid="35"
priority="1.0">
<control type="boolean" name="mute"
perm="readonly"> 0 </control>
</stream>
</participant>
<participant name="Bob" role="Participant">
<stream type="audio" dir="in" name="default-audio-in"
sid="36"
priority="1.0"/>
<stream type="audio" dir="out" name="default-audio-out"
sid="37"
priority="1.0">
<control type="boolean" name="mute"
perm="readwrite"> 0 </control>
</stream>
</participant>
</conference>
There are two participants, Alice and Bob, who both contribute input streams and receive output streams and neither is muted.
Bob's client decides to change the Mute state for its audio stream and sends the following to the conference server to change the state of the conference.
<conference type="basic-audio" name="Weekly Conference">
<participant name="Bob" role="Participant">
<stream type="audio" dir = "out" name="default-audio-out" sid="37" >
<control type="Boolean" name="mute"> 1
</control>
</stream>
</participant>
</conference>
A key part of this is that Bob's client may have known about this basic audio template and what the semantics of the "mute" control implied. The client may have connected this up with a button of the client's that was labeled mute. On the other hand, Bob's client may not have known anything about this template and simply rendered a button on the screen and labeled it "mute" with no idea what this would do. A third client may not have been able to deal with the control at all and may have just ignored it. Clearly the user interface can be better if the client understands the semantics of what the template means, but the user interface is still functional when the client does not.
A more complex video example is given below.
note need - value for if stream gets bumped from mix and another value that indicates relative positioning. confernce type="video" name="" Participant name="Alice" stream type=audo dir=in name="default-audio-in" stream type=audio dir=out name=default-audio-out stream type=video dir=out name=presenter[0] stream type=video dir=out name=preentaion[0] Participan name="Bob" stream type=audio dir=in name=default-audio-in stream type=video dir=in name=default-video-in stream type=application dir=in name=defaul-presentaion-in stream type=audio dir=out name=default-audio-out stream type=video dir=out name=bob-video-out control type=selector value="3+5" group control type=streamSelector value=default-presentation[0] q=0.9 control type=streamSelector value=default-presenter[0] q=0.8 control type=streamSelector value=default-speaker[0] q=0.7 duplicate=next group control type=streamSelector value=moderator q=0.4 duplicate=next control type=streamSelector value=participants q=0.3 duplicate=next Participan name"Brian" stream type=audio dir=in name=default-audio stream type=video dir=in name=default-video stream type=video dir=in name=default-video-small stream type=video dir=out name=default-presentation[0] sid=s1 stream type=video dir=out name=default-presenter[0] sid=s2 stream type=video dir=out name=default-participant[0] sid=s3 stream type=video dir=out name=default-participant[1] sid=s4 stream type=video dir=out name=default-participant[sid=27] sid=s4 stream type=audio dir=out name=default-presentation[0] sid=sa1 stream type=audio dir=out name=default-presenter[0] sid=sa2 stream type=audio dir=out name=default-participant[0] sid=sa3 stream type=audio dir=out name=default-participant[1] sid=sa4 Participan name = Snoopy stream type=video dir=out name=sid27 stream type=video dir=out name=sid2 stream type=video dir=out name=sid3
In the example above, ..... TODO
A stream-id is an integer assigned by the focus to each physical input and output stream. For RTP medai, this coresponds to a single RTP session. This integer is unique to all streams in a specific conference (and all its sub-conferences).
Each output stream can specify the physical or logical set of input streams which contribute to that output stream. In some cases, a stream can contain multiple components; for example, video, text, whiteboard, or application tiles or panels in a composite video output stream, or audio inputs placed logically for stereo or spatial mixing.
Logical sets of streams indicate ordered lists of input streams which change dynamically and potentially very quickly during the lifetime of a conference. For example, one logical set is the set of input video streams corresponding to the current speaker or speakers. Another logical set is the set of input audio streams that correspond to the current holders of a particular floor.
An exclusivity-group is a group of output streams or components which are grouped to allow control over whether the same physical input stream contributes to multiple related output streams or components. For example, Alice might choose to display the input video stream of Bob (the presenter) in one tile (component) and the input video stream which corresponds to the current speaker in another tile; however if Bob is the current speaker, Alice would like to see a different video stream instead in this tile. Note that different components of a single output-stream could appear in different exclusivity-groups.
Templates contain a list of stream, roles for participants, parameters that need to be set, and controls for the conference.
Participants are the logical user entities participating in a conference.
The stream is a named stream of media. An example is a simple audio conference with 6 participants and a mixer that mixes the loudest three. Each participant contributes an input stream. There is a single logical output stream, but every participant gets a "custom" version of this stream, because, in normal mixers, each participants can hear all inputs except his own. This is commonly referred to as "mix-minus". If the output steam also has a control (mute), the output streams for each participant may also vary depending on the state of the control.
Streams all have a type, a name, a direction (in or out), one or more URLs, and a priority. The URL is the source or sink of the stream. The priority indicates how important this particular stream is to the conference and the type indicates the type of media carried in this steam.
Streams have types. These correspond to the major MIME types of the media the stream carries.
Streams originate as participant contributions (dir="in") that are mixed using some kind of algorithm. Intermediate streams may be created, which are subsequently mixed with other streams yielding streams which are sent to participants (dir="out"). Controls commonly available on audio streams include input or output faders (volume controls), stereo balance, and mute.
Streams originate as participant contributions (dir="in") that are combined with some kind of algorithm. Intermediate streams may be created, which are subsequently combined with other streams yielding streams which are sent to participants (dir="out"). Controls commonly available on video streams might include selectors for choosing a tiling format, selectors which input streams appear on output tiles, and video mutes.
Streams originate as participant contributions (dir="in") (Instant Messages). Messages from all participants are combined using some algorithm. Intermediate streams may be created, which are subsequently combined with other text streams yielding streams which are sent to participants (dir="out").
At a minimal level, this consist of a URL that defines the application. Many systems will simply update an http URL that fetches an HTML page that shows the current presentation.
Streams have URLs that specify the source or sink of the stream. These would typically be a SIP, H323 or IM URL.
Streams have a priority from 0 to 1. Zero indicates that a client, by default, should not play/display this stream unless the user specifically requests it. A priority of 1 indicates that, by default, the client should render this stream and should warn the user if it cannot. Other values only define an ordering, and clients should attempt to use their resources to display the higher priority streams before the lower.
TODO - switch Role so a participant can have several roles simultanously
Roles are defined as part of Conference Policy but are used here so that the Media Policy can define separate streams and controls depending on role. Roles are defined by in the template. Some templates may allow a participant to take on more than one role at a time. Each template must define a role named "participant", which is the default role. "Moderator" is a typical role, as is "Floor-Holder", but templates do not intrinsically define or require such roles.
Controls manipulate the state of the conference while it is instantiated. All controls have a name, a type, a current value and permissions that indicate whether or not the current client can modify them. They may also have, optionally, a min and max value.
A control can be defined as being part of a role. In that case, all participants who assume that role have an instance of the control. A control may also be defined as part of a stream, in which case all contributors of that stream (dir="in") have an instance of the control, or all sinks of the stream (dir="out") have an instance of the control. There can be global controls, which are available to all participants. Implicit controls extract values from streams (or other controls), such as choosing video inputs based on loudest speakers
Parameters are variables that modify the function of the template. They are fixed when the conference is instantiated and can not be changed after that. Parameters allow a single template definition to describe a range of possible mixer capabilities.
Parameters have a name, a type, a value and, optionally, a min and max value.
A conference client can request the template from the focus. This allows the client to discover what the current media policy is, what controls it can manipulate. The client can then send a template update to the focus to chance the controls to manipulate media policy for various participants.
The state of the media policy for a conference is represented in an instantiated template. Inside the template are one or more participants where the media policy is manipulated. Each participnat section indentifies media sessions (identified with stream id's) that are being contributed to stream lists. It also indtifies media that is sent to the client. Each one of these input or output may contains varios controls that manipulate the media.
A template may define varios virtual stream lists. For example, one video stream may contain video of the active presenter and nother video stream may have the presentation that the presenter is showing. Media from a participant is contributed to one of the virtual stream lists. Various controls, such as gain, may be attached to each input contribute.
Each participant also has output streams which represent media being sent to the client. Output streams to a client are named and may have complex controls that effect which streams are selected to contribute to the result. Output strams may be foremed using multiple input components streams. This is typically done for video when the output is some composited form of the input compenet streams but it can also be done for audio in such cases as selecting muliple mono audio streams and defning how they are composinted into a stereo stream.
Streams can be selected out of a stream list using an array notation. This selection of the item must not a select the same pyisical stream if that stream has already been selected inside the same exclusinvity group.
A template is an xml document that both describes the state of a confernce and what can be changed about the confernce. There is a set of well known templates that are IANA registered but clients can deal with nkonw templates. The template definition includes a name, which is a string, for example:
<template name="audio-basic">
The parameters in the templates customize a generic template for a specific conference. Parameters have name, type, value, and optionally min/max. Parameters are defined in the template description. Only conveners can set template parameters
One typical template parameter is "max-participants". When the CS generates the template for the client, it can customize the min and max value of this parameter to match what it is capable of. When the client instantiates the template and creates the conference, it can specify the value that has been requested. The value typically represents the limits the mixer is capable of. Resource availability may limit the actual value that can be achieved.
Parameter names are strings.
Parameter Types:
Values of course must be conformant to the type. Min and Max, if defined, must also be conformant to the declared type.
Example:
<parameter name="Master Volume", type="integer", min="0", max="100">75</parameter>
Templates define all the Roles that a participant can take and (optionally) the max number of participants of each role. Each role is defined in a role element. A Role element includes a name and optionally a "max-participants" value. Role elements may also contain stream elements, which define per-participant-in-role streams. The frist stream list of a given media type inside a Role is the default location for that type of media.
Example:
<role name="moderator" max-participants="1" />
Templates also define all the streams lists available. A stream element has a name, a type, a direction ("in" or "out"), and stream id.
The stream id correlates the stream with a particular RTP session or media session for non RTP based media. The cleint can learn the correlation of stream ID to the parrticular media streams it is sending by subscribing to the confernce pacekage (TODO REF).
Example:
<stream name="input-audio" type="audio" dir="in" priority="1.0" >
Stream lists are name lists of virtual sets of streams. A specific member of the set can be referenced using an array notation with square brackets. In general, [0] is the most import memeber or first member of the stream.
A control can be inside the template, participant, or stream. The control will apply to the appropriate context. By including stream definitions in multiple roles that have the same name, different controls can be provided to different roles affecting streams contributed or sunk from multiple roles. For example, a moderator may be given a set of input volume controls controlling a mix, and every participant can be given an output master mix control for the output stream sent to him
Conference state can be requested by any participant. A document will be returned elucidating the complete current conference state, which would contain all the participants, all the streams, and the values of all the controls. The form of the document mirrors the template definition. The conference can also contain sidebars.
The client can attempt to change the state of various controls in the CS by sending a document that contains just the things it wants to change.
The client can request that conference state be automatically sent when it changes.
TODO: Need to define how the information is sent between the client and the conference server. XCAP?
Controls need to collect information. This can be classified into several types. It should be possible to provide default values, a name for the control and text it displays, help text, control if a value is required, and control of whether or not the value is editable. It should be possible to express constraints on the form an input can take by specifying a minimum or maximum for types where that makes sense, or specifying a regular expression that must be satisfied. For numeric values in a constrained range, it should be possible to provide an increment value used by the control. For strings it should be possible to indicate that they should not be displayed when they are entered for things like passwords. Need the ability to internationalize any text that is displayed to the user.
There are control types for:
If an unknown control is encountered, it should be treated as a string type. The <label> element controls what is displayed to the user and the <value> element contains the current setting of the control. If set in the template definition, it represents the default value. An optional <description> element provides some text that can be used as help text for the control.
This is typically rendered as a text input field.
<control type="string" name="Host" private="true" > <label> Meeting Host </label> <value>Richard</value> <description>Host for this weeks meeting</description> <regex>.*[rR].*</regex> </control>
The "private" attribute indicates that the string should not be displayed as it is entered.
This can be rendered as a slider or volume knob if it has a constrained range; otherwise it is a text field. The text field may have increment or decrement buttons.
<control type="integer" name="gain">
<label> Volume </label>
<value>0</value>
<range min="-18" max="6" increment="3"/>
</control>
This is typically rendered as a toggle button.
<control type="boolean" name="mute">
<label> Mute </label>
<value>True</value>
</control>
This is typically rendered as a pull down menu or as a radio button box.
<control type="select1" name="foo">
<label> the thing </label>
<value>2</value>
<item>
<label>one</label>
<value>1</value>
</item>
<item>
<label>two</label>
<value>2</value>
</item>
</control>
The list of items that can be selected is contained in <item> elements. Each item has a label that is displayed and a value that is returned when it is selected.
This is typically rendered as a combo box or list.
This is the same as a selection, except that the type is selected and the initial value is a space-separated list of values.
Provides a hint to groups of controls. UIs are not constrained to follow the frame construct and MAY ignore it.
<frame name="Address">
<control type="string" name="addr" private="true" >
<label> Street Address </label>
<regex>.*[rR].*</regex>
</control>
<control type="string" name="city" private="true" >
<label> City </label>
<regex>.*[rR].*</regex>
</control>
<control type="string" name="state" private="true" >
<label> State </label>
<regex>.*[rR].*</regex>
</control>
</frame>
The following is a more complex template with bits of text explaining it:
In this template, there are three roles, Participant, Presenter and Moderator. There is an input and output audio stream for each role. All roles have mute and master volume controls for their outputs. The moderator has input controls for each input.
The video presentation is "Hollywood Squares". Each role contributes one video stream. The moderator can select the presentation (tile format) from an enumeration. All viewers see the same output presentation.
Finally, there is an application sharing channel which is provided by the Presenter, and received by all roles.
<template name="audio-video-presentation">
<parameter type="integer" name="max-participants"
min="2" max="16"/>
<role name="Participant">
<parameter type="integer" name="max-participants"
min="0" max="16"/>
<stream type="audio" name="AudioIn" dir="in"/>
<stream type="video" name="VideoIn" dir="in"/>
<stream type="video" name="VideoOut" dir="out"/>
<stream type="application" name="AppShare" dir="out"/>
<stream type="audio" name="MixOut" dir="out">
<control type="binary" name="mute"/>
<control type="real" name="master"
min="-18" max="+6" note="Master Gain in DB"/>
</stream>
</role>
<role name="Presenter">
<parameter type="integer" name="max-participants"
min="0" max="16"/>
<stream type="audio" name="AudioIn" dir="in"/>
<stream type="video" name="VideoIn" dir="in"/>
<stream type="video" name="VideoOut" dir="out"/>
<stream type="application" name="AppShareIn" dir="in"/>
<stream type="application" name="AppShare" dir="out"/>
<stream type="audio" name="MixOut" dir="out">
<control type="binary" name="mute"/>
<control type="real" name="master"
min="-18" max="+6" note="Master Gain in DB"/>
</stream>
</role>
<role name="Moderator">
<parameter type="integer" name="max-participants"
min="0" max="1"/>
<stream type="audio" name="AudioIn" dir="in">
<control type="real" name="gain"
min="-18" max="+6" note="Input Gain in DB"/>
</stream>
<stream type="video" name="VideoIn" dir="in"/>
<stream type="video" name="VideoOut" dir="out">
<control type=selector name="Tile Format">
<item name="1x1" value="0"/>
<item name="2x1" value="1"/>
<item name="2x2" value="2"/>
<item name="3x3" value="3"/>
<item name="4x4" value="4"/>
</control>
<stream type="application" name="AppShare" dir="out"/>
<stream type="audio" name="MixOut" dir="out">
<control type="binary" name="mute"/>
<control type="real" name="master"
min="-18" max="+6" note="Master Gain in DB"/>
</stream>
</role>
</template>
An IANA registry will be created for commonly encountered template definitions. This document will include some starter templates
[Still need TODO this].
[TODO]
What is the boundary between conference control, media control, and policy control for both of them.
Many thanks to Nermeen Ishmail and Rohan Mahy.
| [1] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [3] | Mahy, R and N Ismail, "Media Policy Manipulation in the Conference Policy Control Protocol", Internet-Draft draft-mahy-xcon-media-policy-control-00, June 2003. |
| [4] | Even, R, "Conferencing Scenarios", Internet-Draft draft-even-xcon-conference-scenarios-00, June 2003. |
| [5] | Rosenberg, J, "A Framework for Conferencing with the Session Initiation Protocol", Internet-Draft draft-ietf-sipping-conferencing-framework-00, May 2003. |
| Cullen Jennings | |
| Cisco Systems | |
| 170 West Tasman Drive Mailstop SJC-21/2 |
|
| San Jose, CA 95134 | |
| USA | |
| Phone: | +1 408 421 9990 |
| EMail: | fluffy@cisco.com |
| Brian Rosen | |
| Marconi | |
| 2000 Marconi Drive |
|
| Warrendale, PA 15086 | |
| USA | |
| Phone: | +1 724 742 6826 |
| EMail: | brian.rosen@marconi.com |
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the Internet Society.