TCP-Based Media Transport in the Session Description Protocol (SDP)
draft-ietf-mmusic-sdp-comedia-10

[Ballot discuss]
My comment is similar to one of Ted's but I'm going to home in some text.  In Section 3, it seems
inappropriate to look forward to other connection-oriented protocols with:
                                            These
  attributes MAY be used in conjunction with any m= line which uses a
  connection-oriented transport protocol, even if the protocol
  identifier of the m= line is not TCP.
Their point should be stated as:  the meanings of the attributes are not TCP-specific, and
therefore this specification's defined attributes are usable by future comedia if they need them.
Other connection-oriented protocols might not choose to - DCCP, for instance - so it should
be left to those future specifications to call out which they use.

I read the IANA discussion of format as confusing, but in conjunction with this from
RFC 2327:

    For media whose transport protocol is not RTP or UDP the format
    field is protocol specific.  Such formats should be defined in an
    additional specification document.

It reads ok to me.  I understand the SHOULD because some media are not
formatted.

Within the IANA Considerations:  don't the values of setup and connection also need
to be registered?

[Ballot discuss]
Easy to fix, and relatively minor...

In the IANA considerations:

>    Section 5 respectively.  These two attributes should be registered by
>    the IANA on
>
>    http://www.iana.org/assignments/sdp-parameters
>
>    under "att-field (both session and media level)".

please don't use the URLs. Better:

  Section 5 respectively.  These two attributes should be registered
  by the IANA under "Session Description Protocol (SDP) Parameters"
  [RFC2327] under "att-field (both session and media level)".

same for other IANA URLs

IANA Review - Per section 9 (IANA Considerations), we understand upon approval of this document that the IANA will make 3 (three) registrations in the sdp-parameters registry.

[Ballot discuss]
Is there any value to allowing extensibility in conn-value, so that a system
which wanted to disambiguate among existing connections (replace *this* one,
among the set) could use it to do so?

In section 5.2, it first appeared to me that an offerer who wished to
allow re-use of an existing connection must always offer it first, since
there is no way for the answerer to off "existing" to "new".  First,
does this bias the re-use, and is that bias intended?  Second, reading
the 3rd party call control scenario made me suspect that I might be
reading to much in--in that scenario, is it possible to replace existing
with new?

I found the IANA section also a bit tough to puzzle out.  Does it mean
that the "fmt" registry is an independent registry which is largely a subset of the MIME registry
or does it mean that any sensible MIME registration may be used with
the TCP proto?  Is the text "specifications...must define the rules...." there
normative?

I think the IANA issue above is actual a symptom of trying to do a bit
more than define the TCP proto--the document is also giving advice
on what other connection oriented documents ought to do.  That
advice seems to be sometimes couched as "this may be used for any proto
of this type" and sometimes as "anyone following in our footsteps must
do this too".  I don't think they've made choices in any of that, but
the spec would be tighter if it were organized so that re-usable
items were clearly marked as 'now available', 'good advice you may want',
or 'required'.

[Ballot comment]
There are some special characters in this document.  All of the hyphens appear strangely (at least I think they are supposed to be hyphens), for example the one used in "m-".