Re: limits on HTTP Prefer Request Header in [ISSUE-89] resolution

> forces two Response Headers from the server -- Preference-Applied and 
Vary

Preference-Applied is only "required" if the client has no way to tell 
from the response content that a given preference was applied; that's in 
the Snell draft already.
Vary is also there, and I mentioned it in both proposals.  I agree in our 
context that we would very likely require it (the exception would be on 
requests that are not cacheable by default), but ONLY if its value 
influenced the response entity ... e.g. if a server chose to always ignore 
Prefer (b/c it only hosts simple containers, for example), you don't need 
either response header.

I'm agnostic on Ted's syntax.  It's an option I have not looked at while 
drafting mine.  I can say that I confirmed (since this is not explicitly 
stated) the author's intent that such extensions were/are permitted; he's 
not going to update the draft b/c he'd lose his place in the RFC # queue, 
but he mentioned it as an erratum.

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario