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

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 04 June 2019 18:23 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1790C12036D for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2019 11:23:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcPTcSHBpNfj for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2019 11:23:01 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B836A12036B for <mmusic@ietf.org>; Tue, 4 Jun 2019 11:23:01 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x54IMukf001708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Jun 2019 14:22:57 -0400
To: Colin Perkins <csp@csperkins.org>
Cc: mmusic@ietf.org
References: <155922060388.22145.12090008162284261785.idtracker@ietfa.amsl.com> <5b944fc8-3f97-55e6-2faf-45bfd11c5837@alum.mit.edu> <122cfa2d-e1e6-18c9-5418-4e6fa1fe938f@alum.mit.edu> <3394C534-6B5E-446C-B797-FF6B0A1435BA@csperkins.org>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <04d9a8a4-db77-84f5-47f2-585f3313cf60@alum.mit.edu>
Date: Tue, 04 Jun 2019 14:22:56 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <3394C534-6B5E-446C-B797-FF6B0A1435BA@csperkins.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/tWdlxaihlMgIycne3iBZAxxkmIw>
Subject: Re: [MMUSIC] HELP: Definition of Media Type suitable for SDP ?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jun 2019 18:23:03 -0000

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?

	Thanks,
	Paul