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

RE: Scope of CT Guidelines

From: Jo Rabin <jrabin@mtld.mobi>
Date: Mon, 29 Oct 2007 10:29:25 -0000
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B484F3D7@mtldsvr01.DotMobi.local>
To: <public-bpwg-ct@w3.org>

Hi Bryan

Think this is really useful to help shape the document. Others should of
course feel free to add their voices!

Further thoughts below


> -----Original Message-----
> From: Sullivan, Bryan [mailto:BS3131@att.com]
> Sent: 29 October 2007 05:41
> To: Jo Rabin; public-bpwg-ct@w3.org
> Subject: RE: Scope of CT Guidelines
> Jo,
> Based upon your responses I think I better understand your objectives
> for the CT guidelines. Here are some further comments:
> Re "...it's about what is acceptable behavior in the absence of HTTP
> based control, and indeed perhaps what should be done outside of HTTP
> allow the user to exert some control": First I think we need to define
> the criteria for "acceptable". I take from your statement that the
> of the CT guidelines extend to a true "service definition" for CT as
> end-to-end service. That would be an ambitious goal, since it could
> include e.g. presentation-layer guidelines on when and how to present
> options to the user, with presumably some statefulness, to avoid
> repeating the options selection each time a page is accessed. In
> extending to such a scope, care would need to be taken to balance the
> desire for a specific vision of this "service", without restricting CT
> product differentiation and innovation, or the roles of the various
> actors involved in the service.
Yes agreed. If we did go down the route of saying that people should be
offered a choice I don't think we'd want to specify how that choice is
offered - though we would need to know that it was feasible to do so.

> On the ability of the CT proxy to "just say no", I agree it's a little
> more complicated that I stated. But this statement was meant to test
> result of the earlier discussion around my comments re policy control
> functions of CT proxies. So I think we agree there are cases in which
> the CT proxy can differ with the requests of the CP or user. You could
> consider error correction (e.g. even extending to normal "tidy"
> operation) as a policy of the CT proxy, if it improves the
> interoperability of the service. This policy could override a CP's
> request for no-transform for errored content, and leave some parts
> untouched or at least not functionally modified (e.g. as in tidy).

Yes, I think we need a fair amount more discussion on this point; I
think that there should in fact be an option to "just say no" which
people are encouraged not to use unless strictly necessary - e.g. that
they know they are sending broken markup, but are doing so for a good

> Consent is a much more complicated issue. From a usability and
> reliability view, consent at T&C time (service agreement) is the best
> approach. Frequent requirements for explicit consent will drive users
> away very fast (how many people blindly click past interstitial
> and will seek more usable services if the interruptions don't diminish
> e.g. though server recording of their preferences). Further, Service
> Providers are responsible for the overall quality of experience, and
> often have to presume some consent on behalf of the user (e.g. to
> correct content errors) as this is by "request of the user" in seeking
> an overall reliable service.

I'm not sure I understand what you mean by Service Provider in this
context. If I have a relationship with a Content Provider from the
desktop and use them to download content that I transfer to my mobile
which I then use to get to their mobile Web experience, the access needs
to be seen in the context of that relationship, rather than a
relationship with the provider of my broadband or mobile connectivity.  

> On the policy control functions (e.g. content insertion/editing and
> optimization), we need to be clear about the objectives. For example,
> the objective to improve the usability of the content, or to specify
> when/how to layer in additional value-added services (this may extend
> the scope into problematic areas, e.g. those already/being considered
> other SDO's).

Yes, we do need to be clear.

> Re "The case in which the UA and CP are both unaware is the primary
> case...": If this is the case, I recommend that the guidelines focus
> how the CT proxy can provide this service transparently to the user,
> with at most minimal direct user interaction with the CT proxy at the
> presentation layer. For example, to select preferences, the CT proxy
> include "switch to mobile" or "switch to desktop" links in a
> header/footer. More sophistication than that (e.g. providing
> interstitial menus of options) will burden the user and complicate the
> guidelines.
> On Non-web UA/applications, there are many non-web HTTP clients that
> extend the RFC2616 HTTP methods or use other HTTP extensions such as
> specialized status codes, headers, etc. However if we assume that the
> scope of the CT guidelines are addressing primarily web browsers,
> non-web UA/applications are less of an issue. What I meant by the
> assumption is that non-web UA/applications are typically configured to
> bypass proxy services for various reasons, including the fact that
> non-transparency issues do occur or the more basic fact that the proxy
> likely provides little if any value-added service to the non-web
> UA/applications (thus proxy providers, e.g. Mobile Network Operators,
> have a vested interest in ensuring the non-web UA/applications are
> pre-configured to bypass the proxy, if only for capacity reasons).
Right, but the problem today is that there are Java apps out there that
are being thwarted from fulfilling their purposes because a transcoding
proxy has been introduced and is interfering with their communication
with the server.

> Re "Is it possible or desirable to distinguish the routing or
> transformation options on the basis of URIs?": not typically possible,
> as mobile browsers (usually) do not selectively control their proxy
> settings. Thus the CT proxy may have to keep an untransformed copy of
> the original content and serve it locally (thus the URI will be
> different from the original content URI). Note this implies a fairly
> considerable cache requirement on the CT proxy, so alternatives should
> be considered (e.g. the original URI is included as a parameter to a
> proxy URI, and upon requests to this URI the CT proxy retrieves the
> content referenced by the parameter... But this also may break some
> services so it's not a perfect solution either).
> I am interested to see to what extent we can reliably specify "crude
> control of an "unaware" proxy".


> Best regards,
> Bryan Sullivan | AT&T | Service Standards
> bryan.sullivan@att.com
> -----Original Message-----
> From: public-bpwg-ct-request@w3.org
> [mailto:public-bpwg-ct-request@w3.org] On Behalf Of Jo Rabin
> Sent: Thursday, October 25, 2007 1:51 AM
> To: public-bpwg-ct@w3.org
> Subject: RE: Scope of CT Guidelines
> Hi Bryan
> Interesting thoughts. Some comments interspersed among your text.
> Jo
> > -----Original Message-----
> > From: public-bpwg-ct-request@w3.org
> [mailto:public-bpwg-ct-request@w3.org]
> > On Behalf Of Sullivan, Bryan
> > Sent: 24 October 2007 09:14
> > To: public-bpwg-ct@w3.org
> > Subject: RE: Scope of CT Guidelines
> >
> >
> > Here is my initial input. Overall I agree with Jo's proposal that
> > initial CT guidelines should focus on a limited scope. To that
> I
> > suggest we limit the use cases to the three I mention below. There
> > still plenty of variation around that e.g. the available
> > representations, who selects them, etc.
> >
> > First, some assumptions:
> >
> > 1) The focus of the CT guidelines is to enable HTTP-based control of
> CT
> > for wired web content usability (which includes compatibility and
> > effectiveness) by mobile UA.
> Yes, it's good to be clear about this. I agree that it is in part
> control, but perhaps more importantly, in the first instance at least,
> it's about what is acceptable behaviour in the absence of HTTP based
> control, and indeed perhaps what should be done outside of HTTP to
> the user to exert some control.
> E.g. if my web browser and the site I am accessing know nothing about
> the niceties of the CTTF-defined HTTP stuff, and this is the starting
> point use case, then we might chose to say that the user SHOULD be
> presented with a choice.
> >
> > 2) Given user consent for service via a CT proxy for usability
> purposes,
> > it's expected that a CT proxy will have no reason to violate a CP or
> > user agent directive related to the CT service, even if the
> is
> > incorrect and results in a poor user experience.
> >
> I think that's yet to be decided. Firstly what do we mean by user
> consent? Is it sufficient for their consent to be buried in the terms
> service of their network provider? What can they do on a case by case
> basis about altering that consent?
> Also I think we have yet to decide what to do in cases like:
> Server sends dangerous markup (in the sense that a proxy thinks this
> will trigger a bug in the UA that results in massive misoperation).
> says that in such cases they want the markup fixed. CP says that their
> content is not to be altered under any circumstances (that what I take
> "no-transform" to mean, because I the server think you the proxy don't
> know as much as I do - and this I think implies we need a less
> value to mean that content should not in general be altered but may be
> at the request of the user).
> > 3) There are other roles for CT proxies, but they are not covered by
> > this guideline. They include CT functions related to generic policy
> > control (e.g. content filtering), content (e.g. ad) insertion,
> > optimization, etc. For these roles there are cases in which a CT
> > may violate Content Provider (CP) or user agent directives, thus
> > negotiation or at least error handling may apply in those cases.
> Well, I'm not clear that it is as clear cut as that. I think we need
> resolve where we want to go on some of the things you mention. Though
> seems clear to me that we are not in the business of filtering, we
> probably do need to say things about ad removal and insertion. And we
> almost certainly, in my view, need to say things about optimization.
> >
> > 4) For secure services (HTTPS), the CT proxy service would normally
> > bypassed for UA invoking TLS tunneling to the CP via the HTTP
> > method. Alternatively, the CT proxy can rewrite CP URLs as local
> > resources (recreating the WAP gap!), but this may not be acceptable
> for
> > some CP. Thus unless the CT proxy rewrites CP URLs, it can have no
> role
> > in CT for secure services.
> I think that is a possible conclusion, however I think the group would
> need to discuss and resolve this.
> >
> > 5) The CT guidelines will focus on CT control and thus assumes at
> least
> > one of the CP or UA is CT-aware. The case in which both CP and UA
> > CT-unaware will be typical for years to come, but this is
> > business-as-usual for CT proxies.
> >
> The case in which the UA and CP are both unaware is the primary use
> and I think that is the one we are most worried about.
> > 6) CT proxies will typically be inserted into the request path by
> > UA/application configuration or network routing. Non-web
> UA/applications
> > will typically be configured to bypass CT proxies. If required,
> > detection of non-web UA/applications will likely use the same
> > as for CT-unaware UA detection, e.g. UA header filtering.
> I'm not sure I understand this point. Non-Web applications typically
> simulate Web applications in order to borrow the Web application's
> transport/connectivity.
> >
> > Re in "Magnus's original contribution"
> > http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Sep/0014.html
> > "The content transformation proxy needs to be able to tell the
> > browser...where to find the original content if it has been
> > transformed.": It seems this would be of no use to the UA unless it
> can
> > selectively bypass the CT proxy. As well, the original request URI
> > should be the same as the location of the original content, unless
> > CT proxy is rewriting the URLs.
> Interesting point. Is it possible or desirable to distinguish the
> routing or transformation options on the basis of URIs?
> >
> > Re Jo's email:
> > "in theory at least there are 64 different combinations of
> aware/capable
> > component types in the delivery chain":
> > I think we should assume the CT proxy is CT-aware. Otherwise all
> > are off; it may ignore the new headers etc that are specified. If
> > accept that and my assumption (5), there are only three
> > i.e.
> > - CT-unaware CP, CT-aware UA
> > - CT-aware CP, CT-unaware UA
> > - CT-aware CP, CT-aware UA
> I think we need to examine what happens in cases where the proxy is CT
> unaware. That probably means making sure we scrutinise RFC 2616 for
> bits that say that proxies MUST pass unchanged ... etc. and hope that
> there aren't other bits of HTTP that we didn't spot that contradict
> that. Having done that we can be confident that a conforming proxy
> behave consistently with what we are trying to achieve, and that the
> and CP will both be aware of the proxy's presence, aware that it is CT
> unaware, but be unsure as to whether it is transformation capable. By
> borrowing existing bits of HTTP like "no-transform" the UA and CP
> still be able to exert crude control of an "unaware" proxy, assuming
> that it is RFC 2616 conformant.
> >
> > Case 3 "Client goes ahead and simulates desktop...this could land
> > user in a delay and cost nightmare...":
> > UA that attempt to simulate desktops should support advanced HTTP
> > features such as persistent connections and multiple outstanding
> > requests. Other than that, I think it should be outside (these) CT
> > guidelines scope to address optimization. That begins to get into
> > policy/value-added-service area, in which as I mentioned before, CP
> > UA directives may be violated by the CT proxy.
> And as I mentioned above, I'm not clear exactly what represents a
> deciding line for "policy" related issues. Also I think that things
> Opera Mini / Onspeed whatever need to be considered in this context.
> >
> > Best regards,
> > Bryan Sullivan | AT&T | Service Standards bryan.sullivan@att.com
> > -----Original Message-----
> > From: public-bpwg-ct-request@w3.org
> > [mailto:public-bpwg-ct-request@w3.org] On Behalf Of Jo Rabin
> > Sent: Tuesday, October 23, 2007 10:12 AM
> > To: public-bpwg-ct@w3.org
> > Subject: Scope of CT Guidelines
> >
> >
> > I thought it worth making a note and stimulating further discussion
> > following today's productive CT TF call.
> >
> > I'm worried that if we step into the space of how to do 3 way
> > negotiation we will be opening the lid on Pandora's box.
> >
> > The starting point, I think, is that there are three types of
> component,
> > server, proxy and browser. Each of those can be capable of
> > transformation. Add to this that each of them will independently
> be
> > aware or unaware of whatever our guidelines state about how to
> > cooperate. So in theory at least there are 64 different combinations
> of
> > aware/capable component types in the delivery chain. That's a bit
> > complicated for my taste.
> >
> > So I wonder if it's worth considering the question of repurposing
> > presentation separately from markup and formatting fixups?
> >
> > So far as presentation is concerned I think there's a relatively
> > set of cases, though each of them undoubtedly has its own
> >
> > Case 1.
> > a) the Server has only a desktop oriented presentation only
> > b) the browser has mobile presentation only
> >
> > A proxy may have a useful role in re-presenting the content.
> >
> > Note though, that in this case, the server's desktop presentation
> > actually be a universal presentation (call my web pages boring but
> they
> > are designed to render across all delivery contexts) so in that case
> the
> > proxy should not interfere either.
> >
> > Case 2.
> > a) The Server has both a mobile and a desktop experience
> > b) Client has mobile experience only
> >
> > Server presents mobile experience. Proxy stays out of the way.
> >
> > Case 3.
> > a) The Server has a desktop oriented presentation only
> > b) Client can simulate desktop
> >
> > Client goes ahead and simulates desktop
> >
> > (There is an argument that says that this could land the user in a
> delay
> > and cost nightmare. So is that an argument against the concept of
> > simulating desktop on a mobile, or is it an argument for saying that
> > there is a role for transforming proxy to reduce that delay and cost
> > nightmare?)
> >
> > Also same case as in 1, where the server has a single presentation,
> but
> > that presentation is suitable across the board.
> >
> > Case 4.
> > a) The server has a choice of presentations
> > b) The client has a choice of presentations
> >
> > The user should be able to get either i) the mobile presentation ii)
> the
> > simulated desktop presentation. That choice may be triggered by
> > selection locally to the client or at the server.
> >
> > Case 5.
> >
> > Although this looks like a Web request, in fact it isn't. It's some
> > hoc protocol xmlhttprequest-like thingy.
> >
> > (Proxy leaves well alone)
> >
> > I'm assuming that this is a more of less complete list of scenarios
> > where the presentation is adjusted at most once.
> >
> > Now I think that we can consider on top of this whether the proxy
> a
> > role adjusting not the presentation, but details of the formatting -
> > e.g. to tweak the content type header, or to tweak the DOCTYPE to
> avoid
> > problems. Possibly to re-render images from one format to another.
> >
> > To my mind, that is almost certainly enough to do deal with in
> 1
> > of the guidelines. I think we should leave the door open to later
> > elaborations that discuss 3 way content negotiation, servers
> > deliberately delegating formatting or presentation tasks to proxies
> and
> > so on. However all that falls firmly in a volume 2.
> >
> > I'm hoping that by restricting the initial scope we stand a chance
> > meeting the proposed timescales for the deliverable, and of
> > in a timely way the key point of the Task Force's existence - which
> > to provide a way for Transforming Proxies to get out of the way of
> > mobile ready content.
> >
> > Hope this makes sense and looking forward to comments.
> >
> > Jo
Received on Monday, 29 October 2007 10:30:07 UTC

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