Subject: RE: EPP statuses and other questions

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 26 Nov 2002 07:06:04 -0500

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

The list archives are back up.  I'm no fan of ROIDs myself, but instead of
rehashing the debate that led to their inclusion in the protocol I'd suggest
that you go through the archives.  It starts about here:

http://www.cafax.se/ietf-provreg/maillist/2001-01/maillist.html

and goes on for quite a while.

-Scott-

---

From: Michael Graff <[email-masked]>
Date: 26 Nov 2002 21:07:58 +0000

> and goes on for quite a while.

I've read almost every post on that page, and a few from other pages.

My only concern is that by adding RIODs, there are now two ways to refer
to an entity.  Worse yet, there are amazing ways to end up with
inconsistent and confusing versions of the local and global IDs.

In the spec, for contacts, the globally unique id (ROID, if I understand
things right) is the client-supplied local name + the registry identifer.
This is intended to allow external references to that contact.  How is this
expected to actually work?  How are notifications passed to others using
this global ID?  I don't see anything about that in the spec.

I'd suggest global IDs be removed, and added back as an extension later,
if (1) a registry WANTED that extension, and (2) a good, well-thought-out
inter-registry/inter-database protocol is formed.

We don't need to have that in the first cut, this is an extensable protocol,
after all, and the base implementation is already complicated enough.

P.S.  I don't see why we need to complicate the protocol with ROIDs, anyway.
After all, when I want my web page to refer to someone else's site, I just
include an identifer (the host and the path, etc) -- why can't an
inter-registry handle be something more similar to a URN?

        srs.isc.org:mg2
        srs.example.com:foo.com

etc.  This does the same sort of thing that ROIDs do now, and keeps the
complications of ROIDs out of the picture.  The other points about inter-
database sharing of IDs still applies, though.

--Michael

---

From: Michael Graff <[email-masked]>
Date: 26 Nov 2002 22:32:44 +0000

> I've read almost every post on that page, and a few from other pages.

And after reading much more, I feel the mistake is that there are two
handles for objects now, and that is becomming a pain in trying to
implement EPP.

(0)  ROIDs are not well thought out, nor well integrated into the 07
     draft at least.

(1)  A handle (like FOO1-ISC) is not self-describing.  Is that a contact
     handle, a domain handle, or what?

(2)  Part of the handle namespace is client-chosen, part is registry-chosen.
     On contacts, the local (and thus the global) identifiers are chosen
     by the registrant, where domain and other ROIDs are chosen by the
     registry.  This means the registry cannot fix (1) easily.

     Example:  Suppose a contact, "FLAME1" is created, and assigned
     ROID of FLAME1-ISC.  Now, later, that contact is deleted.
     Suppose a domain is created, "FLAME.ORG", and it is 
     assigned the ROID of "FLAME1-ISC".  Now, that is no longer a
     valid contact ROID.  All external references will be totally
     confused.  WORSE, since domains and contacts can have passwords,
     would:

        <authinfo roid="FLAME1-ISC">password</authinfo>

     allow me to modify other domains?  After all, FLAME1-ISC may be
     listed as an external technical contact for FOO.COM, and I can
     get the password right for the domain-versio of FLAME1-ISC.

(3)  The various <create> commands need to return the ROID an object was
     assigned.  As things are now, I need to look up the contact using
     <info> before I can use it in an <authinfo roid="whatever"> tag.

(4)  Using two names, one which is (in the contact case) derrived from the
     other, seems pretty silly.  If you're going to do that, use only the
     global (or use the URN concept to refer to external data,
     mentioned in the mail archives and in my last post.)

(5)  The -FOO suffix doesn't really fit with the new world order of
     URIs, URNs, and is different than how XML, the EPP protocol of
     choice (yuck) would do it.

(6)  EPP is extensible.  Once other issues, such as how to notify
     referrers of data, or even a good use for this sort of thing is
     found, a draft can be written to extend EPP to handle
     registry-side ROIDs.  Until then, I at least feel they complicate
     an already complicated protocol, and should be removed for now.
     Additionally, making it OPTIONAL gives the registry more
     flexability into if it WANTS external references or not.

--Michael

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Nov 2002 10:49:05 +0100

On Tue, Nov 26, 2002 at 10:32:44PM +0000,
 Michael Graff <[email-masked]> wrote 

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

>      by the registrant, 

Which is bad, IMHO. It may require several round-trips before the
registrar (<pc>the client</pc>) finds a free handle. Why is there no
provision for registry-generated contact handles? (Or should we assume
the ROID will have this role?)

---

From: Michael Graff <[email-masked]>
Date: 27 Nov 2002 17:15:30 +0000

> 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

> the ROID will have this role?)

See above, the ROID is derrived directly from the local part.

So, we have:

        entity local name       ROID            ROID Chosen by
        ---------------------   ------------    --------------
        foo.com                 FOO-ISC         Registry
        ns1.foo.com             NS1_FOO-ISC     Registry
        mg2                     MG2-ISC         Registrant

I don't see why using what I see as a far more sane method of using URNs
here wouldn't work.  After all, that's more or less the expected thing in
an XML encoding, and it solves the problem without any need for ROIDs.
Baring that, I think the ROID issue is serious enough, and badly spec'd
enough, that it needs to be fixed before the draft makes it to RFC status.

--Michael

---

From: Patrick <[email-masked]>
Date: Fri, 29 Nov 2002 14:42:02 +0100

> handles for objects now, and that is becomming a pain in trying to

As someone implementing EPP, I totally agree with Michael.

>      <info> before I can use it in an <authinfo roid="whatever"> tag.

This is a serious problem. IIRC it was given in the create response
in earlier drafts, then removed.

Current status of ROIDs in the three new gTLD registries is a mess,
especially regarding what is available in whois.

If the purpose is to confuse registrants, currently it is achieved.
Most people have problems with handles, and currently they must have,
for them a different handle for *each* Registry.

>      an already complicated protocol, and should be removed for now.

Agreed.

Patrick.