Re: [MMUSIC] HELP: Definition of Media Type suitable for SDP ?

[Adam Roach <[e-mail]>]

[as an individual]

On 6/4/19 1:22 PM, Paul Kyzivat wrote:
> On 6/4/19 1:13 PM, Colin Perkins wrote:
>>> On 4 Jun 2019, at 17:35, Paul Kyzivat <[e-mail]> wrote:
>>> I'm working on resolving IESG comments on rfc4566bis. I need some 
>>> help on this one:
>>>
>>>> On 5/30/19 8:50 AM, Alexey Melnikov via Datatracker wrote:
>>>>> Alexey Melnikov has entered the following ballot position for
>>>>> draft-ietf-mmusic-rfc4566bis-35: No Objection
>>>
>>> ...
>>>
>>>>> In 3.1 “media types” need a Normative reference.
>>>
>>> I've always struggled on this. The "simple" answer to refer to 
>>> RFC2046. That indeed defines the notion of two part names for media 
>>> types, and the IANA registry for those. But it is really focused 
>>> primarily on those things that can exist as body parts in email, 
>>> sip, etc. While that same registry is used for streaming media, it 
>>> seems clear that not everything in that registry is suitable for use 
>>> as streaming media.
>>>
>>> Is there a more suitable reference for definition of the media types 
>>> that SDP is concerned with?
>>
>>
>> RFC 2046 is obsolete. I think the current version is RFC 6838.
>>
>> Aside from that, I’m not sure I understand the concern. SDP is a 
>> general purpose signalling protocol and should be able to negotiate 
>> any media type. Specific rules for framed media, such as RTP payload 
>> formats, are described in Section 4.8 of RFC 6838, but those are a 
>> detail that doesn’t affect SDP.
>
> Do you mean that it would be fine to use SDP to negotiate the 
> streaming of multipart/mixed or text/plain over RTP? 


As fine as it would be to send an email with a Content-Type of 
"application/sdp".

If someone came along and somehow defined semantics for these, then the 
syntax and registration processes would support that. But MIME doesn't 
do anything to ensure semantic consistency: there are infinite ways to 
send nonsense.

/a