Mobile Web Best Practices Working Group Teleconference -- 20 Nov 2007

<trackbot-ng> Date: 20 November 2007

<jo> Scribe: magnus

Guidelines Draft

jo: main topics are draft of action 581

New Member

andrew: Hycho Gerlach (sp?) from Vodafone Group will be joining the team

jo: Rhys has announced that he is unable to continue chairing this group due to work duties. Jo is interim chair. Contact Jo to propose others.

Back to Guidlines Doc

sean: looks like a good start

jo: will put into pretty format after this meeting
... waiting for feedback during this meeting

bryan: buried preparing for OMA meeting. Will get comments to you by the end of the week.

andrew: haven't had a chance to review. Will do so over the next few days.

magnus: haven't had a chance to review yet

<jo> Draft in Text Form

jo: let's do a quick runthrough now and then review it again after it has been formatted
... am I capturing the various contriobutions in a fair and accurate way?
... starting with Magnus' document. Significant contribution from Sean and others.
... make sure that they feel that their contributinos are fairly represented

<jo> wanted to make sure that the statements of advantages from Aaron and Sean both were reflected in the landscape doc

jo: haven't followed the original doc headers. Using a more natural flow based on who does what.
... in reflection of comments, especially from Brian, about behavior of prxies, I hope that that point is fairly reflected
... it's reasonable that administrative arrangemnts can be part of the behavior of the transforming proxy
... user interaction can affect the transforming proxy or the server itself. That is not a very big part of what this document says now.
... If anybody feels differently we need to elaborate that.

Brian: there are 2 basic approaches: one inside and one outside the technology
... focus is on what the user agent can know and not what the user knows

jo: document focuses on interaction with user-agent
... there is not much there on the subject of direct interaction with the user
... The discussion focuses primarily on interaction with a server that is assumed to be adapting or with multiple representations
... says nothing about redirection to specific mobile content. Looking for contributions here.

Sean: is that such a big deal?
... are we talking about CT unaware sites?

jo: my concern is that if we land on a universal home page
... and are redirected, a varying header may not be present
... how should a mobile experience signal that it is a mobile experience?

Sean: you are looking for direction

Jo: yes, for instance google.m may not have a varying header
... the algorithm may not work because the proxy doesn't know what it is reaching

We need a use-case analysis anyway

scribe: Jo: there are specific sections in the HTTP spec stating how to extend the protocol
... are we at liberty to introduce new headers?
... looking for comments

Bryan: be careful about addition of new headers
... content providers may want to becomae transformatino aware
... is "preserve headers" an example of something new?

Jo: yes
... another is "no-transform, allow-reencode..."

Bryan: whenever we introduce a new header there are going to be conditions that we need to address
... it should not break things that depend on header insertion
... within bounds the stuff we add may influence the bahavior of proxies
... if we do go down the path of adding headers it is going to be complex to assess the consequneces

Jo: valid point. There are differences in the type of transformations you undertake.
... you may simply compress files - that's a transformation
... as is removing white space, transcoding images, etc
... we need something richer than "no-transform".
... We need a richer vocabulary. We need to invent something here.

Sean: It will be difficult to add new non-x-headers

<Andrew> Is this what the use of Vary tag could do?

Sean: are we talking x-headers ?

Jo: there are 2 different aspects
... 1) inventing new headers
... 2) adding new value for existing headers
... extending cache-control headers seems less extreme
... otherwise we have rather blunt stuff

Sean: you think it's more about adding stuff to cache-control?

Jo: yes, that's right
... HTTP spec provides an example of how to extend cache-control header
... however, it's an interpretation question

Sean: other headers that are extensible?

Jo: It's thje obvious candidate
... It's backward compatible.

Bryan: I think we might need to do is provide some introductory remarks
... transfer encoding is not in scope

Jo: I wish I could agree

<jo> A proxy MUST NOT modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request: - Content-Encoding - Content-Range - Content-Type

Bryan: there's a difference between content- and transfer-encoding
... we need to explain this
... be careful that we don't disable all optimization of HTTP

Jo: that is what we are tryiong to do
... we need to be careful. Point taken.
... The thing we need to revisit is see what people think
... Can we add value without re-inventing things.

<jo> ACTION: JO to raise an issue on how useful this spec will be without HTTP extensions of some form [recorded in http://www.w3.org/2007/11/20-bpwg-minutes.html#action01]

<trackbot-ng> Created ACTION-602 - Raise an issue on how useful this spec will be without HTTP extensions of some form [on Jo Rabin - due 2007-11-27].

Jo: please rview the text with this in mind.
... RFC 2295
... Has anybody read this? It's experimental but implemented in Apache as a module.
... We might consider borrowing from this.
... We can use some of the ideas.
... They are trying to do similar things.
... There are possibilities here. Keep this in mind while reading the text.
... There is an extensive list of contributions to this text.

<Andrew> Zarkim, unmute me

Andrew: I wonder whether you can give us a quick synopsis of RFC 2295?

Jo: The now legendary RFC 2295 discusses a number of things. Content negotiation, variants, ...
... We are interested in the fact of that the descriptions can include intended media types
... i.e. "this is intended for media type handheld"
... Our guess is that it has some degree of accpetance in the mainstream.
... Feature negotiations are not implemented but worth reading.
... Shows what people have thought in this area. Features are things like "what language?", etc
... The introduction is moderately readable.
... It explains the conmtext.
... At this point, what remains is the text as proposed.
... Is there any point in running through it now?
... Does anybody want to go through the document?
... people seem to want to read it first.
... What is open on the problem statement?

Issues and Actions

<jo> Issues and Actions on Problem Statement

<jo> http://www.w3.org/2005/MWI/BPWG/Group/track/products/11

<jo> Close ISSUE-221

Close ACTION-563

Close ACTION-564

Close ACTION-565

Jo: on the guidelines we have an extensive list of actions and issues

<jo> Open Issues and Actions on Guidelines

<jo> ISSUE-187 Leave open

<jo> ISSUE-220 Leave Open

<jo> ISSUE-222 Leave Open, people should study the TAG finding

<jo> ISSUE-223, ISSUE-224 LEave Open

Close ACTION-540

Close ACTION-551

Close ACTION-552

Close ACTION-558

Close ACTION-566

Close ACTION-575

ACTION-581 Leave Open

AOB

Jo: this call continues to be weekly
... On Tuesdays.
... Rhys has announced his departure from the task force on the email list.
... Who is a good candidate to take over the chair?

<jo> [thanks to Magnus for scribing]

<jo> s/I am capturing/I am trying to capture/

<jo> s/handheld" in the URI/handheld"

- DRAFT -

Mobile Web Best Practices Working Group Teleconference

20 Nov 2007

Attendees

Contents

Guidelines Draft

New Member

Back to Guidlines Doc

Issues and Actions

AOB

Summary of Action Items

Scribe.perl diagnostic output