Subject: [media-types] image/svg+xml-compressed

From: Russ Housley <[email-masked]>
Date: Tue, 15 Feb 2022 15:36:55 -0500

The LAMPS WG is considering an update to RFC 3709 and RFC 6170.  These associate images with certificates.  The most widely used implementation embeds a compressed SVG image in the certificate.  As best I can tell, W3C registered image/svg+xml, but image/svg+xml-compressed has not yet been registered.

I see from places like https://reposcope.com/mimetype/image/svg+xml-compressed that this media type is being used.

Is anyone else working on the IANA registration for image/svg+xml-compressed?  The rfc3709bis document seems like an odd place to do that, but I can do it if no one else is aggressing it.

Russ

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 16 Feb 2022 11:11:23 +0000

Hi Russ,

> I see from places like https://reposcope.com/mimetype/image/svg+xml-compressed that this media type is being used.

"image/svg+xml-compressed" is not actually a valid media type, because 
it relies on an existence of "+xml-compressed" structured suffix, which 
is not registered. See 
<https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml> 
for the list of registered suffixes.

So this media type should have been something like image/svg-xml+gzip  
or image/svg+xml+gzip (if the MEDIAMAN WG decides that multiple suffixes 
are Ok).

Alternatively, "+xml-compressed" structured suffix can be registered. It 
is hard to predict how easy or difficult it would be.

> Is anyone else working on the IANA registration for image/svg+xml-compressed?  The rfc3709bis document seems like an odd place to do that, but I can do it if no one else is aggressing it.

Best Regards,

Alexey

---

From: Russ Housley <[email-masked]>
Date: Wed, 16 Feb 2022 09:36:44 -0500

Alexey:

Thanks for your guidance.  I'll plan to use image/svg+xml+gzip, and home that the MEDIAMAN WG supports this approach.

Russ

> On Feb 16, 2022, at 6:11 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Russ,
> 
> "image/svg+xml-compressed" is not actually a valid media type, because it relies on an existence of "+xml-compressed" structured suffix, which is not registered. See <https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml> for the list of registered suffixes.
> 
> So this media type should have been something like image/svg-xml+gzip  or image/svg+xml+gzip (if the MEDIAMAN WG decides that multiple suffixes are Ok).
> 
> Alternatively, "+xml-compressed" structured suffix can be registered. It is hard to predict how easy or difficult it would be.
>

---

From: Manu Sporny <[email-masked]>
Date: Wed, 16 Feb 2022 09:39:48 -0500

On 2/16/22 6:11 AM, Alexey Melnikov wrote:
> So this media type should have been something like image/svg-xml+gzip  or 
> image/svg+xml+gzip (if the MEDIAMAN WG decides that multiple suffixes are
> Ok).

Russ, if you think you are interested in going with the latter (a number of
W3C WG's have effectively chosen that direction already), a quick review of
this spec would be appreciated:

https://www.ietf.org/archive/id/draft-ietf-mediaman-suffixes-00.html

I'd also be happy to put the image/svg+xml+gzip example into the spec as it's
another example of a multi-level structured suffix.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/

---

From: Manu Sporny <[email-masked]>
Date: Wed, 16 Feb 2022 10:06:03 -0500

On 2/16/22 9:36 AM, Russ Housley wrote:
> Thanks for your guidance.  I'll plan to use image/svg+xml+gzip, and home 
> that the MEDIAMAN WG supports this approach.

Russ, could you elaborate on why you feel that's the best approach? I'm one of
the Editors for the spec that would make that structure recognized as a valid
structure, and I'm unabashedly trying to mine your perspective on this.

You had a choice, and you decided to go down the path you stated above. Why?

-- manu