[rfc-i] Embedding stuff (code, etc.) in RFCs

Riccardo Bernardini framefritti at gmail.com
Sat Jul 13 01:53:04 PDT 2013


On Fri, Jul 12, 2013 at 10:16 PM, Paul Hoffman <paul.hoffman at vpnc.org> wrote:
> On Jul 12, 2013, at 1:08 PM, Nico Williams <nico at cryptonector.com> wrote:
>
>> On Fri, Jul 12, 2013 at 1:33 PM, Paul Hoffman <paul.hoffman at vpnc.org> wrote:
>>> Is the problem statement:
>>>   Some RFCs have stuff (code, etc.) inline, and it would be useful for a reader
>>>   to be able to get it easily without having to unindent, remove page breaks,
>>>   split into separate files, and so on?
>>>
>>> If so, a simple solution would be "the stuff (code, etc.) in this RFC can be found at http://www.rfc-editor.org/rfc-stuff/rfc7890.tgz". The URL would be canonical, the response one gets when resolving it would not be, just as is the response one gets for other non-canonical stuff like PDF versions of RFCs.
>>
>> We'd have to include a cryptographic (SHA-2, say) hash of the tarball.
>
> Works for me.
>
>> RFC5662 should be the canonical RFC *today* for code extraction.
>
> +1
>

Let me emphasize that there are not many differences between the
RFC5662 approach and mine: in both cases we mark each line to be
extracted with a special punctuation: /// in RFC5662, "!." and "!," in
mine.  It is true that the RFC5662 is simpler and it requires only a
shell line for extraction; however, the RFC5662 approach

  * cannot handle more than one file
  * cannot handle lines longer than 60-something characters
(considering the margin and the marker)
  * cannot handle non-7-bit octects

Those limitations were not a problem in RFC5662 because of the
specific nature of the files to be extracted.  If we want a system
that is general enough to be used in a reasonable variety of cases,
you need a way to handle the cases above and this makes the format
more complex: the first issue requires to introduce a "begin marker"
with the filename, the second issue requires the introduction of
different markers to denote a continuation line, the third issue
requires an escaping mechanism.  As you can see, given the requirement
of being general, the proposed format is quite minimal.

Riccardo

> But the RFC Editor should consider the tarball approach as well for thing that are not as code-y, such as ABNF, XML, and so on.
>
> --Paul Hoffman
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest


More information about the rfc-interest mailing list