Re: CTG: non-traditional browsing applications

Replying to the initial message but I took good note of your reply to my 
previous reply ;)


Eduardo Casais wrote:
[...]
> In the field, application developers have been facing aggressively configured CT
> proxies that interfer with AJAX communications -- on the basis that the content
> transmitted over HTTP does not fit into pre-defined categories of "mobile browsing",
> is henceforth viewed as "desktop content", and then thoroughly garbled by 
> misdirected transformations.

One of the reasons why the group decided to remain silent on that topic 
in the past is that we had no evidence that there was an actual problem 
in practice, i.e. that transcoding proxies were indeed breaking JSON or 
data-related exchanges identified with appropriate media types.

I have seen complaints from Web authors about transcoding proxies 
breaking actual content, but I haven't seen complaints about transcoding 
proxies breaking data-related exchanges (unless the initial page is 
already broken, that is). If you have evidence to support this, that 
would certainly help!



> II.	PROPOSAL
> 
> The following text is included in the normative part of the document:
> 
> "A content transformation proxy MUST handle HTTP requests from a terminal, and 
> corresponding responses to them, transparently whenever the HTTP transaction
> conveys a payload advertised as one of the following MIME types:


The usual problem with MUST is that I think we would fall in the "HTTP 
profile" trap. 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?

Proposed text:
[[
In the absence of a Vary or no-transform directive [...] proxies SHOULD 
NOT transform content matching any of the following rules unless the 
user has specifically requested transformation:
  # the Content-Type has a value listed in Internet Content Types 
associated with application data exchange.
]]

Followed by an appendix that lists the suggested content types.



[...]
> application/xml
> text/xml


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:
  http://www.w3.org/TR/xhtml-media-types/#intro

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.


Francois.


> application/soap+xml
> application/soap+fastinfoset
> application/fastsoap
> application/fastinfoset
> 
> These MIME types distinguish traditional browsing transactions from AJAX 
> communications and messages in Web Services."
> 
> 
> III.	RATIONALE
> 
> a) Compliance with standards
> 
> The listed MIME types are specified by the IETF or the ITU-T: 
> application/json in RFC4627; 
> application/xml and text/xml in RFC3023; 
> application/soap+xml in RFC3902;
> application/fastinfoset in ITU-T Rec. X.891 | ISO/IEC 24824-1; 
> application/soap+fastinfoset and application/fastsoap in ITU-T Rec. X.892 | ISO/IEC 
> 24824-2.
> 
> All are registered at IANA (see http://www.iana.org/assignments/media-types).
> 
> b) Application scope
> 
> The listed MIME types are conclusively used for non-traditional browsing applications.
> 
> application/json, application/soap+xml, application/soap+fastinfoset are exclusively
> associated with AJAX, resp. Web Services applications. 
> 
> The type application/soap+xml is recommended by the W3C for marshalling messages 
> between Web Service entities:
> 
> SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)
> W3C Recommendation 27 April 2007
> http://www.w3.org/TR/2007/REC-soap12-part1-20070427
> 
> The W3C further mandates support for this MIME type in:
> 
> SOAP Version 1.2 Part 2: Adjuncts (Second Edition)
> W3C Recommendation 27 April 2007
> http://www.w3.org/TR/2007/REC-soap12-part2-20070427
> 
> MIME types application/xml and text/xml are preferred by the W3C for information
> exchange during an AJAX session in its on-going standardization of XMLHttpRequest:
> 
> XMLHttpRequest
> W3C Working Draft 20 August 2009
> http://www.w3.org/TR/XMLHttpRequest
> 
> XMLHttpRequest Level 2
> W3C Working Draft 20 August 2009
> http://www.w3.org/TR/XMLHttpRequest2
> 
> These two MIME types are also those that application developers should or even must 
> use, according to the documentation of several manufacturers of client software.
> 
> c) Overlap with browsing
> 
> The listed MIME types are neither used, nor recommended for traditional browsing;
> hence, there is no ambiguity as to the non-applicability of transformations on HTTP
> transactions that deal with content of those types.
> 
> d) Generality
> 
> An alternative is to insert a "no-transform" directive in the HTTP transactions of
> non-traditional browsing applications. This is however not always possible because
> the AJAX or SOAP modules may be compiled packages that cannot be configured or 
> modified by the developer (whether in the terminal user agent or on the server Web 
> platform), or that are not under the control of the developer (terminal: configuration
> only possible manually by users themselves, or only by the operator; server: platform
> under the control of the ISP in a shared hosting environment). 
> 
> 
> 
> E.Casais
> 
> 
>       
> 
>

Received on Monday, 2 November 2009 09:01:36 UTC