-----Original Message-----
From: rfc-interest-bounces(_at_)rfc-editor(_dot_)org [mailto:rfc-interest-
bounces(_at_)rfc-editor(_dot_)org] On Behalf Of Julian Reschke
Sent: Tuesday, November 24, 2009 5:02 AM
To: IETF discussion list; rfc-interest(_at_)rfc-editor(_dot_)org; xml2rfc
Subject: [rfc-i] Important: do not publish "draft-iab-streams-headers-
boilerplates-08" as is!
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.ha
b.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
_______________________________________________
rfc-interest mailing list
rfc-interest(_at_)rfc-editor(_dot_)org
http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest