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

Re: SVG12: image/svg+xml gzip requirements

From: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
Date: Wed, 08 Dec 2004 15:10:40 -0500
Message-ID: <41B75FC0.1050406@Kodak.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: www-svg@w3.org, ietf-types@iana.org

Bjoern Hoehrmann wrote:

> * 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.

    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?

>>   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.

    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
ignored.

    This would keep existing XML processors conformant to the
mime-type registration (since such transfers violate the
mime-type registration[*] and anyway ignoring the 'non-existent'
parameter is merely a suggestion).  It would also give authors 
something to point to when convincing Admins that a charset should not
accompany the SVG content.

>>   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.

    Sorry, I was referring to my proposal here.

>>   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.

   I'll take that as a no.

[*] It doesn't assume that the receiver has special knowledge of
image/svg+xml but it does "require" it of senders.
Received on Wednesday, 8 December 2004 20:10:44 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:29 GMT