Control of the Behavior of the Proxy and ISSUE-242

Hi guys,

Trying to rationalize the remaining issue, I thought a bit about it, and 
proposes the following potential resolutions to narrow the issue back 
to, well, what it was before I widened it to the whole section 3.2...

I still think we should wait for the updated draft to resolve the issue 
completely, but that shouldn't prevent us from having a discussion on 
the mailing-list, should it? Feel free to react! The following "PROPOSED 
RESOLUTION" are entitled as such so that they may be easily seen, but 
they only represent a consensus between me and myself...

I propose we have a short call next Tuesday to see if there's some 
consensus to move forward on this. Note I'm off on Monday, and will send 
the agenda for Tuesday's call shortly before the call.

My view is that the whole current section 3.2 on Control of the Behavior 
of the Proxy should rather be incorporated explicitly where needed in 
section 4. I thought otherwise before the F2F, but changed my mind on 
the lights of the discussions and progress we made during the F2F. It 
would be by far clearer if controls are explicitly listed along the 
guidelines.

PROPOSED RESOLUTION: goal is to integrate bits of current section 3.2 
explicitly into current section 4, where ever they apply, for 
clarification purpose.

This is at the heart of the following proposed resolutions, but part of 
them may still be agreed even if we want to keep a separate section for 
this.


Typically, the first part of the Control by users directly fits in 4.4: 
it's a guideline to be applied to the HTTP response.

PROPOSED RESOLUTION: Move first bullet list in section 3.2.1 
"Transformation proxies SHOULD provide to their users" to section 4.4.


The part on Content Providers is mostly a placeholder that links to 
section 4. I guess we can just drop it.

PROPOSED RESOLUTION: drop section 3.2.2, since it's already explicitly 
explained in section 4


Control by Administrative arrangements is probably more controversial. 
Jo's point about not stepping into policy matters at the beginning of:
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0039.html
... is a good point, IMO.

PROPOSED RESOLUTION: drop mention of terms and conditions of service, as 
we should not be stepping into policy matters.


Allow/disallow lists should not be removed, IMO. They do serve a 
purpose. But as Jo, again!, pointed out further down in the above email, 
the algorithm-like thing we've agreed upon for 4.1.2 is "self healing". 
In other words, Allow/Disallow lists could be used there to scope bogus 
200 responses, but that does not prevent the CT-proxy from running the 
algorithm and overriding/updating these lists from time to time if the 
response it receives from server evolves. I think we don't need to 
precise this "from time to time". If we want to be more precise, then we 
could be strict and say that the TTL (time to live) of entries is the 
one of the HTTP response (as defined in regular cache control directives).

Neither do we need to precise the mechanisms by which these 
Allow/Disallow lists are created, IMO. But we should keep the note we 
already have in section 3.2.3 about the intractability problem such 
lists entail.

This yields to the following...

PROPOSED RESOLUTION: Allow/Disallow lists may be used to scope bogus 200 
responses in 4.1.2, provided that the CT proxy refreshes the status of 
each entry periodically using the algorithm in 4.1.2. No mention of how 
such lists need to be created. Move the existing note on intractable 
problems that is currently in 3.2.3 to 4.1.2.


... concluded by

PROPOSED RESOLUTION: drop section 3.2.3 based on the two above resolutions.


Eventually, anticipating that we'll be able to identify the remaining 
conflicting cases in the updated draft, and address them correctly, I 
suggest we just drop section 3.2.4, and use its "spirit" to guide us 
while addressing the conflicting cases that are about to arise...

PROPOSED RESOLUTION: drop section 3.2.4 on the grounds that if we're 
explicit, then conflicting cases will be explicitly mentioned in section 
4. Use the underlying idea to guide us when resolving conflicting cases 
in Section 4


Where would that leave us?
Well, actually, this would leave us with the exact initial topic of the 
issue: persistent expression of user preferences, the second point in 
current section 3.2.1

We've already resolved that the CT-proxy SHOULD inform the user when 
multiple representations of a resource are found when the user has 
specified a blanket preference for a desktop-oriented presentation.

In the end, I don't think we should prevent any persistent expression of 
user preferences, but other resolutions that would go in the same 
direction as the above mentioned ones are probably needed. An updated 
draft would be indeed pretty useful to address this remaining point, but 
let's take a quick look at the list of things to address:

a. how the CT proxy should react against specific user preferences when 
a site becomes more capable

I guess it could be difficult to define "more capable". Basically, we 
could require that the CT-proxy records the user's choice for a given 
web site to always serve the desktop-oriented version along with some 
statement on the mobile-friendliness of the web site in question. If the 
server becomes more mobile-friendly capable, then the CT-proxy should 
inform the user. How does that sound? I would say it's a bit too complex 
for the purpose it would serve. Or we could maybe says that "persistent" 
should be synonym to a limited lifetime (a week?, a month?)

PROPOSED RESOLUTION: persistent is not infinite. The user should be 
prompted from time to time to confirm any persistent preference for a 
particular representation.


b. that the default experience should be for the mobile experience

I guess we should simply say that the default setting should be "no" 
setting. In that case, 4.1.2 applies, and the mobile experience 
prevails. Does that really need to be mentioned though?


c. that blanket expression of preferences should be interpreted in the 
context that if an origin server can provide a choice of experience then 
it should do so

Tricky. Links to e. below.


d. that CT proxies should, in restructured content, provide links to 
alternative representations

I suppose we don't want to include a "print" alternative representation 
in there, but it seems to be a good proposed resolution otherwise...

PROPOSED RESOLUTION: in restructured responses, if alternative 
representations of media type screen and/or handheld are available, the 
CT-proxy SHOULD provide links to the alternative representations.


e. how would a CP indicate to a CT Proxy that it offers user choice of 
representation?

Is the use of links sufficient? Needs further thoughts...


f. allow users to change previously expressed preferences

Doesn't this go without saying? It seems to be stepping into the 
detailed behavior of a CT-proxy.


HTH, have a nice week-end.
Francois.

Received on Friday, 27 June 2008 16:05:14 UTC