Please add '.svgz': '.svg.gz' map to mimetypes.suffix_map

What are the media types, and are they registered with IANA?  A citation from http://www.isi.edu/in-notes/iana/assignments/media-types will be needed in order for this addition to happen if they are not x- types.

I checked out of curiousity, and the last time we added something to this table was .mp4, in 2007.

I'm not sure we are talking about the same table. I don't see .mp4 there.
    suffix_map = {
        '.tgz': '.tar.gz',
        '.taz': '.tar.gz',
        '.tz': '.tar.gz',
        '.tbz2': '.tar.bz2',
        }
*.svgz is gzipped *.svg files.

You are correct, I misread your message.  However, my point still stands.  .svg is not a file extension that appears in the types_map table, so adding the line you request to the suffix_map table is not something we would do by itself.  So, to correct my question, what is the media type for '.svg'?

*.svg and *.svgz files have image/svg+xml media type.

I have following in /etc/mime.types
callisto ~ $ grep svg /etc/mime.types
image/svg+xml				svg svgz

This media type does not appear in the official IANA registry.  Has it not yet been officially approved?  If you want to argue that its use is common enough and its approval immanent enough (I do see that it has been submitted) to warrant inclusion in Python prior to IANA approval, I think you will have to make this case to the python-dev mailing list.

This issue is actually a request to add .svg to the types map and the the abbreviation .svgz for .svg.gx to the suffix_map.

I believe Scalable Vector Graphics are well on the way to becoming *the* standard vector graphics format for the web, especially with upcoming IE9 support. https://secure.wikimedia.org/wikipedia/en/wiki/Svg
It (they) are already supported by the other major browsers. In addition, "Google announced on 31 August 2010 that it had begun to index SVG content on the web, whether it is in standalone files or embedded in HTML."

So it might be sensible to add these now rather than two years from now. But if it is too late for 3.2, then I expect addition for 3.3 will be obvious.

Separate issue: from the mimetypes doc ...
"MimeTypes.types_map 
Dictionary mapping filename extensions to MIME types. This is initially a copy of the global types_map defined in the module."

But on Windows, I get a *tuple*, not a dict, of two dicts. The first has just a few pairs
>>> mi.types_map[0]
{'.xul': 'text/xul', '.pic': 'image/pict', '.pict': 'image/pict', '.jpg': 'image/jpg', '.rtf': 'application/rtf', '.pct': 'image/pict', '.mid': 'audio/midi', '.midi': 'audio/midi'}
and the second about a hundred more. Is this a bug?

I think a variance from the policy stated in mimetypes is quite possible, and the kind of information you provide, Terry, is a step in that direction.  We would need release manager approval, of course, since we are in Beta, but this is a small enough change I think it would fly, assuming the policy variance is approved.

For types_map, it's a doc bug.  It is indeed a tuple of dictionaries, the first being the limited, 'strict' set and the second normally including stuff from the "standard locations", which on windows includes the registry.

So, there is an argument in favor of adding the suffix map even if the types_map isn't updated for .svg, since the .svg mapping could come from one of the 'standard locations'.  I'd rather add both, though.

+1 on adding SVG types in 3.2 or 3.3.

Patch attached.

The instructions, after editing the url, are
    # Before adding new types, make sure they are either registered with IANA,
    # at http://www.iana.org/assignments/media-types
    # or extensions, i.e. using the x- prefix

Since there is no registration yet, I add the x- prefix. I presume that can be deleted without harm when it is registered. David, is that true?

Georg, is this OK for 3.2c1?
It can only break code depending on the entries not existing.

Shouldn't .svgz be also added as 'image/x-svg+xml'?

No, the other combined suffixes are not either.

I believe the patch should add the used but non-standard image/svg+xml type to the common_type dictionary, not invent a new x- type.

Yes, adding the x- version would probably be pointless as most likely nobody uses it.

Has anyone found any definitive info on where exactly in the approval process image/svg+xml is?

I think we should probably just go ahead and put it in, but it would be nice to link to some mailing list discussion somewhere that indicates that it is solidly standards track.

I found a mailing list posting from 2000 about browser support.

I found this: http://www.w3.org/TR/SVG/intro.html from June 2010 saying the registration was in progress at the w3c.  How w3c registration relates to IANA registration is not entirely clear, but most likely IANA wouldn't register it without w3c approving it first.

RFC 3023 mentions it and says it hasn't been approved yet so it shouldn't be used.  That was in 2001.

Why the incredibly long delay?

As best as I can guess, the mime-type registration is conditioned on the acceptance of the underlying SVG standard it references, and that standard (SVG 1.1) has not yet been ratified by the W3C, which is, if I'm underanding the RFCs correctly, required for IANA approval of the media type request.  SVG 1.1 has, according to wikipedia, been put out for Last Call.

All of which seems pretty irrelevant to the value and likely stability of the image/svg+xml name itself.  Since all the major browsers are supporting it, as far as I can tell, I think Python should too.

I obviously misunderstood the instruction about 'x-' and will remove that. Should I leave the entry where it is or move as Éric suggested?

I’m not sure; the common_types is actually for invalid but used types, like image/jpg (the correct one is image/jpeg and is listed in types_map).  The status of IANA registration is unclear (thanks David for looking at that); since common tools understand that media type, let’s pretend it’s registered.

No, I don't think it qualifies as a common_type.

But since this is technically a feature request we need Georg's approval for the commit.

Got approval from Georg on IRC, so go ahead and commit it, Terry.  Or assign it to me if you'd rather I do it.

r87460