See also: IRC log
<francois> Content Transformation Guidelines 1e
<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
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
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 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 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 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
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
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 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 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 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 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: 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
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 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 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].
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