Re: [rtcweb] Video codec selection - way forward

Harald Alvestrand <harald@alvestrand.no> Fri, 15 November 2013 13:44 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5704F11E81A4 for <rtcweb@ietfa.amsl.com>; Fri, 15 Nov 2013 05:44:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C22NhSg6m-X2 for <rtcweb@ietfa.amsl.com>; Fri, 15 Nov 2013 05:44:08 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6F57311E81B1 for <rtcweb@ietf.org>; Fri, 15 Nov 2013 05:44:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6597139E333 for <rtcweb@ietf.org>; Fri, 15 Nov 2013 14:44:03 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj6dGskh0gS5 for <rtcweb@ietf.org>; Fri, 15 Nov 2013 14:44:02 +0100 (CET)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6FC5639E31B for <rtcweb@ietf.org>; Fri, 15 Nov 2013 14:44:02 +0100 (CET)
Message-ID: <52862521.9090706@alvestrand.no>
Date: Fri, 15 Nov 2013 14:44:01 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <D9C9C6C10CA24644B3A854DB0C12E7D5014C12B5F1@gbplmail03.genband.com> <CA+23+fFyNzK_tZVAv3qn00uVvBWjU6Rh3CDsPKyJUSYgerwjjQ@mail.gmail.com> <4A450D6F-603B-4A9D-9C1F-531D176F465A@apple.com>
In-Reply-To: <4A450D6F-603B-4A9D-9C1F-531D176F465A@apple.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Nov 2013 13:44:13 -0000

On 11/15/2013 03:10 AM, David Singer wrote:
> On Nov 14, 2013, at 23:57 , Jonathan Rosenberg <jdrosen@jdrosen.net>; wrote:
>
>> I agree with others that SHOULD implement both, or other variations on SHOULD, are not helpful. They will anyway be ignored and amount to more or less the no-interop situation we're in if we continue on the current path and have no consensus.  No consensus means the various players doing as they prefer, which is what they'd do if there is a SHOULD.
> I don't agree.  I think that MUST implement at least one of them, and SHOULD do both, provides both clear guidance as to the interop points, and clear pressure to implement both.  I think it's as close to interop as we are likely to get.

I agree that the addition of SHOULD statements makes a difference in 
perception.

There's been a push at times to have SHOULD statements accompanied with 
descriptions of the conditions under which they apply; in this case, one 
could imagine a statement like "MUST implement VP8, and SHOULD implement 
H.264 (MUST unless using a business model where it's impossible to 
comply with the requirements of the available licenses for H.264 IPR)".

Focusing on the naked MUST statements seems to me to be a strategy that 
emphasizes the battle lines.