W3C home > Mailing lists > Public > public-bpwg@w3.org > June 2009

ACTION-981: user preferences

From: Eduardo Casais <casays@yahoo.com>
Date: Fri, 19 Jun 2009 08:00:03 -0700 (PDT)
Message-ID: <682793.10357.qm@web45011.mail.sp1.yahoo.com>
To: public-bpwg@w3.org


Review text and all references to user preferences and make editorial suggestion
on how to clarify, taking into account Sean's points at

The situation is even more confused than Sean suggested, since preferences are dealt
with in sections 1.4.2, 4.1.4,, 4.2.2, 4.2.3, 4.2.9,,, G.1.4.

The problem seems to originate in handling preferences at the request and at the 
response levels separately, whereas for end-users only complete transactions make

Overall, the meaning is as Sean presumed in his message, with a couple of ambiguities
to clear up as suggested hereafter.


In section, retructure the paragraphs as indicated below. This establishes
the fact that, in the absence of any explicitly stated user preference, the server
preferred representation is to be delivered to the terminal. The user can then 
restate the preference as "restructure", but in any case:
a) if there is an alternate representation, he must be given the choice to access it;
b) he must be given the choice to access the original content anyway (from

Proxies must assume that by default users wish to receive a representation 
prepared by the Web site. 

Proxies may offer users an option to override this default and choose to view a
restructured experience even when a Web site offers a choice of user experience.
If a user has made such a choice, then proxies may alter header field values when
requesting resources in order to reflect that choice, but must, on receipt of an
indication from a Web site that it offers alternative representations (see G.1.4.2
Indication of Intended Presentation Media Type of Representation), inform the user
of this fact and allow him to select an alternative representation. 

Proxies must assess whether a user's expressed preference for a restructured
representation is still valid if a Web site changes its choice of representations
(see 4.2.6 Receipt of Vary HTTP Header Field).


The adjustments to the text serves to make clear that individual inhibitions of 
transformations apply whenever the default is set to "transform":

Proxies must provide a means for users to express preferences for inhibiting content
transformation whenever this is has been set as the default behaviour by the user.
In this case, those inhibition preferences must be maintained on Web site by Web site
basis for each user. In the event of a transformed response, the behaviour in
applies anyway.

Proxies must solicit re-expression of preferences with respect to of a server if the
server starts indicating that it offers varying responses as discussed under 4.2.6
Receipt of Vary HTTP Header Field.


We keep the first sentence in as follows:

Proxies should assume that by default users wish to receive a representation 
prepared by the Web site. 

And add the following sentence at the end of the first paragraph in 4.2.2:

If the default proxy behaviour, in the absence of any explicit user preference, is
to transform content, then the user must have an additional option to specify a
blanket inhibition of content transformation for all sites.

The first variant is actually simpler and more consistent with the original intent,
hence preferable.


The second paragraph only mentions a single option -- akin to the infamous dialog
box "serious error, please click ok to continue", leaving no choice but to crash the

There must be another option, i.e. the possibility to abort the transaction.

If a proxy determines that a resource as currently represented is likely to cause
serious misoperation of the user agent, then it may advise the user that this is
the case and must provide an option for the user to continue with unaltered
content, and another one to abort the transaction.

A possibility to continue with an altered response would be inconsistent with the
first paragraph of 4.2.3, as well as sections, G.1.3, G.1.4.2, and would
hollow out the meaningfulness of no-transform directives.


Received on Friday, 19 June 2009 15:00:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:01 UTC