Re: [rtcweb] Request to postpone the question on VP8 as MTI

David Singer <singer@apple.com> Mon, 11 March 2013 22:51 UTC

Return-Path: <singer@apple.com>
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 20D3521F8F37 for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 15:51:53 -0700 (PDT)
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 NLSnxDICzmPH for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 15:51:52 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id F2EAC21F8FF3 for <rtcweb@ietf.org>; Mon, 11 Mar 2013 15:51:51 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset="windows-1252"
Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MJI00FU7Q6EZC01@mail-out.apple.com> for rtcweb@ietf.org; Mon, 11 Mar 2013 15:51:51 -0700 (PDT)
X-AuditID: 11807153-b7f8a6d0000064e7-2e-513e6007c112
Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 87.53.25831.7006E315; Mon, 11 Mar 2013 15:51:51 -0700 (PDT)
Received: from [17.153.107.198] by cardamom.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MJI00DWIQ65WK40@cardamom.apple.com> for rtcweb@ietf.org; Mon, 11 Mar 2013 15:51:51 -0700 (PDT)
From: David Singer <singer@apple.com>
In-reply-to: <C56A8C6C-1D28-42EF-B4E3-F2471E20AD48@iii.ca>
Date: Mon, 11 Mar 2013 15:51:40 -0700
Content-transfer-encoding: quoted-printable
Message-id: <DC5C1D0F-D98A-44C8-A5AF-7F11349C5835@apple.com>
References: <92D0D52F3A63344CA478CF12DB0648AA26537A69@XMB106BCNC.rim.net> <C56A8C6C-1D28-42EF-B4E3-F2471E20AD48@iii.ca>
To: Cullen Jennings <fluffy@iii.ca>
X-Mailer: Apple Mail (2.1499)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUi2FAcp8ueYBdo0HiYx2Ltv3Z2B0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlzOkNKHinXfF75xyWBsaNyl2MnBwSAiYSB46cZIWwxSQu3FvP 1sXIxSEkMJFJYundhawQTiuTREf3eaAMBwezgJ7E/YtaICYvkDlpfxBIr7CAi0TX5jZ2EJtN QFXiwZxjjCA2p4CVRPOKFWBxFqD4trvrmEBsZoE4iZ9Tn7JC2NoST95dALN5BWwkjrW+A6sR EqiUmHx2PguILSKgLHFux11miDtlJVZM7WWawCgwC+GgWQgHzUIydAEj8ypGgaLUnMRKY73E goKcVL3k/NxNjOCAKwzewfhnmdUhRgEORiUeXoVvtoFCrIllxZW5hxglOJiVRHhLHewChXhT EiurUovy44tKc1KLDzFKc7AoifNmBgBVC6QnlqRmp6YWpBbBZJk4OKUaGNXTT0brhAuEdV0/ d4R7vdPXUze3NvZ1H+RPioj6cc2ptXi5dCafN//5+PrKs5f9p+74kscQMmcrf8jbtkf/+7cv 4xK+6Pv29bk7h6zCdIVfcRdGSF/221JT9nDpdJkDnccFOz6c5ufLnc2juUHbfL923YISwajl /nNO1G2Qlvkj9UX3ca5krxJLcUaioRZzUXEiAJ5LZ300AgAA
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Request to postpone the question on VP8 as MTI
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: Mon, 11 Mar 2013 22:51:53 -0000

On Mar 10, 2013, at 8:52 , Cullen Jennings <fluffy@iii.ca> wrote:

> 
> Gaelle, 
> 
> I think these are good points and other have erased similar points. I need to discuss it with my co-chairs but I suspect that for the points you raised, we will need delay this to IETF 86. Again, I need to talk to my co-chairs before we can make a decision on this but I would guess that is the direction things will need to go.

I also think it would be prudent to defer the codec decision.


> 
> Cullen (One of the co-chairs)
> 
> 
> On Mar 10, 2013, at 9:45 AM, Gaelle Martin-Cocher <gmartincocher@blackberry.com> wrote:
> 
>> Dear All,
>> 
>> In light of the recent announcements (both MPEG-LA and the VP8 litigation), I believe that more time is needed to make a proper risk assessment on VP8 and an informed decision. On one side the MPEG-LA announcement provides some relief but also confirms that VP8 does not come for free and that concerns were/are justified. This is further confirmed by the second announcement.
>> It will take more efforts for VP8 supporters (and Google does not need to be alone in that process) to reach the goal of an RF video codec (or a codec with a suitable licensing terms). I think it is understood by now, that this would likely be more prone to success in a standardization body than anywhere else . (speaking here as a WebVC proponent that went through that process too).
>> It is also apparent that the MPEG-LA/Google agreement raises additional questions.
>> 
>> Here are the reasons I believe we need more time and should postpone the question on VP8 (I am not saying that this should not be asked at a later time):
>> -The license is not yet published (and the meeting starts tomorrow)
>> -Some negotiations are still ongoing (e.g. names of the licensors).  
>> -Some questions were/are raised and not answered yet, below are the one that matters to me:
>> - Will the patent list be provided?
>> - Who are the licensors  and how that group of licensors relates to the initial 12 patent holders identified by MPEG-LA?
>> - Will there be alignment of licenses across WebM, RFC, MPEG, and is that even feasible with the possible new license terms?
>> - Questions related to clarifications of the different grants inside/outside the RFC and their applicability to the RFC itself still need to be answered (aka: how  section 20: 27 apply to the RFC code itself or to the code provided in MPEG)
>> - Questions related to the status of VP8 as a standard as it was mentioned that the RFC will not progress to the standard track still remain
>> - In light of the litigation announcement, was due diligence done by VP8 proponents toward patent holders that are not MPEG-LA members?  (e.g. possibly on a model similar to what was done in WebVC)  
>> - More questions will likely be raised once the license is published.
>> -We need to give enough time to Google to finalize its license and provide answers on those above points.
>> -VP8 is not (yet) a standard in IETF nor in MPEG (MPEG only saw an input contribution for the first time in January). It would be desirable that RTCWeb points to a standard or that VP8 reaches a certain stage in MPEG so that it can be considered as an MPEG deliverable. VP8 may reach that status at a next MPEG meeting in April or July, I don’t see how that can be accelerated further. We need to give MPEG the time to proceed properly.
>> -legal entities will need time to review both the new license and the answers to the various questions that were asked. This cannot be achieved in 3 days.
>> 
>> Further, I just came across an informational RFC for VP9:
>> -Is VP9 going to “deprecate” VP8?
>> - What is the timeframe for VP9 in IETF?
>> -if VP9 going to be proposed for a next generation of RTCWeb Client? Which timeframe?
>> I don’t think it would be desirable to mandate VP8 today if VP9 is around the corner and will be proposed for RTCWeb as well.
>> Requesting two codecs to be implemented instead of one in a short timeframe is obviously an issue for implementers that cannot do a simple software upgrade of their products.
>> 
>> 
>> I hope all of you will find that request reasonable.
>> Sincerely,
>> 
>> 
>> Gaëlle Martin-Cocher
>> Standards Manager
>> Office: (905) 629-4746 x14591
>> BlackBerry: (647) 267-0569
>> PIN: 2835485E
>> <image001.gif>
>> www.rim.com
>> 
>> --------------------------------------------------------------------- 
>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

David Singer
Multimedia and Software Standards, Apple Inc.