Subject: EPP statuses and other questions

From: Michael Graff <[email-masked]>
Date: 20 Nov 2002 22:59:58 +0000

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 27 Nov 2002 13:09:47 -0500

> > On Tue, Nov 26, 2002 at 10:32:44PM +0000,
> >  Michael Graff <[email-masked]> wrote 
> >  a message of 55 lines which said:
> > 
> > > (1)  A handle (like FOO1-ISC) is not self-describing.  Is 
> that a contact
> > >      handle, a domain handle, or what?
> > 
> > I see it a a "registry policy" issue. Some will have a global
> > namespace for handles (with the risks you explain) and some 
> will have
> > separate namespaces for contacts and hosts.
> 
> According to the current draft, this isn't possible.  For 
> hosts and for
> domains, sure.  However, for clients, the registrant (not 
> even the registrar
> according to how people say they'll be used!) chooses the local name,
> and therefore the GLOBAL name as well, since the global ROID 
> is defined
> as the local_part-REGISTRY

Where in the current drafts do you see requirements for how the local part
of the ROID is defined as you've described?  There's _nothing_ in the
contact draft that says that the local part MUST be the contact ID, and the
core draft says this (section 2.8):

"Specific identifier values are a matter of repository policy, but they
SHOULD be constructed according to the following algorithm:

a) Divide the provisioning repository world into a number of object
repository classes.

b) Each repository within a class is assigned an identifier that is
maintained by IANA.

(c) Each repository is responsible for assigning a unique local
identifier for each object within the repository.

(d) The globally unique identifier is a concatenation of the local
identifier, followed by a hyphen ("-", ASCII value 0x002D), followed
by the repository identifier."

There's nothing here that I see that requires the restriction you've alluded
to.

-Scott-