Re: CTG: non-traditional browsing applications

Eduardo Casais wrote:
>> If you have evidence to support this, that 
>> would certainly help!
> 
> I'll try to find specific references about
> breaking AJAX again. Certain is that AJAX
> content passed as application/xhtml+xml gets
> modified by those CT-proxies that endeavour
> to modify anything that passes through them
> and looks remotely like a Web page.

I agree but note this particular case would not be covered by your proposal.



> In any case, better be safe than sorry: let us
> prevent now the negative side-effects of eager
> transcoders rather than having to revisit the 
> matter later when the damage is done. The 
> emergence of AJAX in the mobile world 
> requires a more resolute action than a vague
> warning.
> 
>> If the group accepts the thrust
>> of your comment, could this perhaps be 
>> turned into a bullet point in 4.2.9 next to 
>> the one on the Internet Content Types
>> associated with Mobile Content?
> 
> That would lead to an underspecification. 
> 
> In the case of SOAP, we can definitely narrow
> down the behaviour of proxies formally, based
> on existing standards. Here, we can state:
> 
> "A content transformation proxy MUST handle 
> HTTP requests from a terminal, and 
> corresponding responses to them, either 
> transparently or as a SOAP forwarding
> intermediary, whenever the HTTP transaction 
> conveys a payload advertised as one of the
> following MIME types:
> 
> application/soap+xml
> application/soap+fastinfoset
> application/fastsoap
> application/fastinfoset
> 
> This in compliance with section 2.7.2, SOAP
> Version 1.2 Part 1 - Messaging Framework 
> (Second Edition), W3C Recommendation 27 April
> 2007."

I'd be happy to take an action to get more background to section 2.7 in 
the SOAP document you refer to:
  http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#relaysoapmsg

AFAICT, the section creates an analogy to HTTP proxies at the SOAP 
level, where forwarding and active intermediaries for SOAP messages 
roughly tranlate into transparent and non-transparent proxies for HTTP 
messages. Section 2.7.3 contains warnings about side-effects active 
intermediaries may have but does not forbid them.

If the SOAP spec itself does not forbid active intermediaries at the 
SOAP level, why should we globally forbid non-transparent proxies 
operations on SOAP content?


> As for AJAX communications, I do not see any
> role for CT-proxies. How exactly are they
> supposed to intervene in an application
> specific client-server communication scheme
> (i.e. what amounts to an application-specific
> protocol)?

I do not see a role either and don't remember people mentioning true use 
cases, but I do not think no immediate role and potential danger 
translate into "we must prevent".



>> We had removed "application/xml" and "text/
>> xml" from past discussions because they may
>> be used to serve XHTML content as explained
>> in the introduction of XHTML Media Types:
> 
> Those two types are recommended in the W3C
> document about XMLHttpRequest, whereas they
> are only possible but not recommended in the
> XHTML media types document. 
> 
>> If we keep them in the list, one risk is to 
>> end up with a document that indirectly 
>> suggests to use "application/xml" or "text/
>> xml" for XHTML content to bypass proxies, 
>> whereas a more precise media type should be
>> used whenever possible as recommended by 
>> the XHTML Media Types document.
> 
> Well,
> a) There is no indirect recommendation, since
> this issue is clearly dealt with in section 
> H.1.4.1 of the CTG. If needed, the existing 
> statement may be reinforced.

Good point.


> b) That might be an issue for proxies -- but
> they are the ones causing problems in the 
> first place and leading developers to attempt
> bypassing them.
> c) AJAX must avoid a double-jeopardy: if using
> the recommended types (i.e. application/xml or
> text/xml), then it is at the mercy of 
> unwanted transformations because those types
> might be used for XHTML, even if this is not
> recommended, even when AJAX does not actually
> rely upon XHTML. 
> If AJAX uses XHTML and its recommended type, 
> then it might be viewed as browsing and get
> transformed again. From this perspective, 
> there is absolutely no way out for an AJAX
> application relying upon an XML type, except
> emitting "no-transform" -- which I explained
> is not always possible and is possibly more
> difficult in the case of AJAX than for normal
> browsing.
> d) To give a quantitative perspective on the
> matter: the MAMA study by Opera gives the 
> following results on MIME frequencies:
> application/xml: 17 (0.00048%)
> text/xml: 60 (0.0017%)
> over a total of 3509180 transactions. It is
> not like developers are using these types for
> XHTML content like wild.
> e) From your reply, I gather there is no issue 
> with application/json at all. This type is 
> unambiguously and exclusively used for AJAX,
> and there is no rationale for altering content
> of such type in transit.

Yes, the whole thing makes sense.
I still don't think we can put it under a MUST guideline though.

Francois.

Received on Monday, 2 November 2009 16:07:35 UTC