Subject: RE: EPP statuses and other questions

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 20 Nov 2002 19:39:58 -0500

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

---

From: Michael Graff <[email-masked]>
Date: 21 Nov 2002 01:02:01 +0000

> interpretation -- it's there because it describes something about the

I still don't think the registry is the place for this additional
information.  I'm certain people want to store things like credit
card numbers to bill people with, but the registry isn't the place for
that, either.  I know my example here is absurd, but since the data
isn't there for the operation of the registry, it should not be in
the registry, IMHO.

Why flags were set on domains, hosts, etc. seems like it should go into
the registrar database, instead.  But, I understand why it's there,
even if I think it's a mistake.  :)

> normative references listed in the specs.

Ahh, I missed that part, sorry.

> those limits are not something that should be built into the protocol

I can see the need for this sort of thing, even if I don't like it.  I
assume this is so I can move my contact/domains to a new registrar without
having to change contact handles, etc.

--Michael

---

From: Jens-Uwe Gaspar <[email-masked]>
Date: Thu, 21 Nov 2002 12:32:29 +0100

Dear Michael,

> even if I think it's a mistake.  :)

Sure, that kind of information can be stored in the registrar-database.
But we prefer that it is stored in the registry. It often happens, that
a domain has to be set on lock-status for UDRP/WIPO/injunctions.
Even so we store a comment like

  'domain locked at 21-Jan-2002 by request of somebody (UDRP)'

in our registrar-database, we also attach it as comment to the
lock-status in the registry. The registry holds in our case the
authoritative information.

The registry is a good place for it, so our customer support can
easily see the cause for the lock/hold from a registry-request only
(by some internal info-server). 

Kind regards,

Jens-Uwe Gaspar

>...

________________________________________________________________________
Jens-Uwe Gaspar                              Schlund + Partner AG
E-Mail: [email-masked]                       Erbprinzenstr. 4 - 12
Tel. +49-721-91374-50                        76133 Karlsruhe, Germany
Fax  +49-721-91374-20                        http://www.schlund.de

---

From: Michael Graff <[email-masked]>
Date: 25 Nov 2002 23:58:43 +0000

"Hollenbeck, Scott" <[email-masked]> writes:

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

Coming in somewhat late to the EPP game, I still find the object
identifiers to be somewhat confusing.  For contacts, we have a
client-supplied string.  Ok, I can live with that.  For domains, you
say it's the domain name, and for hosts, the hostname.

Then, the "roid" is confusing.  Not only is it NOT returned in
response to a <create> command, it needs to be used in some cases as a
unique identifier!

For authinfo, if you're working on a domain object and want to specify
the authinfo for a contact instead, you use the contact's "roid" --
the client-supplied name (converted to a globally-unique ID), like
"SA1234-ISC" or "MG2-ISC" or whatever.

  C:          <domain:pw roid="JD1234-REP">2fooBAR</domain:pw>

This specifies that the password data is associated with the contact
JD1234-REP, not the domain object's password.  However, this
contact:roid isn't returned in response to a contact <create> request
but is for <info>.

Domains and hosts have riods too, and they are not the
hostname or domain name.  In what context are these to be used?
If the domain roid is really the global identifier (the local ID with
the registry identifier appended, like FLAME-ISC for an "isc"
registry) then the (for lack of a beter term) "handle" for a host or
domain isn't the host or domain name.

  S:        <domain:name>example.tld</domain:name>
  S:        <domain:roid>EXAMPLE1-REP</domain:roid>

Additionally, from the definition of a riod, a period isn't allowed,
and they can only be 80 characters long before the dash.  Domain names
can be longer.

So, once again, I'm back to thinking that we have a unique string (the
old style "handle" mentality) in EPP.  Am I still not seeing
something?

If the riods aren't used externally, so they can be queried through
say whois, why are they needed at all?  In that case, the domain name
or host name really is enough.

--Michael