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
>
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Probl
> 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
intermediary
> 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
variety
> of issues with that approach, including cost, performance (e.g.
> capacity, latency), quality/reliability (web transformation has been,
and
> in my experience remains, a good idea but very variable in reality),
and
> applicability (it is unusable for sites accessed over end-to-end
secure
> connections). Not that we aren't hopeful many of the issues can and
will
> be solved, especially with W3C's focus on this... But I imagine that
other
> Mobile Operators have had the same experience as we have with content
> transformation intermediaries, and their deployment in production
service
> environments is limited as a result.

Suggested change

From

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.

To

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
proxies
> 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
for
> some sites to provide a deterministic content baseline (which is
important
> 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
IE
> 7" response).

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

Suggested change

From

Content transformation proxies typically work by masquerading as desktop
browsers, 

To

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 (1.2.2.1 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
content
> transformation proxy, assuming they are aware-enough to provide a
"Mobile
> OK" content experience. These are often linked to some community (e.g.
a
> Mobile Operator's portal), for which the content transformation proxy
> function can be avoided (e.g. via configuration of the Mobile
Operator's
> WAP proxy or its integrated content transformation function). It may
be
> useful to consider standardized ways for "unaffiliated" content
providers
> to publish this preference, but for now we generally assume that
Mobile
> Operators that use content transformation will use it judiciously
however
> 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 (1.2.2.2 Non Web Applications) "transformation may break the
semantics
> 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
a
> non-proxy option to them specifically. We take specific steps to
ensure
> that the proxy is as transparent as possible, via an extremely limited
> content transformation configuration. Where it is feasible from a
client
> platform functional view, and from a service architecture view, to
allow
> specific applications to bypass our WAP proxies, we do so via device
> configuration or application design. The ability to design/configure
the
> "connection profile" (including proxy options for any defined
interface)
> 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
limitations,
> but we usually are successful in ensuring transparent service via our
WAP
> 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 (1.2.2.4 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
secure
> sites. For WAP2 browsers, unless a content transformation proxy is
> designed to rewrite all of a page's links so that all resources are
hosted
> on the proxy, secure connections will occur directly between the
client
> and server. There is no chance for any intermediary to see/modify
anything
> since the end-to-end connection is established though a TCP tunnel ala
> WAP2's TLS Tunneling (based upon the standard HTTP CONNECT method),
and
> the actual content server's certificate is received by the client and
can
> be verified against the request's hostname. The use of link-rewriting
in
> 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
architectural
> approaches to inserting a content transformation proxy into the
request
> 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
proxy
> 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
account.

> 
> Re (2 Techniques Required) "Identify specifically tailored content in
a
> response":
> [bryan] Other than a generic "transformation applied" notification
(e.g.
> 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
altered.

Thanks
Jo
Received on Tuesday, 25 September 2007 18:25:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:36 GMT