Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

Ted Hardie <> Fri, 05 December 2014 19:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AF9A01AD7BE for <>; Fri, 5 Dec 2014 11:55:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LKCdD5g-kXK9 for <>; Fri, 5 Dec 2014 11:55:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F131E1AD791 for <>; Fri, 5 Dec 2014 11:55:19 -0800 (PST)
Received: by with SMTP id h15so1327851igd.13 for <>; Fri, 05 Dec 2014 11:55:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oCr7muizNnbvjmXrEr78dFL/pt946Ov2k772SjXSYcQ=; b=SMQNLz/IGHpw52FVX4aGOif7Oas1oIG2tkgKvKVtKg97WvLOcvGaCkulbl8JapY66d dFBhjbwivT50f5VX05fqdLcWBlpSMVyfLBbbJ2YE4ECFuSR7OsnpQ8KvP3a04o8E4d02 8IkH8hG+2kgBxSVwQqsTDW8sD/RPDTaKCd/Fw8hgHvbMgi3IuYjeuG66dQWuiH2vQV6e bMRsJBjLwzXdNXMQBjb/jtqYXqRexpBkFXvEGOdcNHfx8EKgLHAgKvt2/0Ob3Mh7mckL Jyi0O4yCrW/hmfmjaZDSPMBtp1Hjtbvn5IX/b9aie+PoMN5jMtPPGnF6rhrcuHYVNgrH XPfQ==
MIME-Version: 1.0
X-Received: by with SMTP id mm17mr17021116icb.18.1417809318397; Fri, 05 Dec 2014 11:55:18 -0800 (PST)
Received: by with HTTP; Fri, 5 Dec 2014 11:55:18 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <20141205035706.GB21150@hex.shelbyville.oz> <>
Date: Fri, 5 Dec 2014 11:55:18 -0800
Message-ID: <>
From: Ted Hardie <>
To: David Singer <>
Content-Type: multipart/alternative; boundary=20cf3036404fc86ed305097d744e
Cc: "" <>
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Dec 2014 19:55:22 -0000

Hi David,

On Fri, Dec 5, 2014 at 11:11 AM, David Singer <> wrote:

> There is a formal notice from a company that they believe they hold IPR
> and they are unwilling to license. You and I can dislike the situation,
> dislike patent law, dislike the procedures, or anything else, as much as we
> wish, it doesn’t change them.
> For the IETF to insert a MUST into a specification it is instructing
> companies,

​This is fundamentally incorrect.  The IETF writes voluntary standards.  A
MUST in an IETF standard is not an instruction to a company; it is a
description of the expected behaviour of an interoperable implementation.
You are not required to implement the standard at all.  At most, it is a
description of what someone who claimed compliance to the standard is
expected to have done.

And note, "is expected" here has exactly no regulatory force; it is "is
expected" by other interoperable implementations.​

> based on no visible analysis, and (unfortunately, since the German case
> closed without a clear answer) no formal judgment, to defy the claim and
> risk suit.

​The IETF, as a body, does not undertake those analyses.  Working group
members may undertake them when deciding whether to implement the standard.​

> That is clearly formally inappropriate.  The most we should do is to use a
> term from RFC 6919 (I’d suggest sections 1 or 6).
​April 1 RFCs are an amusing lot, aren't they?  ​

​The proposed compromise contains multiple methods for handling the risk
you believe present:  choose not to implement the standard; choose a
different level compliance (endpoint); choose to accept the offer of a
binary solution provided by others (as have put forward by both Cisco and
Google).  The sense of the room (as I heard it as participant from the
floor) was that there were lots of people who could work with this
compromise, those methods, and their perception of the risk.

You are absolutely free to perform what risk analysis you like and to take
whatever risk avoidance​ steps you deem appropriate.  That might, sadly,
mean you remain on the sidelines as WebRTC moves forward.  Whatever your
choices there, please represent the IETF process correctly as you do so.


Ted Hardie
as an individual

> David Singer
> Manager, Software Standards, Apple Inc.
> _______________________________________________
> rtcweb mailing list