Telechat Review of draft-snell-http-prefer-
|Requested rev.||no specific revision (document currently at 18)|
|Team||General Area Review Team (Gen-ART) (genart)|
Genart Last Call review of -14 by Martin Thomson (diff)
Secdir Last Call review of - by Taylor Yu (diff)
Secdir Telechat review of - by Taylor Yu (diff)
|Draft last updated||2012-10-16|
I have reviewed -15 of this draft and my major issues have been resolved. This document is ready. On 21 September 2012 16:43, Martin Thomson <martin.thomson at gmail.com> wrote: > Lucky you. I am the assigned Gen-ART reviewer for this draft. For > background on Gen-ART, please see the FAQ at > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-snell-http-prefer-14 > Reviewer: Martin Thomson > Review Date: 2012-09-21 > IETF LC End Date: 2012-10-12 > > Summary: This document is in pretty good shape. I have a concern over > how Prefer: wait might be implemented that I believe needs to be > addressed prior to publication as Proposed Standard. There are also a > number of additional concerns, though nothing particularly serious. > > Major issues: > > Section 3.4 specifies timing requirements that a server has to act > upon with no good way of gaining the information it needs. It assumes > clock synchronization. Given that terrible clock synchronization is > the default mode of operation for internet hosts, this seems to be a > poor choice. > > In any case, this design forces a server to wait less than the allowed > time in all cases, but gives the server no good information to choose > an appropriate time adjustment. A server has to assume that the > client has already expended some period waiting. Assuming that the > client is going to abandon the request at the identified time, then > the server is obliged to wait less than the entire period, lest the > response be wasted. Even if we assume that clocks are synchronized, > the resolution of Date and wait are capped at a second, so worst case > we have a 1 second window of uncertainty on when the request was sent. > This is worse if there are clock errors, particularly if the client > clock runs ahead of the server. > > I can't see how I would implement this feature so that it behaves > reliably for arbitrary hosts. > > On the other hand, the client has the ability to make its own > determination about clock synchronization and network transit delays. > A single request with wait=0 would provide a good measurement of total > non-server delays, without any quantization noise (Date is rounded or > trimmed to the second, which makes this determination difficult). The > client could then adjust the value of the wait preference to account > for what it learns, with the server being able to then concentrate on > the time elapsed between receipt and sending. Clock differences are > then irrelevant. > > Minor comments: > > In Section 3.2: > > When honoring the "return-representation" preference, the server MUST > include a Content-Location header field specifying the URI of the > resource representation being returned. > > This is a requirement that could be inadvertently violated by servers. > This really isn't what you are intending here. The idea is to ensure > that the returned representation doesn't get mistaken for a > representation of the request URI, *when it is not*. This does not > require 2119 language to convey, though I would agree that a reminder > is necessary here. How about: > > The returned representation might not be a representation for the > effective request > URI [[this is the term du jour, I believe]] when the request > affects another resource. > The Content-Location header can be used to identify the URI of the returned > representation. > > (I'd note that return-representation is less useful for PUT than POST > or PATCH. You don't mention PATCH at all.) > > In Sections 3.2 and 3.3, the mutual exclusivity of these parameters is > handled differently to the strict/lenient parameters. Instead of all > the 2119 stuff, how about: > > The "return-minimal" and "return-representation" preferences are > mutually exclusive directives. A request that contains both preferences > can be treated as though neither were specified. > > Alternatively, did you consider specifying a single preference here? > i.e., Prefer: return=minimal and Prefer: return=representation > > Section 3.5, is it useful to observe that the "strict" preference is > useful for ensuring that all aspects of a request are handled, so that > recoverable errors don't result in important parts of a request being > "missed" by a server? > > Did you consider a single preference here? i.e., Prefer: > processing=strict or Prefer: processing=lenient > > Regarding Section 3.5, which do we assume to be the existing behavior > for a server? strict or lenient? > > I'd ask an IANA considerations expert to look at Section 4.1. Did you > want something other than the strict letter of "Specification > Required"? > > Nits: > > The wording of Section 2.1 is a little contorted. The second > paragraph is a single sentence. "event just potentially" is a little > redundant. Suggest a reword to cover just the key points: > - Prefer is not intended to affect content negotiation. > - If a preference could affect what a cache stores or how it stores > it [httpbis-p6], then the server MUST use Vary: Prefer. This applies > even if the request does not include Prefer. > Caution is always good, but advising its application doesn't improve > the probability of it being applied. > > Example 3 in Section 2.2 implies semantics for the undefined "status" > argument. Doing this begs the question about whether this should have > been specified. Rather than invite such questions, try using a > generic argument with a nonsensical name. (Priority in the previous > example is OK, because it's inherently meaningless anyway.) > > You have a few references that aren't really necessary. I don't see > much relevance in httpbis-p7, for example.