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

["Joel M. Halpern" <[e-mail]>]

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:
> 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 , "[e-mail]"<[e-mail]>  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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/codec
>>
>> _______________________________________________
>> codec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/codec
>
>
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>