From: Pieter Vandepitte []
Sent: Monday, April 16, 2018 9:40 AM
To: Hollenbeck, Scott <>
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 
entity identifiers.


regext mailing list

Reply via email to