RE: Content Transformation Guidelines 1r

My comments:

1) What is the significance of the "Revision Description" heading before
the table of contents?

2) Section 2.2 (2.a): The last sentence in the "Restructuring content"
paragraph is repeated twice.  ("It also include rewriting URIs...")

3) Section 3.3: Add "not recommended" as discussed on last week's call.

4) Section 3.4: Probably should add "recommended" and "not recommended"
to the second paragraph, in addition to "should" and "should not".

5) Section 4.1.1: I think that the second sentence of the second
paragraph would read better with the parentheses.  ("A transforming
proxy may convert a HEAD request into a GET request in order...")

6) Section 4.1.2: In the note, the usual capitalization that I've seen
is "XMLHttpRequest" instead of "XMLHTTPRequest".

7) Section 4.1.5: In the first sentence there is the phrase: "...
proxies should not modify the values of header fields other than
User-Agent, Accept, Accept-Charset and Accept-Encoding header fields and
...".  The second instance of "header fields" can be removed.

8) Section 4.1.5.5: The second sentence should start "For example, *if*
the User-Agent header..."

9) Section 4.1.6.1: In the note, the second sentence should probably be
two sentences: "... memory limitations of early proxies.  Most modern
proxies ..."

10) Section 4.2.9: In response to the editorial note:  There's currently
no machine-readable way to claim that web page is mobileOK Basic right
now, right?  (Waiting on mobileOK Scheme and POWDER.)

11) Section 4.2.9: In the sentence between the bullet lists: Should be a
space between "may" and "take".

12) Section 4.2.9.1: In the note, should there be a comma after
"section"? ("Other than as noted in this section, the nature of
restructuring")

13) Section 4.2.9.2: In the first sentence, shouldn't 'Some proxy
deployments require that links in content are "rewritten" in order...'
be 'Some proxy deployments require that links in content *be*
"rewritten" in order...'?

14) Section 4.2.9.3: In the second paragraph of the note the last
sentence starts with "THe BPWG would like..." which should be "The BPWG
would like..."

15) Section G.1.2: "presence" is misspelled "rpesence".


Another note:

I'm still not sure what guidelines are saying about "user preferences"
since there appear (to me, anyway) to be some ambiguous statements in
the document.  In section 4.1.5.3, it says that:

"Proxies may offer users an option to choose to view a restructured
experience even when a Web site offers a choice of user experience."

and

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

Does this mean:

All sites should be, by default, rendered in mobile mode.  The user must
specify on a site-by-site basis which sites should be restructured.

or:

CT proxies should by default be in "mobile mode" for all sites, but the
user could choose to switch to "desktop mode" for all sites.

I thought we were taking the latter interpretation as specified in the
following resolution taken in Sophia:

RESOLUTION: if there is a blanket user preference asserted for any
specific representation option and multiple representations are found to
exist then the CT proxy server SHOULD inform the user of this fact and
provide the user with an option to change to one of the alternative
representations.

The other statement on user preferences is in section 4.2.2:

"Proxies must provide a means for users to express preferences for
inhibiting content transformation. Those preferences must be maintained
on a user by user and Web site by Web site basis."

It seems to say that if the user has chosen to display content in
desktop mode, there must be a way to view those sites in mobile mode on
a site-by-site basis.

Francois was not sure about this either.  See:
http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/0012.html.  I
don't think we ever clarified this.


Sean


-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
Behalf Of Jo Rabin
Sent: Sunday, June 07, 2009 4:19 PM
To: Public MWBP
Subject: Content Transformation Guidelines 1r

Hello folks, a new draft available, taking into account everything up to

the F2F.

You'll find it at

http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guide
lines/090607

Diff to previous versions linked from the doc itself.

Jo


Known Dangling ends:

a) Need to clarify that CT Dangling Ends

http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0167.html

have all been dealt with.

b) Jo's ACTION-934 Try to draft another doc to the TAG about D.1.3.2

c) Discuss Francois's ACTION-925 on testability of link rewriting

d) Discuss Eduardos's ACTION-929

e) Any resolutions after the F2F have not been dealt with yet.

Done:

1) Abstract - from Matt Womer

inter-work? And it needs rewording to reflect bumping CP stuff into an
appendix

http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guide
lines/090313#abstract

Rewritten omitting the reference to interworking

However, note that Eduardo's ACTION-929 has not been discussed yet.

http://www.w3.org/2005/MWI/BPWG/Group/track/actions/929


2) A few typos, from Francois

http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0108.html

3) ACTION-930 was a response to a crie-de-coeur from Rotan and has 
resulted in a new section in the introduction

Write something in the introduction about respect for CP prefernces, 
respect for user preferences and the CP's ultimate sanction on the 
degree of preference they are willing to accommodate

4) Resolutions from the 26th March (London F2F)

http://www.w3.org/2009/03/26-bpwg-minutes.html

(new section on "link rewriting")

RESOLUTION: In the following and in all subsequent discussions Link 
Rewriting is considered to include insertion of links and frame 
flattening and other techniques that introduce the "same origin" issue

RESOLUTION: Link rewriting is a form of transformation and at a minimum 
is subject to the same limitations as other forms of transformation 
described in this document

RESOLUTION: Proxies MAY rewrite links, where content transformation is 
permitted, providing that content domain origin distinctions are 
preserved by the proxy such that browsers accessing content via the 
proxy do not inappropriately misconstrue different content origins as 
being the same and inappropriately share cookies, or allow execution of 
scripts or do other things that cause security problems as a result of 
not knowing that different origins are involved

RESOLUTION: Since there doesn't appear to be a way in which the URI sent

to the User Agent can be manipulated to preserve security related to 
same origin policies it is permissible for a CT proxy to act on content 
in so that security is nonetheless preserved as adjudged by conformance 
tests that are to be researched. If no such security tests can be found 
then there cannot be conformance associated with link rewriting and it 
cannot be permissible for CT proxies to do so.

RESOLUTION: Include text on the following lines as a note under a 
section on Link Rewriting: "Link rewriting is always used by CT Proxies 
that are accessed as an origin server initially, e.g. which provide 
mobile-adapted web search and navigation to the web pages returned in 
the search results, or to which the browser is redirected through the CT

Proxy for adaptation of a web page. Link rewriting *may* be used by CT 
Proxies acting as normal HTTP proxies (e.g. configured or transparent) 
for the browser, but may not be required since all browser requests flow

through the CT Proxy."

RESOLUTION: Proxies must never transform https content unless a prior 
agreement has been reached with the specific origin server.

but

RESOLUTION: Interception of HTTPS and the circumstances in which it 
might be permissible is not a "mobile" question, as such, but is highly 
pertinent to our document. We are aware that interception of HTTPS 
happens in the network today. We think that interception of HTTPS is 
inherently problematic and may be unsafe. We'd like to refer to more 
general conformance criteria to protocol based signalling mechanisms to 
achieve this. Pending futher developments in this area the practice of 
intercepting HTTPS links is strongly NOT RECOMMENDED.

RESOLUTION: Add .mobi to the list of mandatory heuristics as it is a 
stronger indication of mobile intent than many of the content-types and 
DOCTYPEs already agreed - other URI patterns are more ambiguous as to 
their intent

ACTION-926: Inser sections under proxy decision to transform a. to 
specify SHOULD NOT in the presence of the features listed at 
http://www.w3.org/2009/03/10-bpwg-minutes.html and b. to include the 
current cullets listed as heuristics

RESOLUTION: We delete all non-normative heuristics and close issue-288

RESOLUTION: Close Issue-284

ACTION-927: To preface the first sentence in 4.1.5 with Aside from the 
usual procedures defined in [RFC 2616 HTTP]

RESOLUTION: Leave X-Device headers in as they add value and close
ISSUE-289

RESOLUTION: Accept Jo's editorial changes detailed in email 13 mar 2009

RESOLUTION: adopt the text as proposed by Eduardo and modified by Jo 
regarding X- prefix, we will register the header with IETF and close 
ACTION-912

ACTION-931 Insert informative text in the relevant appendix describing 
the use of 403 in declining to server content because of security 
concerns or whatever

ACTION-932 Specify what he means by the USer Agent editorial note under 
4.1.5 - really can't remember, note removed

ACTION-933 Propose text for section 5 referring to \"reasonable terms, 
timeliness, of access and so on, relating to the use cases of bug 
determinations, testing and so on

Received on Monday, 15 June 2009 19:58:16 UTC