Subject: [weirds] a-labels and u-labels in json response

From: Andy Newton <[email-masked]>
Date: Wed, 13 Mar 2013 17:00:39 +0000

Accepting u-labels is only half of the equation. What do people want to do
with the json-response?

Is it it acceptable to say that domain names in the response are always
a-labels? Or is a better approach to say that if the name of the domain
object is a U-label, then the server SHOULD provide a variants section and
those MUST be a-labels?

Opinions?

-andy

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 13 Mar 2013 10:02:05 -0700

We should include both, in different fields.

On Mar 13, 2013, at 10:00 AM, Andy Newton <[email-masked]> wrote:

> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

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

---

From: Behnam Esfahbod <[email-masked]>
Date: Wed, 13 Mar 2013 13:43:21 -0400

Andy,

Please don't ever do that! At IRNIC, we did a similar thing -- showing
U-label of the requested domain and A-labels of the variants -- in our EPP
extension and soon we realized it's very confusing for our clients
(resellers/registrars).

IMHO we need both of them everywhere, as the output is supposed to be
understandable by end-users, whether they understand the script of the
domain name or not.

-Behnam

-- 
    '     بهنام اسفهبد
    '     Behnam Esfahbod
   '
  *  ..   http://behnam.esfahbod.info
 *  `  *  http://zwnj.org
  * o *   3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B

---

From: Ernie Dainow <[email-masked]>
Date: Wed, 13 Mar 2013 15:06:06 -0400

As there is a one-to-one mapping between A-label and U-label, they always
occur in pairs. As pointed out, it becomes confusing if the U-label is used
in some contexts and the A-label in others. So domain/nameserver names
should always appear in json as a pair of names. The example on p.24 of
draft-ietf-weirds-json-response-02 should be something like

"name" :
{
a-label : "aaaaa",
u-label : "uuu",
}
"variants" :
[
{
 "relation" : [ "registered", "conjoined" ],
 "variantNames" :
[
{
a-label : "aaaa1",
u-label : "uuu1",
},
{
a-label : "aaaa2",
u-label : "uuu2",
}
]
},
...
]

Where u-label should be left out if the a-label is an ASCII name.

-Ernie

---

From: "John Levine" <[email-masked]>
Date: 13 Mar 2013 19:32:47 -0000

>should always appear in json as a pair of names.

That seems reasonable, but please keep in mind the error scenarios
when due to bugs or malice, the A- and U- labels don't match.

My preference would be that clients can send either A- or U-labels,
and don't have to say which they're sending, since the server can
easily tell by inspection while it's sanity checking its input.
Servers should send back both.

---

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

I would prefer a full representation of the name not just the *-label, perhaps something like "u-name" and "a-name"?

On Mar 13, 2013, at 12:06 PM, Ernie Dainow <[email-masked]> wrote:

> As there is a one-to-one mapping between A-label and U-label, they always occur in pairs. As pointed out, it becomes confusing if the U-label is used in some contexts and the A-label in others. So domain/nameserver names should always appear in json as a pair of names. The example on p.24 of draft-ietf-weirds-json-response-02 should be something like
> 
> "name" : 
> 	{
> 		a-label : "aaaaa",
> 		u-label : "uuu",
> 	}
> "variants" :
> 	[
> 		{
> Please don't ever do that! At IRNIC, we did a similar thing -- showing U-label of the requested domain and A-labels of the variants -- in our EPP extension and soon we realized it's very confusing for our clients (resellers/registrars).
> 
> IMHO we need both of them everywhere, as the output is supposed to be understandable by end-users, whether they understand the script of the domain name or not.
> 
> -Behnam
> 
> 

Francisco Obispo

---

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

> u-label : "uuu",

This is redundant information.  I am against this.
Only the a-label form should be found in the response. The conversion
from a-label to u-label can be done by the client.

Jean-Philippe

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 13 Mar 2013 12:56:44 -0700

adding more complexity on the client, doesn't help the cause.

besides, we need to send a clear message that this is the 'official' interpretation of the [u,a]-labels, if the client messes with the encoding, they'll end up with a different string, and that's not acceptable.

Francisco Obispo

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 13 Mar 2013 16:10:06 -0400

> adding more complexity on the client, doesn't help the cause.

in a previous email I sent, I claimed that the client has no choice to have already enough i18n processing. So I think this consideration above is moot.

Let me restate another way:
- weirds is about domain names (and else).
- domain names now include idn
- IDNA processing is needed for any software that is handling/processing idn.
- therefore weirds clients shall have IDNA processing already.

Therefore, that  "complexity" can not be avoided.

> besides, we need to send a clear message that this is the 'official' interpretation of the [u,a]-labels, if the client messes with the encoding, they'll end up with a different string, and that's n…

I'm not sure I follow you. official interpretation of u/a labels is defined in IDNA documents.

What we need to define here, for idn, is where the IDNA processing will be done, and what is sent on the wire. (those are obviously closely related)

Marc.

---

From: "John Levine" <[email-masked]>
Date: 13 Mar 2013 20:26:30 -0000

>- IDNA processing is needed for any software that is handling/processing idn.

Sorry, but that's just not true.

A dumb client can just send along the UTF-8 for a name in its queries.
If it turns out not to be a valid U-label (or sequence of U-labels),
it'll get an error from the server, but so be it.

Unless you want your server to crash any time someone uses a buggy
client, it is mandatory that it check the validity of its input.  It
doesn't matter at the server end whether the client has already
validated it, the server can't depend on that so it has to do it
again.

It would often be nice if a client with a human user did all sorts of
elegant validation and provided brightly colored error messages, but
there will also be plenty of clients that do not have human users, and
it makes no difference to the calling software where a bogus name is
rejected.

R's,
John

---

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

>it'll get an error from the server, but so be it.

I think John has a good point. People are gonna write dumb clients.
There's just no way around it. As I said sometime back, RDAP clients
should be easily constructed with bash and curl.

-andy

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 13 Mar 2013 13:55:50 -0700

+1

Francisco Obispo

---

From: Joseph Yee <[email-masked]>
Date: Wed, 13 Mar 2013 17:07:40 -0400

> should be easily constructed with bash and curl.

This takes care of dump client request.  That's only first half.

And do servers expect do more on response when dump request comes in?
If the client sends dump request, what should server assume for the client?
It's dump that the response need to include U-label?  OR It's dump
that don't send Unicode in response because they may crash?

I'm not entirely in favor of A-label only response, but I see the
rationale behind it (there are other reasons beyond this).  And we
kept reiterate it's machine-to-machine.  Sure, there are always some
human will just do command line :)

Joseph

---

From: Behnam Esfahbod <[email-masked]>
Date: Wed, 13 Mar 2013 17:22:02 -0400

+1

Field names should not be named "u-label"/"a-label" as these terms are
already well-defined and are not applicable here. Anything like
"name"/"ascii-name", "unicode-name"/"ascii-name", or "u-name"/"a-name"
would do the job.

-Behnam

On Wed, Mar 13, 2013 at 3:46 PM, Francisco Obispo <[email-masked]> wrote:

> I would prefer a full representation of the name not just the *-label,
> perhaps something like "u-name" and "a-name"?
>
>
>
>
> > As there is a one-to-one mapping between A-label and U-label, they
> always occur in pairs. As pointed out, it becomes confusing if the U-label
> is used in some contexts and the A-label in others. So domain/nameserver
> names should always appear in json as a pair of names. The example on p.24
> of draft-ietf-weirds-json-response-02 should be something like
> >
> > "name" :
> >       {
> >               a-label : "aaaaa",
> >               u-label : "uuu",
> >       }
> > "variants" :
> >       [
> >               {

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

---

From: "John R Levine" <[email-masked]>
Date: 13 Mar 2013 17:44:01 -0400

> And do servers expect do more on response when dump request comes in?

No, they give the same response as always, since they can't tell what the 
client is.

Having written my share of dumb programs, I expect there will be two 
general kinds.  One is for debugging, and they'll just display whatever 
the result is.  The other is likely to be looking for some particular part 
of the response, perhaps a contact telephone number or the country of the 
registrant.  For that latter group, it would be nice to return both the 
U-label and the A-label, so dumb clients that want one or the other can 
just pick it out of the result, without having to drag in an IDNA library 
to do translations.

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

---

From: Behnam Esfahbod <[email-masked]>
Date: Wed, 13 Mar 2013 13:41:35 -0400

Andy,

Please don't ever do that! At IRNIC, for a short period of time we did a
similar thing -- showing U-label of the requested domain and A-labels of
the variants -- in our EPP extension and soon we realized it's very
confusing for our clients (resellers/registrars).

-Behnam

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