On 1-feb-04, at 18:49, Chuq Von Rospach wrote:
I'm not convinced that using non-ASCII characters in headers is a
good idea either.
You have no choice. This is a global service, so it has to support
global usage.
Sure. But global usage also means that people who don't know how to
type each of 20k+ unicode characters can administer the system.
Headers must be simple and unambiguous. Having text in them that
your computer can't even display and if it can, 99% of the world
population can't spell, isn't a good idea.
well, go count how many native Mandarin speakers there are in the
world, and then realize your argument just outlawed English, too. It's
a very english-centric view, and it won't work in designing this new
protocol.
Dan doen we het toch in het Nederlands?
The way I see it we have three choices:
1. Screw things up beyond repair by allowing non-latin characters in
fields that are relevant to mail delivery (some headers are only for
human consumption, I don't care about those)
2. Use latin characters only as this is the most widely used script
3. Use numbers exclusively as every literate person on the planet can
handle those
recipient only, so they can be in any format, and others that must be
more general so they must be in ASCII.
Why? what *technical* reason is there for this limitation?
Simple: not all computers support non-latin scripts. If I'm going to
administer a mail system I must be able to set up filters and such
which makes it necessary to have support for the scripts that I may
need to filter. But I myself don't support any non-latin scripts (not
counting half the greek alphabet) even with a computer that does (such
as my Mac) this won't work well.
Mandatory authentication is also a bad idea IMO. Obviously
authentication is very important and must be supported so that people
who only want to receive mail from verifyable sources get to
implement this policy, but that doesn't mean that we should force
*everyone* to use such a policy.
If we can't authenticate, we can't authorize. If we can't authorize,
we have the status quo. So we might as well go home. there has to be
some kind of provable identity here, or we solve nothing. Exactly what
that identity is can be flexible, as long as it exists.
This stuff exists today in PGP and S/MIME. However, it seems most
people can live without it. If we can limit spam by 90% or so without
something like this then I don't think we need to force everyone to
adopt strong authentication.
Chris Bonatti had something to say about multicast. Obviously this is
something that applies to mailinglist rather than one-to-one
messages.
and mailing lists are increasingly going to individualized messages. I
think designing for bulk delivery is the wrong direction here, and
actually enables the kind of e-mail I think we're trying to discourage
or stop.
Why??? Bulk delivery has many advantages and allows some anti-spam
strategies that aren't applicable to one-to-one messages.
Important point: as long as email is a store and forward mechanism,
encrypting the transport makes little sense: encryption should be
end-to-end.
to me, if there's any opportunity to cross a network in plain-text,
the proposal is dead.
So what exactly does encryption do for you if you don't even know who
you're talking to?