I can see how a RDAP user would see a domain name outside RDAP and wanted to
query the registration data, e.g., a user seeing an ad, (potentially phishing)
email, etc. So, it makes sense to have a bootstrapping mechanism for that use
case.
In the case of entities, I don't think a RDAP user is likely to see an entity
id outside RDAP. If users would most likely obtain an entity handle from
another RDAP output, I'd argue that the problem could be solved the way I
mentioned before. In any case, if users are going to obtain the (not so
user-friendly) ids from RDAP output, should we better provide the URI to the
RDAP query for that object in the RDAP output that the user is going to see (or
even let the URI be the id)?
--
Francisco
On 4/5/17, 10:42 AM, "Hollenbeck, Scott" <shollenb...@verisign.com> wrote:
> -----Original Message-----
> From: Francisco Arias [mailto:francisco.ar...@icann.org]
> Sent: Wednesday, April 05, 2017 1:11 PM
> To: Hollenbeck, Scott <shollenb...@verisign.com>; 'regext@ietf.org'
> <regext@ietf.org>
> Subject: [EXTERNAL] Re: [Ext] [regext] FW: I-D Action: draft-hollenbeck-
> regext-rdap-object-tag-02.txt
>
> Hi Scott,
>
> I think the document should perhaps describe the problem that is being
> solved (one level higher). In other words, why would a RDAP use need to do
> an entity lookup if they don't know the registry the entity is related to.
> Perhaps I'm missing something, in my mind a user would want to know
> details of a contact after they have seen an RDAP output from a registry,
> so allegedly they would know what server to query, no?
In that particular use case one can indeed make an assumption* about the
appropriate server because the client has context derived from a prior query.
Imagine that there is no prior query, and all I have is this identifier that I
wrote down or copied from some earlier exchange:
C162385578-LRMS
This is in fact the handle assigned to me as registrant for one domain name
that I've registered. Which server can I query for more information? If the
registry operator who published this information did this instead:
C162385578-LRMS~FOO
A smart RDAP client could look "foo" up in an IANA registry and bootstrap
an entity query. We're now on more equal footing with other queries that can be
bootstrapped.
The second paragraph of the introduction references this limitation as it's
described in RFC 7484. Given acknowledgement of the limitation in 7484, is it
necessary to provide more context?
Scott
* I might also argue that clients shouldn't make assumptions about untagged
queries. Imagine a world in which a proxy of some sort serves as the front end
to multiple RDAP services. The client sends a domain query to the proxy, who
correctly identifies the appropriate server operator and then works as a middle
man to process the query and its associated response. The client extracts an
entity handle and sends an untagged entity query to the proxy. Which server
operator should receive the query from the proxy? Tagging makes it possible to
eliminate that ambiguity.
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
