Mobile Web Best Practices Working Group Teleconference -- 18 Dec 2007

<trackbot-ng> Date: 18 December 2007

Review of Requirements in Current Draft

<jo> Scribe: Jo

jo: bryan - did you get the chance to catch up on comments on section 2

bryan: no I didn't get the chance yet ...

<kemp> Scribe: kemp

jo: section 3 of the current draft... we need to combine the perspectives in sections 2 and 3... we have content looking at each leg of the journey, while brian's contributions are formatted differently... bryan, can we reformat yours?

Bryan: i don't object, but i imagined there would be text around these -- i was trying to outline basic capabilities and then build use cases around them... but i am fine with incorporating them

<jo> Commentary on Section 2

jo: ok... let's go through these quickly... 2.1.1... not clear what "service features" are... bryan?

Bryan: service features are what the proxy does to the extent that we expose user controllable features... not a strong requirement, some proxies may operate implicitly

jo: ok... i think we should put something in the document about the user controlling the proxy, and say that the user may control the proxy in a variety of ways
... but we don't want to specify the nature of the interaction...

Bryan: that's exactly right... i expect the CT providers will come up with ways to express this at the application layer at least... if there is a protocol layer, maybe we need to specify it...

jo: ok... moving on to 2.1.2. misleading to say "highest quality" -- we don't want the maximum size/color depth for images... what does this mean?

Bryan: an example specific to markup languages... if you are going to change the markup, you want to go to the highest quality markup -- the one with the most user experience features (eg, use XHTML over WML where possible)

jo: i think the language we want here is something like "most consistent with the author's expectations"
... ok, under 2.1.4... is what we are saying that we should allow to CT to fake the user agent and accept headers or not?

Bryan: i think we are... we should allow the user to tell the proxy "be transparent" and the proxy should honour that request... expect when that conflicts with the users' need for service

jo: ok... under 2.1.5, original representation... the question arose: how (technically) does one achieve this?

Bryan: well, many services are stateful... so you can't make multiple requests... most likely thing to do is cache...

jo: the thought arises as to how you would signal from the user agent that you want the cached copy, and not the transformed copy, and secondly, how long the CT should maintain the cache for
... would be interesting to know if this has been implemented anywhere

Bryan: well, first, honour the cache-control header... second, an implementation specific decision based on resources available (disk, memory)

jo: it seems you can't assume the original representation is available necessarily

Bryan: well we would do something like cache things for the expected session lifetime

jo: what would you do about distinguishing a second request for the transcoded representation, as opposed to the original representation?

Bryan: i didn't have a particular approach in mind -- i was focusing on the ability to do this at the user level. maybe a link at the bottom of the page to the original

kemp: that's what we (google) do now

Bryan: just to be clear, i didn't intend for us to say _how_, just to say that there should be a way

jo: i just think it's going to be hard to introduce new http mechanisms...

AndrewS: i don't actually see an implementation difficulty. given the way CT's work, the page will be cached anyway (for the session lifetime)

jo: right, but what if the cache-control headers say "no-cache?"... i am concerned we would end up specifying something complex for a limited usecase...
... but i do understand it's implemented already and people do want this

AndrewS: can we just leave out the implementation details?

jo: yes, but i think we should be clear that we don't think this will be implemented by ad-hoc http headers... so if we are saying the original document should be maintained, we should be clear about the case where cache-control: none is set

<Bryan> we need to make a statement so the readers understand we will not propose new headers, but expect that the expressed need will drive needed standards work and market innovation

jo: moving on to section 2.3.1.. i think this leaves the door open to CT proxies doing what they like... the question in my mind is "who knows better" and why should the origin server accept that the CT knows what is dangerous and what is not
... my preference is that we don't say that it is OK to override the preferences of the origin server, but that we say unless the origin server has good reason, it doesn't specify no-transform

kemp: imagine no-transform + html on a wml phone

jo: ok, but if they put no-transform, presumably they are aware, and don't want a proxy getting in the way...

kemp: i wonder what we should do if we know markup is going to crash the phone? display a page saying that ? pass it through? refuse?

Bryan: i think there is an escape clause there - so that we can show a user a message saying "this won't work on your phone, do you want us to adapt it?".
... so basically, does a user have the right to override no-transform?

jo: interesting... i suppose what it comes down to is that i believe the origin server should be in a better position to decide -- maybe they have a fancy application scheme that the proxy doesn't know about and the proxy will harm
... i don't think we can recommend violation of what HTTP says -- if HTTP says no-transform, we can't say otherwise...

Bryan: i think the point i was trying to raise is that there are two actors who are in control -- the content provide and the user -- the presumption is that the user should have an equal role.

<dom> [does a user have the right to disable style sheets on a web page in her browser? Yes, she does - I think that when a proxy works directly on the user behalf, it works in the same spirit]

Bryan: maybe a preference setting that tells the CT, as a default preference, if something is going to break, do your best on my behalf...

<jo> [but Dom, the Proxy is not acting with the users consent in many cases]

<dom> [I was alluding to what I read from Bryan, i.e. when the user is asked for consent]

kemp: but in the case bryan offered, it is acting with user consent

<jo> [tks Dom, narrowing it down in that way works]

jo: right so if we narrow it down to those cases where there is user consent that's ok

Bryan: i think we should make a statement about user consent... can it be implicit? if i'm configured to use a proxy, that proxy is acting as my user agent and implicitly
... i want it to perform actions on my behalf... by using the proxy i am asking for it to provide the best experience possible

jo: the problem is that this assumption has been made in the past and as a result some origin sites are not working because the proxies are getting in the way...
... so there is an issue of consent here... i think we need a way for origin servers to strongly say, "look, get out of the way"

Bryan: i think the proxy has a role as a user agent and some preferences may be implicit, but that we need to do a better job so that these situations don't arise

jo: ok... moving on, we'll likely come back to this. i don't have any other points on section 2. does anyone have anything on section 3 that i should consider while doing the editorial work of merging section 3 into 2?
... ok anything in general from anybody? if not, let's close the call...

Bryan: one thing i didn't put into the requirements is the ability to escape the behaviour for certain sites based on preconfigured knowledge so that we don't mess things up for specific sites.
... wildcards for example to indicate a certain domain doesn't stand up to transformation well...

jo: yes i think we should at least mention policy based approaches, but it's not up to us to specify their use... but we should mention them -- much the same as the interaction with the user.

Next Meeting

jo: looks to me that the next meeting will be the 8th of january

AOB

<jo> [meeting closed with Festive Greetings all round!]

<jo> [Thanks to Aaron for scribing]

<jo> ACTION: Jo to produce new draft - due 8 Jan 2008 [recorded in http://www.w3.org/2007/12/18-bpwg-minutes.html#action01]

<trackbot-ng> Created ACTION-615 - produce new draft [on Jo Rabin - due 2008-01-08].

- DRAFT -

Mobile Web Best Practices Working Group Teleconference

18 Dec 2007

Attendees

Contents

Review of Requirements in Current Draft

Next Meeting

AOB

Summary of Action Items

Scribe.perl diagnostic output