Subject: [regext] FW: I-D Action: draft-hollenbeck-regext-rdap-object-tag-02.txt

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 5 Apr 2017 14:45:54 +0000

> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, April 05, 2017 10:40 AM
> To: [email-masked]
> Subject: [EXTERNAL] I-D Action: draft-hollenbeck-regext-rdap-object-tag-
> 02.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : Registration Data Access Protocol (RDAP) Object
> Tagging
>         Authors         : Scott Hollenbeck
>                           Andrew Lee Newton
>       Filename        : draft-hollenbeck-regext-rdap-object-tag-02.txt
>       Pages           : 11
>       Date            : 2017-04-05
>
> Abstract:
>    The Registration Data Access Protocol (RDAP) includes a method that
>    can be used to identify the authoritative server for processing
>    domain name, IP address, and autonomous system number queries.  The
>    method does not describe how to identify the authoritative server for
>    processing other RDAP query types, such as entity queries.  This
>    limitation exists because the identifiers associated with these query
>    types are typically unstructured.  This document describes an
>    operational practice that can be used to add structure to RDAP
>    identifiers that makes it possible to identify the authoritative
>    server for additional RDAP queries.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-object-tag/

FYI - this version changes the separator character from "@" (a reserved URI character) to "~" (an unreserved URI character) with accompanying text updates. Does anyone see any issues to address before I ask the chairs to see if the WG is interested in adopting the document?

Scott

---

From: Francisco Arias <[email-masked]>
Date: Wed, 5 Apr 2017 17:11:00 +0000

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?

-- 
Francisco spekaing for myself

    
    
    Scott
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 5 Apr 2017 17:42:22 +0000

> From: Francisco Arias [mailto:[email-masked]]
> Sent: Wednesday, April 05, 2017 1:11 PM
> To: Hollenbeck, Scott <[email-masked]>; [email-masked]'
> <[email-masked]>
> 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.

---

From: Francisco Arias <[email-masked]>
Date: Fri, 7 Apr 2017 01:15:07 +0000

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

    
    
    C162385578-LRMS

    C162385578-LRMS~FOO

    
    Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 7 Apr 2017 11:57:29 +0000

> Sent: Thursday, April 06, 2017 9:15 PM
> 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)?

That might help, but it still means that clients have to be "smart" about processing query output, it still leaves entities as second-class objects, and it doesn't address the situation where an entity ID might appear out of context. What I'm proposing extends existing operational practice to provide a more general solution.

Scott