Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
On Dec 22, 2009, at 8:39 PM, Dave CROCKER wrote: Brian, This seems worth being a bit pedantic about, to make sure we all share the same understanding: I take your interpretation to mean that the RFC Editor can, on their own initiative, fix the problem(s) that Julan has raised and that it does not require changes to the about-to-be-published document. Is that correct? Do others agree? (I hope so.) FWIW, I do. As long as those changes are stylistic, editorial, and not so substantive that they cause the various streams to be uneasy with those changes. And in reply to Brian: Maybe we^H^Hthe IAB should have aimed at full delegation of the boilerplate, exactly as for the Trust-maintained boilerplate. That is what I intended with: I believe that in the future such efforts should be pulled by the RSE, with IAB oversight and not by the IAB with RFC-Editor input --Olaf (personal title) d/ On 12/22/2009 11:23 AM, Brian E Carpenter wrote: FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. ... For now, there are indeed weasel words such as: However, this is not intended to specify a single, static format. Details of formatting are decided by the RFC Editor. These paragraphs will need to be defined and maintained as part of RFC stream definitions. Initial text, for current streams, is provided below. I think this gives the RSE, in conjunction with the tools maintainers, reasonable flexibility. -- Dave Crocker Brandenburg InternetWorking bbiw.net Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
I have long held this view Jim -Original Message- From: rfc-interest-boun...@rfc-editor.org [mailto:rfc-interest- boun...@rfc-editor.org] On Behalf Of Bob Hinden Sent: Tuesday, December 22, 2009 12:41 PM To: Russ Housley Cc: Olaf Kolkman; xml2...@lists.xml.resource.org; IETF discussion list; Bob Hinden; rfc-inter...@rfc-editor.org; dcroc...@bbiw.net Subject: Re: [rfc-i] Important: do not publish draft-iab-streams- headers-boilerplates-08 as is! On Dec 22, 2009, at 12:08 PM, Russ Housley wrote: Dave: I agree with Birain's assessment. The RFC Editor can handle this issue without delaying publication of the document. +1 Bob ___ rfc-interest mailing list rfc-inter...@rfc-editor.org http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Julian Reschke wrote: ... In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, and I have updated my document with the current changes; see http://tools.ietf.org/html/draft-reschke-hab-01, in particular http://tools.ietf.org/html/draft-reschke-hab-01#appendix-A.1 (change list) and http://tools.ietf.org/rfcdiff?url2=draft-reschke-hab-01.txt (diffs). ... I just heard that the RFC 5741-to-be is not going to be fixed with respect to the stutter in the boilerplate, such as in: -- snip -- 3.1.6.2. Text of 'Status Of This Memo' This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidate for any level of Internet Standards; see Section 2 of RFC 5741. 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/info/rfc. -- snip -- (see http://tools.ietf.org/html/draft-reschke-hab-01#section-3.1.6.2). This problem was reported over three weeks ago. Are we really incapable to fix something simple like that within three weeks? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Julian, You wrote: This problem was reported over three weeks ago. Are we really incapable to fix something simple like that within three weeks? We are at a point where making trivial changes to headers and boilerplates leads to discussion about more substantive matters and causes even more delay, folk wanted it done. It is unfortunate that the stutter (I agree its there and that its ugly) remains in the document. Headers and boilerplates lives on this tangent between community wishes, RFC oversight, and RFC Editor series continuity and style. Having learned from getting HB done, I believe that in the future such efforts should be pulled by the RSE, with IAB oversight and not by the IAB with RFC-Editor input. FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. --Olaf [top-post, full context below.] On Dec 22, 2009, at 10:26 AM, Julian Reschke wrote: Julian Reschke wrote: ... In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, and I have updated my document with the current changes; see http://tools.ietf.org/html/draft-reschke-hab-01, in particular http://tools.ietf.org/html/draft-reschke-hab-01#appendix-A.1 (change list) and http://tools.ietf.org/rfcdiff?url2=draft-reschke-hab-01.txt (diffs). ... I just heard that the RFC 5741-to-be is not going to be fixed with respect to the stutter in the boilerplate, such as in: -- snip -- 3.1.6.2. Text of 'Status Of This Memo' This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidate for any level of Internet Standards; see Section 2 of RFC 5741. 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/info/rfc. -- snip -- (see http://tools.ietf.org/html/draft-reschke-hab-01#section-3.1.6.2). This problem was reported over three weeks ago. Are we really incapable to fix something simple like that within three weeks? Best regards, Julian ___ rfc-interest mailing list rfc-inter...@rfc-editor.org http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. Maybe we^H^Hthe IAB should have aimed at full delegation of the boilerplate, exactly as for the Trust-maintained boilerplate. For now, there are indeed weasel words such as: However, this is not intended to specify a single, static format. Details of formatting are decided by the RFC Editor. These paragraphs will need to be defined and maintained as part of RFC stream definitions. Initial text, for current streams, is provided below. I think this gives the RSE, in conjunction with the tools maintainers, reasonable flexibility. I also note: The changes introduced by this memo should be implemented as soon as practically possible after the document has been approved for publication. which is presumably intended to allow the tools some time to catch up, again requiring RSE/tools coordination. Regards Brian Carpenter On 2009-12-22 23:50, Olaf Kolkman wrote: Julian, You wrote: This problem was reported over three weeks ago. Are we really incapable to fix something simple like that within three weeks? We are at a point where making trivial changes to headers and boilerplates leads to discussion about more substantive matters and causes even more delay, folk wanted it done. It is unfortunate that the stutter (I agree its there and that its ugly) remains in the document. Headers and boilerplates lives on this tangent between community wishes, RFC oversight, and RFC Editor series continuity and style. Having learned from getting HB done, I believe that in the future such efforts should be pulled by the RSE, with IAB oversight and not by the IAB with RFC-Editor input. FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. --Olaf [top-post, full context below.] On Dec 22, 2009, at 10:26 AM, Julian Reschke wrote: Julian Reschke wrote: ... In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, and I have updated my document with the current changes; see http://tools.ietf.org/html/draft-reschke-hab-01, in particular http://tools.ietf.org/html/draft-reschke-hab-01#appendix-A.1 (change list) and http://tools.ietf.org/rfcdiff?url2=draft-reschke-hab-01.txt (diffs). ... I just heard that the RFC 5741-to-be is not going to be fixed with respect to the stutter in the boilerplate, such as in: -- snip -- 3.1.6.2. Text of 'Status Of This Memo' This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidate for any level of Internet Standards; see Section 2 of RFC 5741. 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/info/rfc. -- snip -- (see http://tools.ietf.org/html/draft-reschke-hab-01#section-3.1.6.2). This problem was reported over three weeks ago. Are we really incapable to fix something simple like that within three weeks? Best regards, Julian ___ rfc-interest mailing list rfc-inter...@rfc-editor.org http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Dave: I agree with Birain's assessment. The RFC Editor can handle this issue without delaying publication of the document. Russ At 02:39 PM 12/22/2009, Dave CROCKER wrote: Brian, This seems worth being a bit pedantic about, to make sure we all share the same understanding: I take your interpretation to mean that the RFC Editor can, on their own initiative, fix the problem(s) that Julan has raised and that it does not require changes to the about-to-be-published document. Is that correct? Do others agree? (I hope so.) d/ On 12/22/2009 11:23 AM, Brian E Carpenter wrote: FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. ... For now, there are indeed weasel words such as: However, this is not intended to specify a single, static format. Details of formatting are decided by the RFC Editor. These paragraphs will need to be defined and maintained as part of RFC stream definitions. Initial text, for current streams, is provided below. I think this gives the RSE, in conjunction with the tools maintainers, reasonable flexibility. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ rfc-interest mailing list rfc-inter...@rfc-editor.org http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
On Dec 22, 2009, at 12:08 PM, Russ Housley wrote: Dave: I agree with Birain's assessment. The RFC Editor can handle this issue without delaying publication of the document. +1 Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
All, I agree with Birain's assessment. The RFC Editor can handle this issue without delaying publication of the document. +1 Me too. Publish the RFC. Please. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Julian Reschke wrote: Bob Braden wrote: Jim, Understood, but the RFC Editor does care how it flows. We would like to get it as nearly right as possible, going out of the gate. Bob Braden ... For tracking purposes, I just published draft-reschke-hab-00 (http://greenbytes.de/tech/webdav/draft-reschke-hab-00.html), which contains the headers and boilerplates for the 19 cases Sandy has identified. Note that the contents for these cases is auto-generated by the experimental version of rfc2629.xslt. I plan to update rfc2629.xslt and this draft as the RFC Editor fine-tunes the text for draft-iab-streams-headers-boilerplates. This will give us easy-to-read diffs on tools.ietf.org. ... In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, and I have updated my document with the current changes; see http://tools.ietf.org/html/draft-reschke-hab-01, in particular http://tools.ietf.org/html/draft-reschke-hab-01#appendix-A.1 (change list) and http://tools.ietf.org/rfcdiff?url2=draft-reschke-hab-01.txt (diffs). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Can we please recommend *not* to put a file extension into the URL? The text can be updated - there is no file extension. The URL is of the form: http://www.rfc-editor.org/static-path/rfcrfc-no For example: http://www.rfc-editor.org/info/rfc2026 RFC Editor/ah On Nov 24, 2009, at 7:01 AM, Julian Reschke wrote: 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/rfcrfc-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
RE: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Let's just get this published and go with what we have even if it does not necessarily read real pretty. The text of the strings can be updated at a later point by a modification of the RFC Style Guide if there are enough complaints about how the text looks. Given that it is boilerplate, I personally don't care that it does not flow. Jim -Original Message- From: rfc-interest-boun...@rfc-editor.org [mailto:rfc-interest- boun...@rfc-editor.org] On Behalf Of Julian Reschke Sent: Tuesday, November 24, 2009 5:02 AM To: IETF discussion list; rfc-inter...@rfc-editor.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/rfcrfc-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
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Bob Braden wrote: Jim, Understood, but the RFC Editor does care how it flows. We would like to get it as nearly right as possible, going out of the gate. Bob Braden ... For tracking purposes, I just published draft-reschke-hab-00 (http://greenbytes.de/tech/webdav/draft-reschke-hab-00.html), which contains the headers and boilerplates for the 19 cases Sandy has identified. Note that the contents for these cases is auto-generated by the experimental version of rfc2629.xslt. I plan to update rfc2629.xslt and this draft as the RFC Editor fine-tunes the text for draft-iab-streams-headers-boilerplates. This will give us easy-to-read diffs on tools.ietf.org. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Jim Schaad wrote: Let's just get this published and go with what we have even if it does not necessarily read real pretty. The text of the strings can be updated at a later point by a modification of the RFC Style Guide if there are enough complaints about how the text looks. Given that it is boilerplate, I personally don't care that it does not flow. Jim Jim, Understood, but the RFC Editor does care how it flows. We would like to get it as nearly right as possible, going out of the gate. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Bob Braden wrote: Jim Schaad wrote: Let's just get this published and go with what we have even if it does not necessarily read real pretty. Ready Fire Aim has characterized the pattern of IPR work on this topic in recent years, and the results have been exactly as messy as one would predict. This is a running system. Changes need to be made cautiously, with an eye towards safe and correct operations. We -- the part of the IETF that has been imposing changes -- haven't been doing that very well. We should fix that, before we blast out more problematic changes. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Jim Schaad wrote: Let's just get this published and go with what we have even if it does not necessarily read real pretty. The text of the strings can be updated at a later point by a modification of the RFC Style Guide if there are enough complaints about how the text looks. Given that it is boilerplate, I personally don't care that it does not flow. Jim 1) The text in the current draft is inconsistent. Please fix it. This is purely editorial. 2) Changing the boilerplate again adds another code path to all tools that need to produce it, requires additional test cases and so on (keep in mind that the tools we are written so that they can produce the correct boilerplate for historic documents as well). BTW I think we need a volunteer for xml2rfc.tcl to implement this anyway; it will not magically happen unless somebody digs into the TCL code and implements it. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Hi Julian, I went through version -08 of the headers-boilerplates document and attempted to put together all of the possible combinations of text for the Status of This Memo. I believe the attached file is a complete list of these possibilities, based on the text in Section 3. Please note that I have updated the URLs to match that of the existing metadata pages that were created in response to this document (http://www.rfc-editor.org/info/rfc). The RFC Editor hopes that the IAB will agree to update the URLs (throughout) and the text in Appendix A to reflect the appropriate text from the corresponding Stream/Status/Consensus in the attached file during the editing process. Please feel free to check the attached files, as manual error is possible. Hope this is of some help! Thanks! Sandy On Tue, Nov 24, 2009 at 02:01:56PM +0100, Julian Reschke wrote: 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/rfcrfc-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
