EPP statuses and other questions

[Michael Graff <Michael_Graff@isc.org>]

I would check the mailing list archives, but...

Trying 192.71.228.17...
telnet: Unable to connect to remote host: Connection refused


I have a few questions.  First, is it an error to attempt to add a status
to an object when that object already has that status?  For instance,
adding clientHold to a domain when it already has that set?

Also, what about removing one that isn't there?

From a SQL point of view, it would be simplier to return an error.  To
allow this would require loading the existing status information and
comparing the changes to what's there, rather than simply returning
an error to the client when the INSERT or DELETE fails.  (Remember,
at least on PostgreSQL, an INSERT which violates constraints like UNIQUE
will abort the current transaction, so it would have to be restarted
after removing the already-present status.)


While I'm on statuses, what is the reasoning for allowing clients to
specify arbitrary text for why things are in a given status?  I can
understand the server doing this, but allowing the client to add this
seems to (1) make it difficult to return language-dependent messages,
since the client specifies only one language for a status, and (2) is
an odd separation of the registry-registrar data.  Even the example
given:

  C:          <domain:status s="clientHold"
  C:           lang="en">Payment overdue.</domain:status>

is something odd, since why would the registry _care_ why the
clientHold, was there?  The registry seems like a bad place for this
information, since it isn't clear if it is returned via say WHOIS.


On to "server local" IDs.

What was the rationale for allowing the CLIENT to specify the SERVER LOCAL
identifier for contacts (and I assume domains, and hosts)?  This seems like
a really bad idea.  For one, I could put some pretty rude IDs in there,
as a registrar.  Just choosing the first letters of a name won't work, since
I could choose "For Unlawful Carnal Knowledge, Very Slowly Goes Nim"
and end up with the obvious contact ID.  :)

Additionally, during a transfer, the receiving registrar can't change it,
so what's the point in letting the originating one specify it?  The
registrar should just record the ID assigned to the object by the server
and be done with it.

As I see it, the spec can:

(1)  Allow it to be specified, but the server may choose to ignore it.
     If the server always ignores it, this will make <contact:check> a
     totally useless command, and having it will create oddness for the
     client.  I.e, either they'll do a <check> and get back "no" for
     everything, and since they HAVE to specify something, be confused, or
     they'll get back a false "OK" and have the value they prefer ignored.

(2)  Remove the ability for a client to specify the name at all.

(3)  Allow the <transfer> command to change the ID, or the <update>
     command to do so, or both.

I would prefer to see (2), since it puts the policy on ID patterns
where I think it should be, on the registry.

--Michael