RE: Scope of CT Guidelines

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

Jo


> -----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
to
> 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
scope
> of the CT guidelines extend to a true "service definition" for CT as
an
> 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
the
> 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
reason.

> 
> 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
dialogs,
> 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,
is
> 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
in
> 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
use
> case...": If this is the case, I recommend that the guidelines focus
on
> how the CT proxy can provide this service transparently to the user,
or
> with at most minimal direct user interaction with the CT proxy at the
> presentation layer. For example, to select preferences, the CT proxy
can
> 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
proxy
> 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
CT
> 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".
> 

Indeed.

> 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
the
> > initial CT guidelines should focus on a limited scope. To that
purpose
> I
> > suggest we limit the use cases to the three I mention below. There
is
> > 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
about
> 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
allow
> 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
directive
> 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
of
> 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).
User
> 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
stringent
> 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
proxy
> 
> > 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
to
> resolve where we want to go on some of the things you mention. Though
it
> 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
be
> 
> > bypassed for UA invoking TLS tunneling to the CP via the HTTP
Connect
> > 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
are
> > 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
case
> 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
approach
> 
> > 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
client
> > 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
the
> 
> > 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
bets
> > are off; it may ignore the new headers etc that are specified. If
you
> > accept that and my assumption (5), there are only three
combinations,
> > 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
the
> 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
will
> behave consistently with what we are trying to achieve, and that the
UA
> 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
should
> 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
the
> > 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
the
> > policy/value-added-service area, in which as I mentioned before, CP
or
> 
> > 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
like
> 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
content
> > 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
also
> 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
too
> > complicated for my taste.
> >
> > So I wonder if it's worth considering the question of repurposing
the
> > presentation separately from markup and formatting fixups?
> >
> > So far as presentation is concerned I think there's a relatively
small
> 
> > set of cases, though each of them undoubtedly has its own
complexity.
> >
> > 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
may
> > 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
ad
> 
> > 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
has
> 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
volume
> 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
of
> > meeting the proposed timescales for the deliverable, and of
addressing
> 
> > in a timely way the key point of the Task Force's existence - which
is
> 
> > 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