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

Content Transformation Guidelines 1r

From: Jo Rabin <jrabin@mtld.mobi>
Date: Sun, 07 Jun 2009 22:18:36 +0100
Message-ID: <4A2C2EAC.8060009@mtld.mobi>
To: Public MWBP <public-bpwg@w3.org>
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/Guidelines/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/Guidelines/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 Sunday, 7 June 2009 21:19:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:01 UTC