[MMUSIC] Comments on draft-holmberg-mmusic-sdp-mmt-negotiation-00

[Paul Kyzivat <[e-mail]>]

Here are a number of comments on 
draft-holmberg-mmusic-sdp-mmt-negotiation-00, written as I prepare for 
the meeting.

Section 5.2.2.1:

I understand why an offerer would typically *want* to group one or more 
media descriptions for specific media types with an "anymedia" media 
description. But why MUST that be done? Why can't an offerer just offer 
the anymedia description if he isn't interested in backward compatibility?

Section 6.1

It is unclear to me whether the <media> value "anymedia" that is defined 
he is legitimate according to 4566. Section 8.2.1 of 4566 says:

    The set of media types is intended to be small and SHOULD NOT be
    extended except under rare circumstances.  The same rules should
    apply for media names as for top-level media content types, and where
    possible the same name should be registered for SDP as for MIME.  For
    media other than existing top-level media content types, a Standards
    Track RFC MUST be produced for a new top-level content type to be
    registered, and the registration MUST provide good justification why
    no existing media name is appropriate (the "Standards Action" policy
    of RFC 2434 [8].

The above suggests that the name needs to be a top level media content 
type, except for the "where possible". (And it's unclear what sort of 
exceptions "where possible" was intended to cover. The above uses the 
iana registry for "Media Types", which is shared with MIME usage. And 
from my quick scan it is not evident how to register a new top level type.

So, I think it might actually require a revision to 4566 to make this 
change - breaking this case out and exempting it from the registration 
process. If so then I think it would be helpful to choose something more 
distinctive than "anymedia" to denote this quite different case. I 
suggest "*". (This is syntactically valid in the <media> field according 
to the existing 4566 syntax, so it *ought* to be backward compatible.)

Section 7 - mmtype attribute:

Note that the use of payload types in m-lines is only for those with one 
of the RTP proto values. For UDP the media subtype is placed in the 
<fmt> field of the m-line rather than in rtpmap.

But with some rewording and explanation what you propose should work in 
most practical cases using the <fmt> value directly. E.g.

   a=mmtype: PCMU/8000 audio
   a=mmtype: H261/90000 video

The only time it wouldn't work is if you wanted to use a common subtype 
for two top level (e.g. both audio/foo and video/foo). That isn't likely.

(I'm having a separate discussion about how the new SCTP... <proto> 
values might describe the assignment of SCTP streams for particular 
purposes. At some point we *might* end up having a way to specify use of 
RTP over an SCTP stream. That then might start to interact with this if 
we wanted to mix audio/video in one such stream. But maybe it is 
premature to deal with that.)

Section 7.3.2:

I think you need to say *something* about O/A. I guess what makes sense 
is that 7.3.1 applies independently to the offer and the answer.

Section 10:

*Something* needs to be done about "anymedia" or whatever replaces it. 
As currently written you would need to register a new media type value. 
With my suggestions you might avoid that but have to identify this draft 
as an extension to 4566.

Unfortunately it is a bad time to revise 4566, since there is a 4566bis 
pending. Conceivably this whole thing could be added in to 4566bis, if 
the schedule works for that.

	Thanks,
	Paul