> 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:
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]>
)_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