Subject: [Tools-implementation] Draft of message noting that we will allow xml2rfc to produce text formatted as an RFC but paginated with page numbers.

From: Robert Sparks <[email-masked]>
Date: Wed, 9 Dec 2020 11:11:24 -0600

Tools-implementation team (plus Jay): -

I plan to send the below note to tools-discuss and forward a pointer to 
it on the ietf list and rfc-interest on Friday unless I hear a request 
for something significantly different from you before then.

Please comment. If you think this is ok as is, please say so.

RjS

----------

Subject: Allowing xml2rfc to generate text documents with page numbers

The RFCs that define the format specifications for RFCs are clear that 
the published rendered text format for RFCs will not have page numbers.

However, we have received many requests to allow the rendering tool to 
add those numbers when people are rendering documents locally for their 
own purposes. Adding and maintaining support for that is trivial, and we 
plan to make that available via a command-line argument in an upcoming 
release of xml2rfc.

This isn't a change to how RFCs will be published - published RFCs will 
continue to follow the format requirements from RFC 7994 and the 
discussions around the revision of the documents defining the RFC 
formats. Those wishing to change how RFCs are published should 
contribute to future efforts revising those specifications.

In general, the formatters will be able to produce a superset of what is 
required for RFC publication, and we anticipate that new capabilities 
will be added when there is appropriate demand.

We acknowledge the concerns around the potential for confusion raised 
during the discussion of the request for this capability. However, we 
note that it is possible to generate a document with the current tools 
that looks like a published RFC with completely different content. 
Addressing this potential for confusion is not an issue to solve with 
the formatting tools.

Robert Sparks, Tools Team Chair

---

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 09 Dec 2020 18:03:13 +0000

Hi Robert,
This looks reasonable to me!

On Wed, Dec 9, 2020, at 5:11 PM, Robert Sparks wrote:
> -- 
> Tools-implementation mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-implementation
>

---

From: Glen <[email-masked]>
Date: Wed, 9 Dec 2020 11:37:09 -0800

No issues that I can see, I think it is okay, although I'm not the most 
qualified to judge this topic area. ;-)

Glen

---

From: Jay Daley <[email-masked]>
Date: Thu, 10 Dec 2020 08:46:02 +1300

Looks good to me. I perhaps would use “different output” rather than “superset” as the latter implies compatibility, but that’s a minor issue. 

Jay

(sent from my phone)

-- 
Jay Daley 
+64 21 678840
[email-masked]
wire: @jaydaley

> On 10/12/2020, at 6:11 AM, Robert Sparks <[email-masked]> wrote:
> 
> I plan to send the below note to tools-discuss and forward a pointer to it on the ietf list and rfc-interest on Friday unless I hear a request for something significantly different from you before then.
> 
> The RFCs that define the format specifications for RFCs are clear that the published rendered text format for RFCs will not have page numbers.
> 
> However, we have received many requests to allow the rendering tool to add those numbers when people are rendering documents locally for their own purposes. Adding and maintaining support for that is trivial, and we plan to make that available via a command-line argument in an upcoming release of xml2rfc.
> 
> This isn't a change to how RFCs will be published - published RFCs will continue to follow the format requirements from RFC 7994 and the discussions around the revision of the documents defining the RFC formats. Those wishing to change how RFCs are published should contribute to future efforts revising those specifications.
> 
> In general, the formatters will be able to produce a superset of what is required for RFC publication, and we anticipate that new capabilities will be added when there is appropriate demand.
> 
> We acknowledge the concerns around the potential for confusion raised during the discussion of the request for this capability. However, we note that it is possible to generate a document with the current tools that looks like a published RFC with completely different content. Addressing this potential for confusion is not an issue to solve with the formatting tools.
>