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

Some more comments inline below.

Sean

> -----Original Message-----
> From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org]
> On Behalf Of Francois Daoust
> Sent: Friday, June 27, 2008 11:04 AM
> To: public-bpwg-ct
> Subject: 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
> 

0.  I kind of like having this section in the document, but if it is
well integrated into section 4, I think I would be OK with the change.


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

The origin server can tell that the request has passed through a CT
proxy from the Via header and the X-headers.  When the origin server has
a new mobile version of the site that it does not want transformed it
can inform that CT proxy using a 406 and the Vary header.


> 
> 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?
> 

Default should be mobile unless the user expresses a preference for
desktop, in which case desktop would be the default, correct?


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

If the origin server has its own restructured version of the content
that it wants to present it can use the method for a. above.


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

+1.  Seems like a good clarification.


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

Could mention LINK tag.  Leave other methods and heuristics to CT
vendors.


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

I agree that it seems fairly obvious (is it a preference if you can't
change it?).  Maybe mention that there should be a way to change
preferences while leaving how it is done undefined.


> 
> HTH, have a nice week-end.
> Francois.

Received on Tuesday, 1 July 2008 16:54:16 UTC