[rfc-i] [IAB] Wrapup of Fwd: Comment on headers-and-boilerplates

Olaf Kolkman olaf at NLnetLabs.nl
Fri Jan 23 03:24:02 PST 2009

On Jan 16, 2009, at 8:15 PM, John C Klensin wrote:
>> IMHO only the stream-definition would be checked at submission.
>> It is during the publishing phase that, based on stream and
>> category, boilerplate material is constructed (so this would
>> be a RFC-Publisher responsibility, as part making the RFC text
>> consistent with the RFC Style manual, and the RFC series).

Rereading this again I notice that the above should have read  
Production Center.

> But we have been pushing very hard, with some success, to have
> the RFC Editor function use the same tools that authors use.  It
> would be a major setback to that approach if the RFC Editor
> function had to take a document in xml2rfc form, patch it with
> boilerplate that could not be generated by the xml2rfc
> processors available to document authors, and then, e.g.,
> repaginate the document with other internal tools.    I assume
> you don't intend that either, but it makes "during the
> publishing phase" a little more subtle than the sentence above
> implies.

Currently the boilerplate on an I-D is modified when the I-D is  
published into an RFC. That changes pagination. I don't think, but I  
am not an xml2rfc authority, that you can generate an RFC boilerplate  
with xml2rfc.

>> ...
>> In other words. I hope the IAB will submit the document to the
>> Editor shortly. Then we start to work with the RFC Editor and
>> the tools folk on the implementation, and once we are
>> satisfied that we did not run into a gigantic corner-case the
>> RFC is published.
> Certainly I prefer that to having the document published --and
> implemented in published RFCs-- without first checking for
> "gigantic corner-cases".  However, I worry that, if one uses
> this particular process model and cases (gigantic or otherwise)
> are discovered that require document changes, the community will
> have about the same opportunity to review those changes that it
> has with AUTH48 chances, i.e., little or none.

If the implementation turns out to have any effect on the boilerplate  
text or any other part of the text (beyond the normal editing for  
grammar and NITS), I'll bring that to the community. I'll take special  
notice during AUTH48.


Olaf M. Kolkman                        NLnet Labs
                                        Science Park 140,
http://www.nlnetlabs.nl/               1098 XG Amsterdam

NB: The street at which our offices are located has been
renamed to the above.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20090123/d87fa7ef/PGP-0001.bin

More information about the rfc-interest mailing list