Subject: [Bimi] SVG P/S Feedback

From: "Brotman, Alex" <[email-masked]>
Date: Fri, 28 Aug 2020 12:57:20 +0000

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

---

From: Jakub Olexa <[email-masked]>
Date: Fri, 28 Aug 2020 18:36:09 +0200

Hi,

I consider text and font elements as potentionally abuseable especially
in context of use of the SVG Tiny P/S for BIMI logos.

Text - a brand logo should always have the text converted to curves as
that is the only way to make sure it will be represented as it should.
It could lead to minor rendering differences that could lead to brand
complaints.

Fonts - increases the SVG file size. When I tested this the results were
abysmal - essentially most of the exports resulted in massive files - 4
glyphs up to 8kb SVG, all glyphs of a single font easily in 200kb+...
and most importantly they did not render correctly under chrome, IE or
FF but Times is being used instead.

This brings in the abuse vector - I could create an SVG with custom
glyphs that will result in a completely different output if rendered
correctly (using the glyphs). Essentially I could have an SVG that reads
"Hello" in Chrome, IE, FF and most rendering engines while resulting in
a logo of a bank in a rendering engine with more advanced support of glyphs.

This could lead to logos being rendered not only incorrectly using
incorrect typeface but more importanlty logos that may render a
completely different content in specific engines.

This is bad user experience and could make brand managers resent BIMI.
It's better to keep it simple and restrict these elements rather than
getting surprising results in the output in my opinion.

Jakub Olexa
Founder & CEO
E-mail: [email-masked] <mailto:[email-masked]>
Tel: +420 777 744 440 <tel:+420777744440>

Mailkit - Closing the circle between Deliverability and Engagement
<https://www.mailkit.com>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Aug 2020 10:26:07 +1200

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:
> _______________________________________________
> rfc-interest mailing list
> [email-masked]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>

---

From: Larry Masinter <[email-masked]>
Date: Fri, 28 Aug 2020 15:55:41 -0700

One of the functional requirements for SVG illustrations is that when
converted to PDF/A that the result is "as good as it gets" so the authors
don't rely on embedded animations or videos to explain the protocol they are
describing.

What if you did a round trip   SVG -> PDF/A -> SVG. I think it's possible to
insure that doing so is idempotent (if it isn't now).

Then the RFC editor wouldn't have to decide whether the SVG fits some
profile.
Just run it as part of the process. Add it to the internet drafts submission
process.

Make sure that everyone reviews the illustrations in BOTH html and pdf
during AUTH48 
--
https://LarryMasinter.net https://interlisp.org

> -----Original Message-----
> From: rfc-interest <[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: Re: [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
> 
> > 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.
> >
> > Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Aug 2020 17:04:02 +1200

Larry,

> insure that doing so is idempotent (if it isn't now).

Only if you had a round trip tool that magically preserves the SVG dialect
in use. I just round-tripped a test file using https://convertio.co.
The PDF and the round-tripped SVG *look* the same as the original, but the
actual content of the SVG file is totally different, and fails svgcheck, so
is no longer conformant with RFC7996. The converter just happens to choose
a different way of representing the same image, since SVG is so versatile.

The converter also messed up the scalability of the image, which is really
annoying if you want the image to be viewable on a tiny screen.

Now I'll round-trip it a second time... once again, the input and output
SVG files are different, although only in a few places. So even the
conversion tools at convertio.co can't achieve idempotency with the SVG
that they themselves generate.

(For the record, convertio.co doesn't claim to be PDF/A conformant,
but I think that's beside the point here.)

   Brian

---

From: Leonard Rosenthol <[email-masked]>
Date: Sun, 30 Aug 2020 16:12:00 +0000

Brian - but what you describe below is a tooling problem not a technology or format issue.

There are ways in which all of the SVG semantics - or even the entire SVG itself(!) - could be included in the PDF/A file and round-tripped with correct fidelity (or even 100% identical bits).

Let's agree on what the goal is, come up with a standard that specifies how to achieve that, AND THEN we can get tools to comply.

Leonard

On 8/29/20, 1:04 AM, "rfc-interest on behalf of Brian E Carpenter" <[email-masked] on behalf of [email-masked]> wrote:

    Larry,

    in use. I just round-tripped a test file using https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconvertio.co%2F&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cf8108cd02b334c72415d08d84bd8f976%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637342742565624784&amp;sdata=1m8XMdcHkgmgUCf%2B4%2F0wEOI37suRSejjVpsbqqsHXI4%3D&amp;reserved=0.

       Brian

    _______________________________________________
    rfc-interest mailing list
    [email-masked]
    https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fmailman%2Flistinfo%2Frfc-interest&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cf8108cd02b334c72415d08d84bd8f976%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637342742565624784&amp;sdata=kN8z9faPWo3aCpTjdQNfyHn0W%2BelVT7%2BTdIW45CBtl8%3D&amp;reserved=0

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Aug 2020 09:09:18 +1200

> Brian - but what you describe below is a tooling problem not a technology or format issue.

IMHO the underlying problem is that SVG allows multiple ways of representing the same image, and a subsidiary problem is that it allows positions to be represented as real numbers. The SVG spec says:
"Unless stated otherwise, numeric values in SVG attributes and in properties that are defined to have an effect on SVG elements must support at least all finite single-precision values supported by the host architecture."
In other words, the precision of positions is host-dependent. I don't know enough about PDF to know how that affects the conversion algorithm, but I suspect it means that...

> There are ways in which all of the SVG semantics - or even the entire SVG itself(!) 

... only embedding the SVG itself would be guaranteed to round-trip in all cases. Since that is exactly what we do in xml2rfcV3, I don't see what we'd gain by doing it in PDF/A instead.

> - could be included in the PDF/A file and round-tripped with correct fidelity (or even 100% identical bits).

Who is the arbiter of "correct fidelity"? The judge and jury in a patent infringement or copyright case? The only safe standard is "identical bits" or at least "identical string of UTF-8 characters". We've relied on "identical string of ASCII characters" for many years.

> Let's agree on what the goal is, come up with a standard that specifies how to achieve that, AND THEN we can get tools to comply.

Sure. We'd need to start with some canonicalization rules for SVG. We need to look again at RFC7996 in any case. But I don't think that relying on host representation of real numbers is ever going to be OK. (Is there a reason that SVG didn't use a host-independent formulation for its statement about precision?)

    Brian

---

From: Leonard Rosenthol <[email-masked]>
Date: Sun, 30 Aug 2020 22:09:37 +0000

Brian - not sure what you are looking at, but in SVG 1.1 (https://www.w3.org/TR/SVG11/single-page.html#types-DataTypeNumber), I see the following definition for a `<number>`

	<number>
	Real numbers are specified in one of two ways. When used in a style sheet, a <number> is defined as follows:

	number ::= integer
           		| [+-]? [0-9]* "." [0-9]+
	This syntax is the same as the definition in CSS ([CSS2], section 4.3.1).

	When used in an SVG attribute, a <number> is defined differently, to allow numbers with large magnitudes to be specified more concisely:

	number ::= integer ([Ee] integer)?
           		| [+-]? [0-9]* "." [0-9]+ ([Ee] integer)?
	Within the SVG DOM, a <number> is represented as a float, SVGNumber or a SVGAnimatedNumber.

As noted, this is consistent with how "numbers" are used in the rest of the open web platform (eg. CSS, HTML, etc.)

Concerning use in PDF or PDF/A, I don't think that Larry was suggesting that it was being used *instead of* xml2rfcv3...but it is one of the normative formats produced from that grammar.   As such, I believe Larry was pointing out the importance of being able to roundtrip from the SVG in the xml2rfcv3->PDF/A->SVG for anyone that might need it.  As mentioned, there are methods to embed the original SVG directly into the PDF at authoring time and then that SVG could be extracted downstream. The tool used by the IETF supports that option, but I don't believe it is enabled.  Something to consider for the future.

> Who is the arbiter of "correct fidelity"?
>
I would argue that data which is semantically identical is correct.  The fact that you can serialize the same data in different ways isn't bad - as they are semantically identical.  However I don’t see a need to debate that at this time...

Leonard 

On 8/30/20, 5:09 PM, "Brian E Carpenter" <[email-masked]> wrote:

        Brian

    >     in use. I just round-tripped a test file using https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconvertio.co%2F&amp;data=02%7C01%7Clrosenth%40adobe.com%7Ccb6c5f20901348ae829808d84d28f979%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637344185664248727&amp;sdata=eN6bT%2FbUwXBQx6iRRWElVJaiZ4Tvw3DT0sV7hvn3Rwc%3D&amp;reserved=0.
    >     https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fmailman%2Flistinfo%2Frfc-interest&amp;data=02%7C01%7Clrosenth%40adobe.com%7Ccb6c5f20901348ae829808d84d28f979%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637344185664258722&amp;sdata=mM1UUMwFMAvTOrS9ongBH1OoQHxHJ6OIv0cQQHNsdvQ%3D&amp;reserved=0
    >

---

From: Larry Masinter <[email-masked]>
Date: Sun, 30 Aug 2020 15:14:29 -0700

Leonard, this IS a tooling problem. There is already a specification for what was expected  RFC 7996, which starts with SVG Tiny. The problem is there is no tools for producing those kinds of SVGs, and it leaves out essential elements.

The goal is to have multiple renditions of the same document for which there shouldn't be any doubt in anyone's mind that what they see and make sense of is exactly the same no matter how the user views the document, at least as far as the renditions produced by the RFC Editor.

IETF is trying to do something no other SDO does, which is to make the content independent of the form.

They're already attaching the original submission (RFC XML) and SVG as attachments. So round-tripping bit-for-bit can't be the goal (since it's already there ). It was more like the PDF/A guarantee that if we all choose it, it becomes the archival document standard. The proof is the uptake.

> From: Leonard Rosenthol <[email-masked]>
> Sent: Sunday, August 30, 2020 9:12 AM
> To: Brian E Carpenter <[email-masked]>; Larry Masinter
> <[email-masked]>; 'Brotman, Alex' <[email-masked]>; rfc-
> [email-masked]
> Cc: 'BIMI (IETF)' <[email-masked]>
> There are ways in which all of the SVG semantics - or even the entire SVG
> itself(!) - could be included in the PDF/A file and round-tripped with correct
> fidelity (or even 100% identical bits).
> 
> Let's agree on what the goal is, come up with a standard that specifies how to
> achieve that, AND THEN we can get tools to comply.
> 
> Leonard
> 
> On 8/29/20, 1:04 AM, "rfc-interest on behalf of Brian E Carpenter" <rfc-
> [email-masked] on behalf of [email-masked]>
> wrote:
> 
>     Larry,
> 
>     in use. I just round-tripped a test file using
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconver
> tio.co%2F&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cf8108cd02b33
> 4c72415d08d84bd8f976%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C
> 0%7C637342742565624784&amp;sdata=1m8XMdcHkgmgUCf%2B4%2F0wEOI
> 37suRSejjVpsbqqsHXI4%3D&amp;reserved=0.
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
> fc-editor.org%2Fmailman%2Flistinfo%2Frfc-
> interest&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cf8108cd02b334c
> 72415d08d84bd8f976%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C637342742565624784&amp;sdata=kN8z9faPWo3aCpTjdQNfyHn0W%2BelV
> T7%2BTdIW45CBtl8%3D&amp;reserved=0

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Aug 2020 11:36:57 +1200

> 	Real numbers are specified in one of two ways. When used in a style sheet, a <number> is defined as follows:

Yes, and that's all fine. But when you start converting formats, and the round trip converts 
32.459999 into 32.424, there's clearly a problem of how real numbers work in a particular hardware and floating point library, and/or a difference in how real numbers are handled in the two formats. So specifying how real numbers are represented in various SGML dialects is only part of the problem.

I'm no expert on this, but https://en.wikipedia.org/wiki/IEEE_754 tells me that it's very complex and there are many cans of worms.

Regards
    Brian

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 31 Aug 2020 10:52:27 +0900

Hello Brian, others,

>> Brian - not sure what you are looking at, but in SVG 1.1 (https://www.w3.org/TR/SVG11/single-page.html#types-DataTypeNumber), I see the following definition for a `<number>`

[snip]

> I'm no expert on this, but https://en.wikipedia.org/wiki/IEEE_754 tells me that it's very complex and there are many cans of worms.

Floating point numbers are what they are, even if many people, including 
engineers, tend to ignore or suppress the details.

The programming language Ruby has some pointers to information about 
floating point numbers on the otherwise quite small top page of their 
bug tracker (https://bugs.ruby-lang.org/). The reason for this is the 
frequency with which we get bug reports about floating point number 
calculations that turn out not to be bugs.

For people interested in details, I suggest reading "What Every Computer 
Scientist Should Know About Floating-Point Arithmetic"
(https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html).

Btw, if a conversion changes 32.459999 into 32.424, then we indeed have 
a serious problem. Floating point arithmetic isn't that inaccurate, even 
on the worst hardware. If the conversion is from 32.459999 to 32.46, on 
the other hand, then that's entirely possible, and shouldn't create any 
problems in patent litigation.

Regards,   Martin.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Aug 2020 14:14:18 +1200

> problems in patent litigation.

The case in point involves two particular converters from SVG to PDF and
back, so it's presumably a complex interaction between those two formats
and how the converters work, rather than a gross error in the floating point
implementations. I don't think we need to debug it, but simply to note
that if we stick to the current doctrine that the xml2rfcv3 file *is*
the canonical form of an RFC, we will be OK. If we try to define a
reversible translation to another format, I think we would come to deeply
regret it.

   Brian

---

From: "Brotman, Alex" <[email-masked]>
Date: Mon, 31 Aug 2020 14:34:25 +0000

Brian,

We've sort of seen the same issue, though we expect that tools will catchup over time.   That being said, I know that Inkscape does not today support SVG Tiny 1.2 as an export format.  Illustrator does a reasonable job with Tiny, though seems to have a few bugs during export.  I haven't yet tried Dia or Scribus (I believe it also supports export to SVG).   Even with support in tools lacking today, we'd like to work toward this goal of creating this format.  We've had good success thus far getting images to conform without skewing the intended representation.

> From: bimi <[email-masked]> On Behalf Of Brian E Carpenter
> Sent: Friday, August 28, 2020 6:26 PM
> Subject: Re: [Bimi] [rfc-i] SVG P/S Feedback
>
> Alex,
>
> 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
> (https://urldefense.com/v3/__https://www.ietf.org/id/draft-carpenter-
> eligibility-expand-04.html*section-
> appendix.a__;Iw!!CQl3mcHX2A!Sw3IJrGz1vhg-
> lLQ4qwXhNufnJeIQBquFhOycYTbRb_sEE7UjU8crw2Ud3Do0KOSSpx6kxA$ ) was
> quite a saga.
>
> Regards
>    Brian Carpenter
>
> > 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
> 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
> > [1]
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-svg
> > -tiny-ps-abrotman/__;!!CQl3mcHX2A!Sw3IJrGz1vhg-
> lLQ4qwXhNufnJeIQBquFhOy
> > cYTbRb_sEE7UjU8crw2Ud3Do0KOSmpkX2ck$
> >
> > --
> > Alex Brotman
> > https://urldefense.com/v3/__https://www.rfc-editor.org/mailman/listinf
> > o/rfc-interest__;!!CQl3mcHX2A!Sw3IJrGz1vhg-
> lLQ4qwXhNufnJeIQBquFhOycYTb
> > Rb_sEE7UjU8crw2Ud3Do0KOSV9_wXTY$
> >
>
> --
> bimi mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bimi__;!!C
> Ql3mcHX2A!Sw3IJrGz1vhg-
> lLQ4qwXhNufnJeIQBquFhOycYTbRb_sEE7UjU8crw2Ud3Do0KOSdnTI4aY$

---

From: "John Levine" <[email-masked]>
Date: 31 Aug 2020 12:18:30 -0400

In article <[email-masked]> you write:
>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**.

I agree that 7996 has problems. We have not yet published an RFC with
SVG pictures and I expect that when we do, we'll have to revise it.

In any case, that profile is designed for documents, and there's no
reason to assume it would be appropriate for logos displayed next to
your junk mail.

R's,
John