Re: mime-type registration for WebCGM.

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