Re: [codec] draft test and processing plan for the IETF Codec

Anisse Taleb <anisse.taleb@huawei.com> Mon, 18 April 2011 22:08 UTC

Return-Path: <anisse.taleb@huawei.com>
X-Original-To: codec@ietfc.amsl.com
Delivered-To: codec@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6F4E5E06E3 for <codec@ietfc.amsl.com>; Mon, 18 Apr 2011 15:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.099
X-Spam-Level:
X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4NANt-y81go for <codec@ietfc.amsl.com>; Mon, 18 Apr 2011 15:08:35 -0700 (PDT)
Received: from lhrga04-in.huawei.com (lhrga04-in.huawei.com [195.33.106.149]) by ietfc.amsl.com (Postfix) with ESMTP id 7E4FCE06A4 for <codec@ietf.org>; Mon, 18 Apr 2011 15:08:35 -0700 (PDT)
Received: from huawei.com (localhost [127.0.0.1]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJV00931C67P0@lhrga04-in.huawei.com> for codec@ietf.org; Mon, 18 Apr 2011 23:08:31 +0100 (BST)
Received: from LHREML202-EDG.china.huawei.com ([172.18.7.118]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LJV009WOC67FX@lhrga04-in.huawei.com> for codec@ietf.org; Mon, 18 Apr 2011 23:08:31 +0100 (BST)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.31) by LHREML202-EDG.china.huawei.com (172.18.7.189) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 18 Apr 2011 23:08:26 +0100
Received: from LHREML503-MBX.china.huawei.com ([fe80::f93f:958b:5b06:4f36]) by LHREML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Mon, 18 Apr 2011 23:08:30 +0100
Date: Mon, 18 Apr 2011 22:08:29 +0000
From: Anisse Taleb <anisse.taleb@huawei.com>
In-reply-to: <4DA5D328.3060504@stpeter.im>
X-Originating-IP: [10.200.217.213]
To: Peter Saint-Andre <stpeter@stpeter.im>, Erik Norvell <erik.norvell@ericsson.com>
Message-id: <F5AD4C2E5FBF304ABAE7394E9979AF7C26BC8AF9@LHREML503-MBX.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"
Content-language: en-US
Content-transfer-encoding: 7bit
Accept-Language: en-GB, en-US
Thread-topic: [codec] draft test and processing plan for the IETF Codec
Thread-index: AQHL/hUl6ghYn5UVbUaF9H5fCjdnBA==
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: <F5AD4C2E5FBF304ABAE7394E9979AF7C26BC684E@LHREML503-MBX.china.huawei.com> <4DA5A748.2050401@fas.harvard.edu> <027A93CE4A670242BD91A44E37105AEF17ACA9B583@ESESSCMS0351.eemea.ericsson.se> <4DA5D328.3060504@stpeter.im>
Cc: "bens@alum.mit.edu" <bens@alum.mit.edu>, "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] draft test and processing plan for the IETF Codec
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: Mon, 18 Apr 2011 22:08:36 -0000

> We knew when we started this process that there might be encumbrances.
> We even knew that there might be unreported encumbrances that would
> emerge only after the codec was published as an RFC, or only after the
> code was in use by companies who would be big targets for patent
> lawsuits. I see no reason to delay publication until all possible
> encumbrances have been resolved, whatever that means (as we all know,
> patent claims are not resolved at the IETF, they are resolved in courts
> of law).

I am unsure I understand this, publishing the codec while there are known encumbrances is against my understanding of what the WG goals are. These have to definitely be resolved first. The codec has to be thoroughly tested and characterized especially for internet applications...otherwise what the codec WG would have succeed in producing is an encumbered codec with no evidence of its suitability for internet applications...