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

[Cullen Jennings <[e-mail]>]

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.
> 
> 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
>>