<< Apart from this one user-interface restriction, the usual C-derived
<< requirement that ASCII NUL not appear in text (which is, I think,
<< observed by all the new character sets)
< Actually, Unicode does use NUL octets in ordinary graphic characters.
< 10646 may do so as well, if it freezes as it stands now. That's why they
< invented UTF, which is an alternate format that does not use NUL and other
< C0 octet values (0-31).
It is for reasons exactly like this that the System V Release 4 mail command
was changed about 4 years ago to be totally content transparent. The mail
associated with AT&T Mail has also been content transparent for the last 6-7
years. As I've said before, but was shouted down each time by people who
didn't want to listen, SVr4 mail uses Content-Length: to indicate how long
the mail is, and then transmits the message verbatim. It DOESN'T CARE what
the mail contains; it just sends it. If the transport protocol cannot handle
the content, then the transport agent will reject the message. This is how
binary mail is prevented from going across an SMTP link; the SMTP programs
know that the SMTP protocol doesn't allow anything outside of 1-0x1e, so
messages containing offending characters are rejected to give another
transport agent a chance to transmit the message. Fortunately, many other
transport agents are also content transparent and the mail goes through.
I'm just wondering now how to make SVr4 mail both content-transparent, AND
be able to follow rfc-xxxx when mail crosses the boundary into the Internet.
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
att!pegasus!hansen, attmail!tony