Re: Domain check in draft-obispo-epp-idn-00.txt

On 01/01/12 12:19, MICHAEL YOUNG wrote:
> BTW on language versus script I agree fully, it should be language not
> script,
> 
> On another note:
> 
> Francisco I am looking again at the old IDN I-D
> http://tools.ietf.org/id/draft-sienkiewicz-epp-idn-00.txt and note that
> your draft excludes the check command.
> 
> An operational nit:
> 
> So the reason it was included in the sienkiewicz draft is to reduce
> operational overhead.  If the registrar is unsure whether a character is
> included in the relevant language table (or a combination of characters)
> they can perform a domain check with the questionable punycode. If its not
> included in the implementation's language table or the combination is not
> permitted, the domaincheck comes back as not available with a specified
> reason.

No, this simply shoves the responsibility onto the registrar. That means the
registrar has two choices: either put in a speed bump to ask the customer
the language (bingo! potential lost sale) or use some heuristic to guess the
language at checking time using codepoint/language whitelists.[1]

Moreover, it complicates slows down the implementation of checking for the
registrar. Say a customer decides they want to register a bunch of French-,
German-, Italian-, and Spanish-language domains. This isn't unlikely: they
might be a pan-European body who wants to register the local variants of
their name. If the registrar is forced to include the a language code when
checking, that means they have to submit separate check commands for each
language. That slows things down a lot unless the registry supports
pipelining, which is far from likely. This is the more important issue.

So, from a registrar's perspective, requiring a language tag to be specified
when checking simply makes the life of the customer and registrar more
difficult just so as the registry can save a few cycles.

> This saves having to fail a domain create discover the same thing, a more
> expensive transaction for the registry.

It doesn't, and as I outlined above, it's feasible for the registrar, when
they're doing the domain availability check, to make sure that the domain
matches at least one of the codepoint tables for a language supported by the
registrar. This way they can avoid <domain:check> transactions for domains
that would fail anyway (and thus avoid a failing <domain:create> transaction
later).

There's a big advantage for the registrar to do this: it allows the registrar
to narrow down the list of languages that the IDN might be for, and thus
impose less of a UI burden on the customer, especially if the IDN matches one
and only one table, in which case the customer doesn't need to be asked what
language the IDN is in at all.

Affordances like these are important to making the process of selling domains
as smooth as possible.

So, while I'm fine with asking a language code in a <domain:create> request,
asking it as part of a <domain:check> request makes no sense from a
registrar's or customer's point of view.

K.

[1] In fact, this is what we do ourselves in our own storefront for .biz and
    .tel IDNs to avoid having to ask the customer for a language code when
    all they're doing is seeing if the domain is available in the first place.

-- 
Keith Gaughan, Senior Developer
PGP/GPG key ID: 3E896381
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg