Re: Prefer Draft Feedback

Thx for the quick response... I'm making some tweaks and using some of
your suggested text in the next draft.

I'd like to be able to put a wrap on this after this next iteration.

- James

On Sun, Dec 18, 2011 at 9:15 PM, Alex Rousskov
<rousskov@measurement-factory.com> wrote:
> On 12/18/2011 07:46 PM, James Snell wrote:
>> Updated version based on the latest round of feedback...
>>
>>   http://www.ietf.org/id/draft-snell-http-prefer-08.txt
>
>>    In the case generating a response will take longer than the time
>>    specified, the server, or proxy, can choose to either return a 202
>>    Accepted response, cancel processing, or continue attempting to
>>    complete the request
>
> If you want to recommend one of TWO server actions (either "return 202"
> or "continue"), then please remove "cancel processing" to avoid the
> implication that there is a third action.
>
> If you want to recommend one of THREE server actions ("return 202",
> "cancel processing", or "continue"), then please consider removing
> "either". In this case, you may want to clarify what "cancel processing"
> means from the HTTP protocol point of view. Some kind of response is
> probably appropriate even if request processing is canceled.
>
> Please consider replacing "can choose to" with "MAY".
>
>
>>    Failing to include a Date header field in the request would
>>    require the server to use the instant it received and began
>>    processing the request as the baseline for determining how long the
>>    client has been waiting which could yield unintended results
>>    depending on how out of synch the client and server clocks are.
>
> The "depending on how out of synch the client and server clocks are"
> trailer should be removed because:
>
> 1) When the clocks are out of sync, the Date header can only hurt so the
> "Failing to include" precondition is not applicable when clocks are out
> of sync.
>
> 2) When the clocks are in perfect sync, but there is no Date header,
> then there still will be "unintended results", caused by absence of any
> information regarding how long the client has already been waiting for
> when the server received the request.
>
> In other words, the Date header is no meant to solve the problem with
> out-of-sync clocks. It is meant to solve the problem of a [long] chain
> of [slow] connections/proxies eating at the remaining time to process
> the request.
>
>
>>    Note that because of the inherent difficulties in reliably
>>    determining the length of time a request will take to arrive at
>>    server, the wait preference is, at most, a hint to the server as to
>>    what the client is likely to do should the processing of a request
>>    take too long.
>
> It feels like the "is, at most, a hint" part implies that all of the
> above specs were useless. If the preference is just such a hint (or
> less!), there is no need to specify the wait time. Perhaps it would be
> better to rephrase the above in most specific terms? For example,
>
> Lack of a Date header or poor clock synchronization makes it impossible
> to determine the exact length of time the client has already been
> waiting for when the request was received by the server. The only
> reliable information conveyed by the wait preference is that the client
> is not expecting the server to spend more than the specified time on
> request processing and may terminate the transaction at any time.
>
>
>
>>    When specifying a value for the wait preference,
>>    Client's need to take appropriate care to specify a reasonable period
>>    of time.
>
> Replace "Client's need" with "client needs". I would actually remove
> this sentence completely because it essentially says that "client needs
> to be reasonable" which is kind of obvious/understood.
>
> Moreover, when thinking about a _client_ implementation, I think all of
> the above complications become unimportant. Our assumption is that the
> client has its reasons to limit the wait.  It should not be important to
> the _client_ what portion of its lifetime the request spends in-transit
> or whether the clocks are in sync. All of that is outside client control
> anyway. The client has reasons to terminate the transaction in X seconds
> [after Date], and that is what it should say using this preference.
>
>
> HTH,
>
> Alex.

Received on Monday, 19 December 2011 19:40:22 UTC