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

On 06/01/12 19:03, Andrew Sullivan wrote:

> Of course some would ignore it.  Many registrars do blind create
> today, too, rather than performing a check.  

There's a special circle in hell for people who do that.

>> Still, you've left out the most important reason why servers ought to be
>> checking IDNs
> 
> I had no intention of suggesting that the server side (formally, the
> repository in EPP-speak) needn't check input.  I personally would
> prefer that gTLD registries do more validation, not less, and I think
> you're a moron if you don't check your input for minimal compliance
> with your own policies.

Very much agreed, though I was mentioning as I felt it needed to be mentioned.
What's left unsaid can easily be overlooked, after all.

>> Now, there are reasonable reasons for a registrar to lie. We, for instance,
>> only take a guess at the language an IDN might be for and for the likes of
>> Neustar who require a language code be provided, we provide that to them.
>> The domain might actually be an Irish-language one like
>> rásrothairnabhaile.biz[1], but that'll fit the table for French, which means
>> as far as the registry is concerned, that's a valid IDNs.
> 
> Well, guessing will only get you so far.

To be clear, we only cheat like this when checking, and we wouldn't be able to
sell .biz IDNs if we didn't, because if we *did* ask what language they were
searching in, that places a roadblock in the way of customers when performing
availability checks, which makes them less likely to buy from us. Fewer
roadblocks means more sales. That's why guessing the language when checking is
actually a good thing from both the registrar and customer's point of view.

> If your customer sends you a string in NFD form, what do you do?

NFD isn't too bad. It's easy enough to detect, and on our end we ensure
(insofar as is possible) that everything's in NFC form before checking.
Combining characters aren't that difficult to detect.

> What about in ISO8859-1?

That's potentially a bigger problem because somebody *may* somehow manage to
construct a ISO8859-1(5) encoded label that looks like valid UTF-8, but in
many cases, it's easy to detect and reject due to unexpected synchronisation
bits. It's not perfect, but it at least helps.

K.

-- 
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