Re: standardized local-part structuring

"Adam M. Costello" <[email protected]>
Newsgroups gmane.ietf.imaa
Message-ID <[email protected]>
Dave Crocker <[email protected]> wrote:

> IMAA should list a set of reserved ASCII characters.

It lists a set of "protected" characters.

> I'll suggest that the set of reserved characters be all ASCII graphic
> characters.

The protected characters are defined in section 2 as all ASCII
characters except letters and digits, which is the set you propose
plus the invisible ASCII characters.  IMAA has no desire to muck
with invisible characters, so they might as well be included in the
don't-touch set.

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

ToASCII never introduces new instances of those characters and never
reorders them.  But it also never deletes or hides them.  Why should it?
The purpose of ToASCII is to smuggle non-ASCII characters into an ASCII
local part, not to smuggle special non-alphanumeric ASCII characters
into a purely alphanumeric ASCII local part.  Let ASCII characters be
themselves to the greatest extent possible.  (Quoted-printable takes a
similar approach.)

> and ToUnicode should simply pass those characters unchanged.

It does.  ToUnicode, like ToASCII, never inserts, deletes, or reorders
protected characters.

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

It is necessary if Punycode is used and hyphen is protected.  If hyphen
is protected, then the encoding must not allowed introduce hyphens.
But Punycode introduces a hyphen in the middle of the encoded string.
Therefore the hyphen needs to be replaced by an alphanumeric signal
string, which might as well serve as the ACE signal itself.

It looks to me like IMAA is already doing what you propose:  It steers
clear of nonalphanumeric ASCII characters so that it will never
accidentally invoke local structuring conventions that use those
characters as delimiters.

Plus, it is well-behaved in one additional respect:  Not only are
protected characters left alone, but the substrings between the
protected characters are encoded independently.  For example, if
jos0iesg1dma is the encoding of josé, and msica0iesg17ua is the
encoding of música, then jos0iesg1dma+msica0iesg17ua is the encoding
of josé+música (there is no "crosstalk").  IMAA not only avoids
accidentally invoking local structuring conventions, it is neutral
enough to allow those conventions to be deliberately invoked in
internationalized local parts, even in domains using old MTAs.

In IMAA, a "segment" is simply a substring of a local part whose
encoding is independent of the rest of the local part.  IMAA does not
know whether those boundaries have any significance to higher layers; it
avoids crosstalk across those boundaries just in case some of them do
have significance.

AMC
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.