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

--On Saturday, 15 February, 2003 19:32 +0000 Roy Badami 
<[email protected]> wrote:

> I'm not sure that you understand what I was proposing.  A
> better analogy would be to pose the question: would it have
> been a good thing for ESMTP and 8BITMIME to have been defined
> concurrently with the base MIME standards?  (That isn't
> intended as a loaded question; "No, it wouldn't have made any
> difference" is a perfectly valid answer.)

How would "basically, they were" grab you as an answer?

> I'm proposing that the two solutions are defined as part of an
> encompassing IMA Architecture, not independently without
> regard to interoperability.
>
> This is what I imagine the world will be like a few years from
> now:
>
> All IMA-aware systems will support IMAA (this will be a
> mandatory part of some IMA Architecture standard).
>
> Many systems, particularly those in parts of the world where
> IMAs are popular, will use ESMTP extensions to exchange IMAs
> in native UTF-8, and to exchange messages in an extended
> format that allows native UTF-8 addresses in the headers.
>
> Systems that receive a message with UTF-8 addresses and need
> to relay it to a system that doesn't support the requisite
> ESMTP extensions will need to apply ToASCII to both the
> envelope and header addresses before forwarding the message.
> This is analogous to the (admitedly inconsistently
> implemented) requirement that a system which receives an
> 8BITMIME message converts it to a suitable 7-bit encoding if
> the destination system doesn't support 8BITMIME.
>...

Ok, I see where you are headed.  Let me try to summarize many 
months of moaning in the IDN WG, plus some email experience, 
including with 8BITMIME downgrading, which I'm glad you cited. 
Disclaimer: unlike Paul and Adam, I'm not an IDNA co-author, and 
am widely believed even be an IDNA-hater (not true), so you 
don't get to assume that I'm biased in favor of IDNA-derived 
solutions.

	* UTF-8, while more common and better known than
	punycode, is really not a very efficient encoding,
	especially for Asian languages.  Indeed, under a number
	of conditions, it is a less efficient encoding.  So,
	other than aesthetics and the belief that large benefits
	will accrue from its being closer to the internal form
	used by several (many?) systems, there is no really
	strong case to using it instead of punycode.

	* There are more efficient encodings than either, and
	they use all eight bits of octets, but they are even
	more strange (less familiar and used in other places)
	than punycode.  Several of them are members of the
	"start from 16-bit UCS-2 Unicode (or 32-bit UCS-4 10646)
	strings and compress" family.
	
	* Where we have two ways to do something, bad things
	often happen.  Paul identified one of them -- industry
	looks at the two possibilities, throws up its collective
	hands about interoperability and either does nothing or
	does something that won't interwork with many systems.
	The other is that they get mixed up.  The scenario you
	outline is a nearly-guaranteed recipe (as the
	complexities of 8BITMIME downgrading has been) for an
	over-clever MTA author to say "if I can send IMAA
	without negotiation, and negotiation fails, I can either
	go to all that downgrading trouble, which might not work
	anyway, or I can just send the 8bit stuff, which might
	get through.  The latter is a lot less work, so..."

If negotiation is needed, then we should negotiate, regardless 
of the agreed mail transport format.  If the best mail transport 
format is punycode, we should use it, whether the transport 
environment permits 8bit or not.   But alternate ways to do the 
same thing, especially when they don't provide significantly 
different functionality, tend to cause far more problems than 
they are worth.

I covered another aspect of this in an off-list note to you and 
Paul a short time ago.  If either of you believe that it 
contains any profound insights that would be helpful to others, 
please feel free to forward it to the list.

    john