Re: Domain check in draft-obispo-epp-idn-00.txt
Francisco Obispo <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
I don't see a problem with using the extension during the check command, it could be used as Michael stated, in a complimentary way, and as stated, its use could be totally optional from the registrar side. I agree that registrars should be performing those tests/validations ahead of time and shouldn't rely exclusively on the registry for those types of validation, because that would increase registry load significantly. Regards, Francisco On Jan 4, 2012, at 12:37 PM, Michael Young wrote: > > What can I say, it would be great if the registrar put that kind of intelligence in their storefront and didn't send domain creates that violate a given language table. > > Most registrars aren't making that extensive of an effort. Why? What if the registrar messes up on their filter and denies the registrant a registration the registry actually allows. Ooops starts to sound like a lawsuit, better the registrar makes the registry say no. It's cheaper to say no in domain check than a create. However I think there's room here to satisfy both concerns. > > Adjust the domain check ext so the language tag element is optional. No language tag and it assumes a straight ASCII registration. > > Then those registrars that want to validate their own work can and registrars that aren't sure can test a punycode string against the extended domain check. This seems like a compromise that works, thoughts? > > -M > > > On 2012-01-04, at 2:18 PM, Patrik Fältström <[email protected]> wrote: > >> >> On 4 jan 2012, at 19:46, Keith Gaughan wrote: >> >>> No, this simply shoves the responsibility onto the registrar. >> >> I agree. >> >> Checking MUST be done at the registry. >> >> Registrar push whatever domain name it believes might be possible to register. Either that succeeds or the registry is giving a result back that can be presented to the user. >> >> So the registrar do broad filtering and helps the registrant, but then registry is doing the work. >> >> Patrik >> >> _______________________________________________ >> provreg mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/provreg > _______________________________________________ > provreg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/provreg Francisco Obispo email: [email protected] Phone: +1 650 423 1374 || INOC-DBA *3557* NOC Key fingerprint = 532F 84EB 06B4 3806 D5FA 09C6 463E 614E B38D B1BE _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg