[AVT] Re: [MMUSIC] Comments on draft-freed-media-types-reg-01.txt

[Colin Perkins <csp at csperkins.org>]

[Replies to the MMUSIC list only please, since this is an SDP issue]

On 13 Sep 2004, at 16:27, Even, Roni wrote:
> Reading the document and looking at the IANA database I noticed that 
> the media types do not include “data” and “control”.
>
> The current SDP draft has in section 9
>   
> 9.2.1  Media types ("media")
>  
>    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 MIME content types, and where
>    possible the same name should be registered for SDP as for MIME.  
> For
>    media other than existing MIME top-level 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 [5].
>  
>    This memo registers the media types "audio", "video", "text",
>    "application", "data" and "control".
>  
> So does it mean that in an RTP payload specification I will register a 
> payload type as application and use in SDP m line as data?

No. The "data" and "control" types are somewhat under-specified in SDP, 
but are intended to be used as alternatives to the other top-level 
media types. We should probably either remove them in favour of 
"application", or define new top-level MIME types if there's a need. 
Using "application" as the MIME type and "m=control" or "m=data" in SDP 
is wrong, though.

The simplest solution is to remove these in the next revision of 
sdp-new, and for them to be registered if there's a need later (unless 
someone is willing to contribute text to fix sdp-new).

Colin

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt