- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Mon, 15 Sep 2008 10:02:46 +0100
- To: Francois Daoust <fd@w3.org>
- CC: public-bpwg-ct <public-bpwg-ct@w3.org>
I agree with the direction of your comments, Francois. fwiw I don't think we have been clear enough that the point of specifying server behavior is to assist in cases where the CT proxy might legitimately misconstrue what the server's intentions are. I think a note to that effect would help. As I mentioned under the heading of a clearer title for the document, I think we should consider demoting the server behavior section to non normative, and that these are recommended practices to help make it clear what they are up to. Jo On 15/09/2008 09:53, Francois Daoust wrote: > > The Last Call comment: > http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2007 > > > As text: > "The use of MUST on the CTG when referring to the role of the server > should not be allow, since irresponsible transcoding companies will use > this to disrupt service and destroy the user experience set us back many > years. > We can accept RECOMMENDED, and only RECOMMENDED." > > > For the time being, there are two uses of MUST in section 4.2 Server > Response to Proxy: > 1/ "Servers MUST include a Cache-Control: no-transform directive if one > is received in the HTTP request." > 2/ "If a server varies its representation according to examination of > received HTTP headers then it MUST include a Vary HTTP header indicating > this to be the case" > > Both uses depend on the resolution of other comments, and in particular: > - LC-2080, LC-2041 for 1/ > - LC-2079 on profiling HTTP for 2/ (even though it deals with returning > 406 responses, I'd say it also applies to the Vary HTTP header which is > not required by the HTTP RFC) > > Depending on how we resolve the above comments, the comment may thus > turn out to not to apply to the spec anymore. Let's suppose it still > applies... > > > I do not see any reason not to use MUST for servers as well, when > required. What we are basically saying here is that a CT-proxy cannot > tell for sure what a server has in mind in 100% of all cases. A server > may not conform to the guidelines, that's its choice. The remaining > guidelines (that apply to the CT-proxy) are here to make things work as > much as possible when servers are not aware of the existence of the > guidelines. There is a way for servers to get closer to 100% by > following these guidelines. It involves some dos and don'ts. Claiming > conformance to the guidelines and not following "SHOULD" statements > requires a justification as well. The comment seems to imply that, > provided we only use "SHOULD and MAY" statements, ALL servers would be > conforming to the guidelines by default, and that's not the case. Should > it be? Maybe, but in that case, the notion of a "Content Deployment" > class of product doesn't mean a lot and should be removed altogether, > and normative statements that apply to servers rewritten as > non-normative statements. > > I think we should start by dealing with the comments on "profiling HTTP" > because our position on these ones will have consequences for the way we > can resolved this comment, IMO. > > Francois. >
Received on Monday, 15 September 2008 09:03:34 UTC