Subject: [weirds] Review of draft-ietf-weirds-using-http-11

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 17 Sep 2014 07:20:34 +0000

I've reviewed the "using HTTP" document, and i find it's in very good shape. I have only a few minor comments:

 - Some acronyms are not expanded on first use (eg. JSON, but also HTTP and RDAP). minor nit.
- URLs could benefit from enclosing them in < >, for example at the end of Section 5.2, where one could get the impression the final full stop is part of the URL.

** 2. Terminology:

- "HTTP User Agent" uses caps, while "HTTP server" does not. Should the latter have caps too?

** 5.3. Negative Answer:

- (That might have been discussed before): Are servers which are *not* authoritative for a certain set of objects also allowed to send back 404? From an HTTP perspective, that is of course correct, but a client could assume that eg. RDAP information for a domain (or, worse, the object itself) does not exist at all, although it had just hit the "wrong" server? I don't see many other options in terms of response codes anyway, though... So, i think 404 is appropriate

-> Maybe add a note to the draft that if a client receives a 404, it cannot assume the object itself does not exist (It's tricky, admitted)..

** 5.5. Rate Limiting

- More of a general note - i understand that the section defines client behaviour in case of a 429 response code. I think we really need to be careful that the bahaviour recommended doesn't conflict with the HTTP specs - I'm sure that by no means we want an "Updates:" Header in this document.. (Disclaimer: Didn't read the 429 text in the HTTP specs). I think, though, we can recommend *additional* client behaviour that is not covered in the HTTP specs.

tia,
Alex

---

From: Andy Newton <[email-masked]>
Date: Wed, 17 Sep 2014 14:19:34 +0000

> -> Maybe add a note to the draft that if a client receives a 404, it cannot assume the object itself does not exist (It's tricky, admitted)..

Yes, it has been discussed over and over again. I would think that if a server is not authoritative for an object or set of objects and does not wish to issue redirects, 404 is a good response.

I don’t think we should say that a client should assume a 404 means the object does not exist universally. It just means it does not exist against the server being queried. If a client started with the bootstrap (either directly or through a redirect server) and ultimately ends up with a 404, then that’s that. If a client starts by targeting an arbitrary server and gets a 404, they get what they deserve.

> - More of a general note - i understand that the section defines client behaviour in case of a 429 response code. I think we really need to be careful that the bahaviour recommended doesn't conflic…

Send text, and be prepared for another round of discussions on this.

-andy

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 17 Sep 2014 14:40:31 +0000

> I don't think we should say that a client should assume a 404 means the
> object does not exist universally. It just means it does not exist against the
> server being queried. If a client started with the bootstrap (either directly or
> through a redirect server) and ultimately ends up with a 404, then that's that.
> If a client starts by targeting an arbitrary server and gets a 404, they get what
> they deserve.

[Alexander Mayrhofer] 
Exactly. Actually, what i meant originally is that we should maybe add text that a client should *not* assume an object doesn't exist universally, just because it got a 404 from whatever RDAP server. However, it *might*, if the server is authoritative... sigh.. which, in turn, begs the question how the client identifies whether a certain server is authoritative for a certain set of objects.. 

 Maybe just a "warning" like

Note that a 404 response code only indicates that the server queried does not have any information about the object, but does not give an universal indication whether the object itself exists or not.

(This might also cover the situation where eg. a domain name itself exists, but RDAP information for it doesn't?)

> > - More of a general note - i understand that the section defines client
> behaviour in case of a 429 response code. I think we really need to be careful
> that the bahaviour recommended doesn't conflict with the HTTP specs - I'm
> sure that by no means we want an "Updates:" Header in this document..
> (Disclaimer: Didn't read the 429 text in the HTTP specs). I think, though, we
> can recommend *additional* client behaviour that is not covered in the HTTP
> specs.
> 

[Alexander Mayrhofer] 
Reading through RFC6585, the original specification of the 429 response code doesn't seem to include *any* specification of client behaviour at all (except it must not be cached). Therefore, i think we're fine with what we do here, and can happily avoid a round of discussion :)

Alex

---

From: Andy Newton <[email-masked]>
Date: Wed, 17 Sep 2014 16:23:58 +0000

> (This might also cover the situation where eg. a domain name itself exists, but RDAP information for it doesn't?)

While I think you and I have an understanding of this, I feel this is one of those things better left unsaid because we have more potential to cause confusion than to bring clarity. Further, it will all shake out over time as people implement and use RDAP.

-andy