Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32: Media Description

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 18 February 2019 20:24 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 006DF130F00; Mon, 18 Feb 2019 12:24:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LsyynQY_B323; Mon, 18 Feb 2019 12:24:07 -0800 (PST)
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 26044130E8A; Mon, 18 Feb 2019 12:24:06 -0800 (PST)
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 x1IKNtjE004513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Feb 2019 15:23:56 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: Ben Campbell <ben@nostrum.com>, draft-ietf-mmusic-rfc4566bis.all@ietf.org
Cc: mmusic WG <mmusic@ietf.org>, "'Colin Perkins'" <csp@csperkins.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <04CAFF8C-B6ED-4B7D-9FDD-ED37DCA2848B@nostrum.com> <e7e0042a-8079-8c0e-0ddd-1ea330f08e7c@alum.mit.edu>
Message-ID: <355f8125-87f8-6372-8289-126fa126ccb9@alum.mit.edu>
Date: Mon, 18 Feb 2019 15:23:55 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <e7e0042a-8079-8c0e-0ddd-1ea330f08e7c@alum.mit.edu>
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/8vxLtV6iSK2WW5oUvEGiyEW4nqY>
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32: Media Description
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: Mon, 18 Feb 2019 20:24:09 -0000


> On 2/11/19 10:45 PM, Ben Campbell wrote:

>> §2, “Media Description”: While true, the text here is not a definition 
>> of anything but syntax. Please add a sentence or two to say what the 
>> media description semantically represents.
I'm having trouble finding a suitable semantic definition of Media 
Description.

My first thought is that it provides the information necessary to 
establish a media session. But while *Multimedia Session* is described, 
media Session isn't defined in the document.

I looked at RFC7656 (Taxonomy) for a definition, but it doesn't have one 
either. It defines RTP Session, and Multimedia Session as one or more 
RTP Sessions. That is close, but in SDP media sessions need not be RTP.

Is there any suitable existing definition???

If not, then how about:

"A Media Description contains the information needed for one party to 
establish an application layer network protocol connection to another 
party." ???

OR

"A Media Description contains the information needed for one party to 
establish a Media Session with another party."

"A Media Session is an application layer network protocol connection 
between two parties."

It seems important to get this right! It is essentially a broadening of 
RFC7656 beyond RTP.

	Thanks,
	Paul