Re: [regext] Using RDAP as a Domain Availability Service
Hello Andrew, On 04/04/2017 21:31, Andrew Newton wrote: > I think it is also worth noting that not all TLDs are the same, and > many do not suffer from these issues and hence should not be held back > in this regard. While that's true, we should also be aware that e.g. ICANN has been requiring certain RFCs to be implemented by all gTLD operators, and will probably continue to do so going forward. So it may not be up to the registry operator whether or not to implement this. Also, a standard isn't very useful if only a fraction of operators are likely to implement it. Best regards, Thomas -- TANGO REGISTRY SERVICES® is a product of: Knipp Medien und Kommunikation GmbH Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: supp...@tango-rs.com Germany ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] FW: I-D Action: draft-hollenbeck-regext-rdap-object-tag-02.txt
> -Original Message- > From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of > internet-dra...@ietf.org > Sent: Wednesday, April 05, 2017 10:40 AM > To: i-d-annou...@ietf.org > 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 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [Ext] 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? -- Francisco spekaing for myself On 4/5/17, 7:45 AM, "regext on behalf of Hollenbeck, Scott" wrote: > -Original Message- > From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of > internet-dra...@ietf.org > Sent: Wednesday, April 05, 2017 10:40 AM > To: i-d-annou...@ietf.org > 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 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [Ext] FW: I-D Action: draft-hollenbeck-regext-rdap-object-tag-02.txt
> -Original Message- > From: Francisco Arias [mailto:francisco.ar...@icann.org] > Sent: Wednesday, April 05, 2017 1:11 PM > To: Hollenbeck, Scott ; '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
