[svg-native] What should the file extension be?

[litherum]

Should the file extension be .svg? Or something more specific?

[AmeliaBR]

#266 is related (request for a separate MIME type that behaves like other image types re security)

MIME types and file extensions don't have to go hand-in-hand, of course. Having a separate file extension would make it easier for server configuration. But it's less useful for compatibility, since existing software wouldn't recognize it as SVG.

[jarek-foksa]

The initial draft was proposing .svn extension, which I find rather confusing since Subversion is still quite popular. If a custom extension is used, I would opt for something like .svgn or .nsvg.

[dirkschulze]

I strongly suggest keeping .svg. SVG Native is 100% compatible to SVG and there is no need to exclude SVG Native from the dozens of SVG viewers that exist today and might not get updated anymore to be able to open the new file extension as well.

When it comes to the MIME type the same may apply but on the server side. It took years to get image/svg on the list of supported MIME types for Apache. SVG Native might not be in the situation where it gets added at all. Authors might use image/svg right from the beginning to avoid these problems.

I have a lot of scepticism about a new MIME type.

[svgeesus]

I strongly suggest keeping .svg.

That has a strong downside. Existing servers will serve it as image/svg+xml, which means that browsers will render it differently (in the case of features not supported by SVG Native) compared to an SVG Native renderer. We don't want that (see #665)

[dirkschulze]

@svgeesus We already agreed that a valid SVG Native documents will always look the same in a SVG Native viewer as in a full SVG renderer. If the document is not valid to the subset the behavior is unspecified anyway. Therefore, I don’t see a benefit of a new MIME type but rather the problem of SVG Native not being supported in many many years! Keep in mind that it doesn’t only take time to get the support into the source code of server software but significantly longer to servers directly.

[BigBadaboom]

I know the difficulty of getting a new mime type etc, but just one comment re this...

One of the use cases for this might be things like avatars for websites etc. Currently SVG is not typically allowed in these cases due to the perceived risk of SVG's scripting and interactivity. If there isn't a mime type to put in a file input accept attribute, those sites will probably continue to reject all SVG formats, even though SVG Native would be safe.

[dirkschulze]

@BigBadaboom that is a good point. What holds you up to still add SVG features to that document? Or the renderer to be a full-SVG-renderer able to process this SVG file?

On the other hand, the MIME type maybe a way to enforce an SVG parser/renderer to go to a more strict mode if it would have one. It requires the whole industry to agree to fall back to the strict mode and not simply use the full-SVG parser to be effective though.

That said, SVG used in an <img> element in HTML, <image> in SVG or as CSS image already has a lot of requirements and restrictions that make it suitable to use the SVG as avatar on social platforms. The industry already agreed and implemented those restrictions specifically aiming the privacy and tracking concerns of social media platforms and the users and we still are not allowed to use SVG images. SVG Native is not adding more security IMO.

[dirkschulze]

Another question, can we even keep .svg if we change the MIME type? IIRC all platforms allow to bind an extension to a MIME type. I don't think an extension is supposed to have more than one MIME type.

[jarek-foksa]

Also, should there be an another extension for compressed SVG Native documents? If so, then the possible options could look like this:

New extension, new mime type

Extension	Mime type	Compression	Format
.svg	image/svg+xml	No	SVG
.svgz	image/svg+xml	Yes	SVG
.svgn	image/svgn	No	SVG Native
.svgnz	image/svgn	Yes	SVG Native

New extension, old mime type

Extension	Mime type	Compression	Format
.svg	image/svg+xml	No	SVG
.svgz	image/svg+xml	Yes	SVG
.svgn	image/svg+xml	No	SVG Native
.svgnz	image/svg+xml	Yes	SVG Native

Old extension, old mime type

Extension	Mime type	Compression	Format
.svg	image/svg+xml	No	SVG or SVG Native
.svgz	image/svg+xml	Yes	SVG or SVG Native

[BigBadaboom]

@dirkschulze

What holds you up to still add SVG features to that document?

I would assume those sites wouldn't just trust the user and browser. I imagine they would at least run an SVG Native linter over the upload.

[svgeesus]

Another question, can we even keep .svg if we change the MIME type?

Realistically no (in theory we could, but most servers map file extensions to MIME types 1:1 so this would be a very bad idea in practice).

The use case of getting SVG in places (forum and wordpress image uploads, etc) where it is currently banned (because it has script execution, external references, and interactivity) is a significant one in my opinion. And that argues for a new MIME type.

[css-meeting-bot]

The SVG Working Group just discussed SVG Native file extension.

The full IRC log of that discussion

<AmeliaBR> Topic: SVG Native file extension
<AmeliaBR> Github: https://github.com//issues/664
<AmeliaBR> Chris: to me, file extension and MIME type are intrically connected. Most servers map extensions to media type. Different extensions same media type is do-able, but what's the point?
<AmeliaBR> ... Given that there are servers that restrict the use of SVG (e.g., image uploads from user) because of security requirements, so a new extension & type is useful.
<AmeliaBR> ... The media type is more important. File extension is just a representation of that.
<AmeliaBR> Dirk: The downside of a new type/extension is that existing tools would not be able to open by default.
<AmeliaBR> ... But, we are designing a format for the future.
<AmeliaBR> Myles: Implementations can be divided & some don't currently support all of SVG, anyway.
<AmeliaBR> ... Browsers should render it anyway regardless of Mime type, right?
<AmeliaBR> Chris: Maybe, but it depends. Browsers do some sniffing, but won't do anything.
<AmeliaBR> Dirk: Browsers may not be the main issue, since they're likely to be early adopters.
<AmeliaBR> Amelia: It may also depend on what the new type is. If it's still a valid XML type, browsers may be able to handle it anyway. But desktop software is going to look at the extension.
<AmeliaBR> ... Might need education for authors: you may need to save as a different extension. Servers may need to respond based on HTTP headers.
<AmeliaBR> Sairus: Also worth considering whether we want to create a limited set & then expand it in the future. Would that be a different type?
<AmeliaBR> Myles: If we end up creating too many different subsets, I think we then lose any benefit from having a defined subset at all.
<AmeliaBR> Sairus: So we really want this to be the defined scope & then stick with that.
<AmeliaBR> Dirk: Myles also mentioned the possibility of a distinction internally, e.g., a version attribute.
<AmeliaBR> Chris: This is something we've dealt with before, in XML and in SVG. version attribute and profile attribute. And the end result is that it always gets ignored.
<AmeliaBR> Myles: Does that mean that you think a stronger enforcement at Mime type level is necessary.
<AmeliaBR> Chris: I don't know. Just pointing out the difficulties. Need strong implementer support.
<AmeliaBR> Myles: One use case: for the OS, we might want to open a full SVG file in browser, a native SVG file in image preview. So we'd need a different file extension to do that.
<AmeliaBR> Dirk: Are we leaning towards a decision here?
<AmeliaBR> ... From Adobe's perspective, we'd like a clear distinction. We don't care whether it's internal (attribute) or external (extension / MIME type).
<AmeliaBR> Sairus: I think we need to think more carefully about all the use cases.
<AmeliaBR> Dirk: Ok, leave the issue open for now.
<AmeliaBR> Amelia: It would help to write out, in the issue, the use cases & pros/cons for each.
<AmeliaBR> Myles: I'm not sure whether my use case also applies to Windows.
<AmeliaBR> Amelia: Yes, file associations to software are keyed on extensions. So you'd need different extensions to associate them with different viewers.
<AmeliaBR> Sairus: BTW, I spoke recently with some of the Microsoft team. Trying to get them engaged in this project.
<AmeliaBR> Myles: Ok, I'll ping them in the GitHub thread & see if we can get some input.

[litherum]

If the extension/mimetype is the same as SVG, then this format will be treated as Web content and opened with the browser when you double click on it, but if it's distinct, it can be treated differently. One of the goals of SVG Native is to work outside of the Web content, as a native image format.

@MilesMSCohen Do you have any thoughts?

[mro]

No renderer may naively trust neither mime nor extension – it has to be either strict (=safe) or trusting.

That's the decision to the consumer. Not the producer. So declaring safe via mime or extension isn't a security gain anyway.