Re: standardized local-part structuring

Adam,

I was suggesting a simplifying approach to IMAA.  Apparently I did not make my
point clearly enough.  Or, more likely of course, I am misunderstanding
something pretty basic.

Let's see how this round goes:

AMC> The protected characters are defined in section 2 as all ASCII
AMC> characters except letters and digits, which is the set you propose

Defined, yes.  The problem is why they have syntactic import to a global
standard.

Sections 4.1 and 4.2 define mapping algorithms, between pure Unicode and
IMAA-encoded Unicode.  Doing segmentation at protected boundaries makes the
imaa mechanism significantly more complicated.

(Normally, this sort of character translation is defined by a grammar, rather
than an algorithm. Using a grammar, reference to special, lexical items is
straightforward. The same point applies to the syntactic definition of
boundaries, such as the *fix operator.)

As long as we are discussing the algorithms:

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.

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/#4 is where IMAA gets into the problem of attempting to process local
conventions. Note that simply removing steps #4, #5, #6, and #7 makes the
processing of the entire string work just fine. Assuming that "protected"
characters are never translated, then their possible role as delimiters is
preserved, without IMAA having to be cognizant of that role.

4.1/#6 does not specify what to do if the verification works or fails.  Also,
why is it important that a segment is altered?


>> ToAscii translation should never create a string that uses any of
>> those characters,

AMC> ToASCII never introduces new instances of those characters and never
AMC> reorders them.  But it also never deletes or hides them.

Good.


>> the use of an infix, rather than prefix, "signal" string, seems pretty
>> strange.

AMC> It is necessary if Punycode is used and hyphen is protected.  If hyphen
AMC> is protected, then the encoding must not allowed introduce hyphens.
AMC> But Punycode introduces a hyphen in the middle of the encoded string.


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.

It seems to me that this should all be done as a simple extension to RFC2822:

    addr-spec       =       local-part "@" domain

    local-part      =       ascii-local / ace-local

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

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

    ima-prefix      =       "0iesg1"

    ace-encoded-unicode  =   {here's where your toAscii, etc. algorithm goes}



AMC> Therefore the hyphen needs to be replaced by an alphanumeric signal
AMC> string, which might as well serve as the ACE signal itself.

It seems like there is something wrong with a translation algorithm, when it
needs to protect the translated string from the translation mechanism, itself.


AMC> Plus, it is well-behaved in one additional respect:  Not only are
AMC> protected characters left alone, but the substrings between the
AMC> 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>  For example, if
AMC> jos0iesg1dma is the encoding of josé, and msica0iesg17ua is the
AMC> encoding of música, then jos0iesg1dma+msica0iesg17ua is the encoding
AMC> of josé+música (there is no "crosstalk").

Oh.  You are attempting to provide a quoted-printable kind of selective
translation, rather than a total, base64 type of translation?

So Unicode, itself, does not have a means of switching from one set of
characters to another? So it is required that an IETF standard for email
local-part contain this explicitly?

Or perhaps it should simply be possible to have the whole string be in
Unicode, without the complexity and overhead of switching back and forth...


AMC> IMAA not only avoids
AMC> accidentally invoking local structuring conventions, it is neutral
AMC> enough to allow those conventions to be deliberately invoked in
AMC> internationalized local parts, even in domains using old MTAs.

Only if the conventions entail characters from the protected set.  But in that
case, the structuring characters are passed transparently.

As to "transparently using old MTA's",

1) the whole string is now in ascii, so old mtas doing simple relaying don't
care about the structuring, and

2) the target MTA already must know about both the local conventions and any
special characteristics of the string characters, in order to register and
process the string.


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