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

OK, thanks. Then I guess it is 6838.

	Thanks,
	Paul

On 6/4/19 2:42 PM, Adam Roach wrote:
> [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 <pkyzivat@alum.mit.edu> 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
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic