Re: [Rswg] draft-mcquistin-augmented-ascii-diagrams

[Stephen McQuistin <[e-mail]>]

> On 28 Oct 2023, at 10:50, Colin Perkins <[e-mail]> wrote:
> 
> On 28 Oct 2023, at 11:03, Julian Reschke wrote:
> 
> On 27.10.2023 23:16, John Levine wrote:
> 
> ...
> 
> potential to use with Martin's AASVG
> doubt that we should parse english prose when we actually have a
> markup language to express RFCs
> 
> I agree that the idea is fine, but the hacks to embed it in text RFCs
> are not. I think we could make it an <artwork> type, say that they
> have to match the grammar, sort of like SVG does, and say it is
> specificallt allowed for rendering engines for HTML et al to
> parse them and redraw them using actual lines and boxes.
> 
> Right.
> 
> The entire point of this draft is that it doesn't require any change to the RFC format. It doesn't need to be embedded into artwork, source code, media types, or anything of the sort. It's a structured way of using the existing RFC format, unchanged, and usable today (and, indeed, with any variant of the RFC format we've had in the last few decades).
> 
> We could define something more structured, more integrated with the RFC format. That would be a useful thing to do. It could probably build on the same underlying data description model and code base. But it's not the purpose of this draft.
> 

To that end, would it make sense to split this document into two: (i) a definition of the underlying data model (essentially defining what _any_ protocol description language would need to capture to be able to do what we want to do); and (ii) a definition of the Augmented Packet Header Diagram format. I’m not sure which (R|W)G would be the best place for either/both of those.

Thanks,
Stephen