Re: A couple of comments on the open issues...

--On Saturday, 15 February, 2003 00:15 +0000 "Adam M. Costello" 
<[email protected]> wrote:

>
> Martin Duerst <[email protected]> wrote:
>
>> Is subadressing just something that is done by a few email
>> systems locally, or is it something specified in some of the
>> email standards?
>
> As far as I know, there are no standards for any structured
> local parts. It's all unofficial conventions.

Adam and Martin,

Let me see if I can shed a little light on this, independent of 
the tome I just mailed (which addresses this, and several other, 
issues in the context of questioning whether IMAA is a 
reasonable approach and proposing an alternative.

There are no standards at all for interpreting the local part. 
The standard is "no one but the delivery MTA can try to 
interpret the local part in any way".

>> to what extent do we really have to consider it here?
>
> I'd say we're under no obligation to play nicely with these
> unofficial practices, but our goal is to create utility, not
> frustration, so we shouldn't immediately dismiss the concern.

If your goal is not to break the existing standards, then you 
are obligated to not assign _any_ special interpretation to 
anything that appears in the local-part (unless your document 
applies strictly to the interface between the delivery MTA and 
the network).  That causes these "unofficial practices" --which 
are standard-conforming-- to take care of themselves.

>> Also, using subaddressing seems to be quite popular for
>> high-end users.  But is it actually very much used by the
>> bulk of users (the proverbial hotmail/yahoo/... crowd)?

Wrong question, I think.  There are all sorts of things that do 
things when email arrives.  Many of them are not "users", but 
robots and agents.  Some handle a _lot_ of messages.  And many 
of them funny characters and encodings in the forward and/or 
reverse paths as well as message header lines like "subject:". 
One really doesn't want to break them.

>...
> So users would not get the full IMAA functionality until the
> infrastructure (the MTA) has been upgraded, which is an
> undesirable dependence (one that IDNA does not suffer).  The
> counter-argument is that most users won't care about the
> missing functionality.

Yep.  But you may really screw the users/ robots/ agents/ etc. 
who do care.   Getting internationalization at the cost of 
reduced functionality for anyone or anything that is now doing 
something that conforms should be considered only if it is the 
only way.  It isn't.

regards,
    john