New Draft 1x of Guidelines for Web Content Transformation Proxies

Hello Everyone

The moment you have all been waiting for has arrived. Be that as it may, 
a new draft is available [1] reflecting the resolutions taken at the F2F 
in December [2]. Notes on the changes follow below, diffs from earlier 
versions included in the document.

Jo

[1] 
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/100125.html

[2] http://www.w3.org/2009/12/10-bpwg-minutes.html

RESOLUTION: add a comment to sect 2.2 stating that these are generic 
concepts which we choose not to formalise further

(done)

RESOLUTION: Have the document make explicit, if it does not do so 
sufficiently already, that moral and legal questions are out of scope 
and that this group does not have the authority or expertise to comment 
one way or another about setting precedent or authorising any specific 
behavior or its absence - nor is such a task feasible in this group.

Added a paragraph under 1.3 Scope

Moral, legal and other similar questions are not in scope of this 
document. The BPWG does not have authority or expertise to comment one 
way or another about setting precedent or authorising any particular 
behavior or its absence.


RESOLUTION: Editor to add further text to scope section along lines of 
his earlier minuted statement and Eduardo's recapitulation of it above

Added a paragraph under 1.1 Purpose

It is stressed that this document is unlikely to be the last word on 
this topic. As noted below (1.3 Scope) it is out of scope to provide a 
thoroughgoing solution to control of transforming proxies, though that 
would appear to be needed. It is an attempt to improve a situation at a 
point in time where there appears to be disregard of the provisions of 
HTTP - and is primarily a reminder and an encouragement to follow those 
provisions more closely.

RESOLUTION: While complying with sects 4.1.5 and 4.2.6 proxies should 
avoid making repeated requests for the same resource.

RESOLUTION: In addition to above add a note to 4.1.5.1 stating that 
while HTTP does not prohibit repetition of GET requests servers find 
this troublesome and so it should be avoided

RESOLUTION: Rephrase previous resolution (In addition to above add a 
note to 4.1.5.1 stating that while HTTP does not prohibit repetition of 
GET requests servers find this troublesome and so it should be avoided) 
to talk about places an unnecessary load on the network and server and 
not 'troublesome'.

replaced current 4.1.5.1 - "The theoretical idempotency of GET requests 
is not always respected by servers. In order, as far as possible, to 
avoid misoperation of such content, proxies should avoid issuing 
duplicate requests and specifically should not issue duplicate requests 
for comparison purposes."

with

While complying with this section 4.1.5 Alteration of HTTP Header Field 
Values and 4.2.6 Receipt of Vary HTTP Header Field proxies should avoid 
making repeated requests for the same resource.

Note:

While HTTP does not prohibit repetition of GET requests, repeated 
requests place an unnecessary load on the network and server.

RESOLUTION: Remove scoping statements from 4.1.1 and 4.2.1.

4.1.1 removed "Proxies should not intervene in methods other than GET, 
POST, HEAD."

Removed: 4.2.1 Applicable Responses

Proxies should not intervene in the response if the request method was 
not HEAD, GET or POST.

RESOLUTION: replace final paragraph in 4.1.5.2 with "A proxy MUST NOT 
reissue a POST request as it is unsafe (see section 9.1.1 of RFC 2616)"

done

RESOLUTION: add a bullet point to 4.2.9 for "content that is data - 
[appendix with list of data mime types]"; application/json ; 
application/soap+xml ; application/soap+fastinfoset ; 
application/fastsoap ; application/fastinfoset

RESOLUTION: ref. LC-2269, resolve yes, and note that we have added a 
bullet point under 4.2.9, an appendix and a reference in 4.1.3 to 
address this situation

RESOLUTION: Add the above-mentioned cautionary note to all applicable 
appendices

4.1.3 now reads:

Before altering aspects of HTTP requests and responses proxies need to 
take account of the fact that HTTP is used as a transport mechanism for 
many applications other than "Traditional Browsing". Increasingly 
browser based applications involve exchanges of data using 
XmlHttpRequest (see 4.2.8 Proxy Decision to Transform) and alteration of 
such exchanges is likely to cause misoperation.

added bullet to 4.2.8 (was 4.2.9):

the Content-Type indicates that the content is "data" - some values are 
listed in D Internet Content Types associated with Data Content;

Added Appendix

D Internet Content Types associated with Data Content
This list is not exhaustive and is likely to change.

application/jsonapplication/soap+xmlapplication/soap+fastinfosetapplication/fastsoapapplication/fastinfoset

Added cautionary note to Appendices C and E

RESOLUTION: Add a section under J saying that a standard mechanism for 
establishing two party consent (that the server must have a possibility 
to negotiate or deny HTTPS link rewriting) as discussed under 4.2.9.3 is 
needed.

New Appendix: K.5 Explicit Consent
Robust mechanisms are needed for indicating consent to or prohibition of 
transformation operations of various kinds, especially HTTPS link 
rewriting (see 4.2.8.3 HTTPS Link Rewriting).


RESOLUTION: ref. LC-2317, resolve yes, and add a definition of user 
interaction that mentions the communication channel. Exact wording to be 
defined by the Editor. This definition should be used in all the 
guidelines that mention user interaction similarly to Rotan's proposal 
in http://lists.w3.org/Archives/Public/public-bpwg/2009Dec/0008.html

Added 2.3 under Terminology

2.3 User Interaction
At various points in this document there is reference to "notifying the 
user", "informing the user" - in general making the user aware that a 
situation exists or interacting with the user to solicit a choice of 
options. The expectation is that such user interaction is conducted in a 
way that allows the suer to perceive and interact with such information 
or choices in the same way as they interact with the Web sites that they 
are visiting.

RESOLUTION: re LC-2318 resolve yes and add text to clarify

Added the following note under 4.1.5

Note:

It is emphasized that requests must not be altered in the presence of 
Cache-Control: no-transform as described under 4.1.2 no-transform 
directive in Request.

RESOLUTION: replace bullet 4 of 4.1.5 with: 3. the request is part of a 
sequence of requests comprising either included resources or linked 
resources on the same Web site (see 4.1.5.4)

(sic)

RESOLUTION: Remove 2nd para of 4.2.3 and adjust end of first para to suit

(sic)

RESOLUTION: In re LC-2319, resolve yes and modify the text to say Other 
than the modifications required by RFC 2616

4.1.5 "Aside from the usual procedures defined in [RFC 2616 HTTP] 
proxies should not ..."

changed to suit.

RESOLUTION: in re LC-2322 - add to 4.2.7, in parentheses, If the user 
agent is determined as being "handheld"

done

RESOLUTION: Change "the user agent has features (such as linearization 
or zoom) that allow it to present the content unaltered;" to "the user 
agent has features (such as linearization or zoom, is a desktop device 
using a mobile network for access) that allow it to present the content 
without the need for alteration by the proxy;"

done

Received on Monday, 25 January 2010 13:28:39 UTC