Re: CTG: non-traditional browsing applications

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

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."

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)?

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


E.Casais

Received on Monday, 2 November 2009 14:51:53 UTC