Subject: [weirds] A-label and U-label Lookups

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 13 Mar 2013 16:29:46 +0000

While on the way home last night I had an interesting conversation with one of my colleagues while we were waiting for our flights at the airport. He asked me a question about IDNs that made me think.

Imagine a web browser being used as an RDAP client. A human user types a URL that looks like this in the address bar:

http://example.com/domain/exämple.com

If we require the client to convert the domain name into a-label form, the browser is going to have to parse and process the path portion of the URL to convert /domain/exämple.com to /domain/xn--exmple-cua.com). That means "browser mods needed", which may be an impediment to adoption.

As I slept on this last night I kept hearing "be liberal in what you accept". That's making me think twice about a-labels only. Supporting U-labels for lookups would mean more work for DNR server operators, but it may be work that's worth the price if it truly helps the adoption process.

So should the query/lookup draft include support for both a-labels and u-labels? I'm seriously thinking it should.

Scott

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 13 Mar 2013 09:36:46 -0700

Yes,

My opinion is that we should be able to take both a-labels and u-labels.

(in fact that's how I'm implementing ours).

> So should the query/lookup draft include support for both a-labels and u-labels? I'm seriously thinking it should.

Francisco Obispo 
Director of Applications and Services - ISC
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: Steve Sheng <[email-masked]>
Date: Wed, 13 Mar 2013 09:49:07 -0700

+1 to this on accepting both U-label and A-label. As an end user, I think
this a perfectly valid use case.

Kind regards, 
Steve

-----Original Message-----
From: <Hollenbeck>, Scott <[email-masked]>
Date: Wednesday, March 13, 2013 12:29 PM
To: "[email-masked]" <[email-masked]>
Subject: [weirds] A-label and U-label Lookups

>While on the way home last night I had an interesting conversation with
>one of my colleagues while we were waiting for our flights at the
>airport. He asked me a question about IDNs that made me think.
>
>Imagine a web browser being used as an RDAP client. A human user types a
>URL that looks like this in the address bar:
>
>If we require the client to convert the domain name into a-label form,
>the browser is going to have to parse and process the path portion of the
>URL to convert /domain/exämple.com to /domain/xn--exmple-cua.com). That
>means "browser mods needed", which may be an impediment to adoption.
>
>As I slept on this last night I kept hearing "be liberal in what you
>accept". That's making me think twice about a-labels only. Supporting
>U-labels for lookups would mean more work for DNR server operators, but
>it may be work that's worth the price if it truly helps the adoption
>process.
>
>So should the query/lookup draft include support for both a-labels and
>u-labels? I'm seriously thinking it should.
>
>Scott
>_______________________________________________
>weirds mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/weirds

---

From: Jean-Philippe Dionne <[email-masked]>
Date: Wed, 13 Mar 2013 15:37:13 -0400

> So should the query/lookup draft include support for both a-labels and u-labels? I'm seriously thinking it should.

I think we should accept u-labels in queries.  If we do this, we must
have a canonical url with an a-label to represent the ressource.  This
canonical url could be reported to the client by a link in the json
response or maybe an http redirect.

However, the problem of matching/searching the u-label on the server's
a-label in it's database still reside.

Jean-Philippe

---

From: Andy Newton <[email-masked]>
Date: Wed, 13 Mar 2013 20:44:59 +0000

>response or maybe an http redirect.

I'm not sure about a redirect, but putting a canonical link relation seems
like a good idea.

-andy

---

From: James Mitchell <[email-masked]>
Date: Fri, 15 Mar 2013 01:52:15 +1100

Scott,

Comments below, prefixed with JM.

James

>means "browser mods needed", which may be an impediment to adoption.

JM: Since you are talking about browser clients then we should look at the
behaviour of domain (host) names appearing the the URL/IRI. Browsers map
Unicode strings into a domain name that can be looked up in the DNS. I am
hesitant to use the terms U-label and A-label in this process because the
definition of A/U-label is that they are IDNA-valid according to the IDNA
2008 protocol [https://tools.ietf.org/html/rfc5890#page-11], and as far as
I am aware browsers are still using IDNA 2003 or equivalent mappings.
Considering that, a user types the domain ÖBB.com into their browser and
it works (converts it to xn--bb-eka.com, öbb.com), however ÖBB is not a
U-label. The user then somehow gets to /domain/ÖBB.com and now the weirds
server would need to implement the same mapping as the browser or
otherwise risk introducing confusion.

That said, servers would have some idea of the possible mappings that
would occur for the languages/scripts available in their registry and
should be able to do a fairly accurate job at mapping the Unicode string
into the expected domain name. The way I have implemented this before is
to guarantee that LDH-labels (xn--bb-eka.com) and U-labels (öbb.com) will
work as provided without mapping, and your mileage may vary when using
arbitrary Unicode strings (ÖBB.com, o''bb.com - where '' is my kludge for
combining diaeresis).

On the issue of mapping, I think I would prefer if the IRI changed from
/domain/ÖBB.com into /domain/öbb.com (redirect?), such that the path
always contained only A-labels or U-labels. This would at least be
consistent with how my browser renders the domain name (other browsers may
do different things).

>it may be work that's worth the price if it truly helps the adoption

JM: A-labels actually require more work for us if we are to match
unallocated variants.

>u-labels? I'm seriously thinking it should.

JM: Yes, +1. And if you are expecting this service to work for dumb
software clients proxying for human users then we should probably mention
that there may be usability issues if they do not consider mappings too.

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 21 Mar 2013 16:28:56 +0100

> My opinion is that we should be able to take both a-labels and u-labels.

[no hats]

One clarification question (similar to the one I asked in a different thread earlier today).

If we say A-Labels and U-Labels we mean that the input is valid under IDNA2008. Do we want the client to do that validity check?

Or do we mean that we allow unicode encoded labels and the server will sort out whether those are indeed valid U-Lables?

--Olaf

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 21 Mar 2013 15:35:25 +0000

> From: Olaf Kolkman [mailto:[email-masked]]
> Sent: Thursday, March 21, 2013 11:29 AM
> To: Francisco Obispo
> Cc: Hollenbeck, Scott; [email-masked]
> Subject: Re: [weirds] A-label and U-label Lookups
> 
> 
> If we say A-Labels and U-Labels we mean that the input is valid under
> IDNA2008. Do we want the client to do that validity check?
> 
> Or do we mean that we allow unicode encoded labels and the server will
> sort out whether those are indeed valid U-Lables?

I'm suggesting the latter. I'm concerned about asking generic http clients like web browsers to process portions of URLS in ways that they don't currently.

Scott

---

From: Pete Resnick <[email-masked]>
Date: Thu, 21 Mar 2013 11:30:39 -0500

> I'm suggesting the latter. I'm concerned about asking generic http clients like web browsers to process portions of URLS in ways that they don't currently.

Things get tricky pretty darn quickly here. I expect you'll want to 
answer the following questions as well. Is a server allowed to reject 
things that aren't valid U-Labels because:

- they use uppercase characters?
- they use IDEOGRAPHIC FULL STOP character (U+3002) instead of U+002E?
- they are not in NFC?
- they use any characters that are DISALLOWED?
- they use percent-encoded characters?
- they use ampersand-encoded characters?
- they are not in UTF-8 at all?

Certainly the server will have to protect itself from bad input, 
whatever the document says. But do you want the protocol to allow allow 
any input and not have the client do any processing to validate input? 
And if they are expected to do any validation/processing, why not expect 
them to do all of it?

I'm not suggesting any particular answers to these questions. I'm only 
suggesting that the document is going to have to be clear about what the 
answers to those questions are.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "John Levine" <[email-masked]>
Date: 21 Mar 2013 17:56:28 -0000

>to do that validity check?

Yes.

>Or do we mean that we allow unicode encoded labels and the server will sort out whether those are
>indeed valid U-Labels?

Since the server cannot depend on clients to be bug-free, yes.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 21 Mar 2013 19:20:13 +0000

> From: Pete Resnick [mailto:[email-masked]]
> Sent: Thursday, March 21, 2013 12:31 PM
> To: Hollenbeck, Scott
> Cc: Olaf Kolkman; Francisco Obispo; [email-masked]
> >> Or do we mean that we allow unicode encoded labels and the server
> >> will sort out whether those are indeed valid U-Lables?
> >>
> > I'm suggesting the latter. I'm concerned about asking generic http
> clients like web browsers to process portions of URLS in ways that they
> don't currently.
> 
> And if they are expected to do any validation/processing, why not
> expect them to do all of it?
> 
> suggesting that the document is going to have to be clear about what
> the answers to those questions are.

That's precisely why I included text that requires IDNA processing as specified in 5891. Whether or not that's the right approach is open to debate, but it was an attempt to bound the problem.

Scott