> Date: Tue, 29 Jun 2004 15:08:07 +0100
> From: Robert Sanderson <[log in to unmask]>
> > 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..."
Yes, that works too -- thought I am a bit loathe to relegate something
as core as a transfer encoding to a context-set pertaining to MIME
just because of the historical accident that this is where the notion
was first published.
> eg to allow:
> # 7-Bit - Data is sent as US-ASC data.
> # 8-Bit - 8 bit characters are included in short lines.
> # BASE64 - Used for binary files. Three bytes are transformed into 4 ASC
> characters in lines limited to a length of 76 characters.
> # Binary - Long lines are sent using 8 bit characters. These lines may not
> be transportable using SMTP.
> # Quoted-Printable - Used for ASC text. Line length is limited to 76
> # X-Token - Defines private encoding values prefixed with an "X-".
I think this long list of encodings (taken, I assume, from the MIME
RFCs) is at best reflecting historical issue in email transfer that do
not pertain to us, and at worst an outright mistake. There is in fact
no difference between 7-bit, 8-bit, binary and no encoding specified
-- at least, not for the purposes of encoding arbitrary text for
transfer over a broken transport. The so-called "encoding" called
"7-bit" is in fact an assertion, which I don't think would serve a
useful purpose in SRW.
For this reason, I think it would be misleading to have CQL's way of
expressing Base64 and QP encoding masquerading in a situation that
bears a closer resemblance to MIME than we actually need. All we're
using, and all we want to use at this stage, is the two encodings,
which are not really related to MIME per se. I say make 'em CQL-set
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ If two decades of commercial programming have taught me
anything, it's NEVER to trust dual CPUs, "uninterruptible"
power supplies or RAID disks.
Listen to free demos of soundtrack music for film, TV and radio