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

[Paul Kyzivat <[e-mail]>]

On 6/4/19 3:26 PM, Colin Perkins wrote:
>> On 4 Jun 2019, at 19:22, Paul Kyzivat <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>> On 6/4/19 1:13 PM, Colin Perkins wrote:
>>>> On 4 Jun 2019, at 17:35, Paul Kyzivat <[e-mail] 
>>>> <mailto:[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?
> 
> I doubt the media type for multipart/mixed defines how it should be 
> carried over RTP so it wouldn’t make sense to negotiate that, but SDP 
> should be able to express it as an option.

That is what I was getting at: ISTM that only those that specify how 
they can be carried over RTP, or some other <proto> valid in an m-line, 
are appropriate for use.

	Thanks,
	Paul