Subject: [weirds] Review of draft-ietf-weirds-rdap-query-13

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 19 Sep 2014 14:46:15 +0000

I've reviewed the Query document, and i think it's in very good shape, with open "real" issue (see below "OPEN ISSUE"). All the other comments are minor / editorial:

** 1. Introduction: 

- I'm missing a clear description right at the beginning what this document does. Something like "This document specifies query patterns for the Registration Data Access Protocol..." (BTW, I'm still not sure which of the document specifies the *actual* RDAP, understanding that all documents specify a certain aspect of it... But there's no document saying "This document specifies RDAP" - is it this one?...)

- OPEN ISSUE: I feel that it is *really important* to say that it's local server policy whether or not a server supports a certain query pattern, and which subset of it - especially for the "search" pattern. Do we have that somewhere in the documents?

** 3.1 Path Segments

- Hosts/Domains: Since we talk about "U-Labels" there, i do assume that UTF-8 strings that are not valid U-Labels would trigger an error in the required IDNA processing. For that error, i do assume server behaviour would then be covered by the HTTP draft, Section 5.4,so it would send back a 400 response code, correct?  
 
** 3.2 Search Path Segment

- The text description doesn't seem to match the examples. while the text requires a slash concatenated to the plural form of the subject before the query string, the examples do not contain this slash. Are both Segments fine? Then we need to say an "OPTIONAL forward slash character"...

- I was writing a paragraph/rant here about the "pattern" being underspecified, until i got to Section 4. Section 4 made me happy, but maybe a forward reference to the search pattern descrition in section 4 would be good on first use of the "blah*" pattern..

** 4. Query Processing

- This section could really use sub-sections, such as "4.1 Search Processing", "4.2 Character Folding", "4.3 Matching Rules" - it would make it easier to read (and would also require some thought on re-arranging paragraphs, admitted)

tia,
Alex

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 19 Sep 2014 16:48:50 +0000

Thanks for the feedback, Alex.

Scott

> -----Original Message-----
> From: weirds [mailto:[email-masked]] On Behalf Of Alexander
> Mayrhofer
> Sent: Friday, September 19, 2014 10:46 AM
> To: [email-masked]
> Subject: [weirds] Review of draft-ietf-weirds-rdap-query-13
> 
> I've reviewed the Query document, and i think it's in very good shape,
> with open "real" issue (see below "OPEN ISSUE"). All the other comments
> are minor / editorial:
> 
> ** 1. Introduction:
> 
> - I'm missing a clear description right at the beginning what this
> document does. Something like "This document specifies query patterns
> for the Registration Data Access Protocol..." (BTW, I'm still not sure
> which of the document specifies the *actual* RDAP, understanding that
> all documents specify a certain aspect of it... But there's no document
> saying "This document specifies RDAP" - is it this one?...)

I can add some text to both the Abstract and the introduction. Add to end of abstract and end of first paragraph in the intro:

"These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP)."

> - OPEN ISSUE: I feel that it is *really important* to say that it's
> local server policy whether or not a server supports a certain query
> pattern, and which subset of it - especially for the "search" pattern.
> Do we have that somewhere in the documents?

I can make a change in Section 2 to address this.

OLD:

"It is envisioned that each registry will continue to maintain NICNAME/WHOIS and/or RESTful web services specific to their needs and those of their constituencies"

NEW

"Server implementations will likely implement a subset of these features depending on local requirements. It is also envisioned that each registry will continue to maintain NICNAME/WHOIS and/or RESTful web services specific to their needs and those of their constituencies"

> ** 3.1 Path Segments
> 
> - Hosts/Domains: Since we talk about "U-Labels" there, i do assume that
> UTF-8 strings that are not valid U-Labels would trigger an error in the
> required IDNA processing. For that error, i do assume server behaviour
> would then be covered by the HTTP draft, Section 5.4,so it would send
> back a 400 response code, correct?

I would expect any syntactically invalid query to be addressed as described in Section 5 of using-http.

> - The text description doesn't seem to match the examples. while the
> text requires a slash concatenated to the plural form of the subject
> before the query string, the examples do not contain this slash. Are
> both Segments fine? Then we need to say an "OPTIONAL forward slash
> character"...

I think the "forward slash" text is incorrect and should be removed. There should be no forward slash to make the text consistent with the examples.

> - I was writing a paragraph/rant here about the "pattern" being
> underspecified, until i got to Section 4. Section 4 made me happy, but
> maybe a forward reference to the search pattern descrition in section 4
> would be good on first use of the "blah*" pattern..

OK, that's reasonable, but the details of each search pattern are spelled out in more detail in 3.2.1 ("XXXX is a search pattern representing"...), 3.2.2, and 3.2.3. Section 4 describes query processing. Is this helpful?

OLD
"the equal sign character ('=', ASCII value 0x003D), and the search pattern."

NEW
"the equal sign character ('=', ASCII value 0x003D), and the search pattern. Search pattern query processing is described more fully in Section 4."

> ** 4. Query Processing
> 
> - This section could really use sub-sections, such as "4.1 Search
> Processing", "4.2 Character Folding", "4.3 Matching Rules" - it would
> make it easier to read (and would also require some thought on re-
> arranging paragraphs, admitted)

Yes, I think it would help. I'll see what I can do.

Scott

---

From: Alexander Mayrhofer <[email-masked]>
Date: Sun, 21 Sep 2014 19:01:26 +0000

> I can add some text to both the Abstract and the introduction. Add to end of
> abstract and end of first paragraph in the intro:
> 

Very good, yep.
 
> "It is envisioned that each registry will continue to maintain
> NICNAME/WHOIS and/or RESTful web services specific to their needs and
> those of their constituencies"
> 
> NEW
> 
> "Server implementations will likely implement a subset of these features
> depending on local requirements. It is also envisioned that each registry will
> continue to maintain NICNAME/WHOIS and/or RESTful web services specific
> to their needs and those of their constituencies"

Can we make this even a bit stronger, like

"Server implementations are free to support only a subset of these features depending on local requirements..."?

I'm concerned that implementations that eg. do not offer search capabilities for whatever reason would otherwise be considered "not conforming to the specification".

> > UTF-8 strings that are not valid U-Labels would trigger an error in
> > the required IDNA processing. For that error, i do assume server
> > behaviour would then be covered by the HTTP draft, Section 5.4,so it
> > would send back a 400 response code, correct?
> 

Perfect

> I think the "forward slash" text is incorrect and should be removed. There
> should be no forward slash to make the text consistent with the examples.

> > maybe a forward reference to the search pattern descrition in section
> > 4 would be good on first use of the "blah*" pattern..
> 
> OK, that's reasonable, but the details of each search pattern are spelled out
> in more detail in 3.2.1 ("XXXX is a search pattern representing"...), 3.2.2, and
> 3.2.3. Section 4 describes query processing. Is this helpful?

I'd be happy with both references. The NEW text below is fine.

> "the equal sign character ('=', ASCII value 0x003D), and the search pattern.
> Search pattern query processing is described more fully in Section 4."
> 
> > ** 4. Query Processing
> >

Great, thanks 

Alex

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Sun, 21 Sep 2014 20:40:25 +0000

> From: Alexander Mayrhofer [mailto:[email-masked]]
> Sent: Sunday, September 21, 2014 3:01 PM
> To: Hollenbeck, Scott; [email-masked]
> Subject: AW: Review of draft-ietf-weirds-rdap-query-13
> 
> > "These uniform patterns define the query syntax for the Registration
> Data
> > Access Protocol (RDAP)."
> 
> Very good, yep.
> 
> "Server implementations are free to support only a subset of these
> features depending on local requirements..."?
> 
> I'm concerned that implementations that eg. do not offer search
> capabilities for whatever reason would otherwise be considered "not
> conforming to the specification".

That's not something I can agree to without a stronger sense of WG consensus. I can see DNRs not supporting ASN queries (that's the kind of use case I was envisioning), but not supporting searches sounds like it could/should be a conformance question.

Scott

---

From: "John Levine" <[email-masked]>
Date: 21 Sep 2014 23:36:22 -0000

>> conforming to the specification".

This is a complete non-starter.  The IETF is not the protocol police,
and all we can do is tell people how to interoperate if that is what
they want to do.  Demanding that WEIRDS providers offer services they
do not want to provide is totally, completely out of scope.

(Defining a standard way to say "we don't do that" is within scope, and
I believe we've done that adequately.)

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 21 Sep 2014 22:39:11 -0700

On Sun, Sep 21, 2014 at 1:40 PM, Hollenbeck, Scott <[email-masked]
> wrote:

> That's not something I can agree to without a stronger sense of WG
> consensus. I can see DNRs not supporting ASN queries (that's the kind of
> use case I was envisioning), but not supporting searches sounds like it
> could/should be a conformance question.

My impression of consensus is that, since not all WHOIS servers implement
it today, it's optional in RDAP too.  Does anyone remember something
different?

If that's the case, Alexander's suggestion aligns with consensus as far as
I can tell.

-MSK

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 22 Sep 2014 11:00:07 +0000

From: Murray S. Kucherawy [mailto:[email-masked]]
Sent: Monday, September 22, 2014 1:39 AM
To: Hollenbeck, Scott
Cc: Alexander Mayrhofer; [email-masked]
Subject: Re: [weirds] Review of draft-ietf-weirds-rdap-query-13

My impression of consensus is that, since not all WHOIS servers implement it today, it's optional in RDAP too.  Does anyone remember something different?
If that's the case, Alexander's suggestion aligns with consensus as far as I can tell.

[SAH] That’s specific to search behavior, but the text Alex is suggesting leaves open the possibility of leaving out other features, too. So where do we draw the line? Does an implementation that provides (for example) domain name lookups and nothing else “conform”? I’m not comfortable with referring to existing WHOIS behavior as a guide because exceptions can be found to support pretty much any position.

Scott

---

From: Andrew Newton <[email-masked]>
Date: Mon, 22 Sep 2014 09:04:19 -0400

On Mon, Sep 22, 2014 at 7:00 AM, Hollenbeck, Scott
<[email-masked]> wrote:
> [SAH] That’s specific to search behavior, but the text Alex is suggesting
> leaves open the possibility of leaving out other features, too. So where do
> we draw the line? Does an implementation that provides (for example) domain
> name lookups and nothing else “conform”? I’m not comfortable with referring
> to existing WHOIS behavior as a guide because exceptions can be found to
> support pretty much any position.

I think the answer is yes. We already know some registries will not
support nameserver lookups and some will.

Perhaps we should add text that says servers that do not support a
certain query SHOULD respond with a 501 (not implemented) return code.
Or put that in using-http and have rdap-query point to using-http.
What do you think?

-andy

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 22 Sep 2014 14:35:24 +0000

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Monday, September 22, 2014 9:04 AM
> To: Hollenbeck, Scott
> Cc: Murray S. Kucherawy; [email-masked]

It could work. We already have text in Section 4 that addresses a similar situation:

"If a server receives a search request but cannot process the request because it does not support a particular style of partial match searching, it SHOULD return an HTTP 422 [RFC4918] error."

So how about adding this to Section 2?

"Server implementations are free to support only a subset of these features depending on local requirements. If a server receives a query that it cannot process because it is not implemented it SHOULD return an HTTP 501 [RFC7231] error."

Scott

---

From: Andrew Newton <[email-masked]>
Date: Mon, 22 Sep 2014 10:41:09 -0400

> "Server implementations are free to support only a subset of these features depending on local requirements. If a server receives a query that it cannot process because it is not implemented it SHO…

Works for me. Any objections?

-andy

---

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 22 Sep 2014 15:03:15 +0000

> features depending on local requirements. If a server receives a query that it
> cannot process because it is not implemented it SHOULD return an HTTP 501
> [RFC7231] error."
> >
> > Scott
> 

[Alexander Mayrhofer] 
Sounds good to me too, thanks.

Alex

---

From: Maarten Bosteels <[email-masked]>
Date: Mon, 22 Sep 2014 15:33:19 +0000

Looks good to me too.

Maarten

On 22/09/14 17:03, "Alexander Mayrhofer" <[email-masked]>
wrote:

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