[rfc-i] draft-iab-streams-headers-boilerplates-06 : overlooked details?

Joe Touch touch at ISI.EDU
Sun Feb 1 13:22:35 PST 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Julian Reschke wrote:
> John C Klensin wrote:
>  > ...
>> But those changes and the relationship it implies between RFCs
>> and I-Ds means that there is no such thing as "things that the
>> RFC Editor will need ... to create the appropriate boilerplate".
>> Unless I completely misunderstand how the RFC Editor staff works
>> these days, if the RFC Editor needs to create boilerplate, paste
>> it in, and structure the text to include it, we are back to
>> significant manual processing in nroff... and we are back to the
>> point at which an RFC format cannot be produced directly from
>> XML, that the XML->HTML pieces of those tools cannot accurately
>> render an RFC, and probably that those who are revising
>> documents cannot start with the XML form of the RFC and easily
>> convert back to I-D format.  All of those things are possible
>> and convenient today.
>> ...
> 
> Indeed.
> 
> As one of the tool implementors, what I'm looking for is:
> 
> - stability  (if we revise the RFC boilerplate, can we *please* do that 
> to I-D boilerplate at the *same* point of time?) (*)
> 
> - clear instructions

To that end, a finite set of alternatives is better than a program that
a human has to decode. As I noted before, the idea of "here's the core,
now include this IF, and this ELSE, and maybe this optionally" is insane.

Simple ought to be sufficient. If there are more than 10 cases (as a far
upper bound), you did it wrong, IMO.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmGEpsACgkQE5f5cImnZru8TACfbohRciQyhQB9KTsrNIDq835U
LHMAmwVeOSUuGgvBK/8g/q8AqRnkwKkV
=ATOP
-----END PGP SIGNATURE-----


More information about the rfc-interest mailing list