[rfc-i] draft-iab-streams-headers-boilerplates-06 : overlooked details?
olaf at NLnetLabs.nl
Sat Jan 31 08:54:36 PST 2009
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
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
More information about the rfc-interest