Re: Subaddressing (was: Re: A couple of comments on the open issues...)

At 1:31 PM -0500 2/15/03, John C Klensin wrote:
>--On Saturday, 15 February, 2003 09:29 -0800 "Paul Hoffman / IMC" 
><[email protected]> wrote:
>
>>[ This thread is about subaddressing ]
>
>I adjusted the subject line in the hope that will be helpful.
>
>In case it isn't clear, I think Paul and I are in complete agreement 
>about this.  Just to be sure, let me try to restate this as a design 
>principle to see if he agrees...
>
>	Whether one uses an IDNA-like approach, or something of
>	the general character of 8BITADDRESSES (I suspect I'm
>	going fairly quickly come to hate that term), we don't
>	want to disrupt local-address opacity.  Consequently,
>	anything that is to be done with subaddresses --or any
>	other special-purpose parsing of the local-part into
>	subdivisions for differential processing-- must be
>	done before encoding on the sending side and processed
>	post-decoding on the receiving side.
>
>	The only exception, or group of exceptions, arise if the
>	sender and receiver explicit agree, before the address
>	is sent, on interpreting that address in some specific
>	fashion.  Such an agreement could be via an SMTP
>	extension or, at least in theory, via some out of band
>	negotiation or private agreement.
>
>If we can actually agree on that, then a good many of the recent 
>discussions become irrelevant, and we can move on to other topics.

John and I agree on this; if others do as well, the latter part of 
that sentence becomes true.

>Where we disagree, I think, is how much that rule can be bent and 
>whether it is necessary to do so.  I am imagining implementations in 
>which the originating user enters an address in a local CCS, or 
>Unicode in some form, into an MUA and passes the message off to the 
>local MTA, which processes it into IMAA.

The typical mail model today is that the MUA software acts as the 
first MTA in the chain, so it is the MUA that would do the IMAA 
conversion.

>  Variations on that model, without the i18n characters, are very 
>popular today, and we know roughly how well they work (let's say the 
>experience has not been uniformly good).  The problem is that the 
>MTA implementers and admins, after long experience, decide that they 
>are smarter than the user or the MUA-writer (they are often correct) 
>and start fixing things up.  I think the IMAA approach encourages 
>them to include trying to understand, and fix, the local part, and 
>that is what worries me -- experience indicates that the more 
>transparent that originating MTA can be to what it receives, the 
>less likely we are to have problems.

We agree with the worry, which is why I would trust my MUA to do any 
conversion, but no one else. That also supports the view of opacity 
through all the SMTP servers.

>If the user types (or pastes) the punycode string for the local-part 
>into the MUA, and the MTA just passes it on without looking, I don't 
>have a problem at all, but that really isn't our objective, is it?

Correct. The objective is that the user will { type | paste | speak } 
a name using { the current charset | ACE } into the LHS and It Just 
Works.

. . .

>But, as soon as I do that, the hypothesis that IMAA would permit any 
>user to create an i18n name without having to negotiate with the ISP 
>or mail supplier fails.

And that is why the hypothesis is nowhere in the IMAA-ACE document. 
It is not congruent with today's practice, and it isn't needed. The 
rest of the argument about why this wouldn't work is perfectly true 
but irrelevant to IMAA-ACE.

--Paul Hoffman, Director
--Internet Mail Consortium