The IETF 61 meeting was held from November 7-12, 2004 in Washington, DC, USA
- 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).
Changes in this version are:
- in section 4.1, clarify that the transport port for unicast IP sessions is the remote transport port;
- in section 5.1, clarify that the media description is optional;
- in section 5.7, clarify that "this memo only defines IP4 and IP6", rather than "currently only IP4 and IP6 are defined";
- in section 5.7, note that TTL scoping is NOT RECOMMENDED for multicast, and one should use admin-scoped addresses instead;
- rename section 6 from "Suggested Attributes" to "SDP Attributes";
- in section 5.8, clarify that the bandwidth is in kilobits per second unless otherwise specified in the definition of a new bwtype modifier;
- in section 5.9, clarify that the end time SHOULD be specified unless a session is unbounded;
- in section 5.12, remove example of SIP-over-TLS, since that's not an end to end connection;
- in section 5.13, remove example of use of attributes;
- in section 5.14, clarify behaviour when two RTP sessions share the same transport address;
- section 5.14 was missing a reference to the "application" top-level MIME type for the "udp" proto;
- in section 6, generalise "a=orient" slightly;
- in section 6, remove references to the "wb" application, which is of historical interest only;
- in section 6, specify that "a=maxptime" is an integer multiple of the frame size for frame based codecs;
- in section 7, reference SIP and offer/answer security considerations;
- in section 7, note that firewall holes should only be opened when the user can be appropriately authenticated and is authorized to do so;
- in ABNF, remove comment that suggested that UDP ports should either be 0 or in the range 1024-65535, since this conflicts with existing usage (e.g., port 9 is used by comedia) and isn't mandated by the text;
- in ABNF, allow DNS names for multicast groups;
- in ABNF, remove comment in the definition of "sess-version" that conflicted with the requirement in section 5.2 that an NTP-format timestamp SHOULD be used; and
- in ABNF, allow 127.0.0.1 as a valid IPv4 address;
- 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.