[rfc-i] draft-iab-streams-headers-boilerplates-07 (was: Abstract on Page 1?)

SM sm at resistor.net
Sat Mar 7 20:34:18 PST 2009

At 17:35 05-03-2009, John C Klensin wrote:
>But IESG notes don't appear in I-Ds.  Paul is right there -- one
>needs to be a bit careful in comparing RFC and I-D boilerplate.
>They aren't going to be the same, but keeping them in the same
>places and connected is relatively important.

Keeping different formats (as you said in another thread) for I-Ds and RFCs
is looking for all sorts of trouble.  Although the IESG Note might 
rarely appear in RFCs, it is better to think about it too.

>Yes.  But, with the usual IANAL qualifications, there may be a
>legal requirement that the copyright notice appear on either the
>first page or the last one.  That could make "after the
>abstract" a non-starter if the Abstract might flow past the
>first page.

I'll leave this question to the people better qualified to determine 
whether there is a legal requirement for the copyright notice to 
appear on the first page, the last one or to precede the text covered 
by the copyright notice.

>One additional consideration is that there are several
>advantages, from the standpoint of tool construction, editing
>documents without format-specific tools, and future
>expandability, to keeping all of the boilerplate / front matter
>material together and in the front of the document.  I don't
>know that order (among Abstract, Copyright, Status) makes much
>difference except for the legal constraint of copyright.  But
>scattering things around, or even putting some things in front
>and others in back, would not be a positive step after the
>amount of effort that went into headers and boilerplate and the
>specific followup to 5379 to eliminate just that "some in front
>and some in back" situation.

I personally do not like the "some in front and some in back" 
situation.  I won't label it as a constraint.  I'm in favor of 
trimming the bloat.  Keep it simple, keep it short.

Julian Reschke mentioned in another thread on the IETF list that the 
changes to the boilerplate are not trivial.  I'll second his comments 
by saying think ahead, take into account the work that has to be done 
by tool developers and see whether what is being asked can actually 
be done.  We can also learn something from the followup to 5379.


More information about the rfc-interest mailing list