[CTG] Draft 2008-11-07 / inconsistencies

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:04:24 UTC