Re: CTG: non-traditional browsing applications

 > "Is the current version of the document good enough to ship?"

No, it is not.

- it is not good enough for mobile developers who desperatly need a 
solid platform to build their apps (and not a spec that can be leveraged 
by someone somewhere to justify messing with HTTP in unforeseeable ways)

- it is not good enough for content owners (who don't want to have their 
content messed with)

- it is not good enough for telcos which want to deploy transcoders 
(there are no clear rules about what they should and should not do to 
avoid liability when they transcode other companies' content)

The only people who CTG is good for at the moment are transcoder 
vendors, who can refer to a document which is ambiguous enough that they 
can read whatever they want into it and wrap their products into a 
shroud of W3C legitimacy.

Luca

Jo Rabin wrote:
> 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:54:22 UTC