Hello all. I have some questions about the ICANN policy document, directives 1.5.16 and 2.1. I couldn't find existing answers in the archive of this list, so I thought I would ask. As a general matter, should I also ask my RDAP-only questions here (as opposed to the issues specifically related to ICANN policy)? Or is there another forum for such questions? Brian -------------------------------------------------- *1.5.16. Entities MUST use jCard [RFC7095] structured addresses.* RFC 7095 defines two different types of structured address: one with the street address lines concatenated into one string, and one with a subarray for the street address. It says: 3.3.1.3. Structured Property Values The vCard specification defines properties with structured values, for example, "GENDER" or "ADR". In vCard, a structured text value consists of one or multiple text components, delimited by the SEMICOLON character. Its equivalent in jCard is a structured property value, which is an array containing one element for each text component, with empty/missing text components represented by zero-length strings. jCard Example: ["adr", {}, "text", [ "", "", "123 Main Street", "Any Town", "CA", "91921-1234", "U.S.A." ] ] Some vCard properties, for example, ADR, also allow a structured value element that itself has multiple values. In this case, the element of the array describing the structured value is itself an array with one element for each of the component's multiple values. jCard Example: ["adr", {}, "text", [ "", "", ["My Street", "Left Side", "Second Shack"], "Hometown", "PA", "18252", "U.S.A." ] ] Which form is to be used in RDAP responses? If the first version (list of simple strings, with the street lines concatenated), what is to be done with addresses containing more than two street address lines? -------------------------------------------------- *2.1. Registries offering searchable Whois service (e.g., per exhibit A of their RA) MUST support RDAP search requests for domains and entities. Entities MUST be searchable by name search pattern as defined in RFC7482 section 3.2.3 in order to allow for searches by contact name or address. Boolean search capabilities (AND, OR) MUST be supported, when a RFC defining this capability has been published.* Domain and entity searches are specifically mentioned, but nameserver searches are not. Does that mean that registries need not support nameserver search? Or was that an oversight? RFC 7482 does not cover entity search by address, only by name or handle. Is ICANN requiring support for an additional way to search for entities? What would the syntax of such a search be?
Em 26 de out de 2015, à(s) 18:58:000, Brian Mountford via gtld-tech <gtld-tech@icann.org> escreveu:
Hello all. I have some questions about the ICANN policy document, directives 1.5.16 and 2.1. I couldn't find existing answers in the archive of this list, so I thought I would ask. As a general matter, should I also ask my RDAP-only questions here (as opposed to the issues specifically related to ICANN policy)? Or is there another forum for such questions?
Brian
--------------------------------------------------
2.1. Registries offering searchable Whois service (e.g., per exhibit A of their RA) MUST support RDAP search requests for domains and entities. Entities MUST be searchable by name search pattern as defined in RFC7482 section 3.2.3 in order to allow for searches by contact name or address. Boolean search capabilities (AND, OR) MUST be supported, when a RFC defining this capability has been published.
Domain and entity searches are specifically mentioned, but nameserver searches are not. Does that mean that registries need not support nameserver search? Or was that an oversight?
That's because searchable name servers and registrars are required from all 2012+ registries, not only those who got an extra point for offering "searchable WHOIS" services. 2.2, 2.3, 2.10 and appendix B deal with name server queries; 2.9 deals with registrar queries. Rubens
Interesting. So those are intended to be independent requirements. But I still don't see a requirement for nameserver search with pattern strings. 2.1 refers specifically to search requests with pattern strings, but does not mention nameservers. 2.2 refers to searching for name servers by IP address, which as I read the RFC need not support wildcards (or am I wrong? can wildcards be used with IP addresses? if so, what are the matching rules?). 2.3 refers to the case of multiple hosts with the same name; it doesn't actually call out particular search capabilities, does it? 2.9 deals with entities. 2.10.1 calls out section 3.1.4 of RFC 7482, which deals with nameserver lookup by fully-qualified hostname, not using a search pattern (that's section 3.2.2). The rest of 2.10 appears to deal with format of the returned data. So it still looks to me like actual nameserver search, as discussed in RFC 7482, section 3.2.2, is not required by the ICANN profile. Is that correct? Brian On Mon, Oct 26, 2015 at 5:13 PM, Rubens Kuhl <rubensk@nic.br> wrote:
Em 26 de out de 2015, à(s) 18:58:000, Brian Mountford via gtld-tech < gtld-tech@icann.org> escreveu:
Hello all. I have some questions about the ICANN policy document, directives 1.5.16 and 2.1. I couldn't find existing answers in the archive of this list, so I thought I would ask. As a general matter, should I also ask my RDAP-only questions here (as opposed to the issues specifically related to ICANN policy)? Or is there another forum for such questions?
Brian
--------------------------------------------------
*2.1. Registries offering searchable Whois service (e.g., per exhibit A of their RA) MUST support RDAP search requests for domains and entities. Entities MUST be searchable by name search pattern as defined in RFC7482 section 3.2.3 in order to allow for searches by contact name or address. Boolean search capabilities (AND, OR) MUST be supported, when a RFC defining this capability has been published.*
Domain and entity searches are specifically mentioned, but nameserver searches are not. Does that mean that registries need not support nameserver search? Or was that an oversight?
That's because searchable name servers and registrars are required from all 2012+ registries, not only those who got an extra point for offering "searchable WHOIS" services.
2.2, 2.3, 2.10 and appendix B deal with name server queries; 2.9 deals with registrar queries.
Rubens
Em 26 de out de 2015, à(s) 19:50:000, Brian Mountford <mountford@google.com> escreveu:
Interesting. So those are intended to be independent requirements. But I still don't see a requirement for nameserver search with pattern strings.
2.1 refers specifically to search requests with pattern strings, but does not mention nameservers.
2.2 refers to searching for name servers by IP address, which as I read the RFC need not support wildcards (or am I wrong? can wildcards be used with IP addresses? if so, what are the matching rules?).
2.3 refers to the case of multiple hosts with the same name; it doesn't actually call out particular search capabilities, does it?
2.9 deals with entities.
2.10.1 calls out section 3.1.4 of RFC 7482, which deals with nameserver lookup by fully-qualified hostname, not using a search pattern (that's section 3.2.2). The rest of 2.10 appears to deal with format of the returned data.
So it still looks to me like actual nameserver search, as discussed in RFC 7482, section 3.2.2, is not required by the ICANN profile. Is that correct?
Registry Agreement Specification 4, clause 1.10: 1.10. Searchability. Offering searchability capabilities on the Directory Services is optional but if offered by the Registry Operator it shall comply with the specification described in this section. 1.10.1 Registry Operator will offer searchability on the web-based Directory Service. 1.10.2 Registry Operator will offer partial match capabilities, at least, on the following fields: domain name, contacts and registrant’s name, and contact and registrant’s postal address, including all the sub-fields described in EPP (e.g., street, city, state or province, etc.). 1.10.3 Registry Operator will offer exact-match capabilities, at least, on the following fields: registrar id, name server name, and name server’s IP address (only applies to IP addresses stored by the registry, i.e., glue records). 1.10.4 Registry Operator will offer Boolean search capabilities supporting, at least, the following logical operators to join a set of search criteria: AND, OR, NOT. 1.10.5 Search results will include domain names matching the search criteria. 1.10.6 Registry Operator will: 1) implement appropriate measures to avoid abuse of this feature (e.g., permitting access only to legitimate authorized users); and 2) ensure the feature is in compliance with any applicable privacy laws or policies. 1.10.3 seem to also specify name servers, but only on exact match searches. RDAP Profile 2.1 seems to reflect RA 1.10.2, which does not specify name servers. Although a wildcard is not required in IP address, I could imagine it being done using CIDR blocks instead of character regex. And on name server matches, not being required does not prevent implementation if a registry is willing to do so, in my reading of the agreement. Rubens
1.10.3 might be referring to domain name lookups (which can also use the name server name or IP address) rather than explicit nameserver lookups. And as you point out, it's only for exact match searches. So I still think the profile is constructed so as to avoid requiring registries to support nameserver partial string match queries. On Mon, Oct 26, 2015 at 6:06 PM, Rubens Kuhl <rubensk@nic.br> wrote:
Em 26 de out de 2015, à(s) 19:50:000, Brian Mountford < mountford@google.com> escreveu:
Interesting. So those are intended to be independent requirements. But I still don't see a requirement for nameserver search with pattern strings.
2.1 refers specifically to search requests with pattern strings, but does not mention nameservers.
2.2 refers to searching for name servers by IP address, which as I read the RFC need not support wildcards (or am I wrong? can wildcards be used with IP addresses? if so, what are the matching rules?).
2.3 refers to the case of multiple hosts with the same name; it doesn't actually call out particular search capabilities, does it?
2.9 deals with entities.
2.10.1 calls out section 3.1.4 of RFC 7482, which deals with nameserver lookup by fully-qualified hostname, not using a search pattern (that's section 3.2.2). The rest of 2.10 appears to deal with format of the returned data.
So it still looks to me like actual nameserver search, as discussed in RFC 7482, section 3.2.2, is not required by the ICANN profile. Is that correct?
Registry Agreement Specification 4, clause 1.10:
1.10. Searchability. Offering searchability capabilities on the Directory Services is optional but if offered by the Registry Operator it shall comply with the specification described in this section. 1.10.1 Registry Operator will offer searchability on the web-based Directory Service. 1.10.2 Registry Operator will offer partial match capabilities, at least, on the following fields: domain name, contacts and registrant’s name, and contact and registrant’s postal address, including all the sub-fields described in EPP (e.g., street, city, state or province, etc.). 1.10.3 Registry Operator will offer exact-match capabilities, at least, on the following fields: registrar id, name server name, and name server’s IP address (only applies to IP addresses stored by the registry, i.e., glue records). 1.10.4 Registry Operator will offer Boolean search capabilities supporting, at least, the following logical operators to join a set of search criteria: AND, OR, NOT. 1.10.5 Search results will include domain names matching the search criteria. 1.10.6 Registry Operator will: 1) implement appropriate measures to avoid abuse of this feature (e.g., permitting access only to legitimate authorized users); and 2) ensure the feature is in compliance with any applicable privacy laws or policies.
1.10.3 seem to also specify name servers, but only on exact match searches. RDAP Profile 2.1 seems to reflect RA 1.10.2, which does not specify name servers.
Although a wildcard is not required in IP address, I could imagine it being done using CIDR blocks instead of character regex. And on name server matches, not being required does not prevent implementation if a registry is willing to do so, in my reading of the agreement.
Rubens
1.10 clearly states that searchability is optional. Is Rubens conflating "searchability" with nameserver queries? Isn't it the case that nameserver queries are direct match, where searchability extends that in the 1.10 subsections (which do not apply to registries who do not offer "searchable whois")? On Mon, Oct 26, 2015 at 6:09 PM, Brian Mountford <mountford@google.com> wrote:
1.10.3 might be referring to domain name lookups (which can also use the name server name or IP address) rather than explicit nameserver lookups. And as you point out, it's only for exact match searches. So I still think the profile is constructed so as to avoid requiring registries to support nameserver partial string match queries.
On Mon, Oct 26, 2015 at 6:06 PM, Rubens Kuhl <rubensk@nic.br> wrote:
Em 26 de out de 2015, à(s) 19:50:000, Brian Mountford < mountford@google.com> escreveu:
Interesting. So those are intended to be independent requirements. But I still don't see a requirement for nameserver search with pattern strings.
2.1 refers specifically to search requests with pattern strings, but does not mention nameservers.
2.2 refers to searching for name servers by IP address, which as I read the RFC need not support wildcards (or am I wrong? can wildcards be used with IP addresses? if so, what are the matching rules?).
2.3 refers to the case of multiple hosts with the same name; it doesn't actually call out particular search capabilities, does it?
2.9 deals with entities.
2.10.1 calls out section 3.1.4 of RFC 7482, which deals with nameserver lookup by fully-qualified hostname, not using a search pattern (that's section 3.2.2). The rest of 2.10 appears to deal with format of the returned data.
So it still looks to me like actual nameserver search, as discussed in RFC 7482, section 3.2.2, is not required by the ICANN profile. Is that correct?
Registry Agreement Specification 4, clause 1.10:
1.10. Searchability. Offering searchability capabilities on the Directory Services is optional but if offered by the Registry Operator it shall comply with the specification described in this section. 1.10.1 Registry Operator will offer searchability on the web-based Directory Service. 1.10.2 Registry Operator will offer partial match capabilities, at least, on the following fields: domain name, contacts and registrant’s name, and contact and registrant’s postal address, including all the sub-fields described in EPP (e.g., street, city, state or province, etc.). 1.10.3 Registry Operator will offer exact-match capabilities, at least, on the following fields: registrar id, name server name, and name server’s IP address (only applies to IP addresses stored by the registry, i.e., glue records). 1.10.4 Registry Operator will offer Boolean search capabilities supporting, at least, the following logical operators to join a set of search criteria: AND, OR, NOT. 1.10.5 Search results will include domain names matching the search criteria. 1.10.6 Registry Operator will: 1) implement appropriate measures to avoid abuse of this feature (e.g., permitting access only to legitimate authorized users); and 2) ensure the feature is in compliance with any applicable privacy laws or policies.
1.10.3 seem to also specify name servers, but only on exact match searches. RDAP Profile 2.1 seems to reflect RA 1.10.2, which does not specify name servers.
Although a wildcard is not required in IP address, I could imagine it being done using CIDR blocks instead of character regex. And on name server matches, not being required does not prevent implementation if a registry is willing to do so, in my reading of the agreement.
Rubens
participants (3)
-
Brian Mountford -
Richard G. Roberto -
Rubens Kuhl