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

[Olaf Kolkman]

*blush*

I wrote:
> So this can be fixed... would you be so kind?
>
[... and more hastily written mumbling ...]

This was intended to be send to Leslie, as co-editor, obviously not as  
a CC to the list.

Please ignore that mail.

However, since it clearly indicates that I am not quite convinced that  
I think this document deal with the headers and boilerplates of I-Ds,  
let me elaborate a bit so that it is clear where I am.

First for context, this is John Klensin's 3rd point:
> (3) This draft is almost entirely about RFCs.  As noted on the
> list, it doesn't address the difference between I-Ds and RFCs
> very much at all.  In fact, the term "Internet-Draft" appears in
> it only in its headers and boilerplate.  There are enough issues
> about the differences --including what should be done about the
> Updates section and the associated references from the
> boilerplate-- that approval and publication of this document
> without nailing those details down would be a serious disservice
> to authors and editors.  Indeed, if the intent were to _require_
> boilerplate based on this document in RFCs, waiting why authors
> and tool-developers got the details sorted out with the IAB and
> RFC Editor might introduce document flow constipation fully as
> serious as the case we have had with IPR.

Today_ there is a difference in the headers and boilerplates of I-Ds  
and RFCs. For I-Ds the only guidelines I am aware of are: http://www.ietf.org/ietf/1id-guidelines.txt 
.

There are AFAIK no strict checks on the _headers_ of I-Ds. There are  
some checks on the intended status and possible downrefs that could be  
harmful but I do not recognize (skimming idnits) that the format of  
the headers are checked.  I agree that most of the information that  
lives in the front-page header of RFCs is useful for I-Ds and that it  
seems sensible to, during the lifetime of a document as draft, have  
the upper-left-hand-corner reflect the Working Group, or, for  
instance, the sponsoring AD.

Also, during the transformation from I-D to RFC there is some editing  
done, by the RFC Editor, to remove the I-D specific text. I assume,  
and hope to be corrected by the Editor if I am wrong, that some of  
this is simply done by editing a few fields in the xml (if xml is  
used), and yes, I agree some tool modification will be needed.  
However, I do not think that authors will rarely generate the  text as  
it would appear in the RFC themselves, so the repagination argument  
John brought up before is one that I don't think is strong.

If the point of John's 3rd bullet is that this document should contain  
text that the header and boilerplates instructions are explicitly for  
RFCs and that the guidelines for I-Ds is maintained separately, than  
that can be added.

As far as the two other points were concerned. The current text was  
crafted in such a way that the RFC editor could come up with their own  
suggestion for the reference, either by a cross reference to another  
section or by adding a URI. The intention was to give a guideline  
without nailing down the details in an RFC. To me the reference being  
a simple URI has always been implicit, I am perfectly happy with the  
suggested explicit text.

--Olaf
-------------- 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/20090131/bd9fb462/PGP.bin