Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"

Kaiduan Xie <kaiduanx@gmail.com> Wed, 13 November 2013 21:57 UTC

Return-Path: <kaiduanx@gmail.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 7BDC111E810A for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 13:57:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.933
X-Spam-Level:
X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
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 1pDTK4+4Mg2E for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 13:57:15 -0800 (PST)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id EF41E21E80E3 for <rtcweb@ietf.org>; Wed, 13 Nov 2013 13:57:14 -0800 (PST)
Received: by mail-we0-f178.google.com with SMTP id u57so570402wes.23 for <rtcweb@ietf.org>; Wed, 13 Nov 2013 13:57:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2AF5F5BptXfcgUqHSElxF81ZCSGqD8FY/2pSXHS5MQ8=; b=tr/BrIMO6SVt4w3iz276Eal4cwqrxU6SLiPaxNAUbh/rwJi70pFmsUXHk/tv84D6at TznuBI6E1L7XcIOlQoWjWG3iobLSIhChH8f0LowhxNxbjIh3gOZfcYr/o1sIvFzp3x82 4wV9cAtAgvQtukRrOZwxDpTtVJ+oOxZfiZajAoKdUyPS+gllS9dtomgaa4L14RBvkz1k utGmVKM/K9l+KDybHh+WvCVAc3o6ybzPAJ/Dl8Td7jvKjHB2uwhNT/bDHZr6y8QY/4Ps oM2TYZLslxFyvFDNLQIS8WnxC4G6EgnmGhUSkshe9DGHRkSdq8e417Zlm2YhgqMq2fNE BL4A==
MIME-Version: 1.0
X-Received: by 10.194.205.37 with SMTP id ld5mr2044525wjc.67.1384379834236; Wed, 13 Nov 2013 13:57:14 -0800 (PST)
Received: by 10.216.183.202 with HTTP; Wed, 13 Nov 2013 13:57:14 -0800 (PST)
In-Reply-To: <5283E700.5090300@bbs.darktech.org>
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi> <5283E700.5090300@bbs.darktech.org>
Date: Wed, 13 Nov 2013 16:57:14 -0500
Message-ID: <CACKRbQf=x-wKUFemNhf4ZDwgZzqBFq=okUMw=BLCwaMmE7OJPw@mail.gmail.com>
From: Kaiduan Xie <kaiduanx@gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Content-Type: multipart/alternative; boundary=047d7bb70c5841050304eb160ca9
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
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: Wed, 13 Nov 2013 21:57:17 -0000

"if an implementer gets sued they can simply drop the codec"

Thing is not that simple as "simply drop the codec", for some case you
still have to pay a lot of money.

/Kaiduan


On Wed, Nov 13, 2013 at 3:54 PM, cowwoc <cowwoc@bbs.darktech.org>; wrote:

> Hi John,
>
> First, thanks for summarize the positions brought up in the meeting.
>
> A few weeks ago I advocated making both H.264 and VP8 MTI with the
> reasoning that if an implementer gets sued they can simply drop the codec,
> notify the community, and have that codec removed en-mass from the
> specification. A few months later we would replace it with another MTI
> codec. According to what you wrote above, Cisco is under the impression
> that once a codec is MTI they cannot drop it even if they get sued.
>
> Practically speaking, is that really true? I mean, if the specification
> requires everyone to implement both VP8 and H.264 and one implementer
> temporarily drops one of the codecs, shouldn't things keep on working until
> the lawsuit is over (codec returns) or the community replaces the codec
> with another?
>
> Thanks,
> Gili
>
>
> On 13/11/2013 11:55 AM, John Leslie wrote:
>
>> Mike Linksvayer <ml@gondwanaland.com>; wrote:
>>
>>> I strongly support VP8 for MTI, and oppose H.264. Undecided on which
>>> of both, either, or neither would be second best.
>>>
>>     I'm _very_ glad you care which is "second best!"
>>
>>     I went into last week's session quite prepared to accept either, both
>> or neither. I came out unwilling to support _either_ as MTI.
>>
>>     This is mostly because I came to understand the "cisco" postition.
>>
>>     (Please excuse me for assigning names to the two main positions, but
>> it will make the discussion _much_ simpler.)
>>
>>     The "cisco" position is:
>>
>> - look at all the H.264 hardware out there: we must make use of it;
>> - if VP8 is MTI, we'll get sued and our customers will get hassled.
>>
>>     The "linux" position is:
>>
>> - look at all the VP8 software out there: we must make use of it;
>> - if H.264 is MTI, we'll get sued and our customers will get hassled.
>>
>>     And, alas, they're both right.
>>
>>     What I didn't understand before the presentations was why Cisco
>> believes they'll get sued over VP8, but not H.264.
>>
>>     Basically H.264 has quite a consortium to slap down the likes of
>> Nokia in court should they sue anyone in the consortium. This greatly
>> reduces the chance of Nokia's lawyer suing.
>>
>>     But this consortium won't lift a finger if Nokia sues Cisco over
>> VP8. Cisco is a _very_ attractive target over VP8.
>>
>>     Thus, Cisco management would _very_much_ prefer that VP8 _not_ be
>> MTI. They probably won't implement it.
>>
>>     Conversely, of course, "linux" management would _very_much_ prefer
>> that H.264 not be MTI. They probably won't implement it.
>>
>>     Understanding this, I now strongly recommend against making either
>> H.264 or VP8 MTI. (And I will not consent to a RFC 3929 process limited
>> to choosing between them.)
>>
>>     This issue has dragged on long enough already. We need to start
>> reading the riot act to the folks who claim we "need" either of these
>> as MTI in order to have "satisfied" users.
>>
>>     Both H.264 and VP8 deserve "SHOULD implement" status. Neither,
>> IMHO, will achieve consensus for "MUST implement" status. Yes, this
>> is a sorry state to find ourselves in. But the marketplace has
>> sorted out much worse problems in my memory.
>>
>>     And I claim that both camps are actually more likely to implement
>> (or allow extensions for) the other side's codec if it is _not_ MTI,
>> simply because they can back out at the first sign of lawyers.
>>
>>     I will not go into any details about how VP8 endpoints might talk
>> to H.264 endpoints, but I'm _very_ confident ways will be found if
>> we actually _publish_ an RFC saying both are "SHOULD implement".
>>
>>     (Surely I'm not the _only_ person who'd like to see _both_ H.264
>> and VP8 legacy devices using our standard...)
>>
>> --
>> John Leslie <john@jlc.net>;
>> _______________________________________________
>> 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
>