Re: SVGT 1.2: Section 1.4, svgz

(This is the SVG Working Group response to
http://lists.w3.org/Archives/Public/www-svg/2005Dec/0308.html)
 
Eric,
Thanks for your suggestions. We are in general agreement with your
comments. 
 
We have decided to change the SVG spec in two places: add two sentences
to
Appendix D.5.2 (note: D.4.3 talks about HTTP requirements on servers,
whereas
D.5.2 talks about HTTP requirements on clients) and add a single
parenthetical
sentence to 1.4.
 
Right now Appendix D.5.2 (Conforming SVG Viewers) contains the following
statements about gzip-encoded data streams:
--------------------
SVG implementations must correctly support gzip-encoded [RFC1952] and
deflate-encoded [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 specification [RFC2616]; in
particular, the
client must specify with an "Accept-Encoding:" request header [
HTTP-ACCEPT-ENCODING] those encodings that it accepts, including at
minumum gzip
and deflate, and then decompress any gzip-encoded and deflate-encoded
data
streams that are downloaded from the server. Implementations must also
support
progressive rendering of compressed data streams.
--------------------
 
We have decided to insert the following two sentences into the above
text just
before the last sentence: 
--------------------
When an SVG viewer retrieves compressed SVG content (e.g., an .svgz
file) over
HTTP 1.1 or later, if the "Content-Encoding" response header is missing
or
specifies a value that does not match that matches 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}{hyperlink to
implnote.html#ErrorProcessing}}. SVG viewers must not render compressed
content
delivered over HTTP 1.0 since that protocol does not support appropriate
response headers to indicate that the content is compressed. 
--------------------
 
Right now, section 1.4 (SVG MIME type, file name extension and Macintosh
file
type) contains the following content: 
--------------------
It is recommended that SVG files have the extension ".svg" (all
lowercase) on
all platforms. It is recommended that gzip-compressed SVG files have the
extension ".svgz" (all lowercase) on all platforms.
 
It is recommended that SVG files stored on Macintosh HFS file systems be
given a
file type of "svg" (all lowercase, with a space character as the fourth
letter).
It is recommended that gzip-compressed SVG files stored on Macintosh HFS
file
systems be given a file type of "svgz" (all lowercase). 
--------------------
 
We have decided to add the following parenthetical sentence at the end
of
section 1.4: 
--------------------
(See {{Conformance Criteria}{hyperlink to conform.html}} for more
information
about gzip-compressed SVG files transmitted over HTTP.) 
--------------------
 
Regarding how the .svgz extension is "odd", the .svgz extension has been
part of
the SVG specification since SVG 1.0 and was also part of SVG Tiny 1.1;
thus,
whether it is "odd" or not is more philosophical at this point. .svgz is
required in SVG Tiny 1.2 for backwards compatibility with SVG Tiny 1.1.
 
Regarding whether it would have been better to use .svg.gz instead of
.svgz, 
it's too late to change now. The one bit of history relative to .svgz is
that
there was clear and strong community feedback when SVG 1.0 was developed
that there
had to be a compressed version of SVG or else SVG would be a non-starter
due to
file size issues. There were key constituencies in the SVG community who
were 
very sensitive to file size several years ago (when broadband was not so

prevalent). Also, for protocols (such as file: and ftp:) where do not
support 
compression, .svgz allows content to be delivered compressed. .svgz also
means 
that authoring tools can generate compressed content rather than
delivering 
uncompressed content and hoping that the server will maybe compress it
for you.
 
Regarding Jim Ley's comments in
http://lists.w3.org/Archives/Public/www-svg/2005Dec/0315.html about not
mandating particular error handling behavior, we do not believe that
these
latest spec changes mandate how to handle errors but only add
clarification
about when documents are in error.
 
Thanks for your comment. If you are unsatisfied with this response, then
please
let us know within two weeks.
 
Jon Ferraiolo
Adobe Systems, Inc.
Member SVG WG