Re: [MMUSIC] JSEP Issue #394: What appears in m= lines.

Harald Alvestrand <harald@alvestrand.no> Mon, 02 January 2017 13:42 UTC

Return-Path: <harald@alvestrand.no>
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 A9739129459 for <mmusic@ietfa.amsl.com>; Mon, 2 Jan 2017 05:42:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level:
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 HdFha5InHZ2S for <mmusic@ietfa.amsl.com>; Mon, 2 Jan 2017 05:42:31 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAFAE124281 for <mmusic@ietf.org>; Mon, 2 Jan 2017 05:42:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id EC29D7C4C18 for <mmusic@ietf.org>; Mon, 2 Jan 2017 14:42:28 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkMRseAU0Ziy for <mmusic@ietf.org>; Mon, 2 Jan 2017 14:42:28 +0100 (CET)
Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 058EC7C4C17 for <mmusic@ietf.org>; Mon, 2 Jan 2017 14:42:27 +0100 (CET)
To: mmusic@ietf.org
References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <CABcZeBPznLKNHek-SGE5Ly6QTOBL-j65sZBb5MbwQVkmBkpyFw@mail.gmail.com>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no>
Date: Mon, 2 Jan 2017 14:42:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CABcZeBPznLKNHek-SGE5Ly6QTOBL-j65sZBb5MbwQVkmBkpyFw@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/YFwOlJNWVB2ywzcz7nsWIXeLtcc>
Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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, 02 Jan 2017 13:42:32 -0000

Den 22. des. 2016 18:30, skrev Eric Rescorla:
>      __
> 
>     Okay, I agree that having any rules for what you should offer here
>     based on what the actual outcome is not the best idea here. I think
>     the rules should be based on capability and intent. So if you only
>     are going offer TCP candidates, then you clearly should use TCP/…,
> 
> 
> I'm going to push on this. If we've already agreed that mismatches are
> normal, why should we do that? Wouldn't it be better to just effectively
> deprecate this field?
> 

Concur with EKR.

This field (the TCP/UDP part of the protocol field) was defined in a way
that makes its original purpose (to negotiate profiles) not only
impossible while using ICE, but actively harmful, because you end up
telling lies in very many cases, so people will have to accept things
that don't match reality.

Make the world as simple for implementors as possible: Send a fixed
string, and accept all strings.