Subject: [weirds] U-label support

From: Behnam Esfahbod <[email-masked]>
Date: Thu, 14 Mar 2013 18:52:35 -0400

Scott,

Just looked at the latest draft, following are a few comments regarding
U-label support.

0. It's generally pretty good and it's great news that A-labels are only
allowed under IDNA2008.

1. In section 3.3, It is not clear whether ALL the labels should be in one
format (U-label or A-label) or is it allowed to have one label formatted as
U-label and another one as A-label.

Here are 4 possible representations for one FQDN, all of which must be
accepted, IMO.
مثال.آزمایشی.
مثال.xn--hgbk6aj7f53bba.
xn--mgbh0fb.آزمایشی.
xn--mgbh0fb.xn--hgbk6aj7f53bba.

2. In sections 3.3 & 3.4 we have:

   If the client sends the server an IDN U-label, servers that support
   IDNs MUST convert the IDN into A-label format and perform IDNA
   processing as specified in RFC 5891 [RFC5891].  The server should
   perform an exact match lookup using the A-label.

I do not understand the rational behind this paragraph. I believe we do not
have the intention to tell the server implementation how to work. Some
might like to take the proposed approach, but when the server is able to
lookup a domain name in U-label format, it should be allowed to do so.

If all we care about is the presentation format of domain names in the
response document, we should just say so.

And again please don't forget that domain names have (in most cases here)
more than one U-label. So "an IDN U-label" is not a good way to put it.

3. Instead of "xn--xemple-9ua.com" as an IDNA example domain, I think we
should use a subdomain of example.com or something like that.

[OT] It's a pity that we do not have reserved FQ IDNs to use in these
cases. Is there any chance we can use the example.test names here? Do we
need to make it official first, as an RFC?

4. In section 5, it says:

   [...] but
   clients of programmatic interfaces may wish to submit and display
   A-labels or may not be able to input U-labels with their keyboard
   configuration.

I think this part is not clear enough, as these two situations are not the
only possible situations where A-labels become handy.

In the first part, does "display" refer to the response from server, or
just displaying the queried domain name in the UI?

And finally, in the last part, it's not clear if the "keyboard
configuration" is a "client" limitation or just user's configuration.

Thanks,
-Behnam

-- 
Behnam Esfahbod | بهنام اسفهبد
http://behnam.es/
GPG-FP: 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 14 Mar 2013 23:48:14 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Behnam Esfahbod
Sent: Thursday, March 14, 2013 6:53 PM
To: [email-masked]
Subject: [weirds] U-label support

Scott,

Just looked at the latest draft, following are a few comments regarding U-label support.

0. It's generally pretty good and it's great news that A-labels are only allowed under IDNA2008.

1. In section 3.3, It is not clear whether ALL the labels should be in one format (U-label or A-label) or is it allowed to have one label formatted as U-label and another one as A-label.

Here are 4 possible representations for one FQDN, all of which must be accepted, IMO.
مثال.آزمایشی.
مثال.xn--hgbk6aj7f53bba.
xn--mgbh0fb.آزمایشی.
xn--mgbh0fb.xn--hgbk6aj7f53bba.

Thanks for the feedback. I tend to think that clients will pass either the first or fourth forms through to the server, but if the two middle forms are possible then yes, the text should make it clear that they’re acceptable.

I do not understand the rational behind this paragraph. I believe we do not have the intention to tell the server implementation how to work. Some might like to take the proposed approach, but when the server is able to lookup a domain name in U-label format, it should be allowed to do so.

Actually, we *do* have a responsibility to tell the server implementation how to convert an input format that needs to be converted in order to promote interoperability. This is part of the reason the IDNA specs very clearly define processing procedures.

If all we care about is the presentation format of domain names in the response document, we should just say so.

This isn’t about the presentation for in the response. It’s about consistent server-side processing so clients know what to expect.

And again please don't forget that domain names have (in most cases here) more than one U-label. So "an IDN U-label" is not a good way to put it.

I could accept a change to “an IDN in U-label format”.

3. Instead of "xn--xemple-9ua.com<http://xn--xemple-9ua.com>" as an IDNA example domain, I think we should use a subdomain of example.com<http://example.com> or something like that.

[OT] It's a pity that we do not have reserved FQ IDNs to use in these cases. Is there any chance we can use the example.test names here? Do we need to make it official first, as an RFC?

It’s just an example. I’m inclined to leave it as-is.

   [...] but

I think this part is not clear enough, as these two situations are not the only possible situations where A-labels become handy.

In the first part, does "display" refer to the response from server, or just displaying the queried domain name in the UI?

And finally, in the last part, it's not clear if the "keyboard configuration" is a "client" limitation or just user's configuration.

The idea here is that if you’re using a “dumb” client it may be easier for you to work with a-labels. Something got mangled here in copying and pasting. It should say something like “clients using programmatic interfaces may wish to submit and display A-labels if they are unable to input U-labels with their keyboard configuration”. If that’s not clearer please suggest replacement text.

Scott

---

From: "John Levine" <[email-masked]>
Date: 16 Mar 2013 05:54:17 -0000

>I do not understand the rational behind this paragraph. I believe we do
>not have the intention to tell the server implementation how to work.
>Some might like to take the proposed approach, but when the server is
>able to lookup a domain name in U-label format --

 -- it is non-compliant with all IDNA standards, so whatever it is
doing is out of scope for WEIRDS.  (Keep in mind the "as if" rule,
which allows the server to do whatever it wants internally so long as
it gets the same result as converting U- to A- and looking up the
latter.)  I realize this gets more complicated when we try to do
partial matches, but let's burn that bridge next week.

I would suggest that each input field either has to be all A-labels or
all U-labels.  Although it's technically possible to translate input like
<a-label>.<u-label>.<a-label> I think it's more likely to be a mistake,
so even for us writers of tiny scripts, I don't see any utility in allowing it.

For outupt, I'd like to see some thing like 

  { u-label: "fóo"; a-label: "xn--fo-pdq" } 

wherver an IDN domain name can appear, so the clients can just pick
out whatever they need.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 16 Mar 2013 05:58:45 -0000

>3. Instead of "xn--xemple-9ua.com<http://xn--xemple-9ua.com>" as an IDNA
>example domain, I think we should use a subdomain of
>example.com<http://example.com> or something like that.

Feel free to use xn--exmple-qta.com / exámple.com and see if you can
sneak it past the IESG.

---

From: SM <[email-masked]>
Date: Wed, 27 Mar 2013 10:15:07 -0700

At 16:48 14-03-2013, Hollenbeck, Scott wrote:
>[OT] It's a pity that we do not have reserved FQ IDNs to use in 
>these cases. Is there any chance we can use the example.test names 
>here? Do we need to make it official first, as an RFC?

There are a few IDNs which appear as reserved.  There was an effort 
to get it through a RFC.  The draft did not gain traction.

Regards,
-sm

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 27 Mar 2013 19:10:34 +0000

> -----Original Message-----
> From: SM [mailto:[email-masked]]
> Sent: Wednesday, March 27, 2013 1:15 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: Re: [weirds] U-label support
> 
> >cases. Is there any chance we can use the example.test names here? Do
> >we need to make it official first, as an RFC?
> 
> There are a few IDNs which appear as reserved.  There was an effort to
> get it through a RFC.  The draft did not gain traction.

Minor point, but that's not my text.

Scott

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 29 Mar 2013 10:32:01 +0100

On Mar 27, 2013, at 6:15 PM, SM <[email-masked]> wrote:

> There are a few IDNs which appear as reserved. 

Pointer please?

I am not a big fan of 'sneaking past the IESG', that introduces delays at a point where you can do without, so lets make sure we do not have an issue before sending to the IESG.

--Olaf

NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
[email-masked]

Science Park 400, 1098 XH Amsterdam, The Netherlands

---

From: SM <[email-masked]>
Date: Fri, 29 Mar 2013 03:32:17 -0700

Hi Olaf,
>Pointer please?

See http://www.iana.org/domains/special

>I am not a big fan of 'sneaking past the IESG', that introduces 
>delays at a point where you can do without, so lets make sure we do 
>not have an issue before sending to the IESG.

I don't know whether these examples could be used they don't have the 
same status as the RFC 2606 examples.

Regards,
-sm

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 29 Mar 2013 12:47:53 +0100

> See http://www.iana.org/domains/special

That page documents a temporary experiment. The names on that page seem to be associated with a mnemonic seems to translate to 'test' (according to a quick google-translate experiment). Personally I think we should not step on them without coordination.

> I don't know whether these examples could be used they don't have the same status as the RFC 2606 examples.

As netizen I am pushing back. I think it is bad practice to squat in the Domain name space without appropriate coordination. 

That 'appropriate coordination' is something that I would need to do with my chair hat on and since I am not looking forward digging up the worm-can opener I have a very strong preference to pragmatically use something 'under' example.com.

--Olaf

NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 29 Mar 2013 09:26:21 -0600

> That 'appropriate coordination' is something that I would need to do with my chair hat on and since I am not looking forward digging up the worm-can opener I have a very strong preference to pragma…

Are we looking for documentation examples or examples for real-world
testing?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 29 Mar 2013 17:33:31 +0100

> Are we looking for documentation examples or examples for real-world

Documentation.

--Olaf

NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 29 Mar 2013 10:51:17 -0600

>> Are we looking for documentation examples or examples for
>> real-world testing?
> 
> Documentation.

In that case just do names of the form *.example (from RFC 2606).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "John Levine" <[email-masked]>
Date: 29 Mar 2013 17:13:01 -0000

>> Are we looking for documentation examples or examples for real-world

The only reserved TLDs are the ones listed in RFC 2606: .test.
.example, .invalid, and .localhost.  RFC 6761 created a registry and
the process for adding new ones, but there have not yet been any new
ones.

ICANN's new TLD applicant guidebook has a list of reserved TLDs on
pages 2-9 and 2-10, including those four and 30 others, all ASCII.
They have an additional list on page 2-11 of reserved names related to
the Red Cross and Olympics, both ASCII and IDN.  Regretably, they
didn't (as far as I know) consult with the IETF on any of them so it's
unclear how reserved they really are beyond the current round of TLD
applications.

So I agree, use .example.  If you want to use exámple.com for a sample
IDN, the registrant probably won't object.