See also: IRC log
<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> List of CT actions
<francois> Andrew's text proposal
francois: for today start with Andrew's contribution
<francois> Jo's adaptation of Andrew's text
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
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 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 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
<francois> fd's text and replies
<francois> Scope ref
<francois> Server response ref
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
<francois> Martin's text and replies
<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 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