ICANN/GNSO GNSO Email List Archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [registrars] FW: Registrars - gTLD Registries Constituencies - Items for Discussion?

  • To: Mike Lampson <lampson@xxxxxxxxxxxxxx>
  • Subject: Re: [registrars] FW: Registrars - gTLD Registries Constituencies - Items for Discussion?
  • From: Eric Brunner-Williams in Portland Maine <brunner@xxxxxxxxxxx>
  • Date: Tue, 12 Oct 2004 17:35:59 +0000
  • Cc: Rick Wesson <wessorh@xxxxxx>, "'Registrars Constituency'" <registrars@xxxxxxxx>, Bhavin Turakhia <bhavin.t@xxxxxxxxxxx>, brunner@xxxxxxxxxxx
  • In-reply-to: Your message of "Tue, 12 Oct 2004 16:22:00 -0400." <GGECJFAHCACDDOOANHCIMECDFCAA.lampson@iaregistry.com>
  • Sender: owner-registrars@xxxxxxxxxxxxxx

> I haven't read all of the specs top-to-bottom

I have. So have others on this list.

>                                            ... but in general the EPP specs
> are very careful to provide an implementation that is agnostic to the
> business policies of the Registry.

That wasn't a design goal. Transport protocol independent, epp over beep
over tcp, epp over beep over sctp, those were design goals. We didn't
consider things like fractional second registrants for business that wanted
to time-share share a name, or multiple simultanious registrants for business
that wanted to offer collective name ownerships or ... seriously, there are
a lot of business "rules" buried in the design assumptions of epp 1.0.

>                               ....  As long as PIR supports the syntax of
> the EPP message, I believe that it is within their rights to return an error
> code instead of a success code if their business policies disallow this data
> transformation.

You believe that epp is simply a syntatic binding? Just a way to shuffle
xsd fragments from one box to another???

So you don't care if a <create> actually creates anything, right?

>             ...  For example, PIR may choose to return error code 2306,
> Parameter value policy error, in this case.

3732 3,2,5 says that a client may send an <update:chg> to a server, and
something sensible will occur. A 2306 independent of the object attribute
value would not be sensible.

Just mark it up to another reason why having Afilias operate .net would be
an adventure in paridise (same for vgrs and nu*, different dorks, same net
effect of registrar indifference).

I'll dork my compliance matrix accordingly.

E



<<< Chronological Index >>>    <<< Thread Index >>>