Re: a few short notes

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.