Subject: [weirds] A-labels vs U-labels

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Mar 2013 11:06:03 -0400

In the interests of time, I'll send this to the list.

It is absurd to insist that queries be A-labels.  First, A-labels and
U-labels are perfectly convertible to one another, and therefore there
is no reason to prefer one over the other.  Second, nobody can use
A-labels, so we're just creating a user interface problem but
pretending we aren't.

A
-- 
Andrew Sullivan
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 12 Mar 2013 11:17:06 -0400

> A-labels, so we're just creating a user interface problem but

Hi Andrew,

As we discussed in the meeting, the question is where the pain of
conversion happens. It's not obvious to me (coming from the outside)
what exactly the user agents are in this architecture, and how smart
they could be about doing conversion (vs. leaving it up servers). But I
think I'll try to chat with you in person this week so I can understand
it better.

Peter

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

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 12 Mar 2013 11:22:36 -0400

> think I'll try to chat with you in person this week so I can understand

one of the advantage of client-based processing is that the client will be able to reject non-valid strings right away and give proper error to the user.

Marc.

> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Mar 2013 11:29:10 -0400

> think I'll try to chat with you in person this week so I can understand

You're quite right about this.  Perhaps I could put it another way: if
we insist that input is A-labels, then we need to specify something
like what IDNA2008 did in handling input.  I note the success of the
IDNA mappings document in blunting the publication of UTS-46.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 12 Mar 2013 15:37:21 -0000

>one of the advantage of client-based processing is that the client will be able to reject
>non-valid strings right away and give proper error to the user.

That's not much of an advantage.  If you want to sanity check your
input and verify that a string is a U-label, you can do so whether or
not you translate it to an A-label.

-- 
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: Behnam Esfahbod <[email-masked]>
Date: Tue, 12 Mar 2013 11:41:07 -0400

> A-labels, so we're just creating a user interface problem but

+1

And also note that using U-labels would make the protocol transparent to
IDNA version, IDNA2003 vs IDNA2008. Unless we want to make IDNA2008 on the
client side, using A-labels could be very destructive for
IDNA2008 adaptation, IMHO.

-Behnam

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

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 12 Mar 2013 11:53:53 -0400

Le 2013-03-12 à 11:29, Andrew Sullivan <[email-masked]> a écrit :

> like what IDNA2008 did in handling input.

that is what I wrote (or at least intended to or try to) in my review sent sometime ago. so I agree.

Marc.

>  I note the success of the

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 12 Mar 2013 12:05:00 -0400

> not you translate it to an A-label.

let me try to be more precise on what I was trying to say (which was in fact imprecise):
a) we have various fields that are internationalized, not only domain names
b) because of a), we need to make some pre-processing steps. question is where should we do them
c) the end-users have various input methods, etc...
d) so the client is doomed to "process" some of the internationalization, including handling errors.
e) because of b) and d), it seems to me that the client side should do the work, as browsers are "doing" today for idn.

client side pre-processing means roughly:
- doing idna processing for domain names
- doing precis-based processing for other i18n identifiers

(and maybe something similar for search, depending on what we want to do and the level of agility we want to put on the search)

Marc.

---

From: "John R Levine" <[email-masked]>
Date: 12 Mar 2013 12:14:51 -0400

> d) so the client is doomed to "process" some of the 
> internationalization, including handling errors.

> e) because of b) and d), it seems to me that the client side should do 
> the work, as browsers are "doing" today for idn.

Whether or not the client validates its input, servers also have to 
validate their input, because clients have bugs.

It's not comparable to browser IDNA, because the whole point there is to 
allow existing DNS servers and caches with no knowledge of IDN to continue 
to work.  WEIRDS servers know all about IDNs, so we might as well take 
advantage of that.

Also, as came up at the session today, if you want to permit any sort of 
search or approximate matching, A-labels are hopeless.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 12 Mar 2013 17:38:49 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Marc Blanchet
> Sent: Tuesday, March 12, 2013 11:23 AM
> To: Peter Saint-Andre
> Cc: [email-masked]
> Subject: Re: [weirds] A-labels vs U-labels
> 
> >> U-labels are perfectly convertible to one another, and therefore
> >> there is no reason to prefer one over the other.  Second, nobody can
> >> use A-labels, so we're just creating a user interface problem but
> >> pretending we aren't.
> >
> > Hi Andrew,
> >
> > they could be about doing conversion (vs. leaving it up servers). But
> > I think I'll try to chat with you in person this week so I can
> > understand it better.
> 
> one of the advantage of client-based processing is that the client will
> be able to reject non-valid strings right away and give proper error to
> the user.

I concur with both of these points. The client implementation sits much closer to the actual user. I'm not a fan of having to do a lot of input validation on the server when it comes to doing lookups or searches because that processing will place a load on the server that takes away from doing the actual lookup/search work.

Scott

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Mar 2013 14:35:38 -0400

> IDNA2008 adaptation, IMHO.

This is both true and false.

For instance, a client might send a query for faß.de.  Depending on
what version of IDNA (and preprocessing) the server is operating,
that either matches the domain "fass.de" or "faß.de" or, worst,
{"fass.de","faß.de"}.  I don't think U-labels get us out of that pain.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Behnam Esfahbod <[email-masked]>
Date: Tue, 12 Mar 2013 15:02:41 -0400

Right Andrew. That's exactly my point. Using U-label here doesn't get us
out of the pain, but using A-label would add to the pain! ;)

-Behnam

On Tue, Mar 12, 2013 at 2:35 PM, Andrew Sullivan <[email-masked]>wrote:

> For instance, a client might send a query for faß.de <http://fass.de>.
>  Depending on
> that either matches the domain "fass.de" or "faß.de <http://fass.de>" or,
> worst,
> {"fass.de","faß.de <http://fass.de>"}.  I don't think U-labels get us out
> of that pain.
>
> A
>
> --
> Andrew Sullivan
> [email-masked]

---

From: Behnam Esfahbod <[email-masked]>
Date: Tue, 12 Mar 2013 15:11:20 -0400

Scott,

>  I concur with both of these points. The client implementation sits much
> closer to the actual user.

Why is that a concern? IDNA is an *encoding* and not a *policy*.

> I'm not a fan of having to do a lot of input validation on the server when
> it comes to doing lookups or searches because that processing will place a
> load on the server that takes away from doing the actual lookup/search work.
>

Are you assuming A-labels are in some way more trustful than U-labels? If
yes, why is that?

-Behnam

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 12 Mar 2013 19:21:26 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Behnam Esfahbod
Sent: Tuesday, March 12, 2013 3:11 PM
To: Hollenbeck, Scott
Cc: Marc Blanchet; Peter Saint-Andre; [email-masked]
Subject: Re: [weirds] A-labels vs U-labels

Scott,

I concur with both of these points. The client implementation sits much closer to the actual user.

[SAH] The software client has access to user environment information that makes it much easier for it (the client) to deal with encoding and display issues. I want the protocol and centralized server implementation to be as simple as possible.

I'm not a fan of having to do a lot of input validation on the server when it comes to doing lookups or searches because that processing will place a load on the server that takes away from doing the actual lookup/search work.

Are you assuming A-labels are in some way more trustful than U-labels? If yes, why is that?

[SAH] This isn’t about trust, but with an A-label I don’t have to do additional decoding processing on the server. On a high volume server all of the extra cycles add up.

Scott

---

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

> {"fass.de","faß.de"}.  I don't think U-labels get us out of that pain.

[no-hats]

So it seems that the adaptation of a particular IDNA version is registry policy. 

Given that premiss (are there still registries that operate on IDNA2003), I think the question is if we allow the protocol to be neutral to that policy question? 

If we want it to be policy neutral then isn't it the case that the client then could send Unicode strings and allow the server to check whether the submitted labels are valid U-labels? (Under IDNA2008 they would be valid A-labels too then, but not under IDNA2003).

The alternative would be to standardize clients to use IDNA2008. I am not sure exactly what the impact would be on registries that use IDNA2003. An implementation note for the special cases might be what is needed then?

Personally I would have a preference for client side pre-lookup checks on IDNA2008 but I haven't got a good feel for the consequences. That said I think that it inside of the IETF scope to not use obsoleted protocols (and thereby de-facto favoring specific policy choices).

--Olaf

NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
[email-masked]

Science Park 400, 1098 XH Amsterdam, The Netherlands