Re: [codec] WGLC #2 for draft-ietf-codec-opus-10

"Christian Hoene" <hoene@uni-tuebingen.de> Thu, 17 November 2011 09:33 UTC

Return-Path: <hoene@uni-tuebingen.de>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266B121F9935 for <codec@ietfa.amsl.com>; Thu, 17 Nov 2011 01:33:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.294
X-Spam-Level:
X-Spam-Status: No, score=-4.294 tagged_above=-999 required=5 tests=[AWL=1.955, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 I7DqMx6Rq--j for <codec@ietfa.amsl.com>; Thu, 17 Nov 2011 01:33:06 -0800 (PST)
Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by ietfa.amsl.com (Postfix) with ESMTP id C599421F993E for <codec@ietf.org>; Thu, 17 Nov 2011 01:33:05 -0800 (PST)
Received: from hoeneT60 (u-173-c040.cs.uni-tuebingen.de [134.2.173.40]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id pAH9WkUM028634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Nov 2011 10:32:58 +0100
From: Christian Hoene <hoene@uni-tuebingen.de>
To: 'Ron' <ron@debian.org>, codec@ietf.org
References: <4EAF4419.3000502@jdrosen.net> <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> <4EC28796.5090502@fas.harvard.edu> <027A93CE4A670242BD91A44E37105AEF3BB9FEEC3F@ESESSCMS0351.eemea.ericsson.se> <011701cca44b$b525d640$1f7182c0$@uni-tuebingen.de> <20111116191814.GF765@audi.shelbyville.oz>
In-Reply-To: <20111116191814.GF765@audi.shelbyville.oz>
Date: Thu, 17 Nov 2011 10:32:58 +0100
Organization: Universitat Tubingen
Message-ID: <00b401cca50b$ec086c20$c4194460$@uni-tuebingen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGdnFS6OFAQH0NkTgh2ZlsqwZro7AGUNOupAij5lN0BmDDfUwGte1jAAemny8qVx3VgYA==
Content-Language: de
X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.23; spam filter version: 3.2.0/2.3; host: mx05)
X-AntiVirus: checked by Avira MailGate (version: 3.2.1.23; AVE: 8.2.5.34; VDF: 7.11.10.215; host: mx05); id=26634-VWQ9Ty
Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 17 Nov 2011 09:33:07 -0000

Hi Ron,

> On Wed, Nov 16, 2011 at 11:37:12AM +0100, Christian Hoene wrote:
> > Hi,
> >
> > I would suggest to split two things:
> >
> > First, we need a notion for standard conformance because of the legal
IPR
> > requirements (can be more relaxing).
> > Second, we need some tests in respect to interoperability (should be
more
> > straight).
> >
> >  Both tests need to fulfill different requirements.
> 
> I don't see these as different requirements at all.
> 
> The IPR in this case is not being used to protect a revenue stream
garnered
> from unwitting users of the technology - it is being used to protect the
> interoperability guarantees that can be offered to end users.

[Christian Hoene] Sorry, this would be the first standard (that I am aware
of) that you can be suited for a standard implementation that is not
interoperability - no matter whether it is intentionally or not just a bug.
Sorry, but if having bugs in software implementations is not allowed we will
have any software at all. Each complex software product has bugs. 

If you can be charged for every bug in your Opus implementation that limits
interoperability, then using Opus will become more expensive as there might
be a risk that you have to pay royalties. Insuring this risk is costly.

Also, too strict rules would limit any technology progress. This should be
avoided in any case.

With best regards,

 Christian