Re: a few short notes
2004-02-01 12:55:27
On Feb 1, 2004, at 11:13 AM, Iljitsch van Beijnum wrote:
Sure. But global usage also means that people who don't know how to
type each of 20k+ unicode characters can administer the system.
the system supporting it doesn't imply the user has to worry about it.
And in fact, may not ever see it or use it...
Dan doen we het toch in het Nederlands?
Guten Tag!
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
middle ground: there are some headers that are intended for consumption
by computers where ISO-8859-1 or some similar format is acceptable,
which I think solves your issues, but there are other headers,
primarily those dealing with the PERSON, as opposed to the server or
the transport, where we can't make these kinds of limitations. but that
also limits the need for every computer everywhere to support an
arbitrary language, although it needs to do something reasonable when
it receives it. But no, I'm not suggesting that the headers be
localized into Mandarin or Korean and that all computers be able to
make that translation.
I think we need to, for instance, come up with a single term that
defines "Message Subject", and there's no reason why that can't be
represented internally in 8859-1. But that shouldn't imply that the
external representation shouldn't be localized to the user's native
language, or that the content of that item can't contain content in
that native language.
Is that closer to what you want?
Why? what *technical* reason is there for this limitation?
Simple: not all computers support non-latin scripts.
Does the above resolve your issue here? I agree, j-random-computer
shouldn't need to read Mandarin to figure out which data item is the
Subject, but if the content of that data item is in Mandarin, it needs
to handle it rationally (which might, in some cases, be to display that
the content is unsupported).
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.
Lack of critical mass and motivation. Nobody's created a persuasive
argument to "joe user" that this stuff is really useful to them, and
nobody's created a version of these tools that "joe user" is
sufficiently comfortable with to use. And the former could drive
implementation of the latter, or the latter could lower the bar towards
acceptance in the former, but so far, neither has happened. So
PKI-based stuff remains isolated into a subset of the geek corps. Heck,
we haven't even built systems that geeks are willing to use regularly,
growing it out to the general population is a no-op. But that's a
different discussion for somewhere else..
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.
Better interaction with users, better user experience. It's nicer for
the user, and that's more important than what's efficient for the
computer. or it should be.
again, you have to get out of the geek crew and deal with "joe user"
where I live (actually, I support email systems in both worlds,
but...). Personalization is a key usability issue, especially in
non-technical audiences.
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?
It prevents third party sniffing and man-in-the-middle attacks, to
start. if nothing else, it guarantees that you're talking ONLY to
whoever it is you're talking to, and that's a huge, crucial aspect of
all of this.
|
|