Re: [rtcweb] non-standard codecs

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Mon, 30 July 2012 15:08 UTC

Return-Path: <keith.drage@alcatel-lucent.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 C599321F8809 for <rtcweb@ietfa.amsl.com>; Mon, 30 Jul 2012 08:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.78
X-Spam-Level:
X-Spam-Status: No, score=-109.78 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 vykowj0LRCR4 for <rtcweb@ietfa.amsl.com>; Mon, 30 Jul 2012 08:08:14 -0700 (PDT)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id AA3A321F8687 for <rtcweb@ietf.org>; Mon, 30 Jul 2012 08:08:13 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6UF869c005645 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Jul 2012 17:08:07 +0200
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 30 Jul 2012 17:07:46 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Mon, 30 Jul 2012 17:07:45 +0200
Thread-Topic: [rtcweb] non-standard codecs
Thread-Index: Ac1uW1Vw123CV0UiSYKQEgCIqES9EgABp4ww
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE240B54828@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <BLU401-EAS256F60C698A939735A4597593C60@phx.gbl>
In-Reply-To: <BLU401-EAS256F60C698A939735A4597593C60@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84
Subject: Re: [rtcweb] non-standard codecs
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: Mon, 30 Jul 2012 15:08:14 -0000

There are several things here in this mail that many other standards organizations would find objectionable, if the statement "not under IETF change control" is meant to apply to anything not produced by IETF. 

There is nothing special about an RFC or indeed IETF in this respect.

1)	The drafting rules for all standards organizations I know of make provision for references to be of two types, of a reference to a specific version or publication date, or of a reference to a more generic standard number. As a result of this, prior versions of standards continue to be available, sometimes with a better history of preservation that some of the earlier IETF RFCs.

Therefore if IETF makes a reference to one of these specific versions, they have complete control over change. They can either decide to update the reference at some point in the future or decide not to. It is the reference that provides the change control, not the referenced document.

This is exactly the same process they will have to go through if a referenced RFC gets updated with improvements or corrections. The later version of an RFC does not automatically apply.

2)	While the IPR disclosure rules for IETF may be worded differently, they are in general no different to any other standards organizations. IETF rules do not guarantee FRAND availability, nor do those of any other standards organizations.

IETF in making the reference needs to identity any known IPR and decide whether that is a barrier to progressing the RFC with that reference or not. It has to do that whether it is an IETF reference or a reference elsewhere.

Regards

Keith


> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> Of Bernard Aboba
> Sent: 30 July 2012 14:58
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] non-standard codecs
> 
> There are several reasons why it would be imprudent to seriously consider
> a non-standard codec as mandatory-to-implement:
> 
> A. Change control. Normatively referencing a document not under IETF
> change control as mandatory-to-implement means that a core aspect of the
> standard would be subject to change without IETF review.
> 
> B. FRAND status. SDO IPR policies (and legal precedents) confer important
> benefits to documents that have gone through a standards process. Without
> this, potential IPR claims have no upper bound.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb