RE: EPP statuses and other questions

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> 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.)

If a request can not be completed as requested an error should be returned.
Status values can not exist twice, so I would say that an error should be
returned if a status can not be added because it's already present.  Same
for trying to remove one that's not there.

> 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.

People said that they wanted to include additional information describing
why a status has been applied, to add clarifying info, etc.  The server
might not care about the reason, but it's not necessarily there for server
interpretation -- it's there because it describes something about the
object.

> 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.

The unique identifier for domains and hosts is the domain name and host
name, respectively.  The valid syntax for these names is defined in multiple
normative references listed in the specs.

As I've said in a private response to a message you sent me off-list, the
contact mapping is a general purpose mapping that is not necessarily for use
only with domain names and the like.  The idea is that the identifier can be
something that is easy for a human to remember, much like those you provide
when you register for services like email accounts, web site accounts, etc.
Implementers and server operators can define an implementation profile that
requires certain strings in the ID, or restricts use of certain strings, but
those limits are not something that should be built into the protocol
itself.

-Scott-