Re: [CTG] Draft 2008-11-07 / inconsistencies

Thanks Eduardo

This is useful and mostly I take your points. I think we need to work on 
the precise language as we head towards a second last call.

Jo

On 10/11/2008 19:53, eduardo.casais@areppim.com wrote:
> Hello everybody,
> 
> I discovered a number of inconsistencies in the newest
> draft of the CTG. In principle nothing crippling, but 
> they must be corrected.
> 
> a)	HTTP header
> 
> A normative document must use precise terminology.
> The document resorts to the expression "HTTP headers" 
> to denotate what are actually "HTTP header fields" 
> -- which is the correct technical term from RFC2616. 
> HTTP requests/responses have only one header (and a
> body), which has several fields. 
> 
> b)	Alteration of header fields
> 
> Section 4.1.5 states:
> 	"Proxies should not change headers other 
> 	than User Agent and Accept(-*) headers[...]"
> 
> This formulation is inconsistent with 4.1.6.
> 
> c)	Link to "handheld" representation
> 
> Section 4.2.7 mentions a "CT-proxy"; this is the
> only usage of this word in the entire document.
> It would actually be good to define the term in 
> section 2.1 and use it in the entire document
> wherever non-transparent proxies are intended.
> 
> d)	Server origination
> 
> Section D.1.2 mentions "WAP/WML proxies". The 
> correct term is "WAP gateways".
> 
> "Servers should consider include..." is probably
> "Servers should consider including...".
> 
> e)	Use of vary
> 
> Section D.1.3.1 states:
> 	"Servers that are aware of the behavior of
> 	specific transforming proxies, as identified 
> 	in a Via header make choose to take advantage 
> 	of this knowledge by altering their responses 
> 	to take account of the behavior."
> Which is quite convoluted. What is meant is probably
> this:
> 	"Servers aware of the presence of a transforming
> 	proxy, as identified through HTTP header field
> 	via, might construct their response according to
> 	their knowledge of the proxy behaviour."
> 
> f)	Alteration of response
> 
> Section 4.2.8.1 states:
> 	"2. The altered content should validate 
> 	according to an appropriate published formal 
> 	grammar;"
> 
> Surely this is an oversight -- MUST, not SHOULD. 
> Does anybody claim that presenting syntactically 
> incorrect content to a user agent is acceptable? 
> Does anybody envision any content format that is
> described in such a way as to not allow a formal
> validation? If so, I would be interested in seeing 
> the concrete use cases.
> 
> g)	HTTPS rewriting
> 
> Section 4.2.8.2 states 
> 	"If a proxy rewrites HTTPS links, it must advise 
> 	the user of the security implications of doing so 
> 	and must provide the option by-pass it and to 
> 	communicate with the server directly."
> which needs rewriting for grammatical and semantic 
> correctness: meant are not the security implications of 
> rewriting links, but of following them; the option is to
> bypass the proxy; the client does not communicate with
> the server directly (since there might be further HTTP
> proxies in between), but over an end-to-end unbroken 
> secure connection.
> 
> h)	Examples
> 
> Section E states:
> 	"Internet Content Types that are sometimes or 
> 	usually associated with content intended for 
> 	mobile delivery"
> and
> 	"DOCTYPEs sometimes or usually associated with 
> 	content intended for mobile delivery"
> 
> While I think I understand what the author wanted
> to express, the formulation is actually incorrect,
> since its contraposition is "content types/DOCTYPES
> often associated with content not intended for
> mobile delivery" -- which is 100% incorrect: the
> MIME types and DOCTYPES identify mobile content
> unambiguously all the time, and the MIME types/
> DOCTYPES are never used for content not intended 
> for mobile delivery. The exception is 
> application/xhtml+xml, which often and usually
> identifies mobile content (as XHTML basic), but
> might identify XHTML not intended for mobile
> devices.
> 
> The "mobile delivery" must be substituted with
> something like "delivery to a mobile device".
> 
> i)	Via header field
> 
> Section 4.1.6.1 states:
> 
> 	"Proxies must (in accordance with compliance 
> 	to RFC 2616) include a Via HTTP header indicating 
> 	their presence and should indicate their ability 
> 	to transform content by including a comment in 
> 	the Via HTTP header consisting of the URI 
> 	"http://www.w3.org/ns/ct".
> 
> 	When forwarding Via headers proxies should not 
> 	alter them in any way."
> 
> There are several inconsistencies here.
> 
> First, "in accordance with compliance to" is redundant.
> Then, the comment in the via value does not indicate
> their ability to transform (which would require either
> a measure of quality or of conformance to a class of
> well-defined transformations), but their intent to
> do so. Finally, the last sentence is inconsistent 
> with RFC2616 section 14.45, which stipulates that
> (all kinds of) proxies must actually modify the via
> field according to the scheme defined in the IETF
> standard.
> 
> 
> E.Casais
> 
> 
>

Received on Monday, 10 November 2008 20:39:24 UTC