On 11-Feb-25 11:16, Alexis Rossi wrote:
On Mon, Feb 10, 2025 at 11:15 AM Brian E Carpenter <brian.e.carpen...@gmail.com
<mailto: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 <http://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
<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?
No, that separation is in general a good idea...
(eg splitting those things out separately means the RPC might not feel bound to
support widely used drawing tools, or similar?)
... but it leads to the kind of argument I'm having with Martin; I will reply
to his message next.
Regards
Brian
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
<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
