[rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Julian Reschke]

Hi,

I just created five test cases representing the appendices A.1 to A.5. 
Turns out that the text in the examples is not in sync with the 
definitions in Section 3 (see, for instance, 
<http://greenbytes.de/tech/webdav/rfc2629xslt/samples/sample.ipr.rfc.hab.a2.test.xhtml>).

Best regards, Julian

Julian Reschke wrote:
> Julian Reschke wrote:
>>
>> <http://tools.ietf.org/html/draft-iab-streams-headers-boilerplates-08#section-3.2.3> 
>> says:
>>
>>    "Information about the current status of this document, any errata,
>>    and how to provide feedback on it may be obtained at
>>    http://www.rfc-editor.org/<static-path>/rfc<rfc-no>.html"
>>
>> Can we please recommend *not* to put a file extension into the URL?
>>
>> BR, Julian
>> ...
> 
> Hi,
> 
> in the meantime I have finished a prototype implementation of the new 
> boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is 
> available from <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>, and 
> requires the use of two new extension Processing Instructions to enable 
> the new boilerplate:
> 
>   <?rfc-ext h-a-b="yes"?>
>   <?rfc-ext consensus="no"?>
> 
> (where the first enables the new format, while the second provides the 
> information about whether there was consensus, something the current 
> xml2rfc format doesn't provide).
> 
> I haven't found any problems in addition to what was reported before, 
> except for a trailing dot in one of the boilerplate statements, and 
> cases of repeating sentence beginnings -- maybe all of this can be fixed 
> during AUTH48 (although I'd prefer to see this in a new draft for 
> community review).
> 
> For the record, here's a complete summary:
> 
> -- snip --
> 3.1.  The title page header
> 
>    <document source>  This describes the area where the work originates.
>       Historically, all RFCs were labeled Network Working Group.
>       "Network Working Group" refers to the original version of today's
>       IETF when people from the original set of ARPANET sites and
>       whomever else was interested -- the meetings were open -- got
>       together to discuss, design and document proposed protocols
>       [RFC0003].  Here, we obsolete the term "Network Working Group" in
>       order to indicate the originating stream.
> 
>       The <document source> is the name of the RFC stream, as defined in
>       [RFC4844] and its successors.  At the time of this publication,
>       the streams, and therefore the possible entries are:
> 
>       *  Internet Engineering Task Force
> 
>       *  Internet Architecture Board
> 
>       *  Internet Research Task Force
> 
>       *  Independent
> 
> JRE: as discussed earlier: should this be "Independent Submission"
> instead of "Independent"?
> 
>    [<RFC relation>:<RFC number[s]>]  Some relations between RFCs in the
>       series are explicitly noted in the RFC header.  For example, a new
>       RFC may update one or more earlier RFCs.  Currently two
>       relationships are defined: "Updates", and "Obsoletes" [RFC2223].
>       Variants like "Obsoleted by" are also used (e.g in [RFC5143]).
>       Other types of relationships may be defined by the RFC Editor and
>       may appear in future RFCs.
> 
> JRE: "Obsoleted By" is not a variant of "Obsoletes" or "Updates".
> 
> 3.2.2.  Paragraph 2
> 
>    The second paragraph of the "Status of This Memo" will now include a
>    paragraph describing the type of review and exposure the document has
>    received.  This is defined on a per-stream basis, subject to general
>    review and oversight by the RFC Editor and IAB.  There is a specific
>    structure defined here to ensure there is clarity about review
>    processes and document types.  These paragraphs will need to be
>    defined and maintained as part of RFC stream definitions.  Initial
>    text, for current streams, is provided below.
> 
>    The paragraph may include some text that is specific to the initial
>    document category, as follows: when a document is Experimental or
>    Historic the second paragraph opens with:
> 
>    Experimental:  "This document defines an Experimental Protocol for
>       the Internet community."
> 
>    Historic:  "This document defines a Historic Document for the
>       Internet community."
> 
> JRE: the way paragraph 2 is generated, we end up with instances where
> the 1st and 2nd sentence both start with "This document". This is ugly.
> Is it too late to fix this?
> 
>       In addition a sentence indicating the consensus base within the
>       IRTF may be added: "This RFC represents the consensus of the
>       <insert_name> Research Group of the Internet Research Task Force
>       (IRTF)." or alternatively "This RFC represents the individual
>       opinion(s) of one or more members of the <insert_name> Research
>       Group of the Internet Research Task Force (IRTF)".
> 
> JRE: trailing dot missing in 2nd variant.
> 
> 
> 3.2.3.  Paragraph 3
> 
>    "Information about the current status of this document, any errata,
>    and how to provide feedback on it may be obtained at
>    http://www.rfc-editor.org/<static-path>/rfc<rfc-no>.html"
> 
> JRE: please do not bake a file extension into the permanent URL (see also
> <http://www.ietf.org/mail-archive/web/ietf/current/msg59415.html>)
> 
> -- snip --
> 
> Best regards, Julian
> 
> 
>