Registration Data Access Protocol (RDAP) Query Format
draft-ietf-weirds-rdap-query-18

Thanks for addressing my comments.

Version -17 addresses my comments; thanks very much.

"Servers MUST return an HTTP 501 (Not Implemented) [RFC7231] response to inform clients of unsupported queries."

Shouldn't this go in -using-http?

Also, the wording here could use tightening.  It seems like you want to use 501 for query *types* that you don't support, vs. 404 for things where you just don't have an answer.  So sending a query for "bbc.co.uk" to the ".youtube" server would result in 404, but sending it to the ARIN server might result in 501.

- Using https schemed URIs in the examples would be better.
Mind you, https://example.com does get you a fairly odd
certificate, so I can see why you might push back on that;-)

- I think the privacy considerations from the json response
draft might be better here.

Former DISCUSS Points, left as comments as a reminder to Pete.

Quoting Pete:

Point 1 - add explanatory text as discussed
Point 2 - unpleasant, but can live with it
Point 3 - Stop talking about Posix and make it clear that asterisk is the only choice.

Point 1:

In section 3.1.1, it's not clear which of three alternative things you may have been specifying: (1) the ASCII representation of the IP address is intended to be converted to binary before use, (2) the ASCII representation is intended to be used directly, or (3) whether the IP address is converted to binary prior to use is an implementation choice.   If (1) is what's intended, you should say so explicitly.   If either (2) or (3) is intended, then the representation that's used needs to be in some canonical form, and the text as written does not ensure that it will be.

So to address this discuss, you should either update the text to say that (1) is what's intended, and it won't work otherwise, or you need to require, not suggest, a canonical representation.   If you go with the second option, your reference to RFC 5952 isn't adequate: you need to specifically reference section 4, and specifically exclude section 5.   I have no preference as to how you resolve this.

Point 2:

In 3.1.3, the instructions as given don't really guide implementations toward interoperability.   Why not just say that servers SHOULD either convert a-labels to u-labels, or u-labels to a-labels, and be done with it?   It's not like it's a difficult conversion, and they have to do the conversion to do the comparison, unless for some reason they store both A- and U-labels as keys in their database, which seems really unlikely.   The recommendations are written are so vague that I would expect interoperability to only be likely in the case of queries that contain no IDN labels.   I wouldn't mind this in an Informational document, but it's pretty sketchy in a standards-track document.

It's particularly weird that in one place you say "An RDAP server that receives a query string with a mixture of A-labels and U-labels MAY convert all the U-labels to A-labels, perform IDNA processing, and proceed with exact-match lookup" and then in the next paragraph you say "The server MAY perform the match using either the A-label or U-label form.  Using one consistent form for matching every label is likely to be more reliable."

I'm not sure how to resolve this.   I think there's some underlying decision the working group has made that led to this language, but the lack of consistency I mention above leads me to wonder if either that decision wasn't very clear, or the document failed to reflect it.   Interestingly, 3.1.4 is written as if 3.1.3 gives clear guidance as to how IDNs are represented.

[point 2', which I forgot to label as a separate point, has been moved moved to a comment]


Point 3:

In 4.1, you don't actually specify the syntax for partial string matches.   I think I can intuit what you mean, but you should be explicit, and you shouldn't suggest using POSIX regex searches unless that's what you really mean; if that's what you really mean, then you need to do a lot more work than you've done.   I _think_ what you intend is to simply say that if one or more asterisks appear in a label, then when the search is done, any label that contains the non-asterisk characters in sequence plus zero or more characters in sequence in place of each asterisk would match.   But you don't actually say that, so I'm not sure what you actually intended.   The text could be read to mean that any arbitrary search mechanism is allowed, but if that's the case then you need to go into a lot more detail about the caveats, such as the '.' character in posix regexps and the start and end markers.

The text on partial matches for unicode also seems unnecessarily complicated, and likely not implementable without massive knowledge of all the various unicode character sets, which I would not expect an implementation to bother with.   It seems relatively harmless to allow searches on combining characters, particularly since it would be a lot of work to prevent it.   For example, a search for *ཀ་ would not find all instances of a syllable that starts with the sound "ka" because ka can be either a head letter or subjoined, but a user might search first using the head letter and then the subjoined letter if (as is not unlikely) he or she were unsure of the correct spelling.   It would be a shame if such a search were rendered impossible by an overly-thorough implementation of the current text.

As I say, I don't really know what was intended here, so I can't make a definite suggestion as to what the right thing to do is to fix this; I think we just need to discuss it, hence the discuss point.


Point A:

In 3.1.2:

   For example, the following URL would be used to find information
   describing autonomous system number 12 (a number within a range of
   registered blocks):

   http://example.com/rdap/autnum/12

   The following URL would be used to find information describing 4-byte
   autonomous system number 65538:

   http://example.com/rdap/autnum/65538

The examples don't really seem to illustrate what is said in the text.   The syntax for both examples is the same, and we don't see any return results.   So to say that one example is an example of a number within a range of registered blocks, while the other is a 4-byte number, doesn't make sense because the query formats are identical.   The preceding text is clear, if I understand it correctly: a number in the path element following 'autnum' is an autonomous system number, which references a block of one or more numbers.   If there are additional semantics, e.g., byte size boundaries for AS numbers, that are also encoded in the query, those should be described explicitly.   But IMHO that doesn't make sense: in _this_ context, these are just decimal numbers of arbitrary precision, and how many bytes they are, or whether any particular number references a block or just a single number, is not something that should be mentioned in the examples.

Point B:

Section 6 appears to be confusing presentation and representation.   A client might well present a UI that shows U-labels, but use A-labels on the back end.   The text as written here really doesn't make sense.   What are you trying to say?   I think that you shouldn't confuse what's presented to the user with what's sent on the wire.   Possibly this is related to the confusion over A-labels and U-labels that I called out in Point 2 of the discuss.

Former discuss points:

Point 2' from my initial discuss has been moved here because although I don't know of a mitigation strategy for the privacy concern I raised, I do see the valid use case, and so I don't feel like I have any action item to propose.   It would be great if the authors could address this in the security considerations section, but I won't hold them to it.

Point 2':

In 3.2.1 and 3.2.2, the main use cases I can see for nameserver searches are for spammers to identify related domains, and for eavesdroppers to do the same.   What's the motivation for including these capabilities?   At a minimum, the privacy considerations for this search ought to be discussed in a privacy considerations section or in the security considerations section.