FW: Content Transformation TF Report for BP Call 2007-09-20

Forwarding on behalf of Bryan Sullivan at At&T.

Best wishes
Rhys 

-----Original Message-----
From: Sullivan, Bryan [mailto:BS3131@att.com] 
Sent: 23 September 2007 23:29
To: Rhys Lewis
Subject: RE: Content Transformation TF Report for BP Call 2007-09-20

Rhys,
Can you forward this to member-bpwg@w3.org for me? I'm having issues with
access to the member mailing lists. I could send this to the public lists
(I've seen some discussions there) but I'm unsure if that is appropriate
at this time.

Thanks,
Bryan
+++++

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.

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

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.

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.

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.

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.

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.

Best regards,
Bryan Sullivan | AT&T | Service Standards bryan.sullivan@att.com

-----Original Message-----
From: member-bpwg-request@w3.org [mailto:member-bpwg-request@w3.org] On
Behalf Of Rhys Lewis
Sent: Thursday, September 20, 2007 1:31 AM
To: 'Appelquist, Daniel, VF-Group'; member-bpwg@w3.org
Subject: Content Transformation TF Report for BP Call 2007-09-20


Hello everyone,

The CT TF has continued to make progress on it's problem statement [1] and
guidelines [2]documents.

In particular, we have just received a major contribution [3] for the
guidelines document from Magnus. I expect this to be a major topic for
next week's call.

Best wishes
Rhys

[1]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Probl
em
Statement/070911
[2]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guide
li
nes/2007-08/CTGuidelines.html

> -----Original Message-----
> From: member-bpwg-request@w3.org
> [mailto:member-bpwg-request@w3.org] On Behalf Of Appelquist, Daniel, 
> VF-Group
> Sent: 19 September 2007 15:38
> To: member-bpwg@w3.org
> Subject: [agenda] Agenda for tomorrow's call
> 
> Hi everyone
> 
> Here is the proposed agenda for tomorrow's meeting (logistics info at 
> the end of this message).
> 
> Please send your regrets to the list if you cannot attend. 
> Also, please send updates on your action items.
> 
> Chair: Dan
> Team contact: Mike
> Known regrets: Jo
> Scribe: volunteers needed
> 
> Agenda:
> 
> 
> 1. Task Force Reports
>     - content transformation (Rhys?)
>       (Please review the draft problem statement)
> 
> 2. Plans for Seoul
>     - First week of March?
> 
> 3. mobileOK Basic Tests 1.0 - final review and approval
>     - do we need a "conformance" section? (Process issue - Mike please

> take note.)
> 
> 4. Reminder on Boston
> 
> 5. Agenda for Boston
> 
> 6. AOB
> 
> 
> Logistics:
> 
> Thursday 20 September 2007
> 
> 7:00 PDT; 10:00 EDT; 15:00 BST; 16:00 CET; 17:00 Helsinki; 23:00 Tokyo
> 
> Zakim bridge: tel:+1 617 761 6200 Code: 2794 (BPWG) Also
> (tel:+33 4 89 06 34 99 tel:+44 117 370 6152)
> 
> irc://irc.w3.org:6665#BPWG
> 
> Sorry for the lack of links - this agenda prepared on a mobile 
> devices.
> --
> Daniel K. Appelquist
> +44 7748 111635
> daniel.appelquist@vodafone.com
>

Received on Monday, 24 September 2007 07:58:28 UTC