[MMUSIC] Comments on draft-freed-media-types-reg-01.txt
Colin Perkins
csp at csperkins.org
Mon Sep 13 22:33:07 CEST 2004
[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
More information about the Ietf-types
mailing list