Re: Can we back up a bit and ask some basicquestions?Analternate model

At 13:48 03/02/16 +0000, Roy Badami wrote:

>Sorry, there was a typo in my comment above.  I meant to say:
>
>    we will move to a _message_ which (by default) is just a block of UTF-8

Thanks for the clarification.


>ie, not only will out content-transfer-encoding be 8-bit, but we'll
>dispense with the escaping mechanism in subject and other headers.  At
>this point it makes sense to dispense with the ACE in the headers,
>too.  A message once again becomes just a piece of text you can view
>(most of) in a text editor.

Yes, therefore allowing people around the globe to do all those
things with emails that people in the ASCII-only world have done
all the time: use text editors (as you say), write simple scripts
(with the emphasis on simple) to process their email, and so on.
Great!


>Having thought about it further, the kind of solution I was
>envisioning would have to wait for a new message format to be defined,
>in which the headers were 8-bit.  Making this change just for
>addresses doesn't make sense, and defining the native UTF-8 message
>format is clearly outside the scope of the present discussions.

Well, I agree that we should concentrate on addresses here,
but looking ahead is part of good engineering. So even if
this happens in two steps (UTF8ADDRESS and UTF8HEADER),
we can think about the interactions. And if we find
out that it would be almost as easy to do both at the same,
and maybe just as one extension, then I don't think we
should feel restricted to not do it.

Actually, my current guess is that it's almost as much
effort to do both things in one extension as to do them
separately:

- Widening code paths to 8 bits has to be done only once,
   and can be done completely.
- Negotiation is done on one item, rather than on several.
   This significantly reduces code complexity.

The main problem is how to distinguish between header parts
that are addresses and those that are other text.

Regards,   Martin.