On Tue, 29 Nov 1994 15:16:18 PST, you said:
I've read the latest MIME draft, and it makes it quite clear that the
unicode-1-1 (16 bit character) character set cannot be used with
text/plain, since it does not follow =0D=0A CRLF conventions.
I'd like some suggestions from this group on how to go about revising RFC
1641 and the unicode-1-1 character set accordingly (unicode-1-1-utf-7 and
the forthcoming unicode-1-1-utf-8 are unaffected, as they are ASCII-derived
and can follow the CRLF conventions).
...
I would like to fix this problem so that there will be a means of
transmitting Unicode directly, not encoded with UTF-7 or UTF-8, both of
which impose some overhead. Clearly this would not be for interoperability
with non-Unicode or non-MIME sites, but it would be convenient for
communication between sites using Unicode.
Is there anything Unicode-1-1 needs different from text/plain besides the
removal of the CRLF restriction? And can you specify the exact nature of
the problem for those of us who aren't Unicode-literate?
The problem is that the CRLF convention is dependent on the RFC821 spec
of CRLF and 1000-char lines, so I dont see an easy way of removing it
until/unless you either (a) accept some sort of CTE or (b) that you can only
do it over a connection that uses an SMTP extension to negotiate a binary
transfer.
Would it be acceptable to use unicode-1-1 with some sort of byte-stuffing
hack rather than the full utf-7 or utf-8, similar to the way rfc821
specifies doubling a '.' that is by itself on a line?
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech