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

[Colin Perkins <[e-mail]>]

> On 4 Jun 2019, at 19:22, Paul Kyzivat <[e-mail]> 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?


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. 

Sending text/plain in RTP might make sense as a timed text format, although the text payload formats we have include richer information and use different media types.

Colin





-- 
Colin Perkins
https://csperkins.org/