mappings-01

[Lisa Dusseault]

My crystal ball is probably not as good as yours, but for whatever
it's worth, here's my muddle-ranking:

On Sun, Jul 5, 2009 at 11:41 AM, Mark Davis ⌛<mark at macchiato.com> wrote:
> That is, there are three options people have mentioned:
>
> A. mapping required by IDNA protocol

This would be a standards-phase muddle because we'd have to come to
strong consensus on exactly what every mapping would be, now, before
finishing.  That's a source of pain.  I believe some of the resistance
to this is also that there are cases (like spidering, verifying site
access, updating caches, verifying access logs, many are automated/bot
use cases) where mapping is strongly not desired, where only valid
input should be accepted and invalid input should be rejected as an
error rather than fudged.

> B. no mapping as part of IDNA docs

This would be a huge deployment-phase muddle because some applications
(particularly UIs) will do mapping anyway, to help users get from a
forbidden input to an acceptable lookup string -- and without any
standard, different applications will do it differently, and users
switching between a Web browser and an Atom client, for example, will
experience inconsistencies.  Implementors also have more work to do to
figure out appropriate mappings and who to listen to.

> C. optional, UI-only mapping in IDNA docs

This would also be a deployment-phase muddle because with an optional
mapping, some implementations would choose the option not to do it.
But at least when applications do mapping, users would be more likely
to see consistency.

>
> I think that C is far worse than B. So rather than going down the C route,
> I'd rather go back to John's original formulation (B).

So in sum my crystal ball shows B as worse than C though they're
admittedly all muddles.   I gave my reasoning why; is there something
I'm missing?  I'm pretty confident in the prediction that some
end-user applications will helpfully do mappings no matter what we
say, but we could debate that point if that's where we differ.

Lisa