Parsing the issues and finding a middle ground -- another attempt

[Andrew Sullivan]

On Tue, Mar 03, 2009 at 04:09:51PM -0500, John C Klensin wrote:

> Of course, if one says "SHOULD apply the IDNA2003 mapping", then
> "MUST apply the IDNA2003 mapping by default" is completely
> redundant.   If it means anything at all, it is exactly what
> "SHOUD apply..." means.

I think I have seen other documents that have used that locution,
redundant though it may be, as a sort of emphatic way of saying, "Yes,
really do this."  But I don't have any reference right now.  In any case,
 
> Also, "MUST NOT use any other mapping" puts our Turkish friends
> and a few other edge cases into a situation in which they have a
> choice between doing something sensible and conforming to the
> standard. That is another situation we should try, IMO, to
> avoid, if only because, as soon as we say "to do something
> sensible, you have to violate the standard", we sort of
> encourage other violations for things others consider sensible.
> And that takes us right back to the loose "local mapping"
> language to which you, Mark, and others object.

…that sounds as if we're in the "loose local mapping" area anyway: if
the plan is not to say, "Don't do that," I'm not sure we ought to say
anything at all.  If we're really planning just to accept that
sometimes people are going to do "something sensible" at lookup, then
I believe people can map essentially any character they want (that
isn't already covered elsewhere) into any other character they want.
That sounds to me like a basic indeterminacy built into the lookup.
Yes, I object to that, because it sounds to me like something that
will never be interoperable.  As I've said before, I understand the
motivation behind that, and I'm completely sympathetic.  I also
understand the urgency of getting something out the door.  But surely
we cannot recommend to the world that if we don't have a rule for a
character, people are free to do whatever they want and still be using
"the same protocol"?

A
-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.