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