Re: [rfc-i] getting SVG of RFC diagrams

[Paul Kyzivat <[e-mail]>]

Paul H,

On 11/26/23 6:07 PM, Paul Hoffman wrote:
> On 26 Nov 2023, at 14:53, Paul Kyzivat wrote:
> 
>> OK, it seems Carsten and I are in violent agreement.
>> Can we hear from some others here on rfc-interest on whether this is popular enough to pursue further? At some point it probably needs to be discussed on the tools list.
> 
> This discussion started with "I want to be able to extract $x" and veered into "the RPC should be making $x available to everyone for every RFC". A different path would be "it would be nice if I could extract $x from one or more RFCs locally".
> 
> Given that no one has asked the original question before now, it seems likely to only be needed by a small number (maybe less than a few dozen) people. Thus, a discoverable tool that does it might be better than making the RPC add the tool and the process for everyone.

Its already "possible" to extract this stuff, if you are sufficiently 
knowledgeable. At the most basic you can extract what you want from the 
xml using just a text editor.

We are discussing how to make it easier while requiring less specialized 
knowledge. What to do of course depends on what users we are trying to 
address. There are many potential uses for this capability.

My interest came from working on a bunch of sip documents that define 
syntax using ABNF. The core defining document for sip is RFC3261. Its 
ABNF is large self contained except it uses the ABNF core rules. It 
references SDP (RFC237) but their syntax is independent. There are quite 
a lot of follow on documents that extend and revise RFC3261 and/or 
RFC2327. Many of those contain new ABNF describing their extension as an 
addition/revision of the ABNF in prior documents.

Validating the ABNF of one of those documents requires extracting it 
from the document, then identifying (recursively) other documents 
containing referenced ABNF, extracting that, and merging all of that. 
Only then can the ABNF be validated.

This was sufficiently painful that it was rarely done. While I did it a 
few times, usually it was expedient to just validate the new ABNF and 
manually check that the undefined rules were defined in the referenced 
documents. Other sorts of possible errors such as conflicting 
definitions of rules could easy slip by.

I would like to see tooling that automatically validates ABNF when 
documents are submitted. Doing so would require a tool that extracts 
ABNF from already published documents. The same mechanisms would also be 
important for an implementer who wants to compile all the ABNF into a 
parser.

This automatic validation should of course extend to other sorts of 
sorcecode in document, such as json and yang. So tools to automatically 
extract that would also be needed.

So I see the current proposal as part of one step down this path to 
further tools.

	Thanks,
	Paul K