Re: standardized local-part structuring

Dave Crocker <[email protected]> wrote:

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

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

> 4.1/#1 is not needed.  A Unicode string may contain some Ascii
> characters normally, yes?  Hence, a string of all-Ascii is just a
> special case of a Unicode string of partial Ascii.  Yet the special
> case does not require special handling.

I assume you mean "4.2" (ToUnicode) rather than "4.1" (ToASCII) here and
below.

Your comment applies equally to IDNA and IMAA.  ToUnicode step 1 is
not strictly necessary, but it avoids gratuitously lowercasing ASCII
letters.  For example, the internationalized label "xn--Jos-dma" is
converted to "José" by ToUnicode.  Without step 1, it would be converted
to "josé".

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

> 4.1/#3 does not say what to do if the result is empty.  For that
> matter, it does not say what to do if it is _not_ empty.
>
> 4.1/#6 does not specify what to do if the verification works or fails.

All the verification steps are governed by this paragraph:

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

> Also, why is it important that a segment is altered?

That check is needed in order to comply with the stated function of
ToUnicode:

    If the input sequence is a dequoted local part in ACE form, then
    the result is an equivalent dequoted internationalized local part
    that is not in ACE form, otherwise the original sequence is returned
    unaltered.

If no segment was altered in step 5, then the original input was not
an ACE, and therefore it is to be returned unaltered.  Without this
check, the original input would be returned altered (specifically,
Nameprepped).

> Having re-scanned the punycode specification, I find myself not
> understanding why hyphen gets special concern, for local-part.  If
> you want it to be just one more "protected" character, that's fine.
> However nothing about protected characters requires infix.

Yes, IMAA wants hyphen to be just another protected character.  But the
Punycode encoder introduces a hyphen where there was none.  For example,
if you feed "niño" to the Punycode encoder, it outputs "nio-8ma".

Punycode was designed for domain names, where introducing hyphens was
not a problem.  It uses all 37 LDH characters to maximize efficiency.

We could define a new encoding very similar to Punycode that uses "9"
instead of "-" (at a slight cost in efficiency), but I thought it would
be simpler to put a wrapper around Punycode that removes/restores the
hyphen.

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

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

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

> > 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?

To avoid astonishing users.

Suppose a user obtains an ACE mailbox at example.net that displays as
josé, and his friends with IMA-aware browsers start sending mail to
josé@example.net, which works fine, even though the powers-that-be at
example.net have not upgraded their MTA.  Now suppose that example.net
accepts mail for user+tag and delivers it to user.  People will
naturally expect to be able to send mail to josé[email protected].
That will work just fine if there is no crosstalk across protected
characters, but it will fail if there is crosstalk.

Suppose the manager of the aliases file at example.net creates an ACE
alias that displays as niño and expands to multiple addresses.  The
IMA-unaware MTA, whenever it expands the ACE alias, automatically looks
for a companion alias owner-ACE to use as the envelope From address.
That address will display as owner-niño if there is no crosstalk across
protected characters, but it will display as ASCII garbage if there is
crosstalk.

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

AMC