Subject: [rfc-i] Updates to RFC XML

From: "John R Levine" <[email-masked]>
Date: 9 May 2022 14:27:01 -0400

postal
docName
link
toc

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

_______________________________________________
rfc-interest mailing list
[email-masked]
https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: "John R Levine" <[email-masked]>
Date: 9 May 2022 14:33:12 -0400

Well, that was cryptic.

Here's the coding changes I'd like to make to published RFCs so they 
better match the final v3 spec.

In the <rfc> element, make the docName attribute the name of the RFC, 
e.g., "rfc9999" rather than the draft it used to be.  The draft name is 
available in a <link> element.

<postal> element, replace the current complex format that needs an 
abandonware library to render with a list of <postalline> and <country> at 
the end.

<link> elements in the XML are quite unlike what RFC7991 specified and 
instead are almost but not quite compatible with HTML weblinks.  I would 
prefer to put them back the way 7991 says, or failing that, make them 
entirely compatible with weblinks.  In the rendered HTML, the links are of 
course weblinks, this is about the

Remove the generated <toc> element in prepped XML.  It's not used when 
rendering the document (xml2rfc scans the section headers), takes up 
space, and is confusing.  The TOC in rendered text, HTML, and PDF would be 
unaffected.

R's,
John

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Mon, 9 May 2022 19:32:01 +0000

On 5/9/2022, 2:39 PM, "rfc-interest on behalf of John R Levine" <[email-masked] on behalf of [email-masked]> wrote:

    Well, that was cryptic.

+1

+1

How much are links used as input by authors? If not and only as output from the prep tool, I think we need to move forward to weblink-compatible. But if they ARE used by authors, then you might be stuck accepting both forms, with weblink the preferred form moving forward.

Based on our discussion offline, this is perfectly reasonable. +1

	Tony

---

From: Julian Reschke <[email-masked]>
Date: Mon, 9 May 2022 22:24:48 +0200

> available in a <link> element.

I would prefer to restore the number attribute defined in 7749 (and the
sibling attributes).

> abandonware library to render with a list of <postalline> and <country>
> at the end.

Absolutely.

> entirely compatible with weblinks.  In the rendered HTML, the links are
> of course weblinks, this is about the
>
> space, and is confusing.  The TOC in rendered text, HTML, and PDF would
> be unaffected.

Absolutely. And please remove related atrocities, like <author> as child
element of <section>.

Best regards, Julian

---

From: "John Levine" <[email-masked]>
Date: 9 May 2022 17:47:46 -0400

>I would prefer to restore the number attribute defined in 7749 (and the

I gather that means you can have docName or number but not both?  I wouldn't
be opposed to that but I don't know what that would break.  Also, which
sibling attributes?

>Absolutely. And please remove related atrocities, like <author> as child

Do any published RFCs have <author> in <section>?  I'm trying to limit this
to changes we can do mechanically so we don't have to hand edit and proofread
a thousand documents again.  I suppose I could check easily enough but you
can probably write the xslt faster than I can write the python.

R's,
John

---

From: Robert Sparks <[email-masked]>
Date: Mon, 9 May 2022 21:45:22 -0500

> be opposed to that but I don't know what that would break.  Also, which
I would prefer a future where all documents in this grammar have a name 
in one place that can be simply retrieved, not one that requires a bunch 
of conditional logic to compute.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 May 2022 07:07:25 +0200

> be opposed to that but I don't know what that would break.  Also, which

What RFC 7749 said.

/rfc/@number just overrides /rfc/@docName. There are also
/rfc/@seriesNumber etc. The introduction of <seriesInfo> as child of
<front> was a mistake.

> can probably write the xslt faster than I can write the python.

They have an auto-generated back section with those after running the
preptool. Before, no.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 10 May 2022 10:54:55 +0200

On 10. May 2022, at 07:07, Julian Reschke <[email-masked]> wrote:
> 
> The introduction of <seriesInfo> as child of
> <front> was a mistake.

I never understood this, and I’m trying to learn from why it did happen.

I can understand the introduction of a seriesInfo as the result of running the preptool.
(What we are now moving away from with <toc.)

I don’t understand its role during authoring, or during RPC processing.

If anyone remembers what we were thinking, I’d sure like to understand.

And while we are at it, please explain how <rfc/submissionType= and <stream interact.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 10 May 2022 11:05:42 +0200

> On 10. May 2022, at 10:54, Carsten Bormann <[email-masked]> wrote:
> 

… and <seriesinfo/stream=, while we are at it.
("Deprecated. Use the <stream (Section 2.54)> element instead.”
But RFC8650+ RFCs have it as a /rfc/front/seriesinfo/stream=, and no <stream.)

(FYI, I’m using stream: as an alias for submissiontype: in kramdown-rfc.)

Grüße, Carsten

¶

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 May 2022 12:58:39 +0200

> And while we are at it, please explain how <rfc/submissionType= and <stream interact.

It was an attempt to cut down the number of metadata attributes on /rfc.
It's a total mess, and should be reverted.

(see also
https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/7, raised
5 years ago, and
https://datatracker.ietf.org/doc/html/draft-levkowetz-xml2rfc-v3-implementation-notes-13#section-3.1.21).

Best regards, Julian