Re: Open Issue: Splitting of local-part into labels and where?

This message responds to messages by Marc Mutz, Martin Duerst, Roy
Badami, and Claus Färber.

Marc Mutz <[email protected]> wrote:

> I think that splitting into labels is needed to keep old software
> (esp.  MTAs and filtering software) working. I can't add more to Roy's
> arguments here, and I feel there will be not much discussion about
> this particular issue.

That's optimistic!  :)

> The more interesting point is _where_ to split. There are some very 
> obvious characters (mainly full stops and hyphens),

It would be nice to split at hyphens, but it would also be nice to share
the ToASCII/ToUnicode operations between IDNA and IMAA.  We can't have
both.

> The draft also mentions the option of using all non-alnum US-ASCII
> characters.  If the number of equivalent Unicode code points is small,
> then this is certainly the best option, although we should then
> provide a mapping table for the to-usascii mapping.

It might be preferable to simply require applying NFKC to the entire
local part before splitting it.  It's a more heavyweight operation, but
it's already in the toolbox.

> the draft specifies splitting local-part and domain at _the_ at-sign.

I don't think the draft says that.  It says:

   In an internationalized mail address, the following characters MUST
   be recognized as at-signs for separating the local part from the
   domain name:  U+0040 (commercial at), U+FF20 (fullwidth commercial
   at).

This is not intended to be a full specification of how to parse mail
addresses; see other RFCs for that.  This is merely intended to expand
the set of characters that can be used to separate the local part from
the domain name.

There are other places where the phrase "the at-sign" is used.  It is
meant as shorthand for "the at-sign that separates the local part from
the domain name".  If that's not sufficiently clear from context, we
could be more explicit.

Martin Duerst <[email protected]> wrote:

> Making sure that a user enters a '@' in the right form can and should
> be a quality of implementation issue under the responsibility of the
> application.

The same argument could be made about fullwidth full stop in IDNA.
There were arguments on both sides, and ultimately we chose to require
that all IDNA-aware applications recognize a few characters as dots.
If IMAA is to be a natural follow-on to IDNA, it ought to handle the
at-sign the same way.

By the way, one of the arguments for the dot requirement was the
following scenario:  You and I both have IDNA-aware applications, and I
can type a domain name into mine and it works, but when I type it into
the body of a message and mail it to you, and you paste it into your
application, it fails, because yours doesn't recognize the same dots
as mine.  We don't try to 100% solve that problem, but standardizing
the few most common variants of the essential delimiters is an easy 99%
solution.

Marc Mutz <[email protected]> wrote:

> We will not be able to use the same function for the LHS as for the
> RHS anyway.  That's simply b/c there are characters that are allowed
> in local-parts, but not in domains

The IDNA ToASCII and ToUnicode operations are designed to handle
all ASCII characters just fine, because domain names in general can
contain all ASCII characters, although host names and mail domains are
restricted to letters, digits, hyphens, and the dot separators.

In another thread I have outlined a scheme for reusing the IDNA ToASCII
and ToUnicode in IMAA.  If you think it wouldn't work, please explain.

> it's only logical to split at non-alphanum ASCII characters.

I agree.  Except we'd have to make sure that we can reverse the process.
For example, if we encode each piece in such a way that the encoding can
introduce hyphens, then we better not split on hyphens!  If we don't
reuse the IDNA operations, then it's possible to use an encoding that
uses only alphanumerics, and we can split on all non-alphanumeric ASCII
characters.

> We should, of course, exclude pathological cases, such as control
> characters

Huh?  If control characters are not considered delimiters, then that
leaves them as part of the pieces that get encoded, which is even worse.
If they're considered delimiters, then we don't mess with them at all.
I think "*all* non-alphanumeric ASCII characters" is the right target.

Roy Badami <[email protected]> wrote:

> If we assume we are going to use punycode, then you prety much *have*
> to split at dots, otherwise you'd have cases where punycode generates
> strings containing multiple consecutive dots.  Yes, you could make
> this valid by generating suitable quoting, but you'd be creating local
> parts that stand a significant chance of not working on the current
> Internet.

That's a very keen observation.  I don't know how afraid of quoting we
should really be, but it's good to be aware that non-ASCII forms that
don't need quotes can map to ACE forms that do need quotes.  I hadn't
really noticed that.

> I don't think it's clear at this stage that the implentational
> convenience of using the same function justifies the cost to the
> utility of the specification.

Implementational convenience is not the only reason to use the same
operations.  Another reason is so that when domains are copied into
local parts and vice-versa, they might be displayed intelligibly.  How
well that would or wouldn't work depends on whether local parts are
subdivided.

> Actually, I'm not even convinced at this point that it's clear that we
> should use punycode for the ACE, eg if we choose to ACE-encode strings
> containing dots, and require the result not to contain consecutive
> dots.
>
> Adam, what comes after AMC-ACE-Z ? :)

We can consider different prefixes, and different profiles, but I doubt
that anyone wants to see another encoding.  It just gets to be too much.
People might be willing to accept a simple wrapper around Punycode.
For example, in order to use hyphen as a delimiter we would need to
eliminate hyphens from the Punycode encoding, which could be done by
applying Punycode itself, then replacing the hyphen with the ACE infix
(which would be purely alphanumeric) (or prepend the infix if there is
no hyphen).

> There may of course be quoted at-signs in atoms on either side of the
> unquoted at-sign

Actually, atoms cannot contain at-signs.  Quoted-strings can, but
they're not permitted after the at-sign.

Claus Färber <[email protected]> wrote:

[regarding the set of delimiters for subdividing local parts]

> I'm not quite sure about the quoting characters ``"'' and ``\''. If
> we apply toASCII/toUnicode after dequoting the local part, there's no
> reason to include them.

Sure there is.  Consider:

    From: foo bar <"foo\"bar\\"@example.org>

The dequoted local part is:

    foo"bar\

In any case, I don't see the point of trying to justify each delimiter
individually.  I think its easier to justify a simple policy like
"all non-alphanumeric ASCII characters" or "all ASCII characters that
Punycode doesn't generate" (alphanumerics and hyphen).

AMC