Re: SVG12: image/svg+xml gzip requirements

* Thomas DeWeese wrote:
>    But this is a case of inconsistent meta-data.  The sender says
>that the data is not encoded, but the content indicates that it is
>GZIP encoded.  Thus the user agent is allowed via the TAG to notice
>this inconsistency and override the sender metadata (the UA at
>this point should also notify the user of the override).  Once it
>has overridden the sender data it can interpret the data stream as
>GZIP compressed and get a valid XML Document.

The TAG finding has no impact whatsoever on SVG Viewer conformance
requirements, I think the TAG will happily clarify this if you ask
for it on www-tag. You would need to argue that this is allowed by
the SVG Viewer conformance requirements. I think it is clear that
this is not allowed by those conformance requirements.

>    Saying there can/should not be a charset parameter for
>image/svg+xml or if there is one it _must_ match the XML document's
>encoding is not the same as defining inconsistent processing rules, it
>is supporting the TAG finding.

I agree that this is not the same thing, but I would like to point
out that the proposed MIME Type registration does not discuss that
such information must match, it rather requires implementations to
ignore the charset parameter if provided which is inconsistent with
the processing rules for all other XML MIME Types where it is re-
quired that the charset parameter is honored.

>    As I have stated before if senders conform to the mime-type
>registration no conflict can possibly occur, everyone processes the
>content consistently.

This is false.

>    What I don't get is why you think image/svg+xml can not possibly
>have anything different about it from text/xml.  Does this mean that
>all the SVG UA's are in error because they process the document
>and display it as graphics?  After all that isn't what existing XML
>processors do they must be broken...

What an SVG Viewer might do in addition to XML processing is not of
concern here, but the XML processing is.

>    I think that as long as someone _following_ the image/svg+xml
>mime-type registration does not break existing XML processors there
>is no legacy problem.  This would allow the registration to explicitly
>disallow charset and not break anything or require that it _always_
>match with undefined behavior if it doesn't.  If it specified the
>charset parameter was ignored that would be problematic.

The proposed reqistration renders a broad range of applications non-
conforming, I've already mentioned the W3C Markup Validator, the W3C
CSS Validator, Microsoft's MSXML 4/5 XML toolkit, and Batik. I have
not seen a revised registration proposal so I can't comment on that.

>    Does anyone think it really was a good idea to allow for a
>charset that differs from the content?  Or are we just propagating a
>bad decision on future generations?

RFC 3023 revisions are best discussed on ietf-xml-mime@imc.org.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Wednesday, 8 December 2004 19:35:44 UTC