- From: Francois Daoust <fd@w3.org>
- Date: Tue, 18 Mar 2008 17:34:10 +0100
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hi again,
These are the minutes of today's call:
http://www.w3.org/2008/03/18-bpwg-minutes.html
... copied as text below.
Resolutions agreed during the call:
- remove "If the proxy has transformed (reformatted) the content but not
rewritten https links, it should annotate those links to indicate that
transformation service is not available on them." in 3.1.4
- given that the link "in some circumstances" is fixed [in 1.2], leave
the text for ACTION-634 as it is in 1.2 and 3.2
- keep Martin's text for 3.1.1 intact but continue discussion on
Ajax/XHR requests and the like
Thanks,
François.
18 Mar 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0007.html
See also: [3]IRC log
[3] http://www.w3.org/2008/03/18-bpwg-irc
Attendees
Present
francois, kemp, rob, hgerlach, MartinJ, SeanP, Magnus,
Bryan_Sullivan, AndrewS
Regrets
Jo
Chair
francois
Scribe
rob
Contents
* [4]Topics
1. [5]Reminder - actions
2. [6]HTTPS rewrite (in §3.4)
3. [7]no-transform and WAP gateways (in §1.2 and §3.2)
4. [8]Text for para 2 of 3.1.1 (ACTION-679)
* [9]Summary of Action Items
_________________________________________________________
Reminder - actions
<hgerlach> where can I find the action summary/list?
francois: seen lots of actions being completed and inputs to the
gaps coming in - thanks
<francois> [10]List of CT actions
[10] http://www.w3.org/2005/MWI/BPWG/Group/track/products/12
HTTPS rewrite (in §3.4)
<francois> [11]Andrew's text proposal
[11]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Feb/0026.html
francois: for today start with Andrew's contribution
<francois> [12]Jo's adaptation of Andrew's text
[12]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080313#sec-Proxy-Response
rob: just want to ensure that the user must not have to be asked
repeatedly if they want HTTPS adaptiong or not
kemp: doesn't explicitly state have to ask all the time
hgerlach: a cookie-like session persistence could work
<francois>
[13]http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-draf
ts/Guidelines/080313#sec-Proxy-Response
[13]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080313#sec-Proxy-Response
Bryan: the advice to the end-user can come out-of-band
... eg preferences set or terms accepted in advance
andrews: how can we "annotate those links to indicate that
transformation service is not available on them"?
... the important thing is in the para above. Annotation is not
required.
francois: Bryan, Rob, do you want to modify the "must advise" para?
bryan: no, I think the allowance for this advice being "out-of-band"
is already implicit so does not need repetition here
... do need to recall that there is the need for someone like an
e-wallet service provider to ban HTTPS re-writing on their domains
and dis-allow transformation.
martin: "must provide the option to avoid transformation of the
resources the links refer to" is only part of the story
<francois> ACTION: martin to propose some alternate text for HTTPs
rewrite and "must provide the option to avoid transformation"
[recorded in
[14]http://www.w3.org/2008/03/18-bpwg-minutes.html#action01]
<trackbot-ng> Sorry, amibiguous username (more than one match) -
martin
<trackbot-ng> Try using a different identifier, such as family name
or username (eg. mharris2, mjones4)
<francois> ACTION: jones to propose some alternate text for HTTPs
rewrite and "must provide the option to avoid transformation"
[recorded in
[15]http://www.w3.org/2008/03/18-bpwg-minutes.html#action02]
<trackbot-ng> Created ACTION-717 - Propose some alternate text for
HTTPs rewrite and \"must provide the option to avoid
transformation\" [on Martin Jones - due 2008-03-25].
martin: should it be "must provide the option to avoid interception
and/or transformation of the resources the links refer to" or
similar?
<andrews> I suggest that we remove this.
andrew: I suggest we remove the para on annotating links
<francois> PROPOSED RESOLUTION: remove "If the proxy has transformed
(reformatted) the content but not rewritten https links, it should
annotate those links to indicate that transformation service is not
available on them."
<SeanP> OK with me to remove it\
<kemp> +1
+1
<SeanP> +1
<andrews> +1
<Martin1> +1
<francois> RESOLUTION: remove "If the proxy has transformed
(reformatted) the content but not rewritten https links, it should
annotate those links to indicate that transformation service is not
available on them."
<francois> Close ACTION-633
<trackbot-ng> ACTION-633 Write a clear draft on
@@allow-https-rewrite and the need for the end-user to be aware of
the situation closed
no-transform and WAP gateways (in §1.2 and §3.2)
<francois> [16]fd's text and replies
[16]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Feb/0011.html
<francois> [17]Scope ref
[17]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080313#d0e117
<francois> [18]Server response ref
[18]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080313#sec-ServerResponse
francois: in sec 1.2, re "disrupt delivery of WML"
<francois> PROPOSED RESOLUTION: given that the link "in some
circumstances" is fixed, leave the text for ACTION-634 as it is in
1.2 and 3.2
<SeanP> +1
<hgerlach> +1
+1
<francois> RESOLUTION: given that the link "in some circumstances"
is fixed, leave the text for ACTION-634 as it is in 1.2 and 3.2
Text for para 2 of 3.1.1 (ACTION-679)
<francois> [19]Martin's text and replies
[19]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0008.html
<francois> Close ACTION-634
<trackbot-ng> ACTION-634 Write a note to say something about
Cache-Control: no-transform and WAP gateways closed
francois: there seems to be no way to tell if a request was from
XMLHTTPRequest or from a link/URL in the page
... so there is no way for a CT-proxy to positively identify
XMLHTTPRequests
... Is there a need to recommend what happens in AJAX scripts?
bryan: the intent of the app designer needs to be clear in the
JavaScript implementation of the app
... eg the XMLHTTPRequest object has the facility to modify
User-Agent
martin: that's probably safest and most reliable but how many AJAX
apps are going to follow these rules?
... should we liase with Oen AJAX alliance?
... bryan: understand that the proxy vendors need space to innovate
better solutions but it's worth making recommendations to the app
designers
c/... bryan/bryan/
scribe: this recommendation belongs in BP2
<francois> ack q+
martin: if AJAX developers begin to put no-transform in routinely it
may limit the amount CT-proxy providers can do?
francois: agree that Cache-Control: no-transform might just confuse
everything further
... but recommending always decorating the User-Agent to show "I'm
an app on top of the browser"
hgerlach: can we keep AJAX out-of-scope?
... ie CT-proxies are for legacy pages. Where does AJAX start and
JavaScript stop?
... maybe we should specify minimum events and methods that should
be supported?
francois: I think Martin's text for 3.1.1 is fine. Does anyone want
to ammend this section?
<francois> Irrespective of the presence of the no-transform
directive, the proxy must behave transparently (q.v.) unless it is
able to determine positively that the user agent is a browser. The
mechanism by which the proxy recognizes the user agent as a browser
should use evidence from the HTTP request, in particular the
user-agent and accept headers.
bryan: does the XHR object allow you to change User-Agent?
francois: yes, the API does though I've yet to test it
... I'd recommend leave 3.1.1 text as-is and recommend modifying
User-Agent in another place?
bryan: I think a kind of sticky transformation is dangerous
... Windows Mobile had a split WAP1/WP2 stack that caused all kinds
of trouble with WML URLs linking to HTML pages and vice-versa
francois: hasn't the question about how a CT-proxy knows it's
already transformed the referrer page arisen already?
martin: yes, it already exists because the notion of a session with
the client is so useful
... it's easier as a reverse-proxy of course
... My wording was about when the CT-proxy might transform, noth
that it HAS to transform in these conditions
sean: Frequently JavaScript isn't passed down to the device because
the device can't handle it
<SeanP> I'm OK with the text
<francois> PROPOSED RESOLUTION: keep Martin's text for 3.1.1 intact
but continue discussion on Ajax/XHR requests and the like
<Martin1> +1
+1
<SeanP> +1
<francois> RESOLUTION: keep Martin's text for 3.1.1 intact but
continue discussion on Ajax/XHR requests and the like
<francois> ACTION: daoust to summarize and continue discussion re
Ajax/XHR requests and CT [recorded in
[20]http://www.w3.org/2008/03/18-bpwg-minutes.html#action03]
<trackbot-ng> Created ACTION-718 - Summarize and continue discussion
re Ajax/XHR requests and CT [on François Daoust - due 2008-03-25].
<francois> Close ACTION-679
<trackbot-ng> ACTION-679 Propose text for para 2 of 3.1.1 closed
hgerlach: we need to speed this review up
francois: indeed, we should do more work on the mailing-list so
there is less for the calls
Summary of Action Items
[NEW] ACTION: daoust to summarize and continue discussion re
Ajax/XHR requests and CT [recorded in
[21]http://www.w3.org/2008/03/18-bpwg-minutes.html#action03]
[NEW] ACTION: jones to propose some alternate text for HTTPs rewrite
and "must provide the option to avoid transformation" [recorded in
[22]http://www.w3.org/2008/03/18-bpwg-minutes.html#action02]
[NEW] ACTION: martin to propose some alternate text for HTTPs
rewrite and "must provide the option to avoid transformation"
[recorded in
[23]http://www.w3.org/2008/03/18-bpwg-minutes.html#action01]
[End of minutes]
Received on Tuesday, 18 March 2008 16:34:46 UTC