W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > September 2008

Re: LC-2007: use of MUST when referring to the role of the server

From: Jo Rabin <jrabin@mtld.mobi>
Date: Mon, 15 Sep 2008 10:02:46 +0100
Message-ID: <48CE24B6.6000609@mtld.mobi>
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.


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:30 UTC