Re: standardized local-part structuring

Adam, et al,

This evening's clarification -- that imaa wants to modify basic Internet mail
parsing rules -- goes a long way towards making clear a basic flaw with IMAA.
It is entirely in line with the concerns I've expressed over the current
specifications:

           This specification needs to narrow its scope, not expand it. It
           also needs to specify things much more precisely and clearly.

For starters:

1.  Do not mess with global parsing rules.

2.  Do not mess with local parsing rules.  It is fine to try to avoid
well-known lexical separators, used in various local venues, but keep the heck
away from doing. anything clever.

3.  Encode a larger character set for _user_ data, into the existing,
permissible set for local-part

4.  Do nothing else.


>> Doing segmentation at protected boundaries makes the imaa mechanism
>> significantly more complicated.

AMC> True, but remember that dividing a local part into segments for separate
AMC> encoding/decoding is not significantly more complex than dividing the
AMC> domain part into labels for separate encoding/decoding.

For domains, the syntactic rules are global, rigid, and well-specified. For
local-part, they are varied, unspecified. And, of course, they are local.

Internet mail has gotten quite a bit of benefit from avoiding global knowledge
about local-part internals. Please do not mess with that strategic benefit.


AMC> Your comment applies equally to IDNA and IMAA.  ToUnicode step 1 is
AMC> not strictly necessary, but it avoids gratuitously lowercasing ASCII
AMC> letters.

IMAA had better not lowercase ASCII, whether gratuitously or not.  Local-part
is defined as being case sensitive.  IMAA needs to work within that reality.

Maybe your point is that IMAA, in fact, does not do case-mapping. That's fine,
though it is yet-another distinguishing point that I could not tell from the
current specification.


AMC> Another reason for having this bypass in ToUnicode is to mimic the same
AMC> bypass from ToASCII, where the the bypass is needed to make sure that
AMC> pure ASCII strings are never altered in any way.

Parsing/encoding algorithms that need these sorts of special-case, look-ahead
processing invite mis-implementation. They certainly suggest excessive
complexity for a task that is already plenty complicated.


AMC> All the verification steps are governed by this paragraph:

AMC>     ToUnicode never fails.  If any step fails, then the original input
AMC>     sequence is returned immediately in that step.

Then write that into the algorithm.

           Do not force implementors to juggle meta-rules,
           when reading algorithms.



AMC> Yes, IMAA wants hyphen to be just another protected character.  But the
AMC> Punycode encoder introduces a hyphen where there was none.  For example,
AMC> if you feed "niño" to the Punycode encoder, it outputs "nio-8ma".
AMC> Punycode was designed for domain names, where introducing hyphens was
AMC> not a problem.  It uses all 37 LDH characters to maximize efficiency.
AMC> We could define a new encoding very similar to Punycode that uses "9"
AMC> instead of "-" (at a slight cost in efficiency), but I thought it would
AMC> be simpler to put a wrapper around Punycode that removes/restores the
AMC> hyphen.

So, Punycode is not a general-purpose module, but you can hack around it to
adapt it to the more complex requirements of mail local-part, by making things
even more complex...


>> ace-local  =  ima-prefix  ace-encoded-unicode
>> ima-prefix  =  "0iesg1"
>> ace-encoded-unicode  =  {here's where your toAscii, etc. algorithm goes}

AMC> This is an attempt to pull one step (the addition/removal of the ACE
AMC> prefix) out of the middle of a multi-step algorithm (which includes
AMC> Nameprep, Punycode, checking the absence of the ACE prefix, checking the
AMC> length) and present it using a different kind of spec (a grammar).  I
AMC> think it's simpler to present the whole thing together in one kind of
AMC> spec.

Then please do that.

As of now, you have enough nesting and indirect reference to make the
specification be a long way from transparent.

It's possible that the real problem is that I simply don't know how to read a
spec, but I put enough effort into reading the imaa draft to suspect that that
is not the problem.


AMC> Also, the grammar above doesn't recognize fullwidth characters in the
AMC> ACE prefix, but ToUnicode does (because it performs Nameprep before
AMC> looking for and removing the prefix).

Oh, good.  There is more than one way to do the prefix, too?


>> > Not only are protected characters left alone, but the substrings
>> > between the protected characters are encoded independently.
>> This incurs extra storage and processing overhead and complexity.
>> And it appears to be only for the purpose of trying to support local
>> conventions -- ie, for doing partial global support for a local
>> convention.
>> The benefit of all this is.... what?
AMC> To avoid astonishing users.

AMC> Suppose a user obtains an ACE mailbox at example.net that displays as
AMC> josé, and his friends with IMA-aware browsers start sending mail to
AMC> josé@example.net, which works fine, even though the powers-that-be at
AMC> example.net have not upgraded their MTA.  Now suppose that example.net
AMC> accepts mail for user+tag and delivers it to user.

Yes, trying to solve this problem certainly is an enticing trap to fall into.


AMC> People will
AMC> naturally expect to be able to send mail to josé[email protected].

First of all, there is no public standard for segmented local-parts.  (Of
course, I'm not telling the whole truth, but the exceptions are for special
purposes.)

The extent to which random users can expect to generate a segmented local-part
for a particular recipient is entirely outside the current scope for existing
Internet mail. (I tried to get interest in a global standard for local-part
segmentation, some years ago, but folks didn't take the bait.)

So the string that someone should expect to have work is whatever the intended
recipient originally sent.

To the extent that there is consensus to have the local-part be a mixture of
ace-encoding and classic ascii, then define the ace-encoded strings with
left/right framing.

Something like:

    local-part      =       1*(ascii-local / ace-local)

    ascii-local     =       dot-atom / quoted-string / obs-local-part

    ace-local       =       ima-prefix  ace-encoded-unicode  ima-suffix

will do the trick.


AMC> That will work just fine if there is no crosstalk across protected
AMC> characters, but it will fail if there is crosstalk.

"Crosstalk"?


AMC> Suppose the manager of the aliases file at example.net creates an ACE
AMC> alias that displays as niño and expands to multiple addresses.  The
AMC> IMA-unaware MTA, whenever it expands the ACE alias, automatically looks
AMC> for a companion alias owner-ACE to use as the envelope From address.
AMC> That address will display as owner-niño if there is no crosstalk across
AMC> protected characters, but it will display as ASCII garbage if there is
AMC> crosstalk.
AMC> One could question whether these kinds of benefits are worth the
AMC> complexity.
They aren't.

1. Alias expansion is a function of list processing, not classic MTA
processing. Yes it is useful and popular, but let's be clear about where it
fits in the architecture. Let's not confuse architecture with implementation.

2. Folks probably have not noticed just how much effort you are having to put
into working around all sorts of features in the real world, in order to
delivery all sorts of generalities.  Although the intentions behind these
contortions are laudable, the meta-issue is that this much bobbing and weaving
in a specification is usually a good sign of implementation and adoption
difficulties later.


AMC>   In fact, we raised exactly that question in imaa-00
AMC> (Feb-05), which did not do segmentation but proposed it as an open
AMC> issue.  A discussion ensued in which the pros and cons were explored,
AMC> and there was more support than opposition for the idea, so it was added
AMC> in imaa-01 (Apr-18).

Isn't it nice that we get to review all that, in preparation for bringing this
work into the IETF?


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>