W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > July 2008

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

From: Sean Patterson <SPatterson@Novarra.com>
Date: Tue, 1 Jul 2008 11:53:31 -0500
Message-ID: <24889886D84B794A9259323D7354CF330683059B@novarrainet2.internalnt.novarra.com>
To: "Francois Daoust" <fd@w3.org>, "public-bpwg-ct" <public-bpwg-ct@w3.org>

Some more comments inline below.


> -----Original Message-----
> From: 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,
> 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
> completely, but that shouldn't prevent us from having a discussion on
> the mailing-list, should it? Feel free to react! The following
> 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
> the agenda for Tuesday's call shortly before the call.
> My view is that the whole current section 3.2 on Control of the
> 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
> them may still be agreed even if we want to keep a separate section
> this.
> Typically, the first part of the Control by users directly fits in
> 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,
> 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
> the algorithm-like thing we've agreed upon for 4.1.2 is "self
> In other words, Allow/Disallow lists could be used there to scope
> 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
> 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
> 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
> 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
> 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
> 4. Use the underlying idea to guide us when resolving conflicting
> 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
> 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
> 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,
> let's take a quick look at the list of things to address:
> a. how the CT proxy should react against specific user preferences
> 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
> 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
> for the purpose it would serve. Or we could maybe says that
> 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
> 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
> 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,
> 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
> Is the use of links sufficient? Needs further thoughts...

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

> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:29 UTC