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

Lots to think about here.  My thoughts are inline below.

(I've only reacted to part of the resolutions below because I ran out of
time--I'll give my thoughts on the rest of them later.)

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

+1.  Sounds like a good idea since I was always a bit confused about
what parts of the document 3.2 applies to. I guess I reserve the right
to change my mind after I see the rewritten draft however.  (For
example, if there are too many caveats that impede the readability of
the document.)


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

+1.  I think it is OK to put this in 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

+1.  Yes, it is kind of redundant.


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

-1.  I think it is OK to mention terms and conditions of service.  Just
move this language into 4.1.2.  I don't think the mention of TOS is
stepping into policy matters--we're not telling the CT operators that
they must use TOS to get user consent.  We're just mentioning that this
is a possible (and probably rather common) way that user consent would
be determined.


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

I'm a bit confused about which algorithm we are talking about here.  Is
it this one:

<jo> Request resource with original headers
<jo> - If the response is a 406 response, re-request with altered
headers
<jo> (unless the 406 response contains no-transform).
<jo> - If the response is a 200 response,
<jo> -- if the response contains vary: User-Agent, an appropriate link
<jo> element or header, or no-transform, forward it
<jo> -- otherwise assess (by unspecified means) whether the 200 response
is a
<jo> bogus one
<jo> --- if it is not, forward it
<jo> --- if it is, re-request with altered headers

I thought that this was to be used for determining when to send altered
headers, not for allow/disallow lists.  (Although I see how it could be
used in this manner.)


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

In the F2F minutes it is mentioned that we wouldn't want this algorithm
to be normative (if I am thinking of the correct algorithm!).  It sounds
like that is what you are proposing.  Actually, specifying an algorithm
for allow/disallow lists sound suspiciously like we are stepping into
policy matters!


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

-1 for the above reasons.


> 
> 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 Monday, 30 June 2008 21:04:51 UTC