See also: IRC log
francois: introduces Tom as an
Invited Expert with specific mobile development expertise to
enhance representation from that side
... and to heslp reolve the last call comments
... so round the table
... I am the staff contact for BP and lead the CTTF "I am here
to help"
heiko: I work for Vodafone and own content adaptation in Vodafone
pontus: from Ericsson have been working on the CT product
rob: from Openwave responsible for OpenWeb
jo: from dotMobi, co-chair of BP and editor of CT doc
tom: I am MD of Future Platforms and increasingly involved in mobile Web hence come across transformation
rancois: just wanted to review this, before August we thought we might be able to stop the TF and move the work back to the WG but with the number of comments think it is appropriate to continue the TF
<hgerlach> me
+1 to continuing the TF
heiko: need to get comments done asap should not keep people waiting
francois: don't think we can do it in 2 weeks but yes we seem to be agreed
<hgerlach> +1
francois: I split the comments up between the TF members and wanted people to be responsible so we can just get on it with it, the allocation is random
francois: introduces Tom to SeanP who just joined
seanp: work for novarra
tom: (per the above)
francois: was just trying to find
a way to go faster rather than to impose anything on
anyone
... I left 2 unallocated to deal with today
<francois> Division of the Last Call comments
francois: any objections to my
allocation of coments?
... person responsible to read and summarise the comment and
the position we took before, linking where appropriate, and
propose changes tot he spec or provide a rationale for saying
no, etc.
<scribe> ... done on the mailing list and hence go faster on the call?
<scribe> ... any views?
+1 to the allocation as it stands
heiko: I think I am the only one who can't do anything with the Vary header so would prefer not to do that
jo: I'll take 2081 and 2008
<hgerlach> +1
jo: I will take on making
proposed responses but first think that we need to agree a
policy
... for example I would not be averse to a document that said
don't change any headers
... but I think the members of the TF need to express views
seanp: I like it as it is, think it is practical as it is written to meet the reality of how it is being done now as well as being consistent with the way the group sees content developing
rob: the comments seem mainly about POSTs - is that right?
francois: hmmm, not really
rob: oops, I was reading the
wrong section
... we came up with this text because we thought that altering
the user agent is a good way of getting content to a device
that otherwise would not be able to get it
<francois> jo: I don't preempt discussion on this, but the rationale is twofold: 1. otherwise content would be blocked. I'm personally unaware of this happening. To be fair, we should have more statistics.
<francois> ... 2. because some people want the reformatted view.
<francois> ... Not much to say about that apart from the fact that it may occur.
jo: I think we need to justify with some figure how frequently servers respond with a 406 or equivalent that blocks the user getting a response, which is the main justification for this. The other justification, which is that the user has requested a restructured desktop experience seems to me at least conceivable, but to what extent do we need to accommodate that possibility?
heiko: In general I agree with Jo
- but should we differentiate between different headers - e.g.
the User-Agent might be special, other headers should probably
be treated differently
... I think that the 406 is something different which is why I
mentioned earlier that we should have a white list
francois: what other headers do you think are problematical, the section benefits from being generic
jo: I do think we should distinguish between rejection with 406 because of incompatible accepts vs incompatible User-Agents
francois: well, aaron had an action a while back about this, maybe we should re-awaken his action
jo: sure, google would be well placed to do this if they were able, if they aren't then we will have to do it elsewhere in the group
francois: so you're suggesting we need to test if we can be stricter about the user agent not being changed - and continue to be strict about the accept-* ?
[discussion about who can supply info]
seanp: I can see if we have anything on that
francois: I'll take an action to get back to aaron
jo: I can look and see if we have anyting too
<scribe> ACTION: daoust to get back to aaron from google to see if he can get some stats for us [recorded in http://www.w3.org/2008/09/09-bpwg-minutes.html#action01]
<trackbot> Created ACTION-842 - Get back to aaron from google to see if he can get some stats for us [on François Daoust - due 2008-09-16].
<scribe> ACTION: jo to see if he can come up with wording on this section that might accommodate everyone [recorded in http://www.w3.org/2008/09/09-bpwg-minutes.html#action02]
<trackbot> Created ACTION-843 - See if he can come up with wording on this section that might accommodate everyone [on Jo Rabin - due 2008-09-16].
action-843+ (the section in question being 4.1.5)
francois: we got lots of comments
and the comments are about saying that HTTPS links should not
be re-written in any circumstances as it is a man in the middle
attack
... either we say this is not allowed or we stick to the text
we have amended a bit
... positions and volunteers to address these comments?
sean: we have a pretty good statement in the document - if you outlaw this you can't get to your mail etc. - a lot of the comments refer to banks but there are a lot of other sites that you can't go to which have less security requirements
francois: I don't have a clear position, I understand both the need and the danger
<hgerlach> maybe just add "towards "server and user" at the end
francois: if anything I'd say it
just should not be allowed
... but agree that some applications don't have to be that
secure
... any more thoughts?
... anyone want to take this on?
tom: one of the difficulties here is that it pushes an understanding of the mechanisms on to the user who probably doesn't understand what is going on
<hgerlach> yes, but this is the same with a native browser e.g. firefox
tom: not even clear on the web now, with regular desktop browsers
francois: agree, what do you think would help ref the user
tom: yes, good idea, but can't think of an easy way to do this avoiding malicious attacks in the context of a mobile device
francois: how about noting that
and thinking about it, can I assign you the comments
... a fresh look at the section by someone who did not
participate in the previous discussions
<dom> re https, the web security context guidelines might have some useful definitions and ideas to solve that problem: http://www.w3.org/TR/2008/WD-wsc-ui-20080724/
<Zakim> rob, you wanted to echo Sean's comment; many websites use HTTPS login even though the content isn't sensitive. As Tom says, the end-user somehow makes a decision about what is
rob: there is a difference
between logging in to hotmail, where everything subsequent to
login is done in the plain anyway
... there is an education of the end-users to do, to allow them
to use some kind of login that uses https for that kind of
thing, but not use it for banking, I don't think we should ban
this completely
francois: but shouldn't we put
the load on the CP in that if they don't need https they
shouldn't use it
... but there is more than that - https is used to protect
content in both cases
sean: I agree with most of what Rob says - https is secure from the user to the operator then from operator to Content Provider - so if you trust your operator you are probably OK if not you should not be using HTTPs through a proxy
jo: points out that Dom pasted the link: http://www.w3.org/TR/2008/WD-wsc-ui-20080724/
francois: we should take a look at this
francois: we seem to have assigned all the comments so go ahead and discuss on the mailing list
<hgerlach> great, bye!;-)