Re: Compatibility with IDNA

Reminder of context:  This is a continuation of the thread exploring
the question "What would it take to use the same ToASCII/ToUnicode
operations for both IMAA and IDNA?"

I wrote that IMAA could use the IDNA ToASCII if it didn't allow quite as
much flexibility in the case of the output:

>     If the input of ToASCII contains no uppercase characters, then the
>     output of ToASCII must contain no uppercase characters.

I had the right idea, but I didn't express it quite correctly.  The
above wording fails to account for titlecase characters, or for
uppercase characters that have no lowercase mates (like Cyrillic letter
palochka and all the Georgian capital letters).  What I meant was:

    Definition:  String X is "canonical case" iff CaseFold(X) = X.

    Constraint:  If the input of ToASCII is canonical case, then the
    output of ToASCII must also be canonical case.

I then explained that IMAA would need to impose the constraint on
ToUnicode too.

But earlier I had said that IMAA and IDNA could use the same prefix only
if they used the exact same ToUnicode.  Oops!  How bad is this?

Not a disaster, I think.  The danger of using the same prefix is that
the wrong ToUnicode operation might get applied.  I can think of two
ways this could happen:

1) Implementation error.  A program applies the IDNA ToUnicode operation
to a local part, in blatant violation of the standards.  A different
prefix would protect against this blunder, but one could argue that we
as spec designers are not obligated to provide such protection, if there
are other advantages to be gained by not providing it.

2) Copying local parts into domain names, or vice-versa.  For example,
DNS SOA records.  Now a program might innocently use the ToUnicode
operation appropriate for the data type where the string now sits, not
knowing that it was actually copied from a different data type.  In
fact, this is one of the main reasons for reusing ToUnicode, so that
things might get displayed intelligibly even when copied from one side
of the at-sign to the other.

Regardless of how the wrong ToUnicode gets applied, what damage can
result?  If the IMAA ToUnicode is used on a domain label, there is no
problem, because the IMAA ToUnicode is just a more constrained version
of the IDNA ToUnicode.  If the IDNA ToUnicode is used on a local
part, the result could be wrong (sending mail to it would bounce),
but only if the mail server is case-sensitive and the ToUnicode
implementation gratuitously uppercases some of the output characters
even though its input was all lowercase ASCII.  I can imagine a
ToUnicode implementation that uppercases some of its output characters
when some of the input characters are uppercase ASCII (that's how case
preservation via mixed-case annotations would work), but I cannot
imagine what would posess a ToUnicode implementation to go to the
extra effort of uppercasing some of its output characters given an all
lowercase ASCII input.

Not only is the risk small, but it's a risk that already exists today
with ASCII local parts that are copied into domain names.  Whereas
applications "must" preserve the case of ASCII local parts, they merely
"should" preserve the case of ASCII domain labels.  If the local part
of [email protected] is case-sensitive, and I put foo.example.org in an
SOA record, there is a risk that that the domain name will somehow fall
into the hands of a program that gratuitously capitalizes domain names,
yielding FOO.EXAMPLE.ORG.  When this is eventually converted back to a
mail address, [email protected], it won't work.

In summary, I still think that using the same ToASCII & ToUnicode
operations, including the same profile and prefix, for both domain
labels and local parts, is a viable option worth considering.  I haven't
decided whether I think it's the best option.

AMC