Q1 is mapping on lookup permanent or transitional?

Erik van der Poel erikv at google.com
Sun Apr 5 08:01:41 CEST 2009

On Sat, Apr 4, 2009 at 12:12 AM, John C Klensin <klensin at jck.com> wrote:
> --On Wednesday, April 01, 2009 09:07 -0700 Erik van der Poel
> <erikv at google.com> wrote:
>> On the other hand, although you didn't ask about
>> registration-side mapping, I find it ridiculous to attempt to
>> forbid mapping on that side. It is up to the registrars and so
>> on to come up with their own UIs. We have no say in that
>> matter.
> Depending on how one looks at it, you have either just come up
> with another variation of "we don't care what you do before the
> putative label gets into the protocol"

I think we need to clarify what we mean by "protocol". What does
"before the putative label gets into the protocol" mean? Does it mean,
before the label is placed in its slot in the "wire format"? Or does
it mean, before the rules of the IDNA spec start to apply? It seems
like a number of participants in this mailing list occasionally
confuse wire format with rules. Lately, I have been thinking of
protocol as a set of rules that must be followed by software (and
maybe hardware). Perhaps some protocols even include rules that must
be followed by humans.

> --the "local mapping"
> that you have argued against in other contexts--

You may be confusing me with Mark. Mark has argued strongly against
local mapping. I have stated my opinion that local mapping should not
be ruled out, since e.g. Turkish UIs may wish to perform machine-local
and language-specific mappings.

> or are making a
> different version of the suggestions others have made about
> stacks and/or pre-protocol mapping.
> To the best of my knowledge, no one has ever suggested that
> registrars cannot design their own UIs, that environments in
> which Unicode is not native must be forced to use Unicode, or,
> for that matter, that a would-be registrant who believes "up" is
> actually "down" has to get over that belief.

I was referring to Mark's statement "our meeting consensus was to
forbid mapping on registration". What does that actually mean? Does it
mean that registrars are not allowed to map to lower-case and then ask
the registrant to confirm the result? The term "registration" could
easily include the entire process from registrant's entry of the
label, to registrar's confirmation of that label, to registry's
storage of the label.

> In that regard, there is no protocol-visible difference between
> IDNA2003 and IDNA2008.  From a descriptive standpoint, IDNA2003
> doesn't discuss those issues at all  (some might even say that
> it tries to pretend that they don't exist) while the IDNA2008
> attempted to recognize them, note that different practices were
> appropriate to, and used in, different environments, and then
> move on.  The text that tried to do that upset enough people
> (including, IIR, you) that it has now been removed.  But, in its
> absence, you now believe the text is telling registrars how to
> design their UIs.

Again, I'm not talking about the text in the draft. I was referring to
Mark's statement about the consensus of the meeting.

> If we support mapping at all, the current state of the IDNA2008
> specs are trying to do one thing on the registration side that
> is new, and that is to try to insist that the registrant
> actually understand what is being registered, i.e., that the
> registrar (if there is one and the registrant directly if not)
> present the registry with either a U-label or an A-label or
> both, fully validated.  If the registrar wants to accept EBCDIC
> as part of the process or getting to that U-label and verifying
> it with the user, that really isn't our concern.

I agree with this. So, we're in violent agreement after all? :-)


More information about the Idna-update mailing list