Re: Example of stupid inconsistencies between registries

You can solve your interface dilemma by always accepting key data and have your provisioning system generate the DS data in the background for the registries that require it :) Doing so also allows you to generate the DS using the algorithms required by the registry.

I don't believe that DS should be a must. As Klaus mentioned, server-side variants mean that key data may be preferred.

James

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Patrik Fältström
> Sent: Tuesday, 6 March 2012 8:58 AM
> To: Andrew Sullivan
> Cc: [email protected]
> Subject: Re: [provreg] Example of stupid inconsistencies between
> registries
> 
> 
> On 5 mar 2012, at 16:05, Andrew Sullivan wrote:
> 
> > Your complaint seems to be that a registrant has to provide different
> > data for different names.  I fail completely to see why that is a
> > problem.  (To put this slightly differently, you seem to be arguing
> > that a registrant shouldn't need to understand that example.com and
> > example.org are different domains.  This seems a little bit at odds
> > with your views on the many things people call "variants".)
> 
> No, I am just talking about how to design for example a web interface
> and instructions to the one that is to paste data into it. You have a
> number of fields, and different fields are mandatory depending on what
> TLD it is.
> 
> Same with for example an API. If you run a DNS hosting, would it not be
> easier if you can pass the same information to all registrars, and not
> have to do different depending on which one it is?
> 
> I am just talking about how much more difficult it is for everyone but
> the registry if it asks for something else than the DS, and in many
> cases it can also fetch the Key from the auth server if it want to
> validate the DS... Part from some cases where one want DS pre-published
> in the parent zone when the parent simply must trust whatever the
> registrar send anyway as it can not validate the data passed to it. As
> nothing is in the child zone that the data can be validated against.
> 
>    Patrik

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg