Re: CTG: non-traditional browsing applications

I've read, and re-read the thread started by Eduardo on this. I have a 
couple of observations mainly based on taking a pragmatic stance.

a) We are in second last call, any substantive changes will require a 
third last call which in practice will never happen, since the group 
will no longer be in charter to create such a last call.

b) Any document we publish will have flaws. Is the improvement suggested 
sufficient to risk not having a document at all?

c) Any further specification will be open to further comment that 
emerging applications x, y and z are not specifically dealt with.

d) As Francois pointed out we have considered in the past whether it is 
possible to specify more clearly the idea of leaving programmatic 
exchanges alone. What we ended up with is the non-normative language in 
section 4.1.3 which serves as a general admonition which I think is 
needed, on the basis that the nature and specific technologies involved 
with programmatic exchanges will undoubtedly move on and continue to 
change over time. If we were to be more specific about it, it might 
server to diminish the generality of the idea.

e) It might be desirable to make specification of how a proxy detects 
and treats programmatic exchanges part of its conformance specification. 
I can see the benefit in that, but would be against it if that would be 
sufficiently a normative change to make the document revert to last call 
a further time.

I don't mean in any of this to diminish what Eduardo is saying, and as 
usual value his considered and detailed input highly. However at some 
point (now) we need to ship a document - so the question is: "Is the 
current version of the document good enough to ship?", not "Is it 
perfect?" or "Could it be improved?".

Jo

On 06/11/2009 18:47, Eduardo Casais wrote:
>> 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 Monday, 9 November 2009 12:34:47 UTC