> Date: Tue, 29 Jun 2004 12:38:05 +0100
> From: "Matthew J. Dovey" <[log in to unmask]>
>
> > I have only two comments: first, that the relation modifier's name
> > "mimeEncoded" is ambiguous as it could refer either to Base64 or
> > Quoted-Printable,
>
> The problem with having a base64Encoded modifier is that although I
> know how to decode the data, I've no idea what the thing is I get
> once decoded (is this a string with stange character in, an audio
> wave file, a video, a jpg, a mpeg, an executable).
This matter is orthogonal.
> My intent with mimeEncoded is that it would include the various MIME
> headers as well as the data itself e.g. something like:
>
> Content-Type: text/plain; charset=UTF-8 #xA Content-transfer-encoding:
> base64 #xA Uo8ey785ffshvo78f4873vv87cbt0q63
I disapprove heartily of this -- you're conflating two essentially
unrelated issues here: what kind of thing the term is (word, image,
audio-file) and how it's encoded for transfer. Which is of course
precisely why MIME defines two separate headers.
I think we should just have two new relation modifiers:
cql.base64
cql.quoted-printable
which indicate the encoding of the term; and if it turns out in the
future that there is also a need to convey content-type, then that
should be handled by a new relation modified when it's needed.
foo.image =/cql.base64/cql.content-type="image/gif" "R0lGODlh..."
_/|_ _______________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ "It is impossible to travel faster than light, and certainly
not desirable, as one's hat keeps blowing off" -- Woody Allen.
--
Listen to free demos of soundtrack music for film, TV and radio
http://www.pipedreaming.org.uk/soundtrack/
