On Sat, Feb 8, 2025 at 1:57 AM Carsten Bormann <c...@tzi.org> 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. > Yes, I agree, we are shifting to something where there might be less restrictions so I can see the potential for confusion for authors. We definitely want to avoid late surprises in the editing process for authors. However, I'm hoping that since the RPC will be required to document their policies publicly (I'm guessing at https://authors.ietf.org/en/diagrams), they would be able to make the policies/tools clear enough to help authors in advance so there aren't surprises. Obviously they would need to let everyone know when things change in order to avoid confusion. Do you think there are any changes we should make to the text in the draft to help clarify this expectation? What if we add another sentence to the first policy point: OLD "SVG tooling and implementation decisions are made or overseen by the RPC, and must adhere to the policy requirements in this document. The RPC is expected to solicit community input before making these decisions and to publicly explain their reasoning. Documentation for SVG usage in RFCs will be publicly available." NEW "SVG tooling and implementation decisions are made or overseen by the RPC, and must adhere to the policy requirements in this document. The RPC is expected to solicit community input before making these decisions and to publicly explain their reasoning. Documentation for SVG usage in RFCs will be publicly available. Any changes to tooling or implementation decisions must be widely communicated to the RFC author community using mailing lists or other means." > > 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. > I think that changes to the editorial process may be outside the purview of RSWG (depending on how you slice it), but are definitely out of scope for the replacement of 7996. But thank you for bringing it up so we can all think about it! > 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
