Subject: Updated Prefer Header Draft

From: James M Snell <[email-masked]>
Date: Fri, 12 Oct 2012 11:09:54 -0700

The last call on the Prefer draft has closed as of today. Based on the
excellent feedback I received during the last call, I have updated the
current draft and it has been handed off for IESG review. The current draft
is located here

 http://www.ietf.org/id/draft-snell-http-prefer-15.txt

The major changes based on feedback include:

1. I have brought back the Preference-Applied response header. I know that
there are a few folks who feel this header is entirely unnecessary but
feedback I have received from a number of implementers has convinced me it
is. The use is optional and limited to cases where the application of a
preference may not be obvious and the application of the preference could
have an impact on the processing of a response.

2. I have altered the definition of the wait preference slightly.
Essentially, it now specifies the clients assumption of how long processing
a request should take rather than indicating how long the client is willing
to wait for a response. The difference is subtle but important, and the
change is a very good one.

3. I have made a number of editorial changes to the structure of the
document. Some section numbers have changed.

- James

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Tue, 23 Oct 2012 00:48:46 +0000

Hi James

as a proxy developer, I'm always interested in how such protocol 
changes will impact my product, and there's always the cost/benefit 
analysis which on one hand looks at what is the likely implementation 
rate or importance of sites that may choose to rely on such an 
extension.

So do you have any information (e.g. have there been any indications 
from implementors) as to who would be looking to implement such 
extensions?

My only other comment on the draft would be that there are some 
implicit assumptions that may not always hold (but may be ok for the 
general cases), e.g.

* you can't assume your header will make it to the server, so if the 
server relies on it, or the client relies on the server receiving it, 
there would need to be some clear way to indicate this so the client 
can know whether the server received the directive or not.  E.g. 
intermediaries that strip unknown headers.

* you can't assume anything about how long it may take for a request to 
reach a server.  E.g. a PUT request going through a proxy that does AV 
scanning will take an unforeseeable period of time to receive, then 
scan the content before making an upstream request.  This could cause 
problems with the proposed "wait" preference.  In fact I struggle to 
see how "wait" would be used in practise, and the skeptical side of me 
wonders at its merit.

Regards

Adrien

------ Original Message ------
From: "James M Snell" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 13/10/2012 7:09:54 a.m.
Subject: Updated Prefer Header Draft
>current draft and it has been handed off for IESG review. The current 
>draft is located here
>1. I have brought back the Preference-Applied response header. I know 
>that there are a few folks who feel this header is entirely 
>unnecessary but feedback I have received from a number of implementers 
>has convinced me it is. The use is optional and limited to cases where 
>the application of a preference may not be obvious and the application 
>of the preference could have an impact on the processing of a 
>response. 
>
>Essentially, it now specifies the clients assumption of how long 
>processing a request should take rather than indicating how long the 
>client is willing to wait for a response. The difference is subtle but 
>important, and the change is a very good one.
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Oct 2012 13:07:08 +1100

On 23/10/2012, at 11:48 AM, Adrien W. de Croy <[email-masked]> wrote:

>  
> Hi James
>  
> as a proxy developer, I'm always interested in how such protocol changes will impact my product, and there's always the cost/benefit analysis which on one hand looks at what is the likely implementation rate or importance of sites that may choose to rely on such an extension.
>  
> So do you have any information (e.g. have there been any indications from implementors) as to who would be looking to implement such extensions?
>  
> My only other comment on the draft would be that there are some implicit assumptions that may not always hold (but may be ok for the general cases), e.g.
>  
> * you can't assume your header will make it to the server, so if the server relies on it, or the client relies on the server receiving it, there would need to be some clear way to indicate this so the client can know whether the server received the directive or not.  E.g. intermediaries that strip unknown headers.

I don't think this is a concern for Prefer -- after all, they're preferences, not requirements.

>  * you can't assume anything about how long it may take for a request to reach a server.  E.g. a PUT request going through a proxy that does AV scanning will take an unforeseeable period of time to receive, then scan the content before making an upstream request.  This could cause problems with the proposed "wait" preference.  In fact I struggle to see how "wait" would be used in practise, and the skeptical side of me wonders at its merit.

I share this concern, and I think I expressed it before.

--
Mark Nottingham   http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Mon, 22 Oct 2012 20:50:08 -0700

On Mon, Oct 22, 2012 at 5:48 PM, Adrien W. de Croy <[email-masked]> wrote:

>
> Hi James
>
> as a proxy developer, I'm always interested in how such protocol changes
> will impact my product, and there's always the cost/benefit analysis which
> on one hand looks at what is the likely implementation rate or importance
> of sites that may choose to rely on such an extension.
>
> So do you have any information (e.g. have there been any indications from
> implementors) as to who would be looking to implement such extensions?
>
> My only other comment on the draft would be that there are some implicit
> assumptions that may not always hold (but may be ok for the general cases),
> e.g.
>
> server relies on it, or the client relies on the server receiving it, there
> would need to be some clear way to indicate this so the client can know
> whether the server received the directive or not.  E.g. intermediaries that
> strip unknown headers.
>
>

This, among other reasons, is why the entirely optional Preference-Applied
response header has been reintroduced. Further, as Mark states, the very
nature that this is a Preference and not a Requirement makes this ok.

> scanning will take an unforeseeable period of time to receive, then scan
> the content before making an upstream request.  This could cause problems
> with the proposed "wait" preference.  In fact I struggle to see how "wait"
> would be used in practise, and the skeptical side of me wonders at its
> merit.
>
>

In the latest version, wait has been refactored to account for this concern.

- James

>   <http://www.ietf.org/id/draft-snell-http-prefer-15.txt>