On Mon, Feb 10, 2025 at 11:15 AM Brian E Carpenter < brian.e.carpen...@gmail.com> wrote:
> Martin, > > That mainly sounds right, except for one point: > > > Specifically, the suggestion that the RPC favor accepting SVGs from > common tools. > > What users need, I think, is a statement (very likely somewhere like > authors.ietf.org, but that's a detail) saying that a certain set of > drawing tools has been found by experience to be suitable, and that a > certain other set has been less suitable. That seems like a suggestion, > rather than a policy. > > However, I disagree with you that the text in the -00 draft is a > suggestion. Rather, I think it should be two distinct policy items: > > * The RPC's implementation should strive to allow SVGs produced by widely > used drawing tools. > > * Where possible, implementation decisions should focus on specifying what > is disallowed, rather than attempting to specify exactly what is allowed. > > The current version at https://github.com/alexisannerossi/id-svgsinrfcs/blob/main/svgsinrfcs.md has Martin's changes and also incorporates a notification requirement (from Carsten's email). Do you feel like the new over all format - separating "policy requirements" from "implementation guidance" - hurts the document? (eg splitting those things out separately means the RPC might not feel bound to support widely used drawing tools, or similar?) > Regards > Brian > > On 10-Feb-25 17:46, Martin Thomson wrote: > > On Fri, Feb 7, 2025, at 08:33, Alexis Rossi 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. > > > > I think that this general direction is good. I've sent in a pull > request that is part editorial, part substantive. > > > > https://github.com/alexisannerossi/id-svgsinrfcs/pull/3 > > > > The substantive part is to move some of the bullet points to a > "suggestions" section, rather than make it policy. Specifically, the > suggestion that the RPC favor accepting SVGs from common tools. > > > > I've also sharpened the policy section to highlight the two key points: > > > > 1. This empowers (or burdens) the RPC with the power to determine what > SVGs are and are not acceptable. (In the text I propose, I've identified > the potential for there to be both technical and editorial constraints. If > it isn't obvious what that might mean, I'm happy to expand on these; I > don't that taxonomy is exhaustive.) > > 2. That responsibility also comes with a responsibility to document the > decisions that are made. > > > > Again, splitting that between policy requirements and guidance makes > that easier. > > > > --- > > > > I've suggested some minor guidance: > > * That documentation serves a primary purpose (what will be accepted) > and secondary purpose (help people produce good diagrams). > > * That the RPC periodically review and revise their practices. > > > > --- > > > > On the substance of the list, which I didn't touch in the above: > > > > * "SVGs in RFCs must render well on a wide variety of common devices" is > untestable as worded. Should this instead state the aspiration that "as > many people as possible should be able view the image"? That's still > squishy, so maybe it can move to implementation guidance rather than policy. > > > > * The requirement to propagate SVGs to publication formats that support > them is seems awkward. I think that the goal is: where there are multiple > choices of how to present a figure -- and there is no reason to show > multiple -- the best (that can be supported in the target format) shall be > selected. You might mention that this is expected to be SVG in many cases. > > > > * With the changes I propose, the statement "SVG vocabulary and > implementation may change over time and is not required to remain > backwards-compatible." is a bit redundant. > > > > --- > > > > Other than that, I think that the general direction here is sound and > I'm supportive of retiring RFC 7996. > > > > > > >
-- rswg mailing list -- rswg@rfc-editor.org To unsubscribe send an email to rswg-le...@rfc-editor.org
