Re: EPP statuses and other questions

[Michael Graff <Michael_Graff@isc.org>]

"Hollenbeck, Scott" <shollenbeck@verisign.com> writes:

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

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