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

Hi Eduardo,

You say:

<QUOTE>
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.
</QUOTE>

Although MobileAware is not in the business of intermediate/proxy
adaptation of general content, we have many years providing adaptive
technology at the origin server, so perhaps I can offer a pragmatic and
concrete use case for the delivery of content that would not validate.

Of the thousands of different devices (mostly mobile) that our
technology supports, very few adhere 100% to the specifications they
claim to support. Many also have features that are additional to the
published specifications and are used by people who would complain if
such features were not employed.

Consequently, in order to satisfy the need to give excellent end-user
experiences, we must (sadly) adjust our adapted output to suit the
quirks of the requesting device, thus addressing the bugs/features that
we know to be present. If we were forced (out of a desire to comply with
some notable expression of best practice) to only generate content that
would validate, we'd soon be out of business.

I think that if an intermediate transforming proxy technology were
similarly constrained, its usefulness would also substantially diminish.

I know this position may be seen by some as a possible perpetuation of
the lax approach that browser/device vendors appear to take, but the
reality is that there are billions of such devices already in use, of
which only a tiny fraction could be updated (assuming willingness on the
part of manufacturers to correct the errors, and on the part of users to
download/install the updates). It's not going to happen, so we in the
adaptive world take the pragmatic position of delivering to the devices
that which we know will work.

What we would certainly agree with is some strong encouragement to
support and deliver valid content *where possible*, and perhaps over
time this problem will fade somewhat, letting us get on with adapting to
the important aspects of context and not just the bugs.

---Rotan.


-----Original Message-----
From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org] On Behalf Of
eduardo.casais@areppim.com
Sent: 10 November 2008 19:53
To: public-bpwg-ct@w3.org
Subject: [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 Tuesday, 11 November 2008 09:16:46 UTC