Re: Complexity for case-sensitive systems

Roy Badami <[email protected]> wrote:

> If one wanted to support case-sensitive systems, wouldn't it be enough
> to require punycode to output only lower-case (or alternatively only
> upper-case)?

And require ToASCII to prepend the lowercase form of the ACE prefix.

This then implies changes to either ToUnicode or the formal model of
equivalence.  Either you alter ToUnicode so that only lowercase ACEs
are decoded (which will annoy users, because local parts often get
uppercased, which violates the standards but is currently harmless
in practice); or you let ToUnicode decode uppercase ACEs and change
the symmetric equivalence relation to an asymmetric substitutability
relation (because it's okay to replace IESG--FOO with <nonASCII>, but
<nonASCII> must not be replaced with IESG--FOO, it has to be iesg--foo).

So there is a tradeoff between functionality (playing nicely with
uppercased local parts) versus complexity of the model (asymmetry).

> this would preclude the use of mixed case annotation...

The same tradeoff exists here.

Instead of requiring that ToASCII always use lowercase in the Punycode
encoding and the ACE prefix, we could merely require that it "preserves
lowestcase"; that is, if the input is lowestcase, then the output
must be lowestcase, but non-lowestcase input is also acceptable, in
which case non-lowestcase output is permitted.  Local parts (both ACE
and non-ACE) in case-insensitive domains would be case-insensitive,
while non-traditional local parts in case-sensitive domains would be
lowestcase-only (ASCII ACE forms containing uppercase letters must not
be created, and non-lowestcase non-ASCII forms are unreliable).  A
string is "lowestcase" if Nameprep would have the same effect on it
regardless of whether Stringprep table B.2 (the case-folding table) is
used or omitted.

The easy way for a ToASCII implementation to preserve lowestcase is
simply to always uses lowercase in the Punycode encoding and the ACE
prefix, so this model would be no burden on implementations, but it
would make the spec more complex.

We need to ask whether it makes sense to make any effort or any
compromises to support case-sensitive mail exchangers.  Case-sensitivity
is discouraged by RFC 2821.  Does anyone know of any case-sensitive
local parts that actually exist?

AMC