- From: Francois Daoust <fd@w3.org>
- Date: Tue, 29 Apr 2008 17:55:05 +0200
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hi guys,
The minutes of today's call are available at:
http://www.w3.org/2008/04/29-bpwg-minutes.html
... and copied as text below.
Thanks,
François.
29 Apr 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0044.html
See also: [3]IRC log
[3] http://www.w3.org/2008/04/29-bpwg-irc
Attendees
Present
Heiko, Jo, Francois, MartinJ, SeanP, Rob
Regrets
Magnus, AndrewS, Bryan
Chair
francois
Scribe
Jo
Contents
* [4]Topics
1. [5]Ajax, XHR and Content Transformation
2. [6]format of via header comment
3. [7]Discussion on Session vs Persistent sessions (yada yada)
4. [8]Sending two requests requests 4.1.2
* [9]Summary of Action Items
_________________________________________________________
Ajax, XHR and Content Transformation
<francois> [10]discussion re Ajax/XHR calls
[10]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0042.html
fd: conclusion is that a proxy should examine the content of the
page it receives and have a lot of scripts
<francois> PROPOSED RESOLUTION 1.1: in §4.4, add a bullet point to
the list of heuristics that says "examination of the content reveals
that the page contains client-side scripts that may break if the
page gets adapted"
<francois> +1
jo: wonders if adding the heuristic adds value, though it is
obviously true, it doesn't say how to formulate a conclusion
fd: that's also true of the other heuristics we enumerate in the
same section
<Zakim> rob, you wanted to say that if a page contains script then
usually it does need transforming!
jo: I am thinking that we should not be doing product design and we
need to have a greater degree of feedback from real vendors
rob: usually we do the scripting on behalf of the phone but where
the phone is script capable we do let it through
heiko: there was an open ajax workshop, were there any results
fd: I don' think there was anything related to CT
seanp: there are a couple of possibilities - e.g. a proxy runs the
scripts or passes them through, there may also be some
transformation
... e.g. if link rewriting is done and some of the links in the
Javascript might need to be rewritten, it might be smart enough to
rewrite those too
<Zakim> jo, you wanted to suggest we resolve to put it in as it does
no harm
seanP: that was just by way of clarification not a proposed text
jo: let's just put it in
fd: I think what actually happens is out of scope
rob: mention is fine
<SeanP> +1 for mentioning as a heuristic
rob: the bit that said if there is script don't transform would be
wrong
+1
<rob> +1
RESOLUTION: in §4.4, add a bullet point to the list of heuristics
that says "examination of the content reveals that the page contains
client-side scripts that may mis-operate if the page gets adapted"
[note that the word "break" has been transformed]
<francois> PROPOSED RESOLUTION 2.3: in §???, "Asynchronous HTTP
requests sent from within a Web page (e.g. XHR calls) SHOULD include
a no-transform directive"
fd: another resolution related to that is to do with adding a
no-transform directive to requests, not sure where to put it
... initially I wanted to say something about content types etc.
... but Jo convinced me that this was not right
<francois> PROPOSED RESOLUTION 2.3: in 4.1.1, "Asynchronous HTTP
requests sent from within a Web page (e.g. XHR calls) SHOULD include
a no-transform directive" as a typical example
jo: lets stick it in 4.1.1 as an example of when you might do that
<Zakim> jo, you wanted to say that MAY is better
rob: we mean a mobile friendly Web page
<SeanP> +1 for MAY
<hgerlach> +1
jo: I think this would be text along the lines of ... MAY ... if it
does not wish the request or the response to be altered by a CT
proxy
fd: <tap /> <tap />
<francois> PROPOSED RESOLUTION 2.3: in 4.1.1, "As an example of
this, a web page sending asynchronous HTTP requests (e.g. XHR calls)
may include a no-transform directive if it doesn't want the message
to be transformed"
+1
<rob> +1
<francois> +1
<hgerlach> +1
<SeanP> +1
RESOLUTION: In 4.1.1, "As an example of this, a web page sending
asynchronous HTTP requests (e.g. XHR calls) may include a
no-transform directive if it doesn't want the message to be
transformed"
fd: let's not discuss the content types for transformation
(ACTION-725) we can do that later
... I also had another one one which no longer makes sense so let's
drop it
... as things stand there is no way for the server or a proxy to
know whether the request comes from the browser or from XHR and it
might be worth pointing out to them as a LCC the need to distinguish
XHR calls (Jo already mentioned this to Chaals)
... I am not sure the distinction needs to be made ...
... should we do this?
PROPOSED RESOLUTION: FD to draft a note to the WG and alert them to
this discussion
rob: I'm not sure there is anything to say about it
... not sure there is any need to distinguish
... as long as there is something that identifies that this is part
of the session and all responses come with their own content types
which is what is important to us
jo: don't see why not, it's not a big deal, they can ignore it if
they want
<francois> 0
<scribe> ACTION: daoust to write to the XHR folks and point out a
possible need to identify that a requst comes from script [recorded
in [11]http://www.w3.org/2008/04/29-bpwg-minutes.html#action01]
<trackbot-ng> Created ACTION-749 - Write to the XHR folks and point
out a possible need to identify that a requst comes from script [on
François Daoust - due 2008-05-06].
<hgerlach> +1 proposed -1others
<SeanP> +1 to writing to XHR folks
close ACTION-718
<trackbot-ng> ACTION-718 Summarize and continue discussion re
Ajax/XHR requests and CT closed
close ACTION-739
<trackbot-ng> ACTION-739 Summarize (again) discussion on Ajax/XHR
and propose some resolutions closed
heiko: what about the content type part of ACTION-739
fd: we will discuss this under ACTION-725 on Sean
format of via header comment
<francois> [12]fd's proposal
[12]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0040.html
fd: we wanted to distinguish CT proxy from proxy - when were
discussing this in the context of POWDER we said it would point to a
resource describing what it would do
... bryan pointed out in Seoul that just a flag would be useful
... this could link to a powder resource when we get to that
<francois> PROPOSED RESOLUTION: format of the VIA header comments:
[a URI to a POWDER resource that describes the CT-proxy's
capabilities using the vocabulary-to-be when we're ready to switch
to POWDER or] the CT
<francois> namespace's URI "[13]http://www.w3.org/2008/04/ct#".
Intention to transform must be indicated using the "active"
property: "[14]http://www.w3.org/2008/04/ct#active".
[13] http://www.w3.org/2008/04/ct
[14] http://www.w3.org/2008/04/ct#active
fd: or a namespace id which just means "I am a transformation proxy"
<Zakim> jo, you wanted to ask how to distinguish old style comments
from new style comments when this is not a namespace any more
jo: worried about forward compatibility and how you will know to
distinguish a flag from a link to some powder resource
fd: it will be different URI
jo: I guess we should say so
fd: yes, <tap /> <tap />
jo: maybe we should have a query string so we could have name /
value pairs - just using a fragment ID may not be vvery
extensible/flexible
fd: perhaps we need more investigation if we don't know whether this
is good practice or not
<francois> PROPOSED RESOLUTION: format of the VIA header comments:
either the URI "[15]http://www.w3.org/2008/04/ct", a URI derived
from this one (that defines properties such as "active"), or a URI
to a POWDER resource that describes the capabilities of the proxy
[15] http://www.w3.org/2008/04/ct
+1
<francois> +1
<SeanP> +1
fd: I will investigate how to be able to define multiple properties
in the same URI
<scribe> ACTION: daoust to investigate how to add multiple
property/values to the URI [recorded in
[16]http://www.w3.org/2008/04/29-bpwg-minutes.html#action02]
<trackbot-ng> Created ACTION-750 - Investigate how to add multiple
property/values to the URI [on François Daoust - due 2008-05-06].
RESOLUTION: format of the VIA header comments: either the URI
"[17]http://www.w3.org/2008/04/ct", a URI derived from this one
(that defines properties such as "active"), or a URI to a POWDER
resource that describes the capabilities of the proxy
[17] http://www.w3.org/2008/04/ct
close ACTION-741
<trackbot-ng> ACTION-741 Write a concrete proposal on use of via
header closed
close ACTION-742
<trackbot-ng> ACTION-742 Write some concrete proposal on the format
of the HTTP Via comment to advertise the CT-proxy's presence (and
possibly intention to transform) closed
Discussion on Session vs Persistent sessions (yada yada)
<francois> [18]fd's proposal
[18]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0036.html
fd: this all started as a discussion of what is in or out of scope
... and went into a discussion of "other arrangements"
... I don't understand what the distinction is between session
settings and persistent settings so my proposal is to rewrite 3.2.1
<francois> PROPOSED RESOLUTION: Rewrite §3.2.1 roughly based on what
it was before: "They MAY also provide the ability for their users to
make a persistent expression of preferences."
fd: "persistent or semi-persistent expression of preferences"
... to what it was before, I don't think we need to make a
distinction
<SeanP> I'm fine with that.
<francois> +1
<hgerlach> +1
<SeanP> +1
<rob> +1
0
RESOLUTION: Rewrite §3.2.1 roughly based on what it was before:
"They MAY also provide the ability for their users to make a
persistent expression of preferences."
jo: notes that we are avoiding having a discussion on something that
might reveal important things but for now, let's do it your way fd
Sending two requests requests 4.1.2
fd: in theory GET is idempotent so it should not matter
... if you send more than one request. In practice I listed a number
of cases where this is not true
<francois> [19]discussion
[19]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0043.html
fd: for POSTs this is of course a problem, so I don't think we need
to emphasize this point
<francois> PROPOSED RESOLUTION 1.1: at the end of §4.1.2, add "The
proxy MUST NOT issue a POST/PUT request with altered headers when
the response to the
<francois> unaltered POST/PUT request contains an HTTP status code
200"
<francois> (in other words, it may only send the altered request for
a POST/PUT request when the unaltered one was refused with a clear
406)
fd: in most cases the proxy will already know how to interact with
the server by the time it gets to sending a POST
heiko: what about one time URLs?
fd: yeah, we are just talking about POSTs for now
... but yes we should make the point that the proxy should strive
always to send only one GET request
+1
<hgerlach> +1
<MartinJ> +1
<francois> 0
<rob> +1
RESOLUTION: at the end of §4.1.2, add "The proxy MUST NOT issue a
POST/PUT request with altered headers when the response to the
unaltered POST/PUT request contains an HTTP status code 200" (in
other words, it may only send the altered request for a POST/PUT
request when the unaltered one was refused with a clear 406)
<francois> PROPOSED RESOLUTION 1.2.a: at the end of §4.1.2, add a
"The theoretical idempotency of GET requests is unfortunately not
always respected in practice. Not to break existing content, the
proxy SHOULD strive to send only one request whenever possible."
fd: let's see if we can resolve on the next one, which speaks to
Heiko's last point
PROPOSED RESOLUTION 1.2.a: at the end of §4.1.2, add a "The
theoretical idempotency of GET requests is unfortunately not always
respected in practice. Not to break existing content, the proxy
SHOULD send only one request."
+1
<francois> +1
RESOLUTION: at the end of §4.1.2, add a "The theoretical idempotency
of GET requests is unfortunately not always respected in practice.
Not to break existing content, the proxy SHOULD send only one
request."
<scribe> ACTION: daoust to make sure that we are clear about
idempotency and side-effect freedome etc. per Dom's original
illuminating point about this section [recorded in
[20]http://www.w3.org/2008/04/29-bpwg-minutes.html#action03]
<trackbot-ng> Created ACTION-751 - Make sure that we are clear about
idempotency and side-effect freedome etc. per Dom's original
illuminating point about this section [on François Daoust - due
2008-05-06].
fd: next time we will discuss Sean's contribution and we also need
to do the remainder of the points on the agenda so please study
these points
Summary of Action Items
[NEW] ACTION: daoust to investigate how to add multiple
property/values to the URI [recorded in
[21]http://www.w3.org/2008/04/29-bpwg-minutes.html#action02]
[NEW] ACTION: daoust to make sure that we are clear about
idempotency and side-effect freedome etc. per Dom's original
illuminating point about this section [recorded in
[22]http://www.w3.org/2008/04/29-bpwg-minutes.html#action03]
[NEW] ACTION: daoust to write to the XHR folks and point out a
possible need to identify that a requst comes from script [recorded
in [23]http://www.w3.org/2008/04/29-bpwg-minutes.html#action01]
[End of minutes]
Received on Tuesday, 29 April 2008 15:55:49 UTC