Dave Crocker wrote:
2. compatibility with netascii is an explicit goal when working
with email.
3. the logic behind that goal is applicable to any other
application having a similar installed base history.
Jean-Marc Desperrier writes:
The big difference is that Usenet transport has almost since the very
start been fully 8 bit.
No, no, no. Usenet has always supported 8 bit message bodies, as HTTP
and BEEP have, and unlike SMTP. But RFC 1036 (and RFC 850 before that)
do *not* allow 8 bit headers (and neither do HTTP, BEEP, and SMTP).
To quote RFC 1036:
The primary consideration in choosing a message format is that it
fit in with existing tools as well as possible. Existing tools
include implementations of both mail and news.... Therefore, the
rule is adopted that all USENET news messages must be formatted as
valid Internet mail messages, according to the Internet standard
RFC-822.... However, it should always be possible
to use a tool expecting an Internet message to process a news
message. In any situation where this standard conflicts with the
Internet standard, RFC-822 should be considered correct and this
standard in error.
4. paying attention to the installed base requires worrying about
compatibility with what has been established practise, not what
"might" work or what is "frequently" available.
We have a problem here with the definition of what constitutes
established practise.
In my opinion, in every respect 8 bits in headers is established
practise in usenet.
Yes, in practice, many usenet gateways and user agents support 8 bit
headers (though very few today understand UTF-8). But many others
(including mail gateways and IMAP servers) do not, and those were
written in good faith to be compatible with RFC 1036.
A person who receives a usenet message is never the destinary of that
message, and it is his job to make that it takes to receive them.
There's never a guarantee you'll receive a message, it just happens
sometimes that a specific message does not arrive, on very loaded
binary groups it's even very frequent.
If that happens and you're not happy, you have alternatives and can
try to get it from another source.
Obviously, the goal of a usefor (or rechartered working group) RFC
should be a standard that, when followed, drastically improves the
reliability of usenet, including support for i18n headers as well as
multimedia and i18n message bodies. It should also be a goal that the
standard does not worsen reliability for gateways and agents that don't
(yet) follow it.
- dan
--
Dan Kohn <mailto:dan(_at_)dankohn(_dot_)com>
<http://www.dankohn.com/> <tel:+1-650-327-2600>