Re: [ietf-types] Registration of media typeimage/svg+xml

[Chris Lilley <[e-mail]>]

On Thursday, November 18, 2010, 8:19:20 PM, Julian wrote:

JR> On 18.11.2010 19:02, Chris Lilley wrote:
>> ...
>> Security considerations:
>> ...
>>      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.
>> ...

JR> 1) What does this have to do with "Security Considerations"?

Please read BCP 13, RFC 4288 section 4.6 "Security requirements" where you will find

      A media type that employs compression may provide an opportunity
      for sending a small amount of data that, when received and
      evaluated, expands enormously to consume all of the recipient's
      resources.  All media types SHOULD state whether or not they
      employ compression, and if they do they should discuss 
      what  steps need to be taken to avoid such attacks.


JR> 2) I find the whole paragraph misleading; I'd like to see a clear 
JR> statement about whether the stream of octets resulting from gzipping SVG
JR> can be labeled as "image/svg+xml" or not 

Not by itself, no. In a MIME context, it must be labelled as Content-type: image/svg+xml **AND** Transfer-Encoding: gzip. Please note the AND.

This is not the same thing as Content-type: application/octet-stream and  Transfer-Encoding: gzip - because that conveys the encoding, but omits the content type.

In other words the encoding label ADDS TO the media type; it does not remove the type.

Indeed, this is why separate labelling of encoding was added. Back in the early days people would use gzipped VRML or gzipped PostScript, and attempted to register application/gzip; but since they were using the Media Type to hold the encoding information they had lost important information, so VRML viewers were sent PostScript and so on.  Some people said this was okay, unzip and then look at the filename extension. But a much better way was to add the encoding headers.

JR> (please consider transports 
JR> other than HTTP, such as a file system that actually supports typing by
JR> Internet media types).

Please feel free to file a bug report for the BeOS filesystem saying that it should support labelling of encodings in addition to media types. 

Speaking as a former BeOS user myself, I still consider modern SVG implementations (of which there are many) to be a rather more numerous and relevant consideration than a promising, but obsolete and abandoned, operating system from 15 years ago.

JR> If yes, that's a violation of "+xml" (and the last sentence points into
JR> this direction). If not, please remove the paragraph above.

JR> 3) If the intent is to say that "svgz" acts as file extension for 
JR> gzipped SVG, and *that* content can be served over HTTP as-is with

JR>         Content-Type: image/svg+xml
JR>         Content-Encoding: gzip

That is exactly what it says, yes

JR> than this is obviously ok 

I'm glad its obviously OK.

JR> because it follows from RFC 2616, and has 
JR> *nothing* to do with the media type (except for the extension 
JR> recommendation).

So you oppose reminding people how to detect such gzipped content?

Why would you want to do that?



-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups