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

[hardie@qualcomm.com]

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.

    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.