Re: [codec] Summary of codec specification - Code in RFC

Stephan Wenger <stewe@stewe.org> Sat, 02 October 2010 22:32 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 927683A6D8B for <codec@core3.amsl.com>; Sat, 2 Oct 2010 15:32:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.655
X-Spam-Level:
X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.944, 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 XJCz-agpSDj3 for <codec@core3.amsl.com>; Sat, 2 Oct 2010 15:32:00 -0700 (PDT)
Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 989B83A6C73 for <codec@ietf.org>; Sat, 2 Oct 2010 15:31:59 -0700 (PDT)
Received: from [192.168.1.105] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 803318-1743317 for multiple; Sun, 03 Oct 2010 00:32:48 +0200
User-Agent: Microsoft-Entourage/12.26.0.100708
Date: Sat, 02 Oct 2010 15:32:29 -0700
From: Stephan Wenger <stewe@stewe.org>
To: "fluffy@cisco.com" <fluffy@cisco.com>, codec@ietf.org
Message-ID: <C8CD010D.24D11%stewe@stewe.org>
Thread-Topic: [codec] Summary of codec specification - Code in RFC
Thread-Index: ActigbIwpTZPpnVQuUuLt3zCCYQomg==
In-Reply-To: <070D11DD-137C-42F7-B5E0-21DB8704A4E1@cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
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] Summary of codec specification - Code in RFC
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: Sat, 02 Oct 2010 22:32:01 -0000

As said before, putting base64 code into an RFC makes sense to me.  However,
I would definitely put it into its own RFC (which would be standards track)
and not into an appendix of the same document.  The versioning problem seems
to be less an issue than the trees that will fall if people "print all" the
RFC in question.  So please leave the textual description in another
document.  

Logic suggests that this "human readable" document would be informational,
as the code RFC prevails in case of errors.  However, I don't mind being
slightly illogical here and call it standards track as well.  The document
could also certain code pieces in such cases where a textual description in
English with ASCII fixed width fonts may be to cumbersome.

Someone mentioned the "errata" process for fixing errors.  That process is
not going to work overly well with an base64 encoded zip file... But I don't
consider that a major problem--rather an incentive to get our stuff right
the first time.

Stephan



On 10.2.2010 13:21 , "fluffy@cisco.com" <fluffy@cisco.com> wrote:

> 
> There been a bit of discussion suggesting that we should put into the draft
> both the machine readable base 64 version in that is easy to extract, and a
> version in human readable text that is easy for people to read. This seems
> like a reasonable idea to me. Just to get a rough idea of what this would look
> like, I took the current GIT repository and had a look at the code in it. It'
> a bit over 50k lines including both encoder and decoder. You get 48 lines of
> real text per page of RFC so the human readable version would be over a 1000
> pages. If you take the code, tar it, gzip it, and base64 encode it, you get a
> bit over 180 pages. This sounds big but given it's some bits on a web server,
> I don't particularly see any problem with it. I also have no idea how the
> repository compares to what would be needed to specify the normative parts of
> the decoder. I may have including in the 50k lines of code all kinds of stuff
> that was not needed.
> 
> Cullen
> 
> 
> On Oct 2, 2010, at 8:28 AM, Cullen Jennings wrote:
> 
>> 
>> On Oct 1, 2010, at 11:27 AM, Cullen Jennings wrote:
>> 
>>> 1) The code will be in the appendix of the draft base64 encoded. We can sort
>>> out later if it is gziped tar file of whatever but it will be some easy to
>>> extract format. This has been done on other documents. I have talked to the
>>> AD about this before. I have not talked to RFC Ed but do not foresee any
>>> issues there. 
>> 
>> 
>> I'd like to encourage people interested in this point to look at Appendix B
>> of RFC 4474. 
>> 
>> http://tools.ietf.org/rfc/rfc4474.txt
>> 
>> _______________________________________________
>> codec mailing list
>> codec@ietf.org
>> https://www.ietf.org/mailman/listinfo/codec
> 
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec