From: Pieter Vandepitte [mailto:pieter.vandepi...@dnsbelgium.be]
Sent: Monday, April 16, 2018 9:40 AM
To: Hollenbeck, Scott <shollenb...@verisign.com>
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-object-tag
(1) I think the solution is just not right. It's a quick and dirty way of
doing these things. The right way imo is defining a new RDAP extension (with a
dedicated attribute to identify the authoritative source)
(2) In my opinion there are other, existing, mechanisms for discovering
entities (and mentioned in the draft: self links).
I think you have the use case incorrect. This isn’t about discovering
entities, it’s about being able to bootstrap a query for an entity when you
have no other information available in much the same way that domain queries
can be bootstrapped as described in RFC 7484. You can’t use self links if all
you have to start with is something that looks like “ABC123”. So please fill me
in if you can think of a way for a client to receive an entity handle like
“ABC123” and determine which is the authoritative server for that entity in the
absence of any other information.
No, indeed it isn't about discovering entities, but discovering the
authoritative server for an entity, basically wat is meant with bootstrapping.
There are basically 2 use cases I can think of: (1) you need to discover an
entity referred to by another object (e.g. domain) and (2) you need to discover
an entity for which you only have the handle.
For the first one, RFC 7484 gives some hints how this could be achieved and
I think alternatively you could introduce a new attribute or use the self
links. Maybe we agree on that one?
[SAH] Maybe, if one wants to assume that authority is extended by
association. I don’t think that such implicit assumptions are a good idea when
they are exceptions from the way that authority is derived for other objects.
For the second use case, as you noticed rightly, there's currently no way a
client can guess where the query should be sent to, if you only have the
handle. I agree upon that.
The solution now is: let's extend the handle, and append it with the repo,
then the client needs to parse it, discover the URL and send the entity lookup
request to that URL.
My solution would be: let's extend the client and let it accept a second
argument for the repo. The client still needs to discover the URL (using the
second argument), but you can skip that parsing thing in the clients and no
need for an RFC to solve this issue. (I agree we need a "Bootstrap Service
Registry for Entities")
So my final vote on this draft: if there's a need for "globally unique
handles" (I'm not convinced they are needed to help the clients), then yes, go
ahead, but I would prefer a hyphen (it works, as long as the repos do not have
hyphens), the same as roid in EPP.
[SAH] Unfortunately, the hyphen-minus character won’t work for reasons
explained in the draft. Repos *are* currently using that character in their
regext mailing list