From: Pieter Vandepitte [mailto:pieter.vandepi...@dnsbelgium.be] Sent: Monday, April 16, 2018 9:40 AM To: Hollenbeck, Scott <shollenb...@verisign.com> Cc: regext@ietf.org 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. Scott
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
