Re: CTG: non-traditional browsing applications

> Actually, that's my point, we are not restricting things more than they 
> are in RFC2616. Restrictions over transformation of mobile-optimized are 
> at the SHOULD level, compatible with RFC2616.

I think there is a misconception about what existing standards allow or disallow
with respect to the CTG work.

Standards such as HTTP or SOAP name entities such as "non-transparent proxies" or 
"active intermediaries", but they leave their mode of operation undefined and their 
properties unspecified (with just a couple of precisions for the sake of consistency,
namely in sections 13.5.2 and 14.11 of RFC2616). In short, the standards put these
transformative behaviours squarely outside of their scope.

This has the following important consequences:

1) The simple mention of non-transparent proxies or active intermediaries in existing
standards does not constitute any normative basis for them. In other words: claiming
conformance to a standard for behaviour that is undefined is impossible; asserting
compatibility with a standard for properties that are explicitly outside the scope of
the standard is meaningless; arguing that a standard encompasses behaviour that it
intentionally leaves unspecified is invalid. What the HTTP and SOAP standards are
stating is this: "There are exotic systems that have a behaviour that goes beyond 
what we specify, and we rely upon a specific terminology to identify them. We do 
not deal with that behaviour, but some other standards might. Only the behaviour 
and properties we specify is subject to conformance requirements, assessments and
claims according to our standard."

2) Transformative behaviour is outside the scope of HTTP, SOAP or AJAX, but is exactly
within the scope of CTG; there is no conflict. As long as the CTG does not redefine
the terminology or concepts of pre-existing standards, as long as it does not impose
supplementary requirements on systems for their behaviour that is fully conformant 
with those standards, then the CTG is free to define its typology of transformations,
specify their properties, and impose requirements on systems seeking conformance to
it. The answer to the question whether we can impose MUST/MUST NOT to transformative 
operations of proxies is unambiguous: yes, we can!

3) As a matter of fact, the CTG is already doing exactly this. For instance:
"Other than to convert between HEAD and GET proxies must not alter request methods"
"Aside from the usual procedures defined in [RFC 2616 HTTP] proxies [...] must not 
delete header fields"
"A proxy must not reissue a POST request with altered header fields when the response
to the unaltered POST request has HTTP status code 200"
"When forwarding an HTTP request with altered HTTP header fields, in addition to 
complying with the rules of normal HTTP operation, proxies must include in the 
request copies of the unaltered header field values in the form "X-Device-"<original 
header name>"

4) Experience with deployed transcoders has shown that their compatibility with the
mobile Web is, to put it mildly, quite questionable. The CTG is thus not only entitled
to impose restrictions on their behaviour in the case of AJAX and SOAP; it must do so,
as proxies cannot intervene meaningfully in such client-server interactions. Clearly,
the information exchanged between terminal and server is entirely application-specific
(it may be application-specific XML dialects, fragments of XML documents, etc), and
cannot even be interpreted by falling back onto a default interpretation as structured
"pages" (with titles, headings, paragraphs, lists, tables, embedded images, etc). 
Thus, any disturbance to AJAX/SOAP payload can be even more damaging than a mediocre 
page reformatting -- in those cases, it is equivalent to garbling a protocol. Notice 
that this applies to communications established directly with the terminal 
(originating from an unmodified Web page, or from an installed application); a proxy 
may take over AJAX/SOAP traffic on behalf of a non-AJAX, non-SOAP capable device.

5) Finally, notice that my proposal does not require the elaboration of new behaviour
or the specification of novel algorithmic properties; it just requires CT proxies to
fall back on a well-defined, formally specified behaviour from well-established norms:
transparent proxies and forwarding intermediaries. One cannot be more standards 
compatible than that.


E.Casais

Received on Friday, 6 November 2009 18:47:42 UTC