Mobile Web Best Practices Working Group Teleconference -- 23 Oct 2007

<trackbot-ng> Date: 23 October 2007

<jo> zskim, code?

<rob> zakin, aabb is rob

<scribe> scribe: SeanPatterson

<scribe> Scribe: SeanPatterson

<Rhys> Scribenick: SeanPatterson

Rhys: Thank you to Jo for leading last week's meeting.

Problem Statement

<jo> [no problem]

Rhys: Jo took the proposed prob statement to the full BP group

The BP group is happy if the task force is happy

There is some problem with the title.

BP group agreed prob statement should be published as note

Mike said that comm group didn't like the title

CT TF and BP group don't really care about the title

There is not a problem with the document

In order to keep everyone happy, we should change the name of the prob statement

Possible name changes: CT Challenges or CT Landscape

Jo: Preference would be Landscape

<jo> PROPOSED RESOLUTION: Change title to Content Transformation Landscape

<kemp> +1 landscape

Rhys: Happy with Landscape

<rob> +1

<Magnus> +1 landscape

Andrew: Not wild about either title, but we should just get it out

<jo> RESOLUTION: Change title to Content Transformation Landscape

<jo> Revised Document

Rhys: Next step is to go ahead and publish

Jo: Prob statement is described as W3C working group note and is publishable
... is there a difference between working group note and W3C note?

Rhys: No aware of difference

Jo: Didn't see anything in process document about W3C note.

Should publish as working group note

Rhys: Agree

Jo: Working group note does not imply support of full W3C
... Let's just call it a working group note

Rhys: Working group notes are reference-able documents but have not been accepted by the entire W3C

Should publish as working group note.

Rhys: Doesn't seem to be any difference between W3C and working group note

<jo> PROPOSED RESOLUTION: Publish document referred to above

Rhys: Last we had a resolution about publishing the prob stmt

<Andrew> +1

<jo> RESOLUTION: Publish document referred to above

Guidelines Document

Rhys: Draft is still an outline, hasn't changed. Thanks to contributors
... Want to check that the people who wanted to contribute have made their contributions

Is there any other material that others want to contribute?

Bryan: We will probably be making a submission.

Rhys: How soon?

Bryan: Very soon.

Rhys: What I'd like to start doing is flesh out the document with the contributions

Once we get it fleshed out we'll have some discussions about it

Magnus: Would like to see frequent revisions; best way for me to work

Sorry for not contributing more, but have been busy.

What is the schedule?

Rhys: Thought it might be possible to get a draft done by the moritorium on 10/31

Probably won't be able to get a draft done by then, however.

First working draft hopefully will be done after the F2F

Hopefully have a draft before F2F

Rhys: agrees that it is easier to work with frequent revisions

Still time to make contributions

Magnus: Won't be able to contribute in the month of October; should have time in November?

Rhys: That should not be too late.

Jo: Should make first public working draft as soon as possible

Last call draft scheduled for before Christmas

Magnus: Would like to see an early revision even if there are missing parts

Jo: Create a non-note document that contains contributions about the basic approach

Rhys: Is the public editor's draft stealthy enough to do this?

Jo: Would rather do it on the list.

Rhys: Just need to make sure that we get out revisions so it is not to complicated

Magnus: Can we have a date where the first draft is ready?

Rhys: Sometime after F2F in early November

Magnus: Can do some work in early November, not week after F2F and then can contribute again the last 2 weeks of November

Jo: Think we can put together an editor's draft before the F2F in the next week or so
... Volunteer to put together the editor's draft

Rhys: That sounds good

Magnus: That works for me

Rhys: Do you need an action

<jo> ACTION: Jo to promote discussion on the list and then produce editors draft based on discussion [recorded in http://www.w3.org/2007/10/23-bpwg-minutes.html#action01]

<trackbot-ng> Created ACTION-581 - to promote discussion on the list and then produce editors draft based on discussion [on Jo Rabin - due 2007-10-30].

Rhys: Should we go through the current action items and issues?

Jo: There are quite a few actions items that probably should be closed.

However, maybe we should discuss what is going to go in the editor's draft since there is a good turnout today

Rhys: Do you want to lead discussion?

<Rhys> Magnus's original contribution http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Sep/0014.html

Jo: Sure; we need to get straighted out the kinds of things that the various actors need to say

<Andrew> Also case of Browser <--> CT <--> CT ... CT <--> Content server

We can pick out whose going to say what to whom and am confident that we can say these with HTTP

<jo> Attachment to Magnus's email

Jo: Let's talk about Magnus's contribution

Magnus: I'll walk through it

The basic scenario is with a single CT proxy; there are other cases with more than on CT proxy

Trying to make it easy for now, but we need to handle multiple proxies eventually

First case is client to CT proxy

Jo: Makes good sense.

Browser also needs to be able to talk to server; which is traditional case

Browser needs to be able to tell server that it wants a desktop experience

Magnus: Didn't list this because it is kind of implicit

<Rhys> +1 to client being able to say that it wants to have a mobile or desktop experience

Magnus: There is a logical and physical comm going on.

Jo: It is about the experience as opposed to transforming the content

Magnus: Intermediaries should not screw up comm between client and server

<Andrew> Is that not covered by point 2?

Jo: Add another section about how the client can tell the server what kind of experience it wants: desktop or mobile

Magnus: Could add another section called logical communication

about what client and server need to say to each other.

Jo: Would be simpler to say there are 6 kinds of communication going on

Magnus: How about an origin server that doesn't understand; always sends desktop content
... In this case the CT proxy could provide a stylesheet for the correct media type

Rhys: Magnus' example is a good one. Jo's suggestion of putting a couple of new subsections is a good idea.
... One way to talk about this is to have the client talk about what it wants
... instead of who it talks to

We can get what Jo is looking for by adding a couple of subsections

Andrew: I think it is necessary describe what the client can say to the content server
... Likes Jo's idea of a logical connection between browser and content server

Rhys: What would help for next draft?

<Bryan> can't talk right now...on the bus. but i agree that somtimes the client will bypass the proxy

Jo: How much effort do we want to put in on Magnus's idea about the proxy amplifying or improving the server's response?

of putting a stylesheet in to help out the client

Magnus: CT server can add value to request to server

CT server can step in and improve response in another of ways

CT server can also screw up request and response.

Need to find out when it is OK to add value when when it is not OK to add value

Jo: Proxies can add value for dumb servers
... There is a higher level of value-add. Should we aspire to that in these guidelines?

Volume one of the guidelines could be just how everyone gets out of everyone's way

Volume two could be a higher level of CT

Rhys: Agree with Jo; we should just focus on guidelines to keep things from breaking

<Bryan> want to reserve judgement on that

Rhys: Does anyone disagree that we should just be doing basic things in the first guidelines document?
... The communication between various parties should flow up and down.

There shouldn't be distributed transformation in the first guidelines document

Jo: These guidelines will be about preventing transformation from happening anywhere or facilitating it happening in just one place.

Bryan: Not sure I agree with this. Want to reserve judgment on it.

Magnus: Also uncertain about Jo's last statement that there shouldn't be distributed transformations.

Need to handle the case where neither the client or server knows that the proxy is there.

Rhys: That is an important use case.
... Propose that we start to build the guidelines that assume transformation occurs in only one place

and see if anything else comes out of it.

<jo> [thanks Sean for Scribing (again!)]

<jo> Chair: Rhys

- DRAFT -

Mobile Web Best Practices Working Group Teleconference

23 Oct 2007

Attendees

Contents

Problem Statement

Guidelines Document

Summary of Action Items

Scribe.perl diagnostic output