Subject: Re: [weirds] Determining the registered domain

From: "Alexander Mayrhofer" <[email-masked]>
Date: Fri, 6 Apr 2012 09:37:59 +0200

Murray S. Kucherawy wrote:
> Do the names people think that this work could support the idea of doing 
> a lookup in a way that requests the registration that "contains" the 
> name being submitted?  Or are we looking at only exact matches?

The WHOIS style name services that i'm aware of are all excact-match 
style services, and this is likely also the expectation of the user community
(mostly registrars, but also domain name owners etc.). However, responses 
that allow the server to indicate to the client that the resource might be found
elsewhere could be interesting in the following cases:

a) "Contains" type response:

This is referring to what you described above. The registry is auhoritative for the 
name space "above" the resource provided, such as a superordinate domain.
If the service provides a "contains" response, then i think it needs to be clearly 
delineated from the "exact match" response. For example, a "contains" match could
for example use HTTP response code 303 ("See other"), while an exact match 
would return HTTP 200.

b) Variants

IDN registrations can lead to "variants" of a domain name, which are automatically
"bundled" with the "main registration". Such variants may or may not show up in 
the DNS, based on policy. For example, registration of "würstel.tld" *could* also 
automatically register "wuerstel.tld" as a variant. Typically, there's only one registration record for such an IDN bundle, and typically, there's a "base registration".

In such a case, a server could also respond with 303 See Other, redirecting the client to 
the base registration.

In case that an IDN bundle does not have a "base registration", but all Variants are equal,
the server could also respond with a 300 Multiple Choices (however, on a second thought
it probably doesn't make much sense, because this would send the client into an endless
loop of trying to find the variant that contains the actual registration data).

c) Search-style requests

Search-style requests (such as substring requests) would also potentially create multiple responses. Such requests could also be answered with a 300 Multiple Choices response. 
However, i'm not sure that substring searches would be in scope for this work (and, i 
wouldn't want to run it for several reasons anyway..) 

Alex

---

From: Byron Ellacott <[email-masked]>
Date: Wed, 11 Apr 2012 11:32:43 +1000

> loop of trying to find the variant that contains the actual registration data).

If the names response follows a similar path to the numbers response, I'd expect this sort of information to (potentially) be in the "uris" response element:

"label" : "würstel.tld",
"uris" : [
    {
        "type" : "variant",
        "uri" : "http://example.com/rws/name/wuerstel.tld"
    }
],

But potentially, this could also be a canonical registration label and a variants list:

"label" : "würstel.tld",
"variants" : [ "wuerstel.tld" ],

If the request is for http://example.com/rws/name/wuerstel.tld, it can either redirect to /rws/name/würstel.tld or give the same response with the canonical uri in the "source" uris link.

I'm not sure if the appropriate model for variant registrations is to have them each represented as a separate registration, or to have them represented as variations of the label in the single registration, but there are ways to handle either case while keeping to the "zero or one responses" design choice.

  Byron