Re: [codec] Last Call: <draft-ietf-codec-oggopus-10.txt> (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard

Jean-Marc Valin <jmvalin@jmvalin.ca> Thu, 28 January 2016 21:29 UTC

Return-Path: <jmvalin@jmvalin.ca>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3385D1A9083 for <codec@ietfa.amsl.com>; Thu, 28 Jan 2016 13:29:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsysI3bBUE6H for <codec@ietfa.amsl.com>; Thu, 28 Jan 2016 13:29:17 -0800 (PST)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6CD71A9092 for <codec@ietf.org>; Thu, 28 Jan 2016 13:29:14 -0800 (PST)
Received: by mail-qg0-x230.google.com with SMTP id e32so50812108qgf.3 for <codec@ietf.org>; Thu, 28 Jan 2016 13:29:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jmvalin-ca.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=aesi8DDOW0+XuszbIlqbzberYRys7YAw+ZNUy8Iog+Q=; b=EmNcCTHQTyTmxppg89+pJq8ZM64EGx/mlM9hIiWJVoILIOM3pVKwjBk/mHt0fymg8k FXFHcNKW1wqlzsPDdwRY/VsysYZaYsp2/tPYi1LGylRixbyyzdS1cDvoK2O2wPccqS0l f4r7QMI9zczq0c0ZAn8uGcbDZ0n+VxPJYcFNdLnJLXbrtqsapKoZe9jaXaJa5wnW8EKo OjJGYBnB7zGkwWCbAVcdVJiVz2NU9UMiy7JQTHWnMY5zYusqSKrO8Kp7ujCg4Aw4hG8M C88CsHkw3mSpelo0lDmd5xTWLBbpkj5sJ+02wZfeRrtPnn/e0lMt3mUjYwhQScqT4Ljh EDBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=aesi8DDOW0+XuszbIlqbzberYRys7YAw+ZNUy8Iog+Q=; b=keCpIFfupy3MhPHEKapNOzFiA8Xp+N0f7tmKnUnEq9de2diCpRfCZyexHewEoDsRvE 4a1GpLb9/beYkmfl29IQVQv1NW6k9WKTRmqP+FzLRvixwtkiavuimwnSOkvjIqPRFB7C NKV7YJoUirTl5R5wTj7sq3GfkNOqLtJrChTq5nXO/4WwMCuYoPunTfc4MVCc7/9HhT2Q YqBd7aF4dcsTTZD9r6exdkWrhSNeRfj4OzjRRkqPyv1BkNK4mUhb8mSrIs+YQS7WPpXR AXN3qLMX6zGP37juoNqmuqp/aT/nwNKkEnftfq5ETCbYLyYvNuY6/mDlRbZU4QZafiKu k9DA==
X-Gm-Message-State: AG10YORKz/m/WaSfxTFeBXHV84nNZZ0zs/d7KwsVwXYR6DErsbMmFpU9eduoANF/vI8fNw==
X-Received: by 10.140.217.67 with SMTP id n64mr6965186qhb.26.1454016553818; Thu, 28 Jan 2016 13:29:13 -0800 (PST)
Received: from panoramix.jmvalin.ca (modemcable121.240-21-96.mc.videotron.ca. [96.21.240.121]) by smtp.gmail.com with ESMTPSA id r7sm5316559qhc.38.2016.01.28.13.29.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jan 2016 13:29:13 -0800 (PST)
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Jean-Marc Valin <jmvalin@mozilla.com>, Ben Campbell <ben@nostrum.com>
References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <EF7A1BC5-B0E9-4787-95D2-D60B590E26DB@nostrum.com> <56AA78C9.9030304@joelhalpern.com> <56AA811F.8010201@mozilla.com> <56AA8310.2010300@joelhalpern.com>
From: Jean-Marc Valin <jmvalin@jmvalin.ca>
X-Enigmail-Draft-Status: N1110
Message-ID: <56AA8828.2050008@jmvalin.ca>
Date: Thu, 28 Jan 2016 16:29:12 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <56AA8310.2010300@joelhalpern.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/codec/skinsaaTLAhc8MgNoqBdZHgp5IU>
Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org, ietf@ietf.org
Subject: Re: [codec] Last Call: <draft-ietf-codec-oggopus-10.txt> (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 28 Jan 2016 21:29:19 -0000

On 01/28/2016 04:07 PM, Joel M. Halpern wrote:
> So either the open source communities needs to be able to change the
> text, or it does not need to be able to change the text, or it has
> created rules for itself where it needs to be permitted to change the
> text even though it does not actually want to change.
> 
> The first, not changing the text, is already covered.
> The second, changing the text, is not something I or the IETF community
> support.

It depends on your definition of "changing the text". There's a lot of
pretty reasonable changes you can make to get the RFC text to better fit
within a new document without changing the meaning. Any of these sure
beats "paraphrasing a section of the RFC" from a compatibility point of
view.

> The third would seem to be a different problem, and asking the IEtF to
> change its rules for that seems a VERY strange answer.

There's certainly a bit of that as well. But keep in mind there's no
"chair of the open source community" who can change all the rules.

Cheers,

	Jean-Marc

> Yours,
> Joel
> 
> On 1/28/16 3:59 PM, Jean-Marc Valin wrote:
> On 01/28/2016 03:23 PM, Joel M. Halpern wrote:
>>>> I think that this is a very bad idea.  The point of doing the work
>>>> to create an RFC is to reach agreements on what the words should
>>>> be. Saying after that "oh, but anyone else can change these words
>>>> any way they want" just does not work for me.
> 
> The main issue here is not that people would like to change what the
> RFC says. It's quite the opposite in fact. People would like to be
> able to reuse parts the RFC text in other contexts (e.g. documentation
> for a piece of software that relies on several RFCs). Without
> additional rights, they would have to paraphrase the content of RFCs,
> which would actually lead to more compatibility problems. Also, the
> proposed text already includes the condition "provided that no such
> derivative work shall be presented, displayed, or published in a
> manner that states or implies that it is part of this RFC or any other
> IETF Document". Given that, I'm not sure what the problem is.
> 
> Cheers,
> 
>     Jean-Marc
>>
> 
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec