Subject: [codec] Summary of codec specification

From: Cullen Jennings <[email-masked]>
Date: Fri, 1 Oct 2010 11:27:06 -0600

With my chair hat on, here are thing thing I believe we have consensus on to move forward on.

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. 

2) The code will be under the simplified BSD license as specified by current IETF process documents and most importantly the IETF Trust Licensee Policy. (As a side note, this is not a topic that is debatable in this WG - if you want to change IETF process, go somewhere else)

3) We have rough consensus that where the code and the text version description of the algorithm disagree, the code version is the one that is "correct"

4) The chairs have not yet made any decision about if we have consensus on bit-exactness. I'm not 100% sure where we stand on this but given we are in doubt on this, there is no consensus yet. 

5) The chairs have not made any decisions about if we have consensus on characterization gating. See logic around #4. 

Once we have a WG guidelines document, we as a WG can make sure it represents what is and is not consensus - something we can't do for an individual draft. Given the discussion over the last week, we are probably going to  adopt draft-valin-codec-guidelines as the basis for the WG document  some time real soon now. The chairs need to have a few more conversations about this first. It's would be fine at this point in time for a WG draft on guidelines to have proposed text in it that did not yet have consensus but it should clearly state they did not have consensus and was simply proposed text. 

Cullen <CODEC Co-Chair> - That's a lot of "C"s

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 2 Oct 2010 08:28:35 -0600

> 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 d…

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

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 2 Oct 2010 14:21:57 -0600

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:

> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 02 Oct 2010 15:32:29 -0700

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 , "[email-masked]" <[email-masked]> 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
> 
> 
>>> 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. 
>> 
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 02 Oct 2010 18:44:48 -0400

I have serious problems with a standards track RFC whose normative 
content can not be read by a human being without additional tools.
I also have serious conceptual problems with an RFC whose normative 
content, in human readable form, is 1,000 pages.

I am not objecting to publishing code in RFCs.  That is something we do 
frequently.  I am not even objecting to including base64 encoded gzip 
code, as informational appendices in an RFC.
However, it seems to me that treating base64 gzip code as normative in 
an RFC is distinctly bending the rules for RFC publication.  That text 
can not be editted by the RFC Editors.  It can not be subject to 
erratta.  And it can not be read as meaningful plain ascii according to 
the spirit of our publication rules.

Yes, we have once in a great while published RFCs with tables on the 
order of this long.  It was difficult, but in fact the content was 
carefully reviewed.

Yours,
Joel M. Halpern

PS: If the code were a reasonable length, publishing the text of the 
code as normative, and the base64 gzip as informative would seem to me 
to be a very good way to have clear normative code in an RFC while 
making it easy to use the code.

On 10/2/2010 6:32 PM, Stephan Wenger wrote:
> On 10.2.2010 13:21 , "[email-masked]"<[email-masked]>  wrote:
>
>>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 5 Oct 2010 11:49:43 +0200

> RFC in question.  So please leave the textual description in another

FWIW, this was the approach we followed with the XDR code for NFS 4.1: RFC 5661 has the spec text and RFC 5662 has the XDR (in this case, as plain text).

Lars

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 13 Oct 2010 12:00:06 -0600

These all seem like good points. Let's see if we can figure out a way to do plain text split across two drafts and follow the XDR model. 

On Oct 2, 2010, at 4:44 PM, Joel M. Halpern wrote:

> I have serious problems with a standards track RFC whose normative content can not be read by a human being without additional tools.
> I also have serious conceptual problems with an RFC whose normative content, in human readable form, is 1,000 pages.
> 
> I am not objecting to publishing code in RFCs.  That is something we do frequently.  I am not even objecting to including base64 encoded gzip code, as informational appendices in an RFC.
> However, it seems to me that treating base64 gzip code as normative in an RFC is distinctly bending the rules for RFC publication.  That text can not be editted by the RFC Editors.  It can not be subject to erratta.  And it can not be read as meaningful plain ascii according to the spirit of our publication rules.
> 
> Yes, we have once in a great while published RFCs with tables on the order of this long.  It was difficult, but in fact the content was carefully reviewed.
> 
> Yours,
> Joel M. Halpern
> 
> PS: If the code were a reasonable length, publishing the text of the code as normative, and the base64 gzip as informative would seem to me to be a very good way to have clear normative code in an RFC while making it easy to use the code.
>