Subject: Re: [weirds] search for A-labels

From: Ernie Dainow <[email-masked]>
Date: Mon, 22 Jul 2013 11:07:40 -0400

On looking over that section more carefully, I do have a number of
questions.

The following on p.5 seems unnecessarily restrictive:
Clients SHOULD NOT submit search requests with partial matching for DNS
A-labels.

While there may not be meaning for an arbitrary partial A-label string
because it does not represent a proper Unicode string, that doesn't mean it
doesn't make sense to search for it in some cases.

Suppose someone receives a list of domains that includes A-labels, but the
margins are exceeded and the string is truncated, to say xn--ykq47 instead
of xn--ykq477cfxr. If search for xn--ykq47* is supported, they have a good
chance of discovering the full domain name.

Since the underlying DNS is ASCII, what is ultimately registered and
typically stored in the registry database is the A-label for an IDN. In
this case, this is a simple search. If a provider does not store A-labels,
then they may not wish to support this type of search.

-Ernie

On Wed, Jul 17, 2013 at 9:41 AM, Andy Newton <[email-masked]> wrote:

>
>
> That's correct, this change impacts both the rdap-query draft and the
> json-response draft.
>
> My only hesitation with this approach is with the internationalization
> aspects of search processing. I hope everybody is comfortable with Section
> 4 of that draft, especially paragraphs 3 and 4.
>
> -andy
>
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 22 Jul 2013 15:13:34 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ernie Dainow
Sent: Monday, July 22, 2013 11:08 AM
To: Andy Newton
Cc: [email-masked]
Subject: Re: [weirds] search for A-labels

On looking over that section more carefully, I do have a number of questions.

The following on p.5 seems unnecessarily restrictive:
Clients SHOULD NOT submit search requests with partial matching for DNS A-labels.

While there may not be meaning for an arbitrary partial A-label string because it does not represent a proper Unicode string, that doesn't mean it doesn't make sense to search for it in some cases.

Suppose someone receives a list of domains that includes A-labels, but the margins are exceeded and the string is truncated, to say xn--ykq47 instead of xn--ykq477cfxr. If search for xn--ykq47* is supported, they have a good chance of discovering the full domain name.

A partial A-label can't necessarily be decoded into a partial U-label. We have the SHOULD NOT there because the results may be unpredictable.
Scott

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2013 15:39:33 -0000

> ...

>results may be unpredictable.

But the names they match will be full A-labels.  I have to agree with
Ernie (for once), this seems like a restriction that forbids some
useful scenarios, and doesn't fix anything.  If you return the query
string in the result and can't decode it, then just don't decode it.

If there are A-labels in the database that aren't actually encoded
U-labels, that's a different problem.

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Tue, 23 Jul 2013 18:54:45 +0000

On 7/22/13 11:39 AM, "John Levine" <[email-masked]> wrote:

>>A partial A-label can't necessarily be decoded into a partial U-label.
>>We have the SHOULD NOT there because the
>>results may be unpredictable.
>

The point Scott is trying to make, I think, is that we are attempting to
define how two pieces of software interoperate and that unpredictable
results are likely in this case. At the very least we should point out
that the results will be unpredictable or at-best based on partial match
semantics of ASCII only.

-andy