Re: [ietf-types] Additional comments on image/svg+xml
Chris Lilley <chris@w3.org> Thu, 18 November 2010 16:30 UTC
Return-Path: <chris@w3.org>
X-Original-To: ietf-types@core3.amsl.com
Delivered-To: ietf-types@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC18E28C0E5 for <ietf-types@core3.amsl.com>; Thu, 18 Nov 2010 08:30:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.599
X-Spam-Level:
X-Spam-Status: No, score=-12.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPIcvBsr9w24 for <ietf-types@core3.amsl.com>; Thu, 18 Nov 2010 08:30:53 -0800 (PST)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id CB53928C0CF for <ietf-types@ietf.org>; Thu, 18 Nov 2010 08:30:52 -0800 (PST)
Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtpa (Exim 4.69) (envelope-from <chris@w3.org>) id 1PJ7OZ-0003K3-ND; Thu, 18 Nov 2010 11:31:35 -0500
Date: Thu, 18 Nov 2010 17:30:02 +0100
From: Chris Lilley <chris@w3.org>
X-Mailer: The Bat! (v3.95.6) Home
Organization: W3C
X-Priority: 3 (Normal)
Message-ID: <639427485.20101118173002@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>
In-Reply-To: <4CE4EB0F.1000307@gmx.de>
References: <AANLkTim5-=3A68M5GveeaOBQb8QtghUUWDerRBY3arxH@mail.gmail.com> <4C816A6F.40402@gmx.de> <4C873B4E.8040107@it.aoyama.ac.jp> <4CD2E04F.8070307@gmx.de> <4CE4EB0F.1000307@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Alexey Melnikov <alexey.melnikov@isode.com>, ietf-types@alvestrand.no, ietf-types@ietf.org
Subject: Re: [ietf-types] Additional comments on image/svg+xml
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Chris Lilley <chris@w3.org>
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Nov 2010 16:30:54 -0000
On Thursday, November 18, 2010, 9:59:59 AM, Julian wrote: JR> Hi, JR> we do not seem to make any progress. Every time we seem to make progress, (most recently at TPAC when i discussed this with Alexey) someone comes a day later suggesting a change which is incompatible with deployed tools and content, or ill-advised, or both. JR> How about publishing a small IETF document registering the type, JR> delegating for most of the content to the W3C SVG spec, but pointing out JR> that gzipped SVG is *not* conforming image/xvg+xml content? JR> At least that would populate the registry with useful information. I was about to populate it, when you suggested a breaking change, Julian Existing tools generate and handle gzipped svg just fine, as they have since, erm, 1998 or so. And they are happy to consider that it has both a content-type and also an encoding. JR> On 04.11.2010 17:33, Julian Reschke wrote: >> On 08.09.2010 09:29, "Martin J. Dürst" wrote: >>> Exactly what Julian said below. There are generic XML applications that >>> assume they can process all types that end in "+xml", and would be >>> hopelessly confused when seeing some compressed stuff. You seem to be assuming that, in a MIME environment, they would see the compressed stuff. The point of labelling it is that it can be recognised, decompressed, and handed off to the 'generic application'. >>> Regards, Martin. >>> ... >> Hi, >> picking up an old thread. We talked about this yesterday evening at the >> W3C TPAC reception, and I believe that we do not really disagree on what >> should or should not be done, but just on the right way to phrase it >> properly. >> (Chris, please correct me if I'm getting wrong what you said). >> The main use case for "svgz" is that you could configure the web server >> to serve the content *as stored on disk* as >> Content-Type: image/svg+xml >> Content-Encoding: gzip >> I don't think anybody disagrees that this is a good way to serve SVG >> content (I'll stick to Content-Encoding as opposed to Transfer-Encoding; >> it really doesn't change the argument). >> The important point here is that applications using HTTP *usually* will >> see the uncompressed XML, and treat it accordingly (this is certainly >> true for XmlHttpRequest, for example). >> I'm not completely sure how using "svgz" instead of "svg.gz" as >> extension changes this; but let's assume there are servers where it helps. >> Now does this make the gzipped version of SVG content valid content >> according to the media type? No. We also wouldn't claim that the fact >> that we transfer HTML with >> Content-Type: text/html >> Content-Encoding: gzip >> makes gzipped HTML files actual HTML files, right? (If we did, we had to >> rewrite MANY media type registrations). >> Looking at the current registration template >> (<http://dev.w3.org/SVG/profiles/1.1F2/publish/mimereg.html>, hopefully >> this is the right one...): >> "SVG documents may be transmitted in compressed form using gzip >> compression. For systems which employ MIME-like mechanisms, such as >> HTTP, this is indicated by the Content-Encoding or Transfer-Encoding >> header, as appropriate; for systems which do not, such as direct >> filesystem access, this is indicated by the filename extension and by >> the Macintosh File Type Codes. In addition, gzip compressed content is >> readily recognised by the initial byte sequence as described in >> [RFC1952] section 2.3.1." >> Question: why is this under "Security Considerations"??? >> All of this is correct, but it suggests that instances of gzipped SVG >> *are* SVG. They are not. >> The part about transport over HTTP and similar protocols can be dropped >> (at least from here), it's just a natural aspect of these protocols. >> I would drop the rest, and then, under Additional Information/File >> extensions, currently reading: >> "File extension(s): >> svg, svgz (if gzip-compressed) >> Macintosh file type code(s): >> "svg " (all lowercase, with a space character as the fourth letter), >> "svgz" (all lowercase, if gzip-compressed)." >> Drop the mentions of svgz, here, and just add add a Note, such as >> "Note: >> We recommend using the file extension "svgz" for SVG content that is >> gzip-compressed." >> Feedback appreciated, >> Julian JR> _______________________________________________ JR> ietf-types mailing list JR> ietf-types@ietf.org JR> https://www.ietf.org/mailman/listinfo/ietf-types -- Chris Lilley Technical Director, Interaction Domain W3C Graphics Activity Lead, Fonts Activity Lead Co-Chair, W3C Hypertext CG Member, CSS, WebFonts, SVG Working Groups
- Re: [ietf-types] Additional comments on image/svg… Julian Reschke
- Re: [ietf-types] Additional comments on image/svg… Julian Reschke
- Re: [ietf-types] Additional comments on image/svg… Julian Reschke
- Re: [ietf-types] Additional comments on image/svg… Chris Lilley
- Re: [ietf-types] Additional comments on image/svg… Julian Reschke
- Re: [ietf-types] Additional comments on image/svg… Ron Wilson