See also: IRC log
<francois> discussion re Ajax/XHR calls
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 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
<francois> fd's proposal
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 "http://www.w3.org/2008/04/ct#". Intention to transform must be indicated using the "active" property: "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 "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
+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 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 "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
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
<francois> fd's proposal
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
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> discussion
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 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