Re: Control of the Behavior of the Proxy and ISSUE-242

Coo. Complicated stuff for a Friday afternoon. Thanks Francois.

I'm afraid I won't be on Tuesday's call as I am travelling.

Jo

On 27/06/2008 17:04, Francois Daoust wrote:
> 
> 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 17:09:56 UTC