An aside: On the whole our documents contain 3 types of diagrams:
* Packets * Flows * Architectural DiagramsEach of these can be specified semantically through tools such as uml. The reader is well served across the series when these diagrams are consistently presented. So to me, SVG is an hors d'oeuvre to the entree; and I'm hungry.
Eliot On 13.05.2025 08:56, Eliot Lear wrote:
This seems good enough, but I might also add an admonishment that all images should be checked for consistency with the text.Eliot On 13.05.2025 06:52, Alexis Rossi wrote:Okay, summing up again.It seems like we have a number of people who believe that the conversation around whether imagery is/can be considered normative in IETF documents should be held elsewhere - perhaps first on rfc-interest, but eventually in a WG to write any resulting RFC and get IETF stream approval.If I have that correct, then I propose to use language in this draft that encourages use of text to explain concepts without requiring it. How about:OLD"SVGs may be included in RFCs to help explain a concept more clearly, but cannot be the only representation of that concept. Normative descriptions of concepts - which might include protocols, formats, or system architectures - must be fully represented in the text of the RFC, and must not be contingent on comprehension of any SVG. SVGs are never to be considered as specifications in themselves."NEW"SVGs may be included in RFCs to help explain a concept more clearly, but should not be the only representation of that concept. Normative descriptions of concepts - which might include protocols, formats, or system architectures - should be fully represented in the text of the RFC whenever possible, and should not be contingent on comprehension of any SVG."Alexis On Mon, May 12, 2025 at 11:21 AM Eliot Lear <l...@lear.ch> wrote: Hi, On 12.05.2025 19:33, Eric Rescorla wrote:I would be perfectly happy to see this discussion elsewhere. I suppose it's fine for people to discuss on rfc-interest, but any actual requirement that applied to IETF, would, I think, eventually need to be an IETF RFC.The stream created by RFC 9280 can have impact on ALL streams. However, nobody BUT the IETF cares about the notion of "normative", and that's probably a good thing. If a diagram and text disagree, it is an erratum. What has happened in the code since will dictate what is normative as a practical matter. Eliot-- rswg mailing list -- rswg@rfc-editor.orgTo unsubscribe send an email to rswg-le...@rfc-editor.org
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- rswg mailing list -- rswg@rfc-editor.org To unsubscribe send an email to rswg-le...@rfc-editor.org
