- From: Chris Lilley <chris@w3.org>
- Date: Tue, 25 Aug 2009 17:53:25 +0200
- To: Lofton Henderson <lofton@rockynet.com>
- CC: Thierry Michel <tmichel@w3.org>, WebCGM WG <public-webcgm-wg@w3.org>
On Tuesday, August 25, 2009, 5:14:51 PM, Lofton wrote: LH> Hi Chris, LH> Thanks for the feedback. Here are some thoughts about your message. LH> First, we welcome that CGZ does not require a new media type registration. LH> We also disliked the too-strong connection between the gzip and LH> HTTP 1.1 usage. We have removed that sentence, like SVG did. Sounds good. LH> Section 3.4 (which is in WebCGM 1.0 and 2.0) [1] does give the LH> full media type specification for calling out CGM from an <object> element: LH> The only standard way to reference inline CGMs from HTML LH> documents is through the object element, using the data attribute LH> for the CGM file and the type attribute to specify the full Mime LH> Type. The minimal element for adding CGM into a document would be: LH> <object data="xxx.cgm" LH> type="image/cgm;Version=4;ProfileId=WebCGM" width="200" height="100" /> Okay. Thats a bit indirect, and could be read as a non-normative example, but it does indicate the Internet Media type to use. LH> On the other hand, the WebCGM spec intentionally says very LH> little more about the registered MIME type. The main reason is: LH> WebCGM, unlike SVG, intentionally does NOT standardize any LH> normative conformance requirements for a general-purpose "WebCGM LH> Server" conformance "Class of Product" (in the QAWG sense), You are correct to recognise the origin of that wording. We wanted to say "the media type for svg is image/svg+xml" and express that as a conformance requirement. And the best way to say that (especially since it gave us somewhere to hand the wording about content-Encoding etc as well, which was all clarification based on last call comments) was to invent a new class of product. And it does serve a purpose, as its part of the spec to point server admins to when complaining that they serve svg as text/plain or whatever. LH> and LH> indeed we do not believe that IANA registration of CGM type, LH> beyond use in the <object> tag, plays much of a role in our LH> constituents' operational scenarios. Okay. I read that as "we want to put that in a type attribute but don't want to require any server configuration". LH> Therefore we would like minimize the in-text discussion of the LH> details of the CGM MIME for a general purpose "WebCGM server", LH> rather than spelling out the required usage parameters for those LH> who might want consider such a configuration. Okay. LH> Thanks again, and we welcome any further thoughts you might have. LH> Regards, LH> -Lofton. LH> At 05:13 PM 8/24/2009 +0200, Thierry Michel wrote: LH> Lofton, LH> I have asked Chris Lilley about the mime type registration as he LH> was involved in the Registration Internet Media type for cgm, LH> image/cgm in November 1995, and also with the SVG one. LH> he claims that we don't need a special mime type for GZIP LH> compression .cgz files nor a new registration since WebCGM reuses LH> the image/cgm registration and since gzip compression does not alter the Internet Media type. LH> Following is his response: LH> LH> Chris Lilley wrote: LH> LH> On Monday, August 24, 2009, 2:48:55 PM, Thierry wrote: TM>> Hello, TM>> I would like to have some advice on mime-type registration for WebCGM. TM>> Do we need a special mime type for GZIP compression .cgz files ? LH> No. After an early attempt to register a MIME type for gzip LH> compression, there were then problems because two different media LH> had the same MIME type (compressed PostScript and compressed VRML) LH> so it wasn't possible to assign a single handler application to LH> the one media type. So therefore, the actual media and the LH> compression used, if any, were treated separately in Internet Mail and in HTTP. LH> So, the Internet Media type (mime type) is the same. However, LH> the Transfer-Encoding or Content-Encoding will be different. TM>> [1] TM> http://www.w3.org/TR/2009/WD-webcgm21-20090604/WebCGM21-Concepts.html#webcgm_2_4 LH> Notice that the text at that URI could be read to imply that LH> gzip compression can *only* be used over HTTP. (The SVG spec used LH> to have similar woirding and was in fact so misunderstood, which LH> is the origin of the Firefox bug that svgz only works when served LH> over HTTP, not for local files. We fixed that wording in SVGT1.2 LH> and have back ported it to the second edition of SVG 1.1). TM>> I looked up what Tiny 1.2 did about .svgz: TM>> [2] http://www.w3.org/TR/SVGMobile12/intro.html#mimetype TM>> No apparent mention of svgz there, that I can see . LH> I think you missed LH> "(See Conformance Criteria for more information about LH> gzip-compressed SVG files transmitted over HTTP.)" LH> which points to LH> http://www.w3.org/TR/SVGMobile12/conform.html#ConformingSVGServers LH> which has the appropriate language about svgz and what headers LH> to send for HTTP. You could copy that language for the WebCGM spec. TM>> That [2] points to TM>> this: TM>> [3] http://www.w3.org/TR/SVGMobile12/mimereg.html TM>> Which points to this: TM>> [4] http://www.w3.org/2002/06/registering-mediatype.html TM>> Do we need to register this mime-type using the new procedure, by draft TM>> text within the REC or don't we ? LH> No. LH> The Internet Media type for cgm, image/cgm was registered in LH> November 1995. (I helped with that registration). LH> http://www.iana.org/assignments/media-types/image/cgm LH> All versions of CGM use the same media type but there are two LH> mandatory parameters, version and ProfileId. LH> So you don't need a new registration, but you do need to say LH> what the values should be for version (I guess 4?) and profileID. LH> Actually, you should say to use image/cgm, too (I couldn't see that in the WebCGM 2.0 spec). LH> Also, nowadays, "Security considerations: None" would raise a LH> few eyebrows especially now that WebCGM has a DOM. LH> But all of that is a small section in the spec, and does not LH> need a new registration since WebCGM reuses the image/cgm LH> registration and since gzip compression does not alter the Internet Media type. LH> I'm happy for the entirety of this message to go to a Member of LH> Public list, (either by forwarding, or post there and I will respond likewise). LH> LH> -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Tuesday, 25 August 2009 15:54:11 UTC