IETF 61
The IETF 61 meeting was held from November 7-12, 2004
in Washington, DC, USA
Presentations
MMUSIC Agenda
8 November 2004
AVT Agenda
10 November 2004
Internet Drafts
-
draft-ietf-mmusic-sdp-new
-
Mark Handley, Van Jacobson, and Colin Perkins,
SDP: Session Description Protocol
(.txt|.pdf),
Internet Engineering Task Force,
October 2004,
Work in progress
(draft-ietf-mmusic-sdp-new-21.txt).
-
Mark Handley, Van Jacobson, and Colin Perkins,
SDP: Session Description Protocol
(.txt|.pdf),
Internet Engineering Task Force,
September 2004,
Work in progress
(draft-ietf-mmusic-sdp-new-20.txt).
-
There's a single change in this version: to remove the underspecified
"control" and "data" media types, aligning the SDP media types with MIME
media types. If there's a use for these media types they can be registered
separately. They've been removed here in the interests of getting the base
spec out.
-
Mark Handley, Van Jacobson, and Colin Perkins,
SDP: Session Description Protocol
(.txt|.pdf),
Internet Engineering Task Force,
August 2004,
Work in progress
(draft-ietf-mmusic-sdp-new-19.txt).
-
Running a diff with -18 will show many changes, due to differences in
the way the latest version of xml2rfc formats drafts. The main items
to note are:
-
minor editorial clarifications to Section 5.7 (clarify meaning of
"slash notation");
-
add normative references to RS, RR and TIAS bandwidth modifiers to
Section 5.8;
-
when using "k=clear:" clarify that the key can is interpreted as a
text string according to charset, and that "k=base64:" should be
used if the must contains non-text characters;
-
clarify that "i=" is not suitable for parsing by automata;
-
fix ABNF to disallow extensions to "k=";
-
allow non-IP multicast address formats, to match unicast rules;
-
the rules in section 5.6 say that phone numbers "SHOULD" be full
E.164 numbers preceeded by a "+", whereas the ABNF required this
form, and relax the ABNF to allow other forms of phone number;
-
clarify that time values in SDP are represented as unlimited length
text strings that don't wrap in 2036 (unlike 64 bit binary NTP timestamps);
-
clarify that URIs may now contain literal IPv6 addresses;
-
rewrite description of the proto field in "m=" lines for clarity
(move some of the text to IANA considerations);
-
rewrite description of the fmt field in "m=" lines for clarify, moving
much of the text to the description of the "a=rtpmap:" attribute;
-
in section 9.2.6 and 9.2.7 clarify that any type of RFC is sufficient to
register a new network or address type; and
-
make assorted minor clarifications and editorial fixes.
These address the majority of comments received, although I have made
no attempt to better specify the "control" and "data" media types.