Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible?

Stephan Wenger <stewe@stewe.org> Tue, 25 January 2011 03:59 UTC

Return-Path: <stewe@stewe.org>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5E23A6B6C for <codec@core3.amsl.com>; Mon, 24 Jan 2011 19:59:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.125
X-Spam-Level:
X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIElawaFVyeL for <codec@core3.amsl.com>; Mon, 24 Jan 2011 19:59:26 -0800 (PST)
Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 5CFCD3A6A16 for <codec@ietf.org>; Mon, 24 Jan 2011 19:59:26 -0800 (PST)
Received: from [192.168.1.106] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 55441-1743317 for multiple; Tue, 25 Jan 2011 05:02:18 +0100
User-Agent: Microsoft-MacOutlook/14.2.0.101115
Date: Mon, 24 Jan 2011 20:02:12 -0800
From: Stephan Wenger <stewe@stewe.org>
To: codec@ietf.org, gmaxwell@juniper.net
Message-ID: <C963872D.26A05%stewe@stewe.org>
Thread-Topic: [codec] requirements #12 (closed): bit-exact vs. bit-compatible?
In-Reply-To: <071.de3a02a9da3e01eafb66a41ba319b0e6@tools.ietf.org>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Originating-IP: 24.5.132.232
X-Authenticated-User: stewe@stewe.org
X-ORBS-Stamp: Your IP (24.5.132.232) was found in the spamhaus database. http://www.spamhaus.net
Subject: Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2011 03:59:27 -0000

Hi all:

Let me speak once more against this decision (if such a decision were
really made; see the p.s.).

There are currently three IPR disclosures against the codec draft and/or
its predecessors.  The Xiph disclosure is at this point a placeholder
(Xiph folks: it's time to fix that!).  However, the two other disclosures
on file provide a patent grant only for necessary patent claims and only
when the standard is practiced in full compliance.  These terms (in
various formulations) are quite common.

In order to ensure one has a license (or can rely on a non-assert
covenant), one has to ensure one meets the conditions set by the
rightholder.  On stuff such as reciprocity clauses this is simple.  On
compliance, it's not always easy.

The traditional compliance test for a media codec is a stimulus-response
test: you feed test vectors into the codec, and you get results.  If the
results match, you are in compliance, if not, you are not.  Simple.

Without bit exactness, the compliance criteria have to be defined
differently.  We can do so, and, indeed, I recall that this has been
mentioned as one plan forward.  However, I have seen zero activity in this
direction, and I have also not seen any language that mentions this in the
requirements draft.  I think that the subject of compliance tests, at
least in its most basic outline, needs to be documented in the
requirements draft.  The details can be taken care of elsewhere and later,
but not too much later.  It should be clear that a codec candidate (if
there were more than one) needs to have compliance criteria defined before
that codec candidate can become an RFC.  Without that, the key goal of the
WG, a reasonably freely practicable codec, is just not achievable in the
current legal environment (which includes, in this case, the IPR
disclosures on file).

Of course, it would be sooooo much simpler if we would mandate a bit exact
decoder...  Is it really that restricting to require that?

Stephan

P.s.: for the IETF procedures newcomers: humms taken at meetings need to
be confirmed on a mailing list, and consensus needs to be declared by the
chairs.  On this subject, I do recall mailing list discussions after
Maastricht, but I do not recall that consensus was reached, yet alone
declared.  (Unfortunately, I currently don't have the time to go through
the mailing list archives to verify my recollection; Sorry.)
 


On 1.24.2011 16:45 , "codec issue tracker" <trac@tools.ietf.org> wrote:

>#12: bit-exact vs. bit-compatible?
>
>Changes (by gmaxwell@Š):
>
>  * status:  new => closed
>  * resolution:  => worksforme
>
>
>Comment:
>
> http://www.ietf.org/proceedings/78/minutes/codec.txt
>
> "On the topic of bit exact. Consensus was bit exactness is not required."
>
> I believe this issue is already closed.
>
>-- 
>------------------------------------+-------------------------------------
>--
> Reporter:  hoene@Š                 |        Owner:
>     Type:  enhancement             |       Status:  closed
> Priority:  minor                   |    Milestone:
>Component:  requirements            |      Version:
> Severity:  Active WG Document      |   Resolution:  worksforme
> Keywords:                          |
>------------------------------------+-------------------------------------
>--
>
>Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/12#comment:1>
>codec <http://tools.ietf.org/codec/>
>
>_______________________________________________
>codec mailing list
>codec@ietf.org
>https://www.ietf.org/mailman/listinfo/codec