Re: a few short notes

Headers need not be Internationalization so long we hide the headers 
from the users (or as well as we can).
-James Seng

Chuq Von Rospach wrote:
> On Feb 1, 2004, at 7:56 AM, Iljitsch van Beijnum 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. Many of the challenges in dealing with building e-mail 
> systems today is to get things running properly in a global environment 
> because the initial system wasn't set up for that.
> If you don't allow users globally to use the system in their native 
> environment, it'll kill the proposal. It won't be adopted. The system 
> needs a way to gracefully fall back from missing fonts and etc, but that 
> kind of stuff is well-understood in the unicode world already, so I 
> think that's a non-issue.
> >  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.
> > 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?
>
> Remember, headers are primarily for computers to use, not people. so why 
> are you arbitrarily limiting their functionality? so you can read them? 
> Not a good reason.
> > 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.
> > 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.
> Multicast is a different beast, but I think the person who noted that 
> the e-mail should include an access token to a streaming service had it 
> right; putting the streaming service into mail-ng means it's not e-mail 
> any longer. Let e-mail handle transporting the access token, don't try 
> to re-implement  TCP-IP on top of TCP-IP within email-ng.
> > 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.