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

<DKA> trackbot-ng, just f-ing do it.

<trackbot-ng> Date: 11 October 2007

<DKA> jo, are you going to join us on the call?

<nacho> zakim Ignacio_Marin is me

<matt> Scribe: Matt

<scribe> ScribeNick: Matt

Charter 2 Transition Status

DKA: How many people have correctly re-upped into the group?

<Kai> didn't that happen a while ago?

DKA: Everyone needs their AC rep to resign them up.

<jo> +1

Bryan: How do we know if we're done or not?

DKA: The participants page shows the old people. Not sure what to look at for it.

Matt: I can look around and figure it out.

<jo> current membership status

F2F Agenda

DKA: There are slots for lightning talks at the TP, specifically I was thinking task force talks, such as Content Transformation TF and the checker from the Checker Task Force.
... Asked Sean for a demo of the checker.

jo: Sean prefers to not, since he won't be there that day, prefers jo do it.
... Sean traveling on the day of the TP. I could do a lightning talk, might not be ready by then for demo.

DKA: Could put ourselves in for one, and talk through it if it's not ready.

jo: Should have agenda by now.

DKA: We have a draft, do you have a link?

jo: no, the timings are all wrong.

DKA: I've got the action on that.
... Not going to be possible to do much on it between now and next call.

<DKA> ACTION-570

DKA: Reassigning task to jo to work on agenda.

ack

skarim: Are we ready to have discussions around the HTML5 TF?

DKA: We need a task force leader on the HTML5 TF.
... Can you become the leader skarim?

Bryan: I could see if I can do it.
... Arun said he could do it, but he's in the midst of a transition.

DKA: Should be on the agenda then for Boston.
... Would be a key opportunity to bring HTML5 members into the discussion.
... Should be an action to arrange for a bit of a joint session with HTML5.

http://www.w3.org/2007/11/07-TechPlenAgenda.html

<scribe> ACTION: Matt to look into joint meeting with HTML5 regarding Mobile Requirements for HTML5 work [recorded in http://www.w3.org/2007/10/11-bpwg-minutes.html#action01]

<trackbot-ng> Created ACTION-576 - Look into meeting with HTML5 regarding Mobile Requirements for HTML5 work [on Matt Womer - due 2007-10-18].

DKA: We want to get Chris Wilson or Dan Connolly into our meetings on Monday.

Task Force Reports

DKA: We need to make a resolution to publish the problem statement update in order to make it before the moratorium

Bryan: The BP's might be out of sync with what is currently deployed. It might be a good time at the F2F to talk about the status of the BP.

DKA: I think that's in the BP Doc 2.
... Jo, status of the Content Transformation TF?

jo: Pressing on, various things on the cooker. Would like to request that this group put the latest draft of the problem statement forward as a W3C note.
... Now focusing on the guidelines.

DKA: The TF has reached consensus on publishing?

jo: Yes.

DKA: let's have a resolution and move the document out.

<DKA> PROPOSED RESOLUTION: latest draft of CT problem statement to be published as working group note.

<srowen> +1

<jo> +1

<nacho> +1 for me

<SeanPatterson> +1

<DKA> RESOLUTION: latest draft of CT problem statement to be published as working group note.

DKA: Is the CT problem statement going to be revised?

jo: It's good enough, might be revised, but don't see it needing it.

<jo> Problem Statement

DKA: And the guidelines? The doc itself is a shell at the moment.
... What is going into that doc is on the mailing list. That's the current status?

jo: Yes. Discussing numerous things at this point.
... We're talking about things like going through various proxy/transformation servers, and we're looking at how we can be robust about that. Looking at the HTTP armory to see what capabilities are available.
... Looks to me at first pass that we have an adequate range of HTTP based mechanisms to do that.
... Haven't assigned mechanisms for tasks that need to be done. A task that needs doing for instance is: you may correct my markup but not reformat my content. We have a rough idea how to do it, but no mechanism to do it with yet.

DKA: If we publish this draft, should we be engaging with W3C PR types?
... If we are issuing a draft of the problem statement I'm thinking we might want to engage the W3C communications team to do a kind of media advisory on it. Show that the W3C is taking a lead on this topic.

<scribe> ACTION: DKA to send a note to Marie-Claire regarding PR for the Content Transformation Task Force Problem Statement Note publication [recorded in http://www.w3.org/2007/10/11-bpwg-minutes.html#action02]

<trackbot-ng> Sorry, couldn't find user - DKA

<scribe> ACTION: dan to send a note to Marie-Claire regarding PR for the Content Transformation Task Force Problem Statement Note publication [recorded in http://www.w3.org/2007/10/11-bpwg-minutes.html#action03]

<trackbot-ng> Created ACTION-577 - Send a note to Marie-Claire regarding PR for the Content Transformation Task Force Problem Statement Note publication [on Daniel Appelquist - due 2007-10-18].

DKA: Anything else from CT TF?

jo: Nope.

srowen: would like to release a binary of the mobileOK checker, and include it on a post on our blog

DKA: Yes, makes lots of sense.

Matt: Which blog?

srowen: The MWI BP blog.

http://www.w3.org/2005/MWI/BPWG/

DKA: thought there was going to be a post on the no transform header? Anything happen to it?

jo: It was floated as an idea but no one has done anything on it.

Matt: I can write it if there's an opinion logged somewhere...

jo: It's in the CT group, which hasn't discussed it at all.

<srowen> (we can't just plagiarize dotMobi's post? :) )

<jo> +1 to plagarising myself

<jo> (is that possible?)

DKA: Do we need a resolution to support you in publication of the binary?

jo: If it's the first publication, yes.

DKA: Is it a document?

jo: I believe we should have a resolution from the group that it is going out.

DKA: I don't think we need to have a resolution each time we update the binary. It's something that gets updated a lot.

Matt: If it were a document, you'd resolve on the first publication but not each step in between.

<srowen> PROPOSED RESOLUTION: Publish mobileOK Basic checker code as it exists in CVS today as a first "alpha" release and publicize it on the MWI BPWG blog

<DKA> +1

<SeanPatterson> +1

jo: When publishing we'll put a note out with a list of known problems, etc?

srowen: Yes.

nacho: I will have a user manual for the mobile OK checker for next Tuesday. Should we wait for that?

srowen: Yes, I'm happy to wait if you're about to finish it.

nacho: Will send it to the TF to review by Tuesday.

<srowen> PROPOSED RESOLUTION: Publish mobileOK Basic checker code as it exists in CVS next Tuesday (including Nacho's documentation) as a first "alpha" release and publicize it on the MWI BPWG blog

<srowen> RESOLUTION: Publish mobileOK Basic checker code as it exists in CVS next Tuesday (including Nacho's documentation) as a first "alpha" release and publicize it on the MWI BPWG blog

LC3 comments on MobileOK Tests 1.0

DKA: Have these been inputted into the comment tracker?

srowen: Yes, all that I know of.

<jo> LC-3 comments

DKA: Just six comments so far.

http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mobileOK-basic10-tests-20070928/1859 -- Laurens

srowen: Long thread on this one, will summarize: The question is what gets sent in the accept header during tests? the doc says we send a list of content types that the DDC can handle.
... Laurens point is that that isn't correct for requests for an image for example.
... That is perhaps the desirable behavior, but he's claiming it's wrong.
... The onus is still on the server to send you the right thing. If the server sends you a style sheet when you're looking for an image, then that's wrong on the server side.
... We've found that mobile browsers don't customize their content type.
... Laurens says this disables some content negotiation.

<jo> end of the relevant thread

srowen: One might want a table instead of a graphic of the table. But to me returning HTML in an image URI for instance isn't done in practice.
... Two options: reject this comment or modify the document to say that the headers should be right, but might entail another last call.
... Dom doesn't think that changing that would require another last call.
... So I'm kind of in favor of "fixing" this, even though I don't really think it's broken.

jo: I'm not willing to do another last call on MobileOK...
... Every single browser we've looked at sends in some circumstances the entire set of headers.
... There is only one browser we've found that restricts it.
... If we didn't specify it the way we do then we wouldn't pick up on erroneous browsers.
... Dom's test shows up as completely broken for instance on the webkit browser.
... I think there are no grounds for changing this.

srowen: I'm okay with that, but there are a few subtleties.
... but this wasn't a best practice for not doing this, it was unintentional.
... I would like to agree that it would be nice if all browsers customized their accept headers.
... I disagree with his assertion that not doing this is wrong though.
... If we can weave those into the decision I'd agree.

jo: I think we have said consistently all along that these tests aren't about browsers, but about testing the interoperability of servers.
... Every other comment on browsers we've said it's not about browsers and their behavior.

srowen: My point was that this is picking up bad server side behavior...

<jo> scribenick: SeanPatterson

<matt> srowen: I make my resource available as an HTML page or an image, and that could be a problem with some browsers and that this would highlight it.

<matt> srowen: It's something we're accidentally testing for.

Jo: There are lots of things we pick up in the tests either way.

<DKA> PROPOSED RESOLUTION: we "resolve no" on LC-1859.

<srowen> PROPOSED RESOLUTION: Resolve 'no' on LC-1859 with apologies. Behavior as specified does not contravene HTTP. In practice, it is consistent with most mobile UAs behavior and is desirable on practical grounds for a tester to emulate. It would be nice if all UAs did in fact tailor their Accept header to the type of resource being requested.

<srowen> PROPOSED RESOLUTION: Resolve 'no' on LC-1859. Behavior as specified does not contravene HTTP. In practice, it is consistent with most mobile UAs behavior and is desirable on practical grounds for a tester to emulate. It would be nice if all UAs did in fact tailor their Accept header to the type of resource being requested.

DKA: I don't think we should apologize.

<Kai> :-) battling resolutions

<jo> PROPSOED RESOLUTION: LC-1859 We don't think that the suggested behaviour is mandated in the HTTP specification or that in our test sample of real browsers any browser other than Firefox actually changes its Accept header in this manner for both CSS and images, the majority do neither. Consequently the document remains as is. It should not be inferred from the way the checker behaves that real browsers either should or should not behave that way.

<jo> PROPOSED RESOLUTION: Resolve 'no' on LC-1859. Behavior as specified does not contravene HTTP. In practice, it is consistent with most mobile UAs behavior and is desirable on practical grounds for a tester to emulate. It should not be inferred from the way the checker behaves that real browsers either should or should not behave that way.

Jo: HTTP spec contains many inconsistencies.

Sean: Isn't this what the accept header should be used for

<Kai> Jo, could you post the URI?

Jo: HTTP spec says that server is no required to pay attention to accept header

<DKA> +1 on the last proposed resolution. Can we go home now?

Bryan: Useful to have discussion on accept and issues around it
... Many browsers just use a star in the accept header

<Kai> However, that is certainly not a good practice either :-)

<jo> [Jo drones on about how 14.1 (Accept) of HTTP appears to be in flat contradiction to 10.4.7 (406 response)]

<jo> RESOLUTION: Resolve 'no' on LC-1859. Behavior as specified does not contravene HTTP. In practice, it is consistent with most mobile UAs behavior and is desirable on practical grounds for a tester to emulate. It should not be inferred from the way the checker behaves that real browsers either should or should not behave that way.

<DKA> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/open

Subject: Actions
... ACTION-571

Jo: This one can be closed.
... I'll close it.

<jo> RESOLUTION: CLOSE ACTION-571

DKA: Need to find out if people are coming to Seoul meeting.
... I'll take the action

<jo> ACTION: DKA to change Seoul questionnaire [recorded in http://www.w3.org/2007/10/11-bpwg-minutes.html#action04]

<trackbot-ng> Sorry, couldn't find user - DKA

<jo> ACTION: Dan to change Seoul questionnaire [recorded in http://www.w3.org/2007/10/11-bpwg-minutes.html#action05]

<trackbot-ng> Created ACTION-578 - to change Seoul questionnaire [on Daniel Appelquist - due 2007-10-18].

<jo> action- 4

DKA: Dates are March?

Subject: ACTION-572

Jo: Can be closed.

Subject: ACTION-573

Jo: Need to tell people to get on with it.

Subject: ACTION-574

DKA: Not due yet--due on the 16th.

<jo> ACTION-574 CLOSED

<trackbot-ng> Sorry... I don't know how to close ACTION yet

Jo: Should action Mike on problem statement

<jo> ACTION: Mike to request transition of current CT Problem Statement to W3C NOte [recorded in http://www.w3.org/2007/10/11-bpwg-minutes.html#action06]

<trackbot-ng> Sorry, amibiguous username (more than one match) - Mike

<trackbot-ng> Try using a different identifier, such as family name or username (eg. mchadwic, mike)

<jo> ACTION: Smith to request transition of current CT Problem Statement to W3C NOte [recorded in http://www.w3.org/2007/10/11-bpwg-minutes.html#action07]

<trackbot-ng> Created ACTION-579 - Request transition of current CT Problem Statement to W3C NOte [on Michael(tm) Smith - due 2007-10-18].

<jo> Action- 7

DKA: Any other business?

<jo> Scribe: Matt, SeanPatterson

<jo> s/Jo drones on/Jo drones on/

<jo> [Meeting Closed]

<trackbot-ng> Tracking ISSUEs and ACTIONs from http://www.w3.org/2005/MWI/BPWG/Group/track/

- DRAFT -

Mobile Web Best Practices Working Group Teleconference
11 Oct 2007

Attendees

Contents

Charter 2 Transition Status

F2F Agenda

Task Force Reports

LC3 comments on MobileOK Tests 1.0

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Mobile Web Best Practices Working Group Teleconference 11 Oct 2007

Attendees

Contents

Charter 2 Transition Status

F2F Agenda

Task Force Reports

LC3 comments on MobileOK Tests 1.0

Summary of Action Items

Scribe.perl diagnostic output

Mobile Web Best Practices Working Group Teleconference
11 Oct 2007