Re: U-labels and draft-obispo-epp-idn-00

Hi,

At the risk of creating a stain on the ground where once there was a
horse that had already been beaten to death, let me try once more.

On Wed, Feb 15, 2012 at 08:57:17AM +0100, Patrik Fältström wrote:

> > The examples I gave are not U-labels, no.  But they're Unicode forms
> > of IDNA2003-compliant systems that happen to generate Punycode forms
> > that are perfectly good A-labels.  If I got a candidate U-label that
> > didn't match the A-label, I could detect this.  If I just get the
> > A-label, I can't.
> 
> Bingo!
> 
> Sending U-labels in addition to A-labels does not make any sense.

Of course if we could be sure that every time we had what looked like
an A-label, the party that sent it did in fact have the U-label, then
I agree that there would be no reason whatever to send them both.  The
nice thing about IDNA2008 is that every A-label corresponds to exactly
one U-label.

The nasty thing about IDNA2008, however, is that some A-labels also
correspond to Punycode forms from IDNA2003, and those Punycode forms
do not always match a Unicode form that is the same as the U-label
you'd get under IDNA2008.  See upthread for examples.

This incompatibility is one of the reasons that Unicode pushes UTS 46.
I'm trying to suggest a way to ensure no confusion, by ensuring we
have a (standard) way at registration time of detecting when something
is wrong.  I want to make the element optional precisely so that, at
some brave happy day in the future when we have no reason to suppose
anyone is sending an IDNA2003-based Punycode form, we could turn the
thing off.  Moreover, I'm aware that some registries don't like to do
this sort of additional verification of client-supplied data, and that
therefore it cannot be a required element.  Even RFC 5891 doesn't say
you need to submit both; it just says that it would be better.

> But then you do no longer talk about sending U-labels and A-labels!
> 
> You send unicode strings and A-labels!

Yes, in a case where the U-label and A-label are not products of one
another, then either the U-label or the A-label is wrong.  But in some
of those cases, it is _indeterminate_ which one is wrong.  For
instance, suppose I have a string with a final form sigma in the
middle of it (because it's made up by putting together two strings
that would be words in Greek), an IDNA2003 transformation will not
include Punycode that will get you a final form sigma.  The final form
sigma is mapped away, as you know.  Now, if you have the input of the
candidate U-label and the candidate A-label, you can tell whether they
are in fact the U-label and A-label for one another.  If you only have
the A-label, you can generate a perfectly good U-label, but it isn't
the one the EPP client thought it was requesting.

I maintain -- and I think the plain meaning of RFC 5891 agrees with me
-- that this additional check should result in the rejection of the
registration request.  If it makes you happier to call the element
where we put the candidate U-label "unicodestring", or
"bobsgreatuncle", or "greatpointlesslongnameforelement", instead of
"u-label", I don't care.  My point is merely that it is entirely
reasonable for a registry to have this requirement, and to enforce it.

Best,

A

-- 
Andrew Sullivan
[email protected]
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg