- From: Francois Daoust <fd@w3.org>
- Date: Tue, 26 Feb 2008 17:35:13 +0100
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hi,
The minutes of today's meeting are available at:
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Feb/0056.html
... and copied as text below.
Resolutions taken:
RESOLUTION: Stick to Euro time when US moves clocks forward in March
RESOLUTION: remove 2.4 Proxy States part
RESOLUTION: use a URI in the HTTP VIA header comments field to advertise
the CT-proxy's capabilities
New actions:
ACTION: Jo to adjust text in 3,2 per the previous note in the minutes
ACTION: Jo to make 2.7 and 2.8 sub sections of 2.6
ACTION: Jo to produce new draft based on the many actions he has taken
during this call :-) before BP meeting on THursday
ACTION: JO to raise an ISSUE on labelling using POWDER describing
transformation options on sites
ACTION: Jo to remove sect 3.1 and transfer semantics to the present 3.2
ACTION: Jo to remove sect 3.1 and transfer semantics to the present 3.3
ACTION: Jo to update wording of sect 3.2 p 2 to clarify that the intent
is not to respond with a transformed copy
ACTION: Kemp to draft section 2.6 listing user control options that
SHOULD be supported
ACTION: Kemp to see if he can get some figures that scope the problem of
bogus 200 responses
François.
-----
26 Feb 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Feb/0058.html
See also: [3]IRC log
[3] http://www.w3.org/2008/02/26-bpwg-irc
Attendees
Present
francois, kemp, Magnus, hgerlach, jo, SeanP, AndrewS
Regrets
rob
Chair
francois
Scribe
Magnus, francois
Contents
* [4]Topics
1. [5]New draft available
2. [6]Switch to summer time for next calls
3. [7]New Draft of guidelines
4. [8]Client origination of request (§3.1)
5. [9]Proxy Receipt, Forwarding or Response to a Request
(§3.2)
6. [10]Presentation to main body of the working group
* [11]Summary of Action Items
_________________________________________________________
New draft available
<francois> [12]Content Transformation Guidelines 1e
[12]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080226
<francois> close ACTION-661
<trackbot-ng> ACTION-661 Redraft CT Guidleines based on conversation
on this call closed
francois: proposal is to go through this draft and take resolutions
as to what in practice our guidelines say from a tech point of view
... all the arguments have been discussed on the email list
Switch to summer time for next calls
francois: it's time to take decisions
... switch to DST doesn't match between Europe and US
... proposal is to stick to UTC European time
<jo> +1
francois: this will be for 3 weeks
+1
scribe: hereby agreed
<jo> RESOLUTION: Stick to Euro time when US moves clocks forward in
March
New Draft of guidelines
francois: let's start with the objectives part section 2.4
... does everybody agree that we should not mention active/passive
states since it's confusing?
<jo> +1
+1
<francois> PROPOSED RESOLUTION: remove 2.4 Proxy States part
<francois> RESOLUTION: remove 2.4 Proxy States part
Jo: Just want to mention in section 2.1
... the requirements expressed there are not accurate any more
... desired media types is not a requirement for what the UA tells
the proxy
francois: are you talking about 2.1?
... agree that they are not up to date
... they are beyond the scope of the doc. Let's leave it for now.
jo: fine.
francois: next thing will be about 2.6 control of the behavior of
the proxy
... there is an editorial note here
... are we talkign of a list of mandatory options?
... that the ct proxy should allow user to change?
jo: it needs revising
... are we saying that a ct proxy must offer control to the user
francois: it's about listing the option. Should we specify a list of
mandatory options?
... Do others have opinions?
Aron: some recommendation would be good
... for us we will probably have user controls
... it's dangerous territory to make it mandatory
... but it's a good idea
francois: you would like a list of suggestions?
Aaron: yes. should is ok - must is inappropriate
Jo: I'm happy with that
... could Aaron draft that for us?
Aaron: ok
Jo: we want this done before Seoul
Francois: I suppose you have the points in the previous draft?
... I have listed them in one of my threads
<jo> ACTION: Kemp to draft section 2.6 listing user control options
that SHOULD be supported [recorded in
[13]http://www.w3.org/2008/02/26-bpwg-minutes.html#action01]
<trackbot-ng> Created ACTION-666 - Draft section 2.6 listing user
control options that SHOULD be supported [on Aaron Kemp - due
2008-03-04].
Aaron: I'll take a look
Francois: Maybe prefs are listed somewhere else
... is this within scope?
Aaron: Just wondering if this should be merged into 2.6
... why is this different?
Francois: agreed
Jo: I noticed that as well
... 2.7 and 2.8 should both be subsections of 2.6
<jo> ACTION: Jo to make 2.7 and 2.8 sub sections of 2.6 [recorded in
[14]http://www.w3.org/2008/02/26-bpwg-minutes.html#action02]
<trackbot-ng> Created ACTION-667 - Make 2.7 and 2.8 sub sections of
2.6 [on Jo Rabin - due 2008-03-04].
Jo: I am increasingly thinking that since POWDER is coming out soon
... we should encourage ppl to look for mobileOK labels
... something that various portions of the site - transform this,
don't transfor that
i just got lost in that very very long sentence
Francois: don't know when POWDER will be out
<jo> ACTION: JO to raise an ISSUE on labelling using POWDER
describing transformation options on sites [recorded in
[15]http://www.w3.org/2008/02/26-bpwg-minutes.html#action03]
<trackbot-ng> Created ACTION-668 - Raise an ISSUE on labelling using
POWDER describing transformation options on sites [on Jo Rabin - due
2008-03-04].
Francois: POWDER will be able to replace robots.txt
jo: Exactly
... there is an issue that POWDER is not allowed to have a well
known location to retrieve it
... but we can get around that
<SeanP> The POWDER idea is interesting. I'll need to read up on
POWDER...
Heiko: that's why I suggested response header
francois: let's move on
... part 3.1
Client origination of request (§3.1)
francois: client origination of requests
... the list of options can go there?
... do we have anything to add to this part? It's rather small now
Jo: we don't want to talk about the client
Francois: move on to 3.2
Proxy Receipt, Forwarding or Response to a Request (§3.2)
Francois: so this is a bigger part
<jo> ACTION: Jo to remove sect 3.1 and transfer semantics to the
present 3.3 [recorded in
[16]http://www.w3.org/2008/02/26-bpwg-minutes.html#action04]
<trackbot-ng> Created ACTION-669 - Remove sect 3.1 and transfer
semantics to the present 3.2 [on Jo Rabin - due 2008-03-04].
Francois: I suggest we leave the detection of the cases when the UA
is not a browser an open issue
... I have a small question about the 2nd paragraph
<jo> ACTION: Jo to remove sect 3.1 and transfer semantics to the
present 3.2 [recorded in
[17]http://www.w3.org/2008/02/26-bpwg-minutes.html#action05]
<trackbot-ng> Created ACTION-670 - Remove sect 3.1 and transfer
semantics to the present 3.2 [on Jo Rabin - due 2008-03-04].
Francois: what is the point of the paragraph?
<jo> close ACTION-669
<trackbot-ng> ACTION-669 Remove sect 3.1 and transfer semantics to
the present 3.3 closed
Jo: I think the point is that it should not respond with a cached
transformed copy
... that is not brilliantly clear
<jo> ACTION: Jo to update wording of sect 3.2 p 2 to clarify that
the intent is not to respond with a transformed copy [recorded in
[18]http://www.w3.org/2008/02/26-bpwg-minutes.html#action06]
<trackbot-ng> Created ACTION-671 - Update wording of sect 3.2 p 2 to
clarify that the intent is not to respond with a transformed copy
[on Jo Rabin - due 2008-03-04].
Francois: we are getting to the core part of our discussion
... should the CT proxy advertise that it is there and its
capabilities
... and thirdly how - in which format
... in my agenda I have listed possibilities
... I removed all possibilities that are not based on existing
technologies in practice
... there are only via or pragma header left
... or third ct proxy should not advertise
... my proposal is to use the VIA header to advertise that the CT
proxy is on the line
... it's already in the draft
... my second proposal is that we use the comment section of the VIA
header with the caveat that anybody else may strip them away
Aaron: do we wan t to how we are going to talk about capabilities?
Francois: 1 musd question
<SeanP> I'm OK with using the Via header.
Francois: it has to be an extensible format
... all content providers must be able to parse the string
automatically
... otherwise it's only for humans and useless
Aaron: is there enough that CTs, so I propose a URI poiting to a
description
Francois: what are the things taht a CT proxy can do that can't be
rephrased into simple verbs (reformat, restructure, etc)
Aaron: basically my point is that it can be too generic and not
useful
<Zakim> jo, you wanted to speak in favor of Aaron's proposal and to
add that this could be a pointer to a POWDER
Jo: I'm not Phil Archer's rep in this respect, but it makes sense to
use POWDER
... it would at least be consistent
... with other things we are trying to do in this group
... a URI in the comments fields is not inventing new technology
... it's obvious what it means
... this would be a great help to content providers with a rich
enough vocabulary
... if this is the textual description it would be useful enough
... if it's parsable that would be more useful
<francois> PROPOSED RESOLUTION: use a URI in the HTTP VIA header
comments field to advertise the CT-proxy's capabilities
Francois: it looks like a good idea
... this URI should link to a POWDEr descriptive doc
<kemp> +1
+1
<SeanP> +1
<andrews> +1
<francois> RESOLUTION: use a URI in the HTTP VIA header comments
field to advertise the CT-proxy's capabilities
<jo> +1
<andrews> +1
Francois: let's move on
... no other open questions here
Jo: the point is did we decide what to do about POST?
Francois: no real problem?
Aaron: I must have missed this call. We must be able to do POST. I
am unaware of the problem.
... POST is important
<hgerlach> +q
Francois: that was the conclusion we had on the previous call
Heiko: the question is do we need an option where a user can opt in
to break SSL?
Francois: it's listed further in the sense that there's nothing the
CT proxy should do
... anyway, I saw it somewhere
... it doesn't affect our discussions and no decisions so far
regarding HTTPS rewriting
Jo: question: are we assuming that it will not restructure?
... a POST will not restructure?
<hgerlach> +q
Jo: what about PUT?
Heiko: I think the request will never be modified - only the
response
Jo: no, the headers are modified
Heiko: but never the request body
Francois: Jo, are you thinking of encoding of a document sent via
PUT or POST?
Jo: we just need to be clear
... about the nature of intervention
... there are any number of HTTP POST, HEAD, PUT that you can do in
theory
... we shoudl be clear about the ones that are in scope
... clarify what we are talking about
Aaron: there are cases where we modify the request body in a POST -
encoding issues
... suppose the mobile doesn't support an encoding that the server
requires
... we do this in some cases
Heiko: this has never been in scope in the past at Vodafone
Aaron: I don't want to be forbidden by the document
Francois: as for the other commands, HTTP PUT etc, I', not so
familiar with them
... I only see it used at W3C
<jo> [Jo to adjust text in 3.2 under "intervene in HTTPS" and remove
the reference to HTTPS and add GET POST HEAD and PUT as the methods
in scope, and put in a placeholder as to which parts of the request
and response can be modified]
Francois: I don't know if there is a problem with them or not
Jo: I just posted a possible action
... let me give myself an action to adjust the text
Francois: sounds great
<jo> ACTION: Jo to adjust text in 3,2 per the previous note in the
minutes [recorded in
[19]http://www.w3.org/2008/02/26-bpwg-minutes.html#action07]
<trackbot-ng> Created ACTION-672 - Adjust text in 3,2 per the
previous note in the minutes [on Jo Rabin - due 2008-03-04].
<hgerlach> From:
[20]http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html: The PUT
method requests that the enclosed entity be stored under the
supplied Request-URI., so I think this should not be affected by CT
[20] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html:
Francois: the whole point now is how should the proxy behave?
<hgerlach> +q
Francois: is there any need to change UA header, what should we say?
Heiko: I think we in general should not change UA header, but there
are exceptions
... if you need to bypass server-side restrictions on UA
... we need a list of pages that do not work with device UA
Francois: you don't change UA header by default, but add accept
header
Heicko: that's how it should work
... we have had this issue at Vf UK
... we always sent a fake UA header instead of the original UA
... we must be sure that mobile sites will work
... so content transformation must only be performed for non-mobile
sites
Aaron: ideally I agree to not changing UA header
<andrews> +q
Aaron: but I disagree with the notion that most sites are mobile
aware
... I don't support leaving original UA header as the default
... in the future don't masquerade, but we can't do that now
Andrew: I agree with Heiko's approach
... the way we do CT today is discouraging mobile best practices
... we want to encourage this instead (good mobile web design)
... we are missing clear stats
... how many sites support mobiles
<Zakim> jo, you wanted to think that the default should be that the
original user agent is not modified unless a 406 response is
received or unless a 200 with a heuristically determined
<hgerlach> Our priority must be on mobile internet/mobile sites,
since we are making money with this sites, not with the other ones.
Jo: dotmobi has done stuff in this area that I can't expand upon
... we should be doing stuff that encourages people to build good
mobile content
... we must give them information to do that - like the original UA
header
<hgerlach> The 3rd is if it just answers with 200 OK and a written
error message
Jo: I think we have to resolve that it is best practice
... to preserve the UA header
... and clean up the current mess
... if we are telling them that POWDER is good practice
... we are pushing the web in the right direction
... instead of a cul-de-sac
Francois: I agree
... I just don't want us to go in the right direction if noone else
follows
Aaron: I don't disagree, but it's not going to work
... it's very hard to reliably handle a 200 response
Francois: stats are confidential
... this would be very useful to know
Aaron: I will look into it
Jo: speaking as WG chair: you can share confidentially
Francois: it would be really useful
... are we talking about 1% or 80% ?
<jo> ACTION: Kemp to see if he can get some figures that scope the
problem of bogus 200 responses [recorded in
[21]http://www.w3.org/2008/02/26-bpwg-minutes.html#action08]
<trackbot-ng> Created ACTION-673 - See if he can get some figures
that scope the problem of bogus 200 responses [on Aaron Kemp - due
2008-03-04].
<SeanP> I basically agree with Aaron--there is also the case where
the user actually wants a transformed version of the desktop site
instead of the mobile version.
<francois> ScribeNick: francois
<jo> ACTION: Jo to produce new draft based on the many actions he
has taken during this call :-) before BP meeting on THursday
[recorded in
[22]http://www.w3.org/2008/02/26-bpwg-minutes.html#action09]
<trackbot-ng> Created ACTION-674 - Produce new draft based on the
many actions he has taken during this call :-) before BP meeting on
THursday [on Jo Rabin - due 2008-03-04].
Presentation to main body of the working group
Jo: I'll be able to issue a new draft by next Thursday
<jo> FD: Next week's call is cancelled because of Seoul, so the next
call will be in 2 weeks time
francois: OK, I'll prepare a list of open questions/points that
could be worth considering in the working group
Summary of Action Items
[see beginning of email]
[End of minutes]
Received on Tuesday, 26 February 2008 16:35:35 UTC