Excuse front posting, but I mainly want to express strong support for the draft
while agreeing with everything Carsten and Michael Richardson have said. I
think we need this done ASAP so that the RPC can act to improve the whole
situation around diagrams, including some form of early review.
Regards
Brian Carpenter
On 08-Feb-25 22:57, Carsten Bormann wrote:
Hi Alexis,
thank you for pushing us forward here.
The 7996 experience was dominated by mechanistic checks embodied in two tools
(xml2rfc and svgcheck).
Those mechanistic checks were essentially based on “proof by lack of
imagination”, i.e., they prevented usages that simply didn’t come to mind at
the time the policy was crystallized into the spec (7996) or the tools.
The introduction of your document moves from the mechanistic approach towards
informed decision making, which can consider the actual objectives as opposed
to enforcing mechanistic rules concocted a decade ago from those:
The RFC Publication Center (RPC) is responsible for making SVG tooling and
implementation decisions. They may want to use the content of [RFC7996] as a
starting point for those decisions, but they are not bound by [RFC7996] and
they may change elements of the implementation as needed to support the RFC
authoring community as long as those changes are aligned with the policy
requirements in this document.¶
This is good (even if the text is still a bit too friendly to the Procrustes
bed that 7996 turned out to be).
I’m writing this message to point out that this welcome policy change also
gives rise to process considerations.
Today, authors can shape their documents based on an oracle, the svgcheck and
xml2rfc tools, that gives them immediate feedback on whether RPC is likely to
accept the graphics or not. Of course, it is still possible to grossly violate
the objectives of 7996 in graphics that is accepted by the oracle, but authors
will generally be aware of whether they mustered the criminal energy to make
this happen.
With the new policy, we shift to a situation that is less dysfunctional, but
also less predictable.
Without accompanying process improvements, RPC policy views generally will come
in as a late surprise: in AUTH48.
These late surprises may require significant surgery to the document (**), so
the necessary handling of any concerns should instead happen much earlier in
the process, yielding a document that already contains the necessary
adaptations at the time the various approval stages check it.
Maybe we can learn a bit from the way IANA considerations are handled: IANA
provides input at the IESG approval stage. IANA also looks at selected
documents in earlier stages, e.g., preceding physical meeting weeks. This
allows authors and WGs to make necessary changes (and possibly become aware of
the need to make certain decisions) earlier in the process.
The IANA analogue is limited (as any analogy is): IANA considerations are
dominated by what is feasible in the operation of the registries, which has
less variety than the ways authors and WGs may want to use graphics.
So I’m not proposing a carbon copy of our IANA processes: they are still useful
as an inspiration.
What we don’t want to have is a situation where random bits of experience are
picked up by various actors (contributors, reviewers) and applied without deep
knowledge of the reasoning behind them, essentially creating a Skinner box that
elicits and reinforces strange behavior. RPC needs to be part of the process,
also in order to be able to negotiate solutions that address the objectives of
both RPC and WGs/authors.
RSWG has generally been slow in picking up needs outside “policy”, so I’m
making this point now in order that it not be lost, even if RSWG does not want
to acquire responsibility for making the process improvements happen.
Grüße, Carsten
(**) For instance, that surgery may require introducing new terminology so that
a concept that would be clarified in some graphics can be explained more
verbosely (and, in effect, to the detriment of a large class of users of the
document). [To fend off a reflex of a counter-argument: Of course, the
document needs to be accessible (usable for all users), but that does not mean
it needs to be pessimized to be equally inaccessible for everyone.] As
graphics often reflect the results of complex WG and WG/IESG negotiations,
having to change them late in the process
On 6. Feb 2025, at 22:33, Alexis Rossi <alexisrossir...@gmail.com> wrote:
Hi all,
This ID (co-authored with Nevil and Jean) is meant to obsolete 7996 with text
that more clearly specifies the policies for inclusion of SVGs (and leaves out
implementation details). Most of the policies in here are drawn from 7996.
There is a github repository for this at:
https://github.com/alexisannerossi/id-svgsinrfcs
Name: draft-rossi-svgsinrfcs
Revision: 00
Title: SVGs in RFCs
Date: 2025-02-06
Group: Individual Submission
Pages: 4
URL: https://www.ietf.org/archive/id/draft-rossi-svgsinrfcs-00.txt
Status: https://datatracker.ietf.org/doc/draft-rossi-svgsinrfcs/
HTML: https://www.ietf.org/archive/id/draft-rossi-svgsinrfcs-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-rossi-svgsinrfcs
Abstract:
This document sets policy for the inclusion of SVGs in the definitive
versions of RFCs and relevant publication formats. It contains
policy requirements from [RFC7996] and removes all requirements
related to using a specific SVG profile or specific implementation
code. It also makes the RFC Publication Center (RPC) responsible for
implementation decisions regarding SVGs.
--
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org
--
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org
