- From: Lofton Henderson <lofton@rockynet.com>
- Date: Wed, 26 Aug 2009 09:50:27 -0600
- To: Chris Lilley <chris@w3.org>
- Cc: WebCGM WG <public-webcgm-wg@w3.org>
Chris, Thanks again your helpful feedback. -Lofton. At 05:53 PM 8/25/2009 +0200, Chris Lilley wrote: >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 Wednesday, 26 August 2009 15:51:39 UTC