Re: Whats the status on .svgz support from file://

(Moving this to the main list, since it's a substantive issue, not a
working group administrative issue)

On 26 October 2016 at 11:47, Smailus, Thomas O <Thomas.O.Smailus@boeing.com>
wrote:

> I’m curious where things stand with SVG 2 on svgz support with respect to
> reading an SVG document form file://
>
> The server is the file system.  Does a conforming SVG Interpreter need to
> support SVG content encoded in the svgz compression format?
>
>
>
> Thomas
>

I did the update & re-write of the conformance section. I was trying not to
make any unintentional changes, and I didn't think about this particular
question, so I also didn't add any clarifications for it.

For reference, here's SVG 1.1: https://www.w3.org/TR/SVG11/conform.html
And here's SVG 2:
https://www.w3.org/TR/SVG2/conform.html#SoftwareConformanceClasses

Both state in the bullet list of requirements for Conforming SVG Viewers:


   - SVG implementations must correctly support gzip-encoded
   <http://www.ietf.org/rfc/rfc1952.txt> [rfc1952
   <https://www.w3.org/TR/SVG2/refs.html#ref-rfc1952>] and deflate-encoded
   <http://www.ietf.org/rfc/rfc1951.txt> [rfc1951
   <https://www.w3.org/TR/SVG2/refs.html#ref-rfc1951>] data streams, for
   any content type (including SVG, script files, images). SVG implementations
   that support HTTP must support these encodings according to the HTTP 1.1
   <http://www.ietf.org/rfc/rfc2616.txt> specification [rfc2616
   <https://www.w3.org/TR/SVG2/refs.html#ref-rfc2616>]; in particular, the
   client must specify with an "Accept-Encoding:" request header [
   HTTP-ACCEPT-ENCODING
   <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3>] those
   encodings that it accepts, including at minimum gzip and deflate, and then
   decompress any gzip-encoded <http://www.ietf.org/rfc/rfc1952.txt> and
   deflate-encoded <http://www.ietf.org/rfc/rfc1951.txt> data streams that
   are downloaded from the server. When an SVG viewer retrieves compressed
   content (e.g., an .svgz file) over HTTP, if the "Content-Encoding" and
   "Transfer-Encoding" response headers are missing or specify a value that
   does not match the compression method that has been applied to the content,
   then the SVG viewer must not render the content and must treat the document
   as being in error
   <https://www.w3.org/TR/SVG2/implnote.html#ErrorProcessing>.

If you take out the parts about HTTP, you still have a requirement for all
conforming SVG viewers to support GZip-encoded content, which for file
system access would primarily be about .svgz.

In addition, as you point out, the operating system file server and the
browser's file: protocol together count as a SVG Server. To be conforming,
the should therefore properly identify .svgz files as SVG mime type to
browsers accessing local files. I'm not sure whether the OS file systems
declare MIME types in other software contexts, but if so the same rule
would apply.

If you have suggestions for clarifications, or concerns about this
requirement, open an issue on https://github.com/w3c/svgwg/issues.

This entire section was much neglected in the editing process, because it
was tucked away in an appendix in SVG 1.1, even though it was marked as
normative requirements.  I updated it wherever we had conflicting
requirements elsewhere, or where referenced specs were out of date, but I
didn't change most of these specific details.

~Amelia