draft-ietf-mmusic-sdp-05.txt   draft-ietf-mmusic-sdp-06.txt 
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
INTERNET-DRAFT Mark Handley/Van Jacobson INTERNET-DRAFT Mark Handley/Van Jacobson
draft-ietf-mmusic-sdp-05.ps ISI/LBNL draft-ietf-mmusic-sdp-06.ps ISI/LBNL
21st Nov 1997 22nd Jan 1997
Expires: 21st May 1997 Expires: 22nd Jul 1997
SDP: Session Description Protocol SDP: Session Description Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu- This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and its ments of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
skipping to change at page 2, line 14 skipping to change at page 2, line 14
1. Introduction 1. Introduction
On the Internet multicast backbone (Mbone), a session directory tool is On the Internet multicast backbone (Mbone), a session directory tool is
used to advertise multimedia conferences and communicate the conference used to advertise multimedia conferences and communicate the conference
addresses and conference tool-specific information necessary for parti- addresses and conference tool-specific information necessary for parti-
cipation. This document defines a session description protocol for this cipation. This document defines a session description protocol for this
purpose, and for general real-time multimedia session description pur- purpose, and for general real-time multimedia session description pur-
poses. This draft does not describe multicast address allocation or the poses. This draft does not describe multicast address allocation or the
distribution of SDP messages in detail. These are described in accom- distribution of SDP messages in detail. These are described in accom-
panying drafts. SDP is not intended for negotitation of media encod- panying drafts. SDP is not intended for negotiation of media encodings.
ings.
2. Background 2. Background
The Mbone is the part of the internet that supports IP multicast, and The Mbone is the part of the internet that supports IP multicast, and
thus permits efficient many-to-many communication. It is used exten- thus permits efficient many-to-many communication. It is used exten-
sively for multimedia conferencing. Such conferences usually have the sively for multimedia conferencing. Such conferences usually have the
property that tight coordination of conference membership is not neces- property that tight coordination of conference membership is not neces-
sary; to receive a conference, a user at an Mbone site only has to know sary; to receive a conference, a user at an Mbone site only has to know
the conference's multicast group address and the UDP ports for the the conference's multicast group address and the UDP ports for the
conference data streams. conference data streams.
Session directories assist the advertisement of conference sessions and Session directories assist the advertisement of conference sessions and
communicate the relevant conference setup information to prospective communicate the relevant conference setup information to prospective
participants. SDP is designed to convey such information to recipients. participants. SDP is designed to convey such information to recipients.
SDP is purely a format for session description - it does not incorpor- SDP is purely a format for session description - it does not incorporate
tate a transport protocol, and is intended to use different transport a transport protocol, and is intended to use different transport proto-
protocols as appropriate including the Session Announcement Protocol cols as appropriate including the Session Announcement Protocol [4],
[4], Session Inititation Protocol [11], Real-Time Streaming Protocol Session Initiation Protocol [11], Real-Time Streaming Protocol [12],
[12], electronic mail using the MIME extensions, and the Hypertext Tran- electronic mail using the MIME extensions, and the Hypertext Transport
sport Protocol. Protocol.
SDP is intended to be general purpose so that it can be used for a wider SDP is intended to be general purpose so that it can be used for a wider
range of network environments and applications than just multicast ses- range of network environments and applications than just multicast ses-
sion directories. However, it is not intended to support negotiation of sion directories. However, it is not intended to support negotiation of
session content or media encodings - this is viewed as outside the scope session content or media encodings - this is viewed as outside the scope
of session description. of session description.
3. Glossary of Terms 3. Glossary of Terms
The following terms are used in this document, and have specific meaning The following terms are used in this document, and have specific meaning
skipping to change at page 9, line 14 skipping to change at page 9, line 14
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley) e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127 c=IN IP4 224.2.17.12/127
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly a=recvonly
m=audio 3456 RTP/AVP 0 m=audio 49170 RTP/AVP 0
m=video 2232 RTP/AVP 31 m=video 51372 RTP/AVP 31
m=application 32416 udp wb m=application 32416 udp wb
a=orient:portrait a=orient:portrait
Text records such as the session name and information are bytes strings Text records such as the session name and information are bytes strings
which may contain any byte with the exceptions of 0x00 (Nul), 0x0a which may contain any byte with the exceptions of 0x00 (Nul), 0x0a
(ASCII newline) and 0x0d (ASCII carriage return). The sequence CRLF (ASCII newline) and 0x0d (ASCII carriage return). The sequence CRLF
(0x0d0a) is used to end a record, although parsers should be tolerant (0x0d0a) is used to end a record, although parsers should be tolerant
and also accept records terminated with a single newline character. By and also accept records terminated with a single newline character. By
default these byte strings contain ISO-10646 characters in UTF-8 encod- default these byte strings contain ISO-10646 characters in UTF-8 encod-
ing, but this default may be changed using the `charset' attribute. ing, but this default may be changed using the `charset' attribute.
skipping to change at page 18, line 10 skipping to change at page 18, line 10
media stream referred to by this key field is encrypted. The media stream referred to by this key field is encrypted. The
user should be prompted for the key when attempting to join the user should be prompted for the key when attempting to join the
session, and this user-supplied key should then be used to session, and this user-supplied key should then be used to
decrypt the media streams. decrypt the media streams.
Attributes Attributes
a=<attribute> a=<attribute>
a=<attribute>:<value> a=<attribute>:<value>
A media field may also have any number of attributes (``a='' fields) Attributes are the primary means for extending SDP. Attributes may be
which are media specific. Attribute fields can also be added before the defined to be used as "session-level" attributes, "media-level" attri-
first media field. These attributes would convey additional information butes, or both.
that applies to the conference as a whole rather than to individual
media; an example might be the conference's floor control policy. A media description may have any number of attributes (``a='' fields)
which are media specific. These are refered to as "media-level" attri-
butes and add information about the media stream. Attribute fields can
also be added before the first media field; these "session-level" attri-
butes convey additional information that applies to the conference as a
whole rather than to individual media; an example might be the
conference's floor control policy.
Attribute fields may be of two forms: Attribute fields may be of two forms:
o property attributes. A property attribute is simply of the form o property attributes. A property attribute is simply of the form
``a=<flag>''. These are binary attributes, and the presence of the ``a=<flag>''. These are binary attributes, and the presence of the
attribute conveys that the attribute is a property of the session. attribute conveys that the attribute is a property of the session.
An example might be ``a=recvonly''. An example might be ``a=recvonly''.
o value attributes. A value attribute is of the form o value attributes. A value attribute is of the form
``a=<attribute>:<value>''. An example might be that a whiteboard ``a=<attribute>:<value>''. An example might be that a whiteboard
skipping to change at page 18, line 40 skipping to change at page 18, line 46
lar. lar.
Attribute names must be in the US-ASCII subset of ISO-10646/UTF-8. Attribute names must be in the US-ASCII subset of ISO-10646/UTF-8.
Attribute values are byte strings, and MAY use any byte value except Attribute values are byte strings, and MAY use any byte value except
0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are
to be interpreted as in ISO-10646 character set with UTF-8 encoding. to be interpreted as in ISO-10646 character set with UTF-8 encoding.
Unlike other text fields, attribute values are NOT normally affected by Unlike other text fields, attribute values are NOT normally affected by
the `charset' attribute as this would make comparisons against known the `charset' attribute as this would make comparisons against known
values problematic. However, when an attribute is defined, it can be values problematic. However, when an attribute is defined, it can be
defined to be charset-dependant, in which case it's value should be defined to be charset-dependent, in which case it's value should be
interpreted in the session charset rather than in ISO-10646. interpreted in the session charset rather than in ISO-10646.
Attributes that will be commonly used can be registered with IANA (see
Appendix B). Unregistered attributes should begin with "X-" to prevent
inadvertant collision with registered attributes. In either case, if an
attribute is received that is not understood, it should simply be
ignored by the receiver.
Media Announcements Media Announcements
m=<media> <port> <transport> <fmt list> m=<media> <port> <transport> <fmt list>
A session announcement may contain a number of media announcements. A session description may contain a number of media descriptions. Each
Each media announcement starts with an ``m='' field, and is terminated media description starts with an ``m='' field, and is terminated by
by either the next ``m='' field or by the end of the session announce- either the next ``m='' field or by the end of the session description.
ment. A media field also has several sub-fields: A media field also has several sub-fields:
o The first sub-field is the media type. Currently defined media are o The first sub-field is the media type. Currently defined media are
``audio'', ``video'', ``application'', ``data'' and ``control'', ``audio'', ``video'', ``application'', ``data'' and ``control'',
though this list may be extended as new communication modalities though this list may be extended as new communication modalities
emerge (e.g., telepresence). The difference between ``application'' emerge (e.g., telepresense). The difference between ``application''
and ``data'' is that the former is a media flow such as whiteboard and ``data'' is that the former is a media flow such as whiteboard
information, and the latter is bulk-data transfer such as multicast- information, and the latter is bulk-data transfer such as multicast-
ing of program executables which will not typically be displayed to ing of program executables which will not typically be displayed to
the user. ``control'' is used to specify an additional conference the user. ``control'' is used to specify an additional conference
control channel for the session. control channel for the session.
o The second sub-field is the transport port to which the media o The second sub-field is the transport port to which the media
stream will be sent. The meaning of the transport port depends on stream will be sent. The meaning of the transport port depends on
the network being used as specified in the relevant ``c'' field and the network being used as specified in the relevant ``c'' field and
on the transport protocol defined in the third sub-field. Other on the transport protocol defined in the third sub-field. Other
skipping to change at page 19, line 37 skipping to change at page 19, line 48
to a unicast address, it may be necessary to specify multiple tran- to a unicast address, it may be necessary to specify multiple tran-
sport ports. This is done using a similar notation to that used for sport ports. This is done using a similar notation to that used for
IP multicast addresses in the ``c='' field: IP multicast addresses in the ``c='' field:
m=<media> <port>/<number of ports> <transport> <fmt list> m=<media> <port>/<number of ports> <transport> <fmt list>
In such a case, the ports used depend on the transport protocol. In such a case, the ports used depend on the transport protocol.
For RTP, only the even ports are used for data and the corresponding For RTP, only the even ports are used for data and the corresponding
one-higher odd port is used for RTCP. For example: one-higher odd port is used for RTCP. For example:
m=video 3456/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would specify that ports 3456 and 3457 form one RTP/RTCP pair and would specify that ports 49170 and 49171 form one RTP/RTCP pair and
3458 and 3459 form the second RTP/RTCP pair. RTP/AVP is the tran- 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the tran-
sport protocol and 31 is the format (see below). sport protocol and 31 is the format (see below).
It is illegal for both multiple addresses to be specified in the It is illegal for both multiple addresses to be specified in the
``c='' field and for multiple ports to be specified in the ``m='' ``c='' field and for multiple ports to be specified in the ``m=''
field in the same session announcement. field in the same session description.
o The third sub-field is the transport protocol. The transport pro- o The third sub-field is the transport protocol. The transport pro-
tocol values are dependent on the address-type field in the ``c='' tocol values are dependent on the address-type field in the ``c=''
fields. Thus a ``c='' field of IP4 defines that the transport pro- fields. Thus a ``c='' field of IP4 defines that the transport pro-
tocol runs over IP4. For IP4, it is normally expected that most tocol runs over IP4. For IP4, it is normally expected that most
media traffic will be carried as RTP over UDP. The following tran- media traffic will be carried as RTP over UDP. The following tran-
sport protocols are preliminarily defined, but may be extended sport protocols are preliminarily defined, but may be extended
through registration of new protocols with IANA: through registration of new protocols with IANA:
- RTP/AVP - the IETF's Realtime Transport Protocol using the - RTP/AVP - the IETF's Realtime Transport Protocol using the
skipping to change at page 20, line 49 skipping to change at page 21, line 15
the RTP Audio/Video Profile. the RTP Audio/Video Profile.
When a list of payload formats is given, this implies that all of When a list of payload formats is given, this implies that all of
these formats may be used in the session, but the first of these these formats may be used in the session, but the first of these
formats is the default format for the session. formats is the default format for the session.
For media whose transport protocol is not RTP or UDP the format For media whose transport protocol is not RTP or UDP the format
field is protocol specific. Such formats should be defined in an field is protocol specific. Such formats should be defined in an
additional specification document. additional specification document.
For media whose transport protocol is RTP, SDP can be used to For media whose transport protocol is RTP, SDP can be used to pro-
provide a dynamic binding of media encoding to RTP payload type. vide a dynamic binding of media encoding to RTP payload type. The
The payload names in the RTP AV Profile do not specify unique audio encoding names in the RTP AV Profile do not specify unique audio
encodings (in terms of clock rate and number of audio channels), and encodings (in terms of clock rate and number of audio channels), and
so they are not used directly in SDP format fields. Instead, the so they are not used directly in SDP format fields. Instead, the
payload type number should be used to specify the format for static payload type number should be used to specify the format for static
payload types and the payload type number along with additional payload types and the payload type number along with additional
encoding information should be used for dynamically allocated pay- encoding information should be used for dynamically allocated pay-
load types. load types.
An example of a static payload type is u-law PCM coded single chan- An example of a static payload type is u-law PCM coded single chan-
nel audio sampled at 8KHz. This is completely defined in the RTP nel audio sampled at 8KHz. This is completely defined in the RTP
Audio/Video profile as payload type 0, so the media field for such a Audio/Video profile as payload type 0, so the media field for such a
stream sent to UDP port 3456 is: stream sent to UDP port 49232 is:
m=video 3456 RTP/AVP 0 m=video 49232 RTP/AVP 0
An example of a dynamic payload type is 16 bit linear encoded stereo An example of a dynamic payload type is 16 bit linear encoded stereo
audio sampled at 16KHz. If we wish to use dynamic RTP/AVP payload audio sampled at 16KHz. If we wish to use dynamic RTP/AVP payload
type 98 for such a stream, additional information is required to type 98 for such a stream, additional information is required to
decode it: decode it:
m=video 3456 RTP/AVP 98 m=video 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2 a=rtpmap:98 L16/16000/2
The general form of an rtpmap attribute is: The general form of an rtpmap attribute is:
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>] a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>]
For audio streams, <encoding parameters> may specify the number of For audio streams, <encoding parameters> may specify the number of
audio channels. This parameter may be omitted if the number of audio channels. This parameter may be omitted if the number of
channels is one provided no additional parameters are needed. channels is one provided no additional parameters are needed.
For video streams, no encoding parameters are currently specified. For video streams, no encoding parameters are currently specified.
Additional parameters may be defined in the future, but codec- Additional parameters may be defined in the future, but codec-
specific parameters should not be added. Parameters added to an specific parameters should not be added. Parameters added to an
rtpmap attribute should only be those required for a session direc- rtpmap attribute should only be those required for a session
tory to make the choice of appropriate media too to participate in a directory to make the choice of appropriate media too to participate
session. Codec-specific parameters should be added in other attri- in a session. Codec-specific parameters should be added in other
butes. attributes.
Up to one rtpmap attribute can be define for each media format Up to one rtpmap attribute can be defined for each media format
specified. Thus we might have: specified. Thus we might have:
m=audio 12345 RTP/AVP 96 97 98 m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000 a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000 a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2 a=rtpmap:98 L16/11025/2
Experimental encoding formats can also be specified in this way.
RTP formats that are not registered with IANA as standard format
names must be preceded by ``X-''. Thus a new experimental redundant
audio stream called GSMLPC using dynamic payload type 99 could be
specified as:
m=video 3456 RTP/AVP 99 RTP profiles that specify the use of dynamic payload types must
define the set of valid encoding names and/or a means to register
encoding names if that profile is to be used with SDP.
Experimental encoding formats can also be specified using rtpmap.
RTP formats that are not registered as standard format names must be
preceded by ``X-''. Thus a new experimental redundant audio stream
called GSMLPC using dynamic payload type 99 could be specified as:
m=video 49232 RTP/AVP 99
a=rtpmap:99 X-GSMLPC/8000 a=rtpmap:99 X-GSMLPC/8000
Such an experimental encoding requires that any site wishing to Such an experimental encoding requires that any site wishing to
receive the media stream has relevant configured state in its ses- receive the media stream has relevant configured state in its ses-
sion directory to know which tools are appropriate. sion directory to know which tools are appropriate.
Note that RTP audio formats typically do not include information Note that RTP audio formats typically do not include information
about the number of samples per packet. If a non-default (as about the number of samples per packet. If a non-default (as
defined in the RTP Audio/Video Profile) packetisation is required, defined in the RTP Audio/Video Profile) packetisation is required,
the``ptime'' attribute is used as given below. the``ptime'' attribute is used as given below.
skipping to change at page 24, line 32 skipping to change at page 24, line 48
Northern European languages. In particular, the ISO 8859-1 is Northern European languages. In particular, the ISO 8859-1 is
specified with the following SDP attribute: specified with the following SDP attribute:
a=charset:ISO-8859-1 a=charset:ISO-8859-1
This is a session-level attribute; if this attribute is present, it This is a session-level attribute; if this attribute is present, it
must be before the first media field. The charset specified MUST be must be before the first media field. The charset specified MUST be
one of those registered with IANA, such as ISO-8859-1. The charac- one of those registered with IANA, such as ISO-8859-1. The charac-
ter set identifier is a US-ASCII string and MUST be compared against ter set identifier is a US-ASCII string and MUST be compared against
the IANA identifiers using a case-insensitive comparison. If the the IANA identifiers using a case-insensitive comparison. If the
indentifier is not recognised or not supported, all strings that are identifier is not recognised or not supported, all strings that are
affected by it SHOULD be regarded as byte strings. affected by it SHOULD be regarded as byte strings.
Note that a character set specified MUST still prohibit the use of Note that a character set specified MUST still prohibit the use of
bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets requiring bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets requiring
the use of these characters MUST define a quoting mechanism that the use of these characters MUST define a quoting mechanism that
prevents these bytes appearing within text fields. prevents these bytes appearing within text fields.
a=sdplang:<language tag> a=sdplang:<language tag>
This can be a session level attribute or a media level attribute. This can be a session level attribute or a media level attribute.
As a session level attribute, it specifies the language for the ses- As a session level attribute, it specifies the language for the ses-
skipping to change at page 26, line 47 skipping to change at page 27, line 15
In some cases, however, it is possible that this may be insufficient to In some cases, however, it is possible that this may be insufficient to
communicate the details of an unusual conference control policy. If communicate the details of an unusual conference control policy. If
this is the case, then a conference attribute specifying external con- this is the case, then a conference attribute specifying external con-
trol might be set, and then one or more ``media'' fields might be used trol might be set, and then one or more ``media'' fields might be used
to specify the conference control tools and configuration data for those to specify the conference control tools and configuration data for those
tools. An example is an ITU H.332 session: tools. An example is an ITU H.332 session:
... ...
c=IN IP4 224.5.6.7 c=IN IP4 224.5.6.7
a=type:H332 a=type:H332
m=audio 12345 RTP/AVP 0 m=audio 49230 RTP/AVP 0
m=video 12347 RTP/AVP 31 m=video 49232 RTP/AVP 31
m=application 12349 udp wb m=application 12349 udp wb
m=control 12341 H323 mc m=control 49234 H323 mc
c=IN IP4 134.134.157.81 c=IN IP4 134.134.157.81
In this example, a general conference attribute (type:H332) is specified In this example, a general conference attribute (type:H332) is specified
stating that conference control will be provided by an external H.332 stating that conference control will be provided by an external H.332
tool, and a contact addresses for the H.323 session multipoint con- tool, and a contact addresses for the H.323 session multipoint con-
troller is given. troller is given.
In this document, only the declaritive style of conference control In this document, only the declarative style of conference control
declaration is specified. Other forms of conference control should declaration is specified. Other forms of conference control should
specify an appropriate type attribute, and should define the implica- specify an appropriate type attribute, and should define the implica-
tions this has for control media. tions this has for control media.
7. Security Considerations 7. Security Considerations
SDP is a session description format that describes multimedia sessions. SDP is a session description format that describes multimedia sessions.
A session description should not be trusted unless it has been obtained A session description should not be trusted unless it has been obtained
by an authenticated transport protocol from a trusted source. Many dif- by an authenticated transport protocol from a trusted source. Many dif-
ferent transport protocols may be used to distribute session descrip- ferent transport protocols may be used to distribute session descrip-
skipping to change at page 36, line 5 skipping to change at page 36, line 5
safe ::= alpha-numeric | safe ::= alpha-numeric |
"'" | "'" | "-" | "." | "/" | ":" | "?" | """ | "'" | "'" | "-" | "." | "/" | ":" | "?" | """ |
"#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" | "#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" |
"]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" | "]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" |
"~" | " "~" | "
space ::= ;ascii code 32 space ::= ;ascii code 32
tab ::= ;ascii code 9 tab ::= ;ascii code 9
CRLF ::= ;ascii code 13 followed by ascii code 10 CRLF ::= ;ascii code 13 followed by ascii code 10
Appendix B: Guidelines for registering SDP names with IANA
There are five field names that may be registered with IANA. Using the
terminology in the SDP specification BNF, they are "media", "proto",
"fmt", "att-field" and "bwtype".
"media" (eg, audio, video, application, data).
The set of media is intended to be small and not to be extended
except under rare circumstances. The same rules should apply for
media names as for top-level MIME content types, and where possible
the same name should be registered for SDP as for MIME. For media
other than existing MIME top-level content types, a standards-track
RFC MUST be produced for a new top-level content type to be
registered, and the registration MUST provide good justification why
no existing media name is appropriate.
"proto"
In general this should be an IETF standards-track transport protocol
identifier such as RTP/AVP (rfc 1889 under the rfc 1890 profile).
However, people will want to invent their own proprietary transport
protocols. Some of these should be registered as a "fmt" using
"udp" as the protocol and some of which probably can't be.
Where the protocol and the application are intimately linked, such
as with the LBL whiteboard wb which used a proprietary and special
purpose protocol over UDP, the protocol name should be "udp" and the
format name that should be registered is "wb". The rules for for-
mats (see below) apply to such registrations.
Where the proprietary transport protocol really carries many dif-
ferent data formats, it is possible to register a new protocol name
with IANA. In such a case, an RFC MUST be produced describing the
protocol and referenced in the registration. Such an RFC MAY be
informational, although it is preferable if it is standards-track.
"fmt"
The format namespace is dependent on the context of the "proto"
field, so a format cannot be registered without specifying one or
more transport protocols that it applies to.
Formats cover all the possible encodings that might want to be tran-
sported in a multimedia session.
For RTP formats that have been assigned static payload types, the
payload type number is used. For RTP formats using a dynamic pay-
load type number, the dynamic payload type number is given as the
format and an additional "rtpmap" attribute specifies the format and
parameters.
For non-RTP formats, any unregistered format name may be registered.
If there is a suitable mapping from a MIME subtype to the format,
then the MIME subtype name should be registered. If there is no
suitable mapping from a MIME subtype, a new name should be
registered. In either case, unless there are strong reasons not to
do so, a standards-track RFC SHOULD be produced describing the for-
mat and this RFC SHOULD be referenced in the registration.
"att-field" (Attribute names)
Attribute field names MAY be registered with IANA, although this is
not compulsory, and unknown attributes are simply ignored.
When an attribute is registered, it must be accompanied by a brief
specification stating the following:
o contact name, email address and telephone number
o attribute-name (as it will appear in SDP)
o long-form attribute name in English
o type of attribute (session level, media level, or both)
o a one paragraph explanation of the purpose of the attribute.
o a specification of appropriate attribute values for this
attribute.
IANA will not sanity check such attribute registrations except to
ensure that they do not clash with existing registrations.
Although the above is the minimum that IANA will accept, if the
attribute is expected to see widespread use and interoperability is
an issue, authors are encouraged to produce a standards-track RFC
that specifies the attribute more precisely.
Submitters of registrations should ensure that the specification is
in the spirit of SDP attributes, most notably that the attribute is
platform independent in the sense that it makes no implicit assump-
tions about operating systems and does not name specific pieces of
software in a manner that might inhibit interoperability.
"bwtype" (bandwidth specifiers)
A proliferation of bandwidth specifiers is strongly discouraged.
New bandwidth specifiers may be registered with IANA. The submis-
sion MUST reference a standards-track RFC specifying the semantics
of the bandwidth specifier precisely, and indicating when it should
be used, and why the existing registered bandwidth specifiers do not
suffice.
Registration Procedure
To register a name the above guidelines should be followed regarding the
required level of documentation that is required. The registration
itself should be sent to IANA. Attribute registrations should include
the information given above. Other registrations should include the
following additional information:
o contact name, email address and telephone number
o name being registered (as it will appear in SDP)
o long-form name in English
o type of name ("media", "proto", "fmt" or "bwtype")
o a one paragraph explanation of the purpose of the registered name.
o a reference to the specification (eg RFC number) of the registered
name.
IANA may refer any registration to the IESG or to any appropriate IETF
working group for review, and may request revisions to be made before a
registration will be made.
Appendix C: Authors' Addresses Appendix C: Authors' Addresses
Mark Handley Mark Handley
Information Sciences Institute Information Sciences Institute
c/o MIT Laboratory for Computer Science c/o MIT Laboratory for Computer Science
545 Technology Square 545 Technology Square
Cambridge, MA 02139 Cambridge, MA 02139
United States United States
electronic mail: mjh@isi.edu electronic mail: mjh@isi.edu
skipping to change at page 37, line 14 skipping to change at page 40, line 14
octet Coded Character Set (UCS). octet Coded Character Set (UCS).
[8] D. Goldsmith, M. Davis, ``Using Unicode with MIME'', RFC1641, July [8] D. Goldsmith, M. Davis, ``Using Unicode with MIME'', RFC1641, July
1994 1994
[9] F. Yergeau, ``UTF-8, a transformation format of Unicode and ISO [9] F. Yergeau, ``UTF-8, a transformation format of Unicode and ISO
10646'', RFC 2044, Oct 30th 1996 10646'', RFC 2044, Oct 30th 1996
[10] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for Receiv- [10] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for Receiv-
ing Internet-based H.323 Conferences". ing Internet-based H.323 Conferences", ITU, Geneva.
[11] M. Handley, E. Schooler, H. Schulzrinne, ``Session Initiation Pro- [11] M. Handley, E. Schooler, H. Schulzrinne, ``Session Initiation Pro-
tocol (SIP)'' Internet Draft, July 1997. tocol (SIP)'' Internet Draft, Nov 1997.
[12] H. Schulzrinne, A. Rao, R. Lanphier, ``Real Time Streaming Protocol [12] H. Schulzrinne, A. Rao, R. Lanphier, ``Real Time Streaming Protocol
(RTSP)'' Internet Draft, July 1997. (RTSP)'' Internet Draft, Jan 1998.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/