RE: Evaluation: draft-ietf-mmusic-sdp-new-13

["Peterson, Jon" <jon.peterson@neustar.biz>]

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.

> 
> 
> 
> 
>