SDP: Session Description Protocol
draft-ietf-mmusic-sdp-new-26
Discuss
Yes
(Allison Mankin)
No Objection
(Alex Zinin)
(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Harald Alvestrand)
(Margaret Cullen)
(Mark Townsley)
(Russ Housley)
(Sam Hartman)
(Thomas Narten)
Note: This ballot was opened for revision 26 and is now closed.
Ned Freed Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2005-08-18)
Unknown
Discuss comment transferred from old ballot: This document should explicitly say it obsoletes RFC 2327. This document apparently defines the application/sdp media type, replacing the definition in RFC 2327, but contains no media type registration form nor any IANA action associated with the registration. (This was also true of RFC 2327.) A 44 page document REALLY needs a table of contents. (I realize the RFC Editor is supposed to deal with this, but RFC 2327 is 42 pages and didn't have a TOC either.) That's it!
Steven Bellovin Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2005-08-18)
Unknown
Discuss comment transferred from old ballot: k= strikes me as almost useless. It doesn't have enough information (such as algorithm) to really be usable. I see no protection against replay prevention, nor any mention of that as a requirement for secure transport of SDP announcements. In fact, nothing is said about channel requirements in this context other than "secure and trusted". Is k= really used? Should it be deleted in favor of a pointer to draft-ietf-mmusic-sdescriptions? The Security Consideration section says that automatic mechanisms SHOULD NOT be used to start up interactive applications without user knowledge. I'd prefer MUST NOT, and I'd ask for consent, not simplhy knowledge. See the /dev/audio part of http://www.cert.org/advisories/CA-1993-15.html for why this is a problem...
Allison Mankin Former IESG member
Yes
Yes
()
Unknown
Erik Nordmark Former IESG member
Yes
Yes
(2005-08-18)
Unknown
Comment transferred from old ballot: Intro/abstract doesn't say the document obsoletes RFC 2137, which I think is the intent. The text on internationalization says UTF-8 only applies to informational fields. Does this mean it isn't required to perform any normalization whatsoever on the UTF-8? Would it make sense to explicitly state that normalization isn't needed. Typo: removed. It is assumed that transports of SDP specify will specify this. s/specify//
Jon Peterson Former IESG member
Yes
Yes
(2005-08-17)
Unknown
Comments transferred from old style text ballot: Thanks for your comments Ted - some notes below. - J > -----Original Message----- > From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] > Sent: Tuesday, June 24, 2003 4:01 PM > To: iesg-secretary@ietf.org; iesg@ietf.org > Subject: Evaluation: draft-ietf-mmusic-sdp-new-13 > > > Ted Hardie [ ] [ ] [ X ] [ ] > > DISCUSS: > In Section 5, for the description of u=<URI> > > I'd suggest eliminating "as used by WWW clients." and adding a citation > to draft-fielding-uri-rfc2396bis (or at least rfc2396). Note that this > definition seems to presume that all URIs used will be dereferencable, > which is not true for all URIs. If this is a limitation, then it should > be stated. > OK. > The k=<uri> also seems to presume that the URI is dereferencable. > If this is a limitation of the URI, it should be made explicit which schemes > are appropriate here. Frankly, it seems to mean http:; if that is the > case, specifying it seems like a good idea. Even for dereferencable > URI schemes, not all will use MIME to mark the reply (think of an > ftp: URI, for example). When they do, the mime content-encoding > specifies the encoding of the _message_, so reusing the word > "encoding" here seems problematic. How would "For those URI > schemes which use MIME, the content-encoding and content-type > headers of the reply may provide guidance on the format of the key." > work? > Yes, I think it would be good to be explicit that this SHOULD be http: or even preferably https: - I guess I can imagine LDAP or something as well, but it would be good to encourage something. I think your wording above on MIME headers is good as well. > On that same hobby horse, the ABNF in the appendix has: > ; sub-rules of 'u=' > uri = URI-reference; see RFC1630 and RFC2732 > > I think this should be a pointer to 2396 or the 2396bis draft. > Agreed. > For the a= inactive designation, we've discussed what addresses to use > for sessions which are being set up but for which addresses are not yet known. > It was suggested apps use something like "sdp.inactive" so that the .inactive > TLD could reinforce the a=inactive flag. In that instance, would the presence > of that TLD be a condition under which the RTCP SHOULD is appropriately > not done, and no RTCP sent? If so, is mentioning that case appropriate here? > Um... that's a trickier case. Agreed, of course, that sending RTCP in this case is pointless. I don't think we've as yet identified any particular magic word (like 'address.invalid') that we'd be into the SDP to signify that this SDP is an IOU. I guess it's the case, though, that if the domainname in the c= line cannot be reached, you can't send RTCP to it - so I'm not sure that there's a danger that RTCP will be sent needlessly that could be prevented here with some additional language. > In the IANA considerations, it looks the draft should specify that the > IANA must update the MIME media type registration to point to this > doc instead of RFC 2327. > True enough. > Notes: > > Having Section 5 contain so much without sub-headers made it hard to > give pointers to sections in the comments; that may be true for others > using the spec as well. > Fair. > In section 5, in the section describing the first subfield of c= > Just as a query, has anyone considered using a specific marker of > private address realms for SDP? That is, using a network type other > than IN to indicate that the domain name or address given are > not globally unique/globally reachable? > Well, whether or not a private address is reachable wrt a particular recipient of SDP is of course a matter of placement and context. The question is what the recipient would do with if it had a different marker for 1918 addrs. If the marker were able to tell the recipient whether or not it could reach the address in question, then it would be useful, sure. But barring that I'm not sure how useful this would be. > In the Security considerations, "Many different protocols may be used > to distribute session description," looks like session description should > be plural. > I'll pass these along.
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
()
Unknown
Bill Fenner Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
(2005-11-30)
Unknown
Long editorial comments are in the Gen-ART review by Spencer Dawkins. I wouldn't mind seeing a new version that takes account of these. Review will be placed at http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-mmusic-sdp-new-25-dawkins.txt
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
No Objection
No Objection
()
Unknown
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
No Objection
No Objection
()
Unknown
Scott Hollenbeck Former IESG member
No Objection
No Objection
(2005-11-30)
Unknown
I've looked at Ned's old discuss and believe it has been addressed. The normative reference to RFC 2234 should be updated to 4234, but I assume that'll be done by the RFC Editor.
Ted Hardie Former IESG member
(was Discuss)
No Objection
No Objection
(2005-10-19)
Unknown
I've decided to move to no-objection for this, and to enter the previous DISCUSS text as a comment. I still think the issues should be fixed, but I've decided it is better not to hold the draft for them. n Section 5, for the description of u=<URI> I'd suggest eliminating "as used by WWW clients." and adding a citation to draft-fielding-uri-rfc2396bis (or at least rfc2396). Note that this definition seems to presume that all URIs used will be dereferencable, which is not true for all URIs. If this is a limitation, then it should be stated. The k=<uri> also seems to presume that the URI is dereferencable. If this is a limitation of the URI, it should be made explicit which schemes are appropriate here. Frankly, it seems to mean http:; if that is the case, specifying it seems like a good idea. Even for dereferencable URI schemes, not all will use MIME to mark the reply (think of an ftp: URI, for example). When they do, the mime content-encoding specifies the encoding of the _message_, so reusing the word "encoding" here seems problematic. How would "For those URI schemes which use MIME, the content-encoding and content-type headers of the reply may provide guidance on the format of the key." work? On that same hobby horse, the ABNF in the appendix has: ; sub-rules of 'u=' uri = URI-reference; see RFC1630 and RFC2732 I think this should be a pointer to 2396 or the 2396bis draft. For the a= inactive designation, we've discussed what addresses to use for sessions which are being set up but for which addresses are not yet known. It was suggested apps use something like "sdp.inactive" so that the .inactive TLD could reinforce the a=inactive flag. In that instance, would the presence of that TLD be a condition under which the RTCP SHOULD is appropriately not done, and no RTCP sent? If so, is mentioning that case appropriate here? In the IANA considerations, it looks the draft should specify that the IANA must update the MIME media type registration to point to this doc instead of RFC 2327. Notes: Having Section 5 contain so much without sub-headers made it hard to give pointers to sections in the comments; that may be true for others using the spec as well. In section 5, in the section describing the first subfield of c= Just as a query, has anyone considered using a specific marker of private address realms for SDP? That is, using a network type other than IN to indicate that the domain name or address given are not globally unique/globally reachable? In the Security considerations, "Many different protocols may be used to distribute session description," looks like session description should be plural.
Thomas Narten Former IESG member
No Objection
No Objection
()
Unknown