Subject: Re: [rfc-i] [EXTERNAL]Re: [Bimi] SVG P/S Feedback

From: Kirk Hall <[email-masked]>
Date: Tue, 1 Sep 2020 23:14:27 +0000

Here is input from Serge Mister of Entrust Datacard.

The mention of fonts as a risk is interesting (I'd flagged missing-glyph as a risk for similar reasons; but it sounds like some renderers ignore the glyphs even if they are present?).  Personally I've had trouble generating SVGs (for work illustrations) that use fonts because the same fonts aren't available on the different platforms (e.g. Linux and Windows), so I agree that in practice logo designers would want to convert their text to curves (both to avoid rendering issues and to save space).

The SVG native effort does sound like it has similar goals.  Just based on reading the introduction it does sound like it would be nice to combine the efforts.  I wonder if there would be any funding (I'm thinking from BIMI) for adding support for the output format to InkScape.  That would go a ways to helping with adoption.  I don't know what it would cost.

-----Original Message-----
From: bimi <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Friday, August 28, 2020 3:26 PM
To: Brotman, Alex <[email-masked]>; [email-masked]
Cc: BIMI (IETF) ([email-masked]) <[email-masked]>
Subject: [EXTERNAL]Re: [Bimi] [rfc-i] SVG P/S Feedback

Alex,

I have to say that the RFC7996 profile of SVG Tiny is, in my experience, a problem rather than a solution. It was designed with the best possible intentions and some of the rules (like no colour, no greyscale, and no external references) are appropriate for the RFC context, but trying to generate conformant SVG with popular and widespread drawing tools is almost impossible**.

** Even with dia, which is a pretty minimal tool, some post-processing of the SVG may be needed. Producing my own recent effort (https://www.ietf.org/id/draft-carpenter-eligibility-expand-04.html#section-appendix.a) was quite a saga.

Regards

   Brian Carpenter

On 29-Aug-20 00:57, Brotman, Alex wrote:

> Hello,

> [Apologies for the cross-posting]

> As part of a separate project, we wanted to create a smaller SVG profile[1].  It is based on SVG Tiny 1.2, with several components removed.  The goal is to try to keep the document self-contained, remove animations, and generally more portable and secure (hence P/S).  Personally, I've been curious if we should be trying to create a new baseProfile as we've specified, given that it may behoove a developer to only target this subset of Tiny features, reducing footprint and attack surface.  We also welcome feedback about the text and font elements that we've permitted in the draft, and their security implications.

> We thank you for any advice or feedback you can provide.

> [1] https://datatracker.ietf.org/doc/draft-svg-tiny-ps-abrotman/

> --

> Alex Brotman

> Sr. Engineer, Anti-Abuse & Messaging Policy Comcast

> _______________________________________________

> rfc-interest mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

--

bimi mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/bimi

_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Sep 2020 09:16:24 +1200

On 22-Sep-20 03:46, Phillip Hallam-Baker wrote:
...> Basically there is a group of people who will write no code or even bother to understand the problem that nevertheless insist that the decision they took with no understanding of the issues five years ago must stand for all time.

That's a bit rude. I do agree that we should re-open the topic, but it's clear to me that we cannot possibly just say that any old SVG is allowed in RFCs. I am shocked by the amazing messes in the SVG produced by very common tools: what the heck is a large bunch of ECMAscript doing there just because the picture includes a circle, for example?

So there are going to be rules, like
 - no colour
 - no grayscale
 - no script
 - no external URLs
 - must be a viewbox and not width/height (to allow scaling)
and certainly more.

But first, I'd like a report on the experience of producing RFC8899.

   Brian