- From: Francois Daoust <fd@w3.org>
- Date: Tue, 01 Apr 2008 17:36:19 +0200
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
The minutes for today's call are available at:
http://www.w3.org/2008/04/01-bpwg-minutes.html
... and copied as text below.
Next steps:
1. an editors meeting between Jo and fd tomorrow
2. remaining resolutions on Thursday's BPWG call
3. leaving a week for reviewing
4. publication as FPWD
Is that being too optimistic? Well, probably ;)
As a summary, things we resolved during today's call:
- for 3.1.4, "the proxy must add a X-Device-[original HTTP header name]"
and put an editorial note about the fact we'd love to recommend
something else but don't see how and a note about the choice of "device"
- 3.4 list of heuristics - leave it as it is for the time being
- accept Martin's text for ACTION-717
- with the users explicit prior consent, when dangerous content is
detected, and when using a browser, instead of forwarding the dangerous
content MAY warn the user and send a page with links to both transformed
and non-tranformed versions dangerous that may cause mal-operation of
the users device
- let's try: editors' meeting tomorrow, resolutions on Thursday's call,
reviewing and then publication
François.
01 Apr 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0038.html
See also: [3]IRC log
[3] http://www.w3.org/2008/04/01-bpwg-irc
Attendees
Present
Magnus, SeanP, andrews, francois, hgerlach, jo, rob
Regrets
Bryan, kemp, MartinJ
Chair
francois
Scribe
rob, jo
Contents
* [4]Topics
1. [5]Targeted schedule
2. [6]ACTION-685: how to embed original headers (§3.1.4)
3. [7]Proxy response to User Agent (§3.4)
4. [8]Proxy Receipt and Forwarding of Response from Server
(§3.3)
5. [9]Publication as FPWD
* [10]Summary of Action Items
_________________________________________________________
Targeted schedule
<jo> Agenda:
[11]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0038.
html
[11]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0038.html
francois: apart from a few issues probably settled today we're ready
to publish a "First Working Draft"
... aim to resolve during today's call the outstanding issues and
arrange an Editor's Meeting
ACTION-685: how to embed original headers (§3.1.4)
francois: could publish First Working Draft in the week after next
<francois> [12]3.1.4
[12]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080313#d0e528
<francois> [13]fd's action
[13]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0030.html
francois: couldn't find a way to echo original header values without
breaking things
<jo> +1 to sending X-headers and to adding an editorial note stating
we'd prefer not to use this mechanisnm but can't think of any other
way
<Zakim> rob, you wanted to say we already have precedent for
X-headers in live systems
<Zakim> jo, you wanted to suggest that the app at the server would
probably not have access to Warning headers ...
rob: X-headers are deployed live by Novarra and Openwave and their
presence is known to the developer community
jo: It is a pity we couldn't find a better solution but suggest we
accept it as undesirable but still worth recommending
andrews: supports the X-headers for echoing changed headers
<Zakim> jo, you wanted to say we should stop wringing our hands
about this
francois: so this means multiple X-headers if multiple headers have
been changed?
jo: you can't have new HTTP headers without an experimental period,
so recommend proceed with X-headers
hgerlach: need to understand what headers can change and what
headers should never change
francois: in practice it's only User-Agent and Accept
<francois> PROPOSED RESOLUTION: for 3.1.4, "the proxy must add a
X-Original-[original HTTP header name]" and put an editorial note
about the fact we'd love to recommend something else but don't see
how.
<jo> +1
<jo> scribe: jo
<Magnus> +1
PROPOSED RESOLUTION: for 3.1.4, "the proxy must add a
X-Original-[original HTTP header name]" and put an editorial note
about the fact we'd love to recommend something else but don't see
how.
andrew: should it be X-Device like Novarra has it?
seanP: Either way seems reasonable to me
rob: maybe developers will expect X-Device as it is already in use
jo: i'd prefer something like X-received
francois: we have a number to choose from
... I don't like device but don't really care
... would prefer original or received?
<francois> x-device?
<SeanP> +1
[straw poll]
rob and andrew also prefer x-device (fallen off IRC)
andrew: take jo's point x-received might be truer
<francois> PROPOSED RESOLUTION: for 3.1.4, "the proxy must add a
X-Device-[original HTTP header name]" and put an editorial note
about the fact we'd love to recommend something else but don't see
how and a note about the choice of "device".
francois: can you live with that Jo
jo: really doesn't matter just lets add a ntoe saying it is a
provisional choice
<SeanP> +1
<rob> +1
<andrews> +1
hgerlach: we asked that we did not define our own headers so we
should make sure that these headers are unique like containing CT or
some other label
... so they are not used by other applications for different
purposes
francois: take your point but they use could be more generally
applicable
jo: suggest taht we take resolution and move on as headers shouldn't
be bounded by a presumed application
fd: well these ones are already in use so why don't we just do this
hg: we have lots of X- headers in the vodafone network
... not a major issue to change headers think the headers need only
to be used for the single purpose
seanp: didn't come across any collisions with the X-Device headers
... to the point about which other headers might be changed:
Accept-Charset and Accept-Encoding for example
<francois> RESOLUTION: for 3.1.4, "the proxy must add a
X-Device-[original HTTP header name]" and put an editorial note
about the fact we'd love to recommend something else but don't see
how and a note about the choice of "device"
fd: right let's make a note about the name and take the resolution
Proxy response to User Agent (§3.4)
<francois> [14]3.4
[14]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080313#sec-Proxy-Response
fd: suggest we leave this list alone for now and come back to it in
a later step
<francois> PROPOSED RESOLUTION: 3.4 list of heuristics - leave it as
it is for the time being
+1
<rob> +1
<hgerlach> +1
<SeanP> +1
<andrews> +1
<francois> RESOLUTION: 3.4 list of heuristics - leave it as it is
for the time being
<francois> [15]Martin's text for ACTION-717
[15]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0033.html
fd: Martin sent some text under ACTION-717
<andrews> +1
fd: clarifying that it is not allowed to break the end to end
security
<francois> PROPOSED RESOLUTION: accept Martin's text for ACTION-717
<andrews> +1
+1
<SeanP> +1
<francois> RESOLUTION: accept Martin's text for ACTION-717
<francois> Close ACTION-717
<trackbot-ng> ACTION-717 Propose some alternate text for HTTPs
rewrite and "must provide the option to avoid transformation" closed
<scribe> scribe: rob
<francois> ScribeNick: rob
francois: remaining topic on dangerous content is a bit outdated
<francois> PROPOSED RESOLUTION: for dangerous content, something
along the lines of:
<francois> "[when dangerous] the proxy MAY warn the user, and give
the user the choice to see a transformed version of the resource"?
francois: suggest if there is a Cache-Control: no-transform but
CT-proxy determines content won't work on the handset that the
CT-proxy should ask the user?
<jo> ... instead of forwarding the dangerous content MAY send a page
with links to both transformed and non-tranformed versions ...
hgerlach: what is dangerous content?
francois: eg a page that is too big and will cause out-of-memory in
the phone browser
<jo> [ref HGerlach's comments, virus scanning is surely not in
scope?]
hgerlach: does a virus-scanner do this?
francois: I think it's out of scope unless there is a clear
incompatibility
<Zakim> rob, you wanted to say sending a "do you or don't you?"
interstitial is definitely *not* a no-transform
rob: sending a "do you or don't you?" interstitial is definitely
*not* a no-transform and this could break an application if the
content is saved to memory
<jo> +1 to "no transform" means "no-transform"
francois: yes, the CT-proxy needs to be cautious about this
seanp: if it is dangerous content then something must be done to fix
it, obviously the CT-proxy needs to be cautious about altering it
<francois> PROPOSED RESOLUTION: for dangerous content, something
along the lines of:
<francois> "[when dangerous] the proxy MAY warn the user, and give
the user the choice to see a transformed version of the resource",
with emphasis on the MAY to say that it may be "dangerous"
<Zakim> jo, you wanted to say if one could tell what was dangerous
content then I'd agree with SeanP, the problems seems to be that one
can't tell well enough in general
jo: should be absolutely only if the user wants the CT-proxy to
correct dnagerous content
... and as usual the users' preferences can be persistent
... even the interstitial wil break an application if there is no
user to see the page
... so the user's decision needs to be "prior consent"
<jo> "with the users explicit prior consent [when dangerous] instead
of forwarding the dangerous content MAY warn the user and send a
page with links to both transformed and non-tranformed versions"
<jo> PROPOSED RESOLUTION: with the users explicit prior consent,
when dangerous content is detected, and when using a browser,
instead of forwarding the dangerous content MAY warn the user and
send a page with links to both transformed and non-tranformed
versions
hgerlach: should we use the word "dangerous"?
<SeanP> I'm OK with the term "dangerous"
<francois> +1
francois: the term is defined clearly
<andrews> +1
<hgerlach> +1
<SeanP> +1
<Magnus> +1
<jo> +1
<francois> RESOLUTION: with the users explicit prior consent, when
dangerous content is detected, and when using a browser, instead of
forwarding the dangerous content MAY warn the user and send a page
with links to both transformed and non-tranformed versions dangerous
that may cause mal-operation of the users device
Proxy Receipt and Forwarding of Response from Server (§3.3)
francois: 3.1.4 says if the headers are altered the CT-proxy must be
prepared to vary the headers
jo: this isn't clear
... if you don't get a Vary in the response you don't know to
reissue the request differently
... the point of sending a Vary is to avoid caching in situations
where it is inappropriate to cache
Publication as FPWD
<francois> PROPOSED RESOLUTION: editors' meeting tomorrow,
resolutions on Thursday's call, reviewing and then publication
<francois> RESOLUTION: let's try: editors' meeting tomorrow,
resolutions on Thursday's call, reviewing and then publication
<hgerlach> bye:-)
Summary of Action Items
[End of minutes]
Received on Tuesday, 1 April 2008 15:36:49 UTC