W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > September 2007

RE: ISSUE-221: Bryan Sullivan's Feedback [Content Transformation Problem Statement]

From: Jo Rabin <jrabin@mtld.mobi>
Date: Tue, 25 Sep 2007 19:25:24 +0100
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B47327D5@mtldsvr01.DotMobi.local>
To: <public-bpwg-ct@w3.org>

> +++++
> Hi all,
> As requested, here are some comments to
> emStatement/070911
> Re (1.2 Content Transformation Proxies) "So in order to provide a more
> satisfactory user experience of the Web to mobile users, an
> is inserted ":
> [bryan] This should be "may be inserted". At AT&T (AT&T Wireless,
> Cingular, and now the new AT&T) we have never deployed content
> transformation intermediaries (specifically for that purpose, beyond
> simple HTML conversion for legacy WAP1/WML-only devices) due to a
> of issues with that approach, including cost, performance (e.g.
> capacity, latency), quality/reliability (web transformation has been,
> in my experience remains, a good idea but very variable in reality),
> applicability (it is unusable for sites accessed over end-to-end
> connections). Not that we aren't hopeful many of the issues can and
> be solved, especially with W3C's focus on this... But I imagine that
> Mobile Operators have had the same experience as we have with content
> transformation intermediaries, and their deployment in production
> environments is limited as a result.

Suggested change


So in order to provide a more satisfactory user experience of the Web to
mobile users, an intermediary is inserted in the communications path
between the user agent and the origin server.


One approach to providing a more satisfactory mobile user experience of
mobile unaware and blocking sites is to insert an intermediary in the
communications path between the user agent and the origin server.

> Re (1.2 Content Transformation Proxies) "Content transformation
> typically work by masquerading as desktop browsers":
> [bryan] It would be good to mention the reasons why intermediaries are
> sometimes designed to act this way, e.g. a "known" browser is required
> some sites to provide a deterministic content baseline (which is
> for the transformation engine's rules), or any at all (if they don't
> recognize the browser, they may return the annoying "please upgrade to
> 7" response).

I'm not sure I understand the expression "deterministic content
baseline", however

Suggested change


Content transformation proxies typically work by masquerading as desktop


In order to avoid blocking behaviour and in order to achieve a
consistent presentation from Web sites that vary their experience
according to the browser type, proxies typically work by masquerading as
a specific desktop browser,

> Re ( Web Presentation) "mobile aware sites whose purpose is to
> provide mobile compatible pages or mobile compatible content like
> ring-tones or Java applications are unable to operate correctly":
> [bryan] "Mobile aware" sites should be accessible without use of a
> transformation proxy, assuming they are aware-enough to provide a
> OK" content experience. These are often linked to some community (e.g.
> Mobile Operator's portal), for which the content transformation proxy
> function can be avoided (e.g. via configuration of the Mobile
> WAP proxy or its integrated content transformation function). It may
> useful to consider standardized ways for "unaffiliated" content
> to publish this preference, but for now we generally assume that
> Operators that use content transformation will use it judiciously
> they do so, to avoid breaking mobile-aware sites.

That's one of the problems we are discussing. This is not always the
case. Suggest leave text as is.

> Re ( Non Web Applications) "transformation may break the
> of the client-server communication":
> [bryan] I agree, this is another reason for judicious application of
> content transformation. At AT&T, we serve many non-web HTTP-based
> applications/protocols via our WAP proxies, for specific service
> architecture reasons, or because the client platform does not provide
> non-proxy option to them specifically. We take specific steps to
> that the proxy is as transparent as possible, via an extremely limited
> content transformation configuration. Where it is feasible from a
> platform functional view, and from a service architecture view, to
> specific applications to bypass our WAP proxies, we do so via device
> configuration or application design. The ability to design/configure
> "connection profile" (including proxy options for any defined
> for specific applications is a necessary capability that we ensure is
> considered in any standardized service enabler (e.g. under OMA) or
> platform (e.g. MIDP etc). In some cases (e.g. MIDP) there are
> but we usually are successful in ensuring transparent service via our
> proxy.

I'm not clear that an edit is required here. For example the recent
introduction of a transcoding proxy in Ireland which converts POSTs to
GETs has broken the J2ME provisioning semantics, apparently.

> Re ( Security Issues) "of any kind, including content
> transformation proxies, may break this security model":
> [bryan] Except for WAP1 devices (which are few in number anymore, and
> rapidly disappearing from the market), there really should be no
> reasonable concern over use of content transformation proxies for
> sites. For WAP2 browsers, unless a content transformation proxy is
> designed to rewrite all of a page's links so that all resources are
> on the proxy, secure connections will occur directly between the
> and server. There is no chance for any intermediary to see/modify
> since the end-to-end connection is established though a TCP tunnel ala
> WAP2's TLS Tunneling (based upon the standard HTTP CONNECT method),
> the actual content server's certificate is received by the client and
> be verified against the request's hostname. The use of link-rewriting
> content transformation proxies is understandably a concern for generic
> secure sites (those without a specific business relationship with the
> transformation service provider). However there are better
> approaches to inserting a content transformation proxy into the
> path, so link rewriting should be avoidable.

Again, the issue here is that the intermediary interrupts the direct
relationship between client and server and hence causes a security
vulnerability. Hence I am not sure that an edit is needed.

> Re (2 Techniques Required) "Indicate a user's or site designer's
intent to
> intermediary proxies":
> [bryan] It would be good to consider ways to publish this, e.g. a
> "MobileOK" site being registered somehow, enabling transformation
> providers to pre-configure their systems. Proxies can also discover a
> site's capabilities/preferences upon the first request for a specific
> user-agent, and cache that information for future requests.

Yes, that's why we indicate it is a technique we need to have. It's not
the job of the problem statement to pronounce on this, though it does
allude to labelling as one of the clues that should be taken into

> Re (2 Techniques Required) "Identify specifically tailored content in
> response":
> [bryan] Other than a generic "transformation applied" notification
> header), there may not be a standardized way to mark the specific
> transformed items. This also applies to some of the other suggested
> techniques.

I think that what we are looking at here is a way for the origin server
to mark content to indicate that it is already, in its view, suitable
for delivery. The same, probably for an upstream transformation proxy to
a downstream one. Not sure an edit is needed, however if it is not clear
as it stands then I'd welcome comments on how the wording might be

Received on Tuesday, 25 September 2007 18:25:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:28 UTC