Re: Content for ACTION-666

Hi Aaron,

Thanks for this!
It arrived just a couple of hours too late for discussion in Seoul, but 
it's on the agenda for tomorrow's discussion.

See my remarks inline.

François.


Aaron Kemp wrote:
[...]
> 2.5.1 Control by the User
> Transforming proxies SHOULD provide to their users:
> 
>   - An indication that the content being viewed has been adapted for
> mobile presentation.  If the content has not been modified, because of
> server or user preferences, but transformation is possible and
> potentially useful, the proxy MAY indicate that a transformed version
> is available.  [Aaron Kemp: This is a direct contradiction of section
> 3.1.1, which I think we should talk about.]

What do you mean in practice?
- The CT-proxy may add a link to an otherwise-unmodified response.
- The CT-proxy may first return a page with two links that say:
"I plan not to transform anything although it may be useful, click here 
to see the untransformed page, or here to see the transformed version of it"

The first case indeed is in contradiction of what one may think is an 
unmodified version of a page. The second case is probably less in 
contradiction of section 3.1.1 (provided we allow an intermediary 
response to be returned in lieu of the regular one) since the real 
response will be returned intact in the end, but clearly is awful in 
terms of user experience :(

Viewing the CT-proxy as an intermediary as agreed, I tend to think such 
a link MAY be added to pages the CT-proxy *decides* not to transform 
(because the page looked OK), but MUST NOT be added to pages the 
CT-proxy *could not* transform (because it received a Cache-Control: 
no-transform directive).

But, again, from the user experience's point of view, this approach does 
not provide a consistent behavior as there's no way a user may 
understand why the link sometimes is there, and sometimes isn't there. Argh!


>   - An option to view the original, unmodified content.  Ideally, the
> original content will be retrieved from cache whenever possible to
> eliminate a second request to the origin server.

Just thinking aloud, should we include some examples here (also work for 
the content tasting paragraph actually) as to why a second request may 
be harmful? Such as:
1/ one must not POST data more than once
2/ GET requests are sometimes (though incorrectly as far as web "spirit" 
applies) used as POST requests and thus, well, see 1/
3/ it makes it harder for content providers to count stats.


> [Aaron Kemp: I'd like to add something like this:
> 
> A transforming proxy MAY offer additional "sticky" preferences to
> their users, such as the ability to ignore preferences set by a server
> that could cause their phone to malfunction.
> 
> ...but I don't imagine that will be well received?]
> 
> 2.5.2 Control by the Origin Server
> Transforming proxies MUST provide support for control over the content
> transformation process by origin servers.
> 
> These control mechanisms are detailed in section 3 (Behavior of Components).
> 
> In situations where the origin server's preferences and the user's
> preferences disagree, the user's SHOULD take preference.  [Aaron Kemp:
> This is my opinion, and I'm sure it isn't shared by everyone.  I do
> believe we should indicate whose preferences win, one way or another.]

We resolved in Seoul's F2F that:
"in matters of presentation, the Content Provider's preference should 
take preference over user's preference, but user should be able to exert 
a high-priority override over the content provider's preference if desired."
http://www.w3.org/2008/03/04-bpwg-minutes.html#item58

In other words: if a user explicitly wants to override the CP's 
preferences, he can.

I would say your text goes in the same direction...


> 
> 2.5.3 Control by Administrative or Other Arrangements
> The preferences of users and of servers MAY be ascertained by means
> outside the scope of this document.
> -------
> 
> Unfortunately I won't be at the F2F, but I plan to lurk on IRC as much
> as possible.
> 
> Thanks
> Aaron
> 
>

Received on Monday, 10 March 2008 15:39:19 UTC