See also: IRC log
<francois> comment received
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 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].
fd: in 4.1.2 there is some text ... [quotes] ... there was some discussion on the mailing list
<francois> thread on the topic
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
<francois> discussion on Ajax/XHR calls
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 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].
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 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
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> 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 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 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]