Re: [ietf-types] Additional comments on image/svg+xml
Julian Reschke <julian.reschke@gmx.de> Thu, 18 November 2010 08:59 UTC
Return-Path: <julian.reschke@gmx.de>
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 3721C3A6804 for <ietf-types@core3.amsl.com>; Thu, 18 Nov 2010 00:59:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.166
X-Spam-Level:
X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=-1.867, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 y7jX0g+1Mx-Q for <ietf-types@core3.amsl.com>; Thu, 18 Nov 2010 00:59:23 -0800 (PST)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id C67863A67D3 for <ietf-types@ietf.org>; Thu, 18 Nov 2010 00:59:22 -0800 (PST)
Received: (qmail invoked by alias); 18 Nov 2010 09:00:07 -0000
Received: from p508FCC1A.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.204.26] by mail.gmx.net (mp020) with SMTP; 18 Nov 2010 10:00:07 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1++6zZ+IkO+azH+Mh7qXCSt1VZZnk+FGAymXC8xbR 2fQLcnKrBNRW/0
Message-ID: <4CE4EB0F.1000307@gmx.de>
Date: Thu, 18 Nov 2010 09:59:59 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
References: <AANLkTim5-=3A68M5GveeaOBQb8QtghUUWDerRBY3arxH@mail.gmail.com> <4C816A6F.40402@gmx.de> <4C873B4E.8040107@it.aoyama.ac.jp> <4CD2E04F.8070307@gmx.de>
In-Reply-To: <4CD2E04F.8070307@gmx.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: Alexey Melnikov <alexey.melnikov@isode.com>, ietf-types@ietf.org, ietf-types@alvestrand.no
Subject: Re: [ietf-types] Additional comments on image/svg+xml
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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 08:59:24 -0000
Hi, we do not seem to make any progress. How about publishing a small IETF document registering the type, delegating for most of the content to the W3C SVG spec, but pointing out that gzipped SVG is *not* conforming image/xvg+xml content? At least that would populate the registry with useful information. Best regards, Julian 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. >> >> 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 >
- 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