[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Text mime types

From: Vincent Lefevre <vincent+svn_at_vinc17.org>
Date: 2005-06-14 09:46:15 CEST

On 2005-06-13 17:56:52 +0100, Julian Foad wrote:
> Vincent Lefevre wrote:
> >On 2005-06-12 13:15:37 +0100, Julian Foad wrote:
> >>Vincent Lefevre wrote:
> >>>So, svn:mime-type should contain text/plain and there should be a way
> >>>to specify the file encoding (compression scheme). "utf8" is not an
> >>>encoding in the MIME sense.
>
> I think there is some confusion between "file encoding" and "transfer
> encoding".

No, this is the same thing (though a file could be compressed before
the transfer...).

For instance, "wget -S http://www.vinc17.org/research/papers/rnc6.ps.gz"
gives:

[...]
10 Content-Type: application/postscript
11 Content-Encoding: x-gzip

and the file that is downloaded is really a .ps.gz file.

> >>Hmm... I can't see how that would work in general. It could have
> >>made sense in MIME's original context - attachments to email
> >>messages - where the compression was perhaps temporary, to be
> >>automatically undone at the end of the transfer, but I can't see
> >>that making sense where MIME types are used more generally to
> >>describe arbitrary files.
> >
> >The application could still perform the decompression
>
> It _could_, but that would be a completely new and different
> feature. We are not talking about that.

Not new. And it's the only way to get more information about the
contents of the file and the application that can handle them.

> >One of the questions one may ask is how MIME types should be used by
> >Subversion. An advantage of considering compression schemes not as
> >MIME types is for svn diff for instance: the diff could be shown on
> >the uncompressed file (as the may be unwanted or may be slow, this
> >could be an option only).
>
> Ditto.
>
> I think the comment in Debian's /etc/mime.types is wrong and
> misleading and is assuming that gzip (etc.) is only ever used as a
> content _transfer_ encoding. Where no transfer (with its consequent
> automatic encoding and decoding) is performed, the transfer encoding
> is inapplicable and we just want to state the file content type. In
> this regard, "gzip" (MIME type probably "application/x-gzip") is the
> outermost content type of a gzipped file.

No, when one has a gzipped postscript file, one wants to process it
with a postscript viewer, so that it really makes sense to have a
application/postscript MIME type for this file. Otherwise what would
be the need for MIME types?

Of course, a MIME type could contain information about both the
content type and the compression scheme, such as application/x-gtar
for gzipped tar archives. But an additional property specifying the
content encoding would be a nicer solution in general.

-- 
Vincent Lefèvre <vincent_at_vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 14 09:47:33 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.