- From: Francois Daoust <fd@w3.org>
- Date: Tue, 22 Apr 2008 17:18:00 +0200
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Minutes of today's call are available at:
http://www.w3.org/2008/04/22-bpwg-minutes.html
... and copied as text below.
I'll summarize and propose some resolutions based on the discussions we
had during the call so that we can decide and move on next week!
François.
22 Apr 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0035.html
See also: [3]IRC log
[3] http://www.w3.org/2008/04/22-bpwg-irc
Attendees
Present
francois, Magnus, hgerlach, jo, MartinJ, andrews, SeanP
Regrets
kemp, bryan, rob
Chair
francois
Scribe
jo
Contents
* [4]Topics
1. [5]Comments on FPWD
2. [6]Linearization/zoom/format support and CT
3. [7]Discussion on Linearization and Zoom and All That Jazz
4. [8]Ajax Calls and CT Proxies
5. [9]Comments and Via Headers
6. [10]The format of the Via Header
* [11]Summary of Action Items
_________________________________________________________
Comments on FPWD
<francois> [12]comment received
[12]
http://lists.w3.org/Archives/Public/public-bpwg-comments/2008AprJun/0000.html
fd: actually we only received one comment which is pretty good going
<hgerlach> I just sent the document to our Vodafone OpCos. By when
do you need their comments?
fd: raises an interesting point but I am not sure how to take them
into account
... basically it is about how a transforming proxy can make a valid
page invalid
... not sure how we can put this in
... we could say that it should always generate a valid page?
magnus: the comment is that the proxy added javascript and thus made
the page invalid
... think it is pretty obvious that the proxy shouldn't make pages
invalid
... proxy builders should show adequate humbleness, it's easy to get
this wrong
ack (ne
<Magnus> s/humily/humbleness/
fd: it's an obvious statement but how should we phrase it, who
thinks we should not mention it?
... does anyone think it is too obvious?
jo: think its non-obvious and is definitely an omission from present
draft
... and that we should add something about generating valid markup
(and images too, for that matter)
... happy to take an action to propose some text in next draft
fd: probably should go in 4.4 ,,,,
<scribe> ACTION: jo to create text about transforming proxies
generating valid documents and propose it in next draft [recorded in
[13]http://www.w3.org/2008/04/22-bpwg-minutes.html#action01]
<trackbot-ng> Created ACTION-738 - Create text about transforming
proxies generating valid documents and propose it in next draft [on
Jo Rabin - due 2008-04-29].
Linearization/zoom/format support and CT
Discussion on Linearization and Zoom and All That Jazz
fd: in 4.1.2 there is some text ... [quotes] ... there was some
discussion on the mailing list
<francois> [14]thread on the topic
[14]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0032.html
fd: first this applies to the response
... so we should remove it from where it is
... and move it to 4.4 Proxy response to user agent
... jo and sean have different perspectives on this
jo: there needs to be something under 4.1.2 reference not changing
headers
fd: but we already say that headers should not be changed
... unless the response would be rejected
... so it doesn't add anything
... you suggest that we add this as an additional point?
jo: I think it should go under "knowledge it has of user agent
capabilities" as you suggest under Possiblity 1 c)
fd: OK, yes as an example of UA capabilities
seanp: even on advanced browsers you may want to do some kind of
transformation
... depends on network, memory and so on, so you might want to do
some segmentation
fd: still worth mentioning under 4.1.2 but maybe change the wording
under 4.4
seanp: the way I would phrase it is that the capabilities of the
browser should be taken into account but shouldn't be a restriction
fd: perhaps it is just another example of the type of heuristic that
the proxy should apply
jo: perhaps it could go there but I am worried that we end up being
too wishy washy. what we are trying to avoid is having the server
doinf adaptation, and transforming proxies transforming and ditto
the browsers - this turns into a real mess. And we should say that
this is to be avoided etc.
sean: yes, I agree but the case I was referring to was when the
Server doesn't adapt then it may be worth the proxy doing things
<francois> PROPOSED RESOLUTION: to replace paragraph on "adavanced
browsers" and CT, add it as an example to "any knowledge it has of
user agent capabilities" in 4.1.2 and add it as a bullet point in
the list of heuristics in 4.4
<SeanP> +1
<francois> +1
<andrews> +1
<hgerlach> -1
<Martin1> +1
+1 to francois's auto-+1
heiko: don't agree because of the arbitrary choices of my local
marketing department
<hgerlach> +1
<Zakim> jo, you wanted to disagree strongly with heiko
fd: if we add this to the list of heuristics then it is not as
strong so matters less
jo: I think that whether your equipment is conformant to these
guidelines or not is their choice, we can't make arbitrary choices
in the sections based on the bits they may or may not choose to
ignore
RESOLUTION: to replace paragraph on "advanced browsers" and CT, add
it as an example to "any knowledge it has of user agent
capabilities" in 4.1.2 and add it as a bullet point in the list of
heuristics in 4.4
Ajax Calls and CT Proxies
<francois> [15]discussion on Ajax/XHR calls
[15]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0028.html
fd: basically if you have an XHR in a page then there is no way for
the CT proxy to know that this is an AJAX call
... rather than just a page request
... we did discuss this
... it's just about choosing the right response content type -
text/xml or text/plain
... I wonder if we should write about it or forget about it
... there isn't really a problem in practice
... we could add this to a list of heuristics
<hgerlach> +1
fd: saying that if you see scripts then be prepared for this
heiko: the application has to add no-cache so adding no-transform
should not be a problem
<Zakim> jo, you wanted to suggest that we put an example in the
appendix
jo: think that we should discuss this and say the no-transform
should be added in both the request and the response
fd: do you mean the request or just the response
... not sure there is need to add it in the request
jo: think this is the classic use case for no-transform in the
request
heiko: normally the Ajax client and data are owned by the same
operator so they can add this easily
... either way round
seanp: martin said at the f2f if the page that contained the ajax
request was transformed then you might want to transform the
response
heiko: transformed ajax pages won't work, in my expectation
seanp: the point was that if the proxy knows enough to transform the
page with the request then it will know enough to transform the
request
fd: if it knows enough then it is going to be smart enough to remove
the no-transform it receives
<hgerlach> sorry, I have to leave for the doc.- bye Heiko
martin: I agree that if you transform an Ajax page then it's
unlikely to work, but there could be some minor optimizations that
are worth doing and should not be prohibited
fd: wondering aloud, um, er,
... if it is smart enough it could remove the no-transform from the
request so ...
... <scribe not following FD's drift here>
heiko: got to go , just want to say there should be no-transform on
the response to the AJAX request
fd: agree that it should be present in both
jo: I find it worrying that you suggest that a transforming proxy
MAY transform requests with no-transform on them
fd: hmmm, difficult to write it
... some where in the doc we should add the text saying that XHR
requests should have no-transform on (and consequently according to
the rules it will alos be on the response)
jo: suggest that we put this in as one among other examples of how
the whole thing is intended to be used
... in a non-normative appendix, for example
seanp: I was thinking along the lines of the ??? itself hasn't been
and there is no no-transform on the request or the response
scribe is confused?
seanp: if it is no-transform ab initio, then it shouldn't be
transformed, but just because it is Ajax doesn't mean it should not
be transformed
<francois> ACTION: daoust to summarize (again) discussion on
Ajax/XHR and propose some resolutions [recorded in
[16]http://www.w3.org/2008/04/22-bpwg-minutes.html#action02]
<trackbot-ng> Created ACTION-739 - Summarize (again) discussion on
Ajax/XHR and propose some resolutions [on François Daoust - due
2008-04-29].
Comments and Via Headers
fd: we are in 4.1.3
... there is a statement that comments in Via headers may be removed
... it seems that this was motivated my memory constraints and they
don't exist in practice
... doesn't mean that comments are always kept just means they are
kept most of the time
... don't think we should change anything
<SeanP> On the XHR issue, my comment was that if a page was
transformed, then any XHR requests originating from that page may
need to have their responses transformed, so these requests should
probably not be marked no-transform.
<francois> According to the HTTP RFC (§14.45), Via headers comments
"MAY be
<francois> removed by any recipient prior to forwarding the
message". Noting that
<francois> the justification for removing such comments is
memory-based, that most
<francois> modern proxies are able to handle that amount of
information and that
<francois> comments are useful for CT, the BPWG recommends that Via
headers
<francois> comments SHOULD NOT be removed.
fd: and move the ednote to a note and point out that there is a
slight difference to HTTP RFC 2616
... per the text I just pasted
... any objection or anything to add?
<scribe> ACTION: Jo to find a way of crafting FD's text above and
weaving it skillfully into the flow of the text [recorded in
[17]http://www.w3.org/2008/04/22-bpwg-minutes.html#action03]
<trackbot-ng> Created ACTION-740 - Find a way of crafting FD's text
above and weaving it skillfully into the flow of the text [on Jo
Rabin - due 2008-04-29].
<francois> Close ACTION-722
<trackbot-ng> ACTION-722 Check why HTTP RFC states comments MAY be
removed from a VIA header. closed
fd: close the action
<francois> Close ACTION-684
<trackbot-ng> ACTION-684 Include a note that we think it is bad
practice to strip the comment from downstream via header fields
closed
fd: and also there was one on jo too, so we can close that as it's
all included in the new action
The format of the Via Header
fd: i'd prefer if we finished the guidelines without powder and
sprinkle it on later
... wondering what we can use in the meantime
... could it be a namespace stating "I'm a CT Proxy?"
<francois> [18]http://www.w3.org/2008/04/ct/
[18] http://www.w3.org/2008/04/ct/
jo: what will a server do knowing that it is a CT proxy but not
knowing anything about its facilities
fd: we could have one or two values
... including statement of intent to transform
... think it would be directly usable
... later then the usage could be expanded, we could use it as a
flag and this would actually already add value
<andrews> +q
jo: so what is a server actually going to do differently
fd: it could refuse to serve the page
... it's in the requirements, we wanted the server to know that
there is a ct proxy
[OK I think there is no downside to this and suggest we do as FD
suggests]
andrew: it's not just the server that would find this useful, it
could be useful for diagnostics
fd: could be used for debugging
andrew: great strength of http is that it is human readable
... v useful to have this information in there.
... moot point as to when you consider yourself to be a
transformation proxy
fd: there is also the proxy intention to transform that we want to
communicate to the server
... and I don't see any other way of doing this
<scribe> ACTION: daoust to write a concrete proposal on use of via
header [recorded in
[19]http://www.w3.org/2008/04/22-bpwg-minutes.html#action04]
<trackbot-ng> Created ACTION-741 - Write a concrete proposal on use
of via header [on François Daoust - due 2008-04-29].
<francois> ACTION: daoust to write some concrete proposal on the
format of the HTTP Via comment to advertise the CT-proxy's presence
(and possibly intention to transform) [recorded in
[20]http://www.w3.org/2008/04/22-bpwg-minutes.html#action05]
<trackbot-ng> Created 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) [on François Daoust -
due 2008-04-29].
fd: look at the other to do's at the end of the agenda
... we have to get this done and I will try to stimulate discussion
on these topics
[meeting ends]
Summary of Action Items
[NEW] ACTION: daoust to summarize (again) discussion on Ajax/XHR and
propose some resolutions [recorded in
[21]http://www.w3.org/2008/04/22-bpwg-minutes.html#action02]
[NEW] ACTION: daoust to write a concrete proposal on use of via
header [recorded in
[22]http://www.w3.org/2008/04/22-bpwg-minutes.html#action04]
[NEW] ACTION: daoust to write some concrete proposal on the format
of the HTTP Via comment to advertise the CT-proxy's presence (and
possibly intention to transform) [recorded in
[23]http://www.w3.org/2008/04/22-bpwg-minutes.html#action05]
[NEW] ACTION: jo to create text about transforming proxies
generating valid documents and propose it in next draft [recorded in
[24]http://www.w3.org/2008/04/22-bpwg-minutes.html#action01]
[NEW] ACTION: Jo to find a way of crafting FD's text above and
weaving it skillfully into the flow of the text [recorded in
[25]http://www.w3.org/2008/04/22-bpwg-minutes.html#action03]
[End of minutes]
Received on Tuesday, 22 April 2008 15:18:37 UTC