W3C home > Mailing lists > Public > www-svg@w3.org > December 2004

Re: SVG12: image/svg+xml gzip requirements

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Wed, 08 Dec 2004 21:45:41 +0100
To: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
Cc: www-svg@w3.org, ietf-types@iana.org
Message-ID: <41c462b5.466627781@smtp.bjoern.hoehrmann.de>

* Thomas DeWeese wrote:
>> 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.
>    Huh?  If the network layer detects that the HTTP response
>is in fact GZip encoded even though the header isn't set and decodes
>it why is this a problem?

Because such software does not interoperate with software that does not
perform such error correction. Would you also argue that for a ISO-8859-
1 encoded document

  Content-Type: image/svg+xml

  <?xml version="1.0"?>

the "network layer" may detect that the resource is ISO-8859-1 encoded
and decodes it? The XML 1.0 Recommendation requires here, too, that the
processor aborts normal processing and reports a fatal error to the
application. I am not sure where you draw the line between errors this
"network layer" may correct.

>    I'll agree with this.  However you should then agree that there is
>no problem if the SVG mime-type registration states that there is _no_
>charset parameter for image/svg+xml, and merely suggests that if a
>processor encounters this non-existing parameter that it should be

The proposed registration implies "MUST ignore", changing that to SHOULD
ignore is even worse as it explicitly allows non-interoperable behavior.
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 20:46:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:04 UTC