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

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 19 February 2019 16:22 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 C2B1E130F20 for <mmusic@ietfa.amsl.com>; Tue, 19 Feb 2019 08:22:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 PlIZsPjmEL1e for <mmusic@ietfa.amsl.com>; Tue, 19 Feb 2019 08:22:15 -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 77A0D130F1E for <mmusic@ietf.org>; Tue, 19 Feb 2019 08:22:15 -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 x1JGMDuu007911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <mmusic@ietf.org>; Tue, 19 Feb 2019 11:22:13 -0500
To: mmusic@ietf.org
References: <04CAFF8C-B6ED-4B7D-9FDD-ED37DCA2848B@nostrum.com> <e7e0042a-8079-8c0e-0ddd-1ea330f08e7c@alum.mit.edu> <355f8125-87f8-6372-8289-126fa126ccb9@alum.mit.edu> <6E58094ECC8D8344914996DAD28F1CCD18CB5561@dggemm526-mbx.china.huawei.com> <16e3f203-f914-34e6-8383-788231c78914@alum.mit.edu> <D50DD9EA-3E5B-47AE-9588-714C54C752D9@ericsson.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <0d686068-f24f-a764-6297-38e2a1c08016@alum.mit.edu>
Date: Tue, 19 Feb 2019 11:22:12 -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: <D50DD9EA-3E5B-47AE-9588-714C54C752D9@ericsson.com>
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/0M-jnFNJU3-0PJj0PMbV_eg6-kI>
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: Tue, 19 Feb 2019 16:22:18 -0000

On 2/19/19 11:06 AM, Christer Holmberg wrote:
> Hi,
> 
> The media description describes the properties, associated with a data flow, that an endpoint provides in order to properly be able to process data associated with the data flow. It includes IP address and port, and properties specific to the transport protocol and media type associated with the data flow.

I would rather not define it in terms of other undefined things. So I 
have a problem with "data flow".

It clearly has to do with a network connection, but only defines half of 
one.

When used with O/A, it defines only the receiving end of a connection, 
while with declarative SDP it defines both a sending and receiving end.

And while the c= line and the port from the m= line typically specify 
part of a *transport* protocol, the intent in the proto and fmt is to 
identify an application level protocol.

	Thanks,
	Paul

> ...or something like that.
> 
> I don't think we need to make it more complicated.
> 
> Regards,
> 
> Christer
> 
> 
> On 19/02/2019, 17.48, "mmusic on behalf of Paul Kyzivat" <mmusic-bounces@ietf.org on behalf of pkyzivat@alum.mit.edu> wrote:
> 
>      On 2/19/19 1:52 AM, Roni Even (A) wrote:
>      > Hi Paul,
>      > I am not sure why we need to  change the definition.
>      >
>      > A media description describes the media and it start with a m= line  ... (and so on)
>      >
>      > If want to expand maybe say that it must start with an m= line and will include the sdp types as listed in section 5
>      
>      This came up because Ben felt that the current definition was inadequate
>      because it is only syntactic. He asked for a semantic definition to be
>      added.
>      
>      IMO the fact that it seems hard to come up with a suitable semantic
>      definition makes it more important to do so.
>      
>      	Thanks,
>      	Paul
>      
>      _______________________________________________
>      mmusic mailing list
>      mmusic@ietf.org
>      https://www.ietf.org/mailman/listinfo/mmusic
>      
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>