[rfc-i] Private documents [was Alternatives to 'deprecated' in xml2rfc v3]

Julian Reschke julian.reschke at gmx.de
Tue May 6 22:32:55 PDT 2014

On 2014-05-07 02:28, Brian E Carpenter wrote:
> On 07/05/2014 10:04, Julian Reschke wrote:
>> On 2014-05-06 22:38, Brian E Carpenter wrote:
> ...
>>> However, the topblock="no" case does raise one question in my mind.
>>> Are we clear that v3 has the generation of valid I-D and RFC formats
>>> as its *only* goal? The statements in the Abstract and Introduction
>>> of draft-hoffman-xml2rfc don't make this clear. Speaking as the
>>> maintainer of http://www.ietf.org/about/process-docs.html, I need
>>> clarity on this.
>>> (The same is true of draft-reschke-xml2rfc, in fact.)
>> I think the vocabulary should support creating "private" documents. If
>> this requires additions in the vocabulary in v3, we definitively should
>> do that.
> The v1 PIs included

These are not "v1", they are "xml2rfc.tcl". They are not described in 

> <?rfc topblock="no"?>
> <?rfc private="whatever"?>
> An experiment has showed me (to my surprise) that it's 'private'
> that suppresses the I-D boilerplate; I'm not sure what 'topblock="no"'
> really does. Anyway, it seems that the v2 processor ignores them,
> or I am missing something obvious?

It might.

> --- OK, what I'm missing is that topblock, header and footer
> affect ASCII output, not HTML output. That is so 20th century. ---

That's what you get by ordering new software without a proper 
specification, nor a test suite :-)

> I think a 'private' attribute for v3 might lead to endless
> debate about what it means. How about 'noBoilerplate'?
> And if there are other features we would like private documents
> to be able to drop, we could add other 'noFoobar' attributes
> accordingly.

I wonder whether this could be simply triggered by specifying neither 
rfc# nor draft name?

Best regards, Julian

More information about the rfc-interest mailing list