Mobile Web Best Practices Working Group Teleconference

Jo: Jeff S has escaped the autumnal New York landscape has gone to Trinidad

<francois> [ a few profs from the COSTAATT Dept of Info Tech]

Jo: he's on a sabatical in Trinidad so we have some observers from T&T

<brucel> hi Trinidad and Tobago peeps!

<jo> from the College of Science, Technology, and Applied Arts of Trinidad and Tobago

<jeffs> <wavings/>

<jo> welcome to our observers

<jeffs> tnx

Face to Face 9 - 11 December in London

Jo: My proposal is to spend a day on LC comments from ABP and one on CT leaving half a day for admin
... if you have any other agenda items let me know

Clock changes

PhilA: Europe will be 31/10
... (last Sat in October)

<francois> http://www.timeanddate.com/worldclock/city.html?n=179

<francois> 1 November 2009

Jo: so we end more or lessa t the same time

Update on BP 2.

Jo: We're on target for transition this week?

Francois: Yes - should be later today

Jo: Anything else on BP 2?

Adam: Not from me. Thanks to fd for sorting out the 'cleaning up stuff'

Addendum

FD: Philipp's comment is that the name addendum suggests that we're adding more normative content - what it needs is something more like what it is

<francois> Suggested title: Evaluation criteria for MWBP adherence

francois: Where I agree is that addendum suggests that we're extending it which we're really not.

Jo: SO what shall we do Francois?

Francois: Kai isn't here. What do you think Jo?

Extended Mobile Best Practice Evaluation?

Extended Mobile Best Practice Evaluation and Conformance?

Jo: What's wrong with calling it an addendum again?

Francois: It sounds as if we're extending BP in a normative way

Jo: I'm sort of happy with addendum. Can we just make it clear that it's not normative?

PROPOSED RESOLUTION: Stick with the present title

<EdC> Does this mean an additional explanatory sentence at the beginning of the document?

<jo> PROPOSED RESOLUTION: Stick with Addendum as title of the document

<francois> PROPOSED RESOLUTION: Stick with Addendum as title of the document because the document contains more than just evaluation of conformance to Best Practices

<jo> Current Draft

PhilA: Current title is Addendum to Mobile Web Best Practices

Jo: Shall we change the abstract to be more clear

<jo> current abstract:

<jo> This document supplements W3C Mobile Web Best Practices 1.0 [MWBP] by providing additional evaluations of conformance to Best Practice statements and by providing additional interpretations of Best Practice statements.

<jo> proposed abstract:

<jo> This document supplements W3C Mobile Web Best Practices 1.0 [MWBP] by providing additional non-normative evaluations of conformance to Best Practice statements and by providing additional interpretations of Best Practice statements.

Extended evaluation and interpretation of MWBP

<EdC> Is the word "clarification" what is missing?

<jo> ISSUE: Addendum to BP reads as though it is a normative extension - PH requests we find a new name for it

<trackbot> Created ISSUE-300 - Addendum to BP reads as though it is a normative extension - PH requests we find a new name for it ; please complete additional details at http://www.w3.org/2005/MWI/BPWG/Group/track/issues/300/edit .

CT Guidelines

<francois> List of last call comments

Jo: Would like to agree the text of LC comment resolutions. Want to scoot through at one per 15 seconds
... Can you give us an update on LC publication

Francois: No, it's going to ship today

Jo: Well then let's get on with it... and we'll come back to the CT landscape and test suite
... LC comment 2025 from Eduardo

<francois> LC-2025

EdC: I don't even remember writing that one...

Jo: I think we have done most of what is said there
... This dates back over a year
... would you be happy to accept that we have attended to the points over the last year

EdC: Yes

<jo> PROPOSED RESOLUTION: re LC-2025 we have attended to the main thrust of the comments here and the document reflects the commenters points more than it did at least

RESOLUTION: re LC-2025 we have attended to the main thrust of the comments here and the document reflects the commenters points more than it did at least

Jo: Moving on to 2043 from Mark Baker

<jo> LC-2043

<francois> LC-2043

Jo: He's saying it needs to be guidelines and not a protocol. I think we've done that and followed a number of very useful comments he made.
... It's resolved yes
... and to use existing text

<jo> PROPOSED RESOLUTION: ref LC-2043 resolve yes and use existing proposed response

RESOLUTION: ref LC-2043 resolve yes and use existing proposed response

Jo: LC-2097

<francois> LC-2097

Jo: That's on OPEF - Open Pluggabel Edge Services. Comment from Internet Architecture Board. We should make reference to the ?? discussion which we have done
... we have also discussed the content of RFC 2238 at great length

<jo> PROPOSED RESOLUTION: ref LC-2097 resolve yes and use existing proposed response

RESOLUTION: ref LC-2097 resolve yes and use existing proposed response

<francois> LC-2089

Jo: Next up is LC-2089
... proposed resolution is no as we don't specify that CT must take place

<jo> PROPOSED RESOLUTION: ref LC-2089 resolve NO, and use existing comment

RESOLUTION: ref LC-2089 resolve NO, and use existing comment

<francois> LC-2065

Jo: LC-2065 from WAP review. He writes a great column
... looks as if we have a partial resolution already
... On that one we're saying that we agree and have added an appendix
... no need for a formal resolution.

<francois> LC-2018

Jo: move on to LC-2018
... from Michael McQueen

Says title is uninformative. We agree and have changed the title of the document

<francois> LC-2050

scribe: LC-2050

From Eduardo

We are resolving partial on that in that we have moved some definitions around

<EdC> ok with me.

<francois> LC-2067

Jo: Next one from MNot. We've already resolved yes
... we have detailed why we're not following the SHOULD statements

<francois> LC-2003

LC-2003

scribe: from Luca P

We have resolved previously 'no' as only the text is open for discussion

scribe: the doc is not about how a transforming proxy should do what it does. Just the output

<francois> LC-2034

LC-2034 from Mark Baker

scribe: about the methods applicable and the response proposed is "we don't see any reason why"

So already resolved...

<francois> LC-2019

LC-2019

From Eduardo again

We have already resolved partial on that

<EdC> ok.

<francois> LC-2044

LC-2044

Resolved partial on already

The comment was that there is no way of determining whether the request is coming from a Web browser or not. WE did change the text a little as he's right.

<francois> LC-2069

LC-2069 from MNot. Already resolved yes

<francois> LC-1996

Removed the normative statement on web browser detection

LC-1996 from Luca

Have resolved no already

Although we comment that we have altered the relevant section a lot already

Francois: there are more similar comments

<francois> LC-2071

This is about no transform being respected. We've resolved no on this

<francois> LC-2072

LC-2072 also from Mark Not - resolved yes

<francois> LC-2073

LC-2073 from MNot. Resolved no on this occasion

Have we put mandatory heuristics on there now?

francois? No - this is about how to decide whether 2 URIs are the same website or not?

<francois> LC-2049

LC-2049 from Eduardo

Resolved no

<francois> LC-2017

We have resolved no on this

<francois> LC-2036

Again from Mark Baker and we have resolved no on this one

Mainly because we object to people using multiple Gets - we say it should be reduced to a minimum and refer to our feedback

<francois> LC-2053

This one is open

From Eduardo

We haven't got a specific response to this I'm afraid.

EdC: Hang on...

<brucel> Observers in Trinidad and Tobago might find this a welcome diversion from the excitement http://www.bbc.co.uk/weather/coast/shipping/

EdC: It seems that something will have to be found. But...

<jo> PROPOSED RESOLUTION: Ref LC-2053, resolve partial and respond that we hope the current version of the document addresses this

EdC: I see that at the F2F this was discussed. Let's close it
... happy with the resolution

RESOLUTION: Ref LC-2053, resolve partial and respond that we hope the current version of the document addresses this

LC-2005 is already resolved no, we can use the boiler plate response for this one

<francois> LC-2005

<francois> LC-2038

LC-2038 from Mark baker. We have resolved partial

Jo: We say it's not BPs it is guidelines

<francois> LC-2054

LC-2054 from Eduardo again. We have resolved no already

Francois: Its has the boiler plate on it

<francois> LC-2074

Jo: LC-2074 from MNot

we have resolved no to this

<francois> LC-2075

scribe: again about re-issuing requests

EdC: Content providers don't like it because it definitely messes up some applications

Jo: we don't prohibit it, just note that it upsets people
... we have already resolved no on 2074

<francois> LC-2037

LC-2037 from Mark Baker

We have removed all references to HTTP PUT now

<francois> LC-2076

LC-2076 from MNOt

scribe: we have resolved yes on this one and changed various items of text

<francois> LC-2039

LC-2039 from Mark Baker resolved yes

scribe: about consistency of HTTP Header and we agreed

<francois> LC-1997

LC-1997

from Luca - we have rsolved no

<francois> LC-2046

LC-2046 from Eduardo we have resolved yes

<francois> LC-2014

LC-2014 from Sean Owen have resolved partial

we said that what he was saying was prob out of scope

LC-2077 from MNot

<francois> LC-2077

Resolved no

We've said we're reflecting ucrrent practice and trying to sort it out

<francois> LC-2006

We have resolved no for LC-2006

<francois> LC-2040

LC-2040 from Mark Baker

we need to resolve this one

Mark's comment is that we propose a protocol and so should be in an I-D not a W3C Note so ...

<jo> PROPOSED RESOLUTION: ref LC-2040 resolve yes, and use proposed response

RESOLUTION: ref LC-2040 resolve yes, and use proposed response

<francois> LC-2078

<francois> LC-2007

LC-2078 from MNot we have resolved yes and clarified the doc

LC-2007 which we have resolved yes

Jo: This was about removing the part of he doc that referred to server behaviour

<francois> LC-2079

LC-2079 which we have resolved yes to

<francois> LC-2080

Moved into informative section

LC-2080 again from MNot and again resolved yes

LC-2041 from Mark Baker resolved yes again about origin servers

<francois> LC-2041

<francois> LC-2010

LC-2010 from Jose - resolved partial

<francois> LC-2011

LC-2011 alsp from Jos� resolved yes

<francois> LC-2009

LC-2009 - resolved yes

<francois> LC-2020

LC-2020 from Eduardo - resolved no

<francois> LC-2045

LC-2025 also from Eduardo resolved paryial

LC-2091 from Luca

<francois> LC-2091

REsolved no

Francois: We only resolved no because we didn't feel we needed to add text although we agree with the point

<francois> LC-2082

LC-2082 from MNot resolved yes

<francois> LC-2042

LC-2042 from Mark Baker - we agree with his point

<francois> LC-2083

LC-2083 from Mnot - about sniffing for error messages we resolved no

<francois> LC-2084

LC-2084 resolved partial

<francois> LC-2090

2090 from Luca we resolved no

LC-1998 again from Luca again resolved no

<francois> LC-1998

<francois> LC-1999

LC-1999 from Luca and we resolved no

EdC: just a second. Is 1998 really correct

actually we do endorse the heuristics

Jo: That is true - we should remove that last sentence from the reply
... thank you Eduardo for spotting that one

Francois: Anotehr thing - the application/xhtml+xml is not part of the list as it is not a clear indication of mobile content

LC-2048 from Eduardo

Jo: About adding things to the list of URIs. We haven't actually formulated a proposed response to this

<jo> PROPOSED RESOLUTION: On LC-2048, As discussed, the sole remaining URI Pattern is listed in Appendix E

RESOLUTION: On LC-2048, As discussed, the sole remaining URI Pattern is listed in Appendix E

LC-2000 from Luca - resolved no

Jo: mumbles on a bit...

LC-2022 already resolved partial from Luca

Jo: no text for this one

<francois> LC-2000

<francois> LC-2022

<francois> LC-2002

<jo> PROPOSED RESOLUTION: ref LC-2002 - text is, after considerable discussion the group decided not to recommend any URI patterns other than those listed in Appendix E

RESOLUTION: ref LC-2002 - text is, after considerable discussion the group decided not to recommend any URI patterns other than those listed in Appendix E

Jo: LC-2052 resolved partial from Eduardo about Doctypes etc.

<francois> LC-2052

<francois> LC-2021

LC-2021 also from Eduardo. Resolved basically yes

LC-2022 from Eduardo resolved partial

<francois> LC-2022

<francois> LC-2023

LC-2023 again resolved partial from Eduardo

<francois> LC-2085

LC-2085 from Tlr

Link re-writing

Jo: Who has a proposed response for me here?

<jo> PROPOSED RESOLUTION: Ref LC-2085 resolved yes, we note your comments and have added textt reflect your concerns

RESOLUTION: Ref LC-2085 resolved yes, we note your comments and have added textt reflect your concerns

LC-2028 no resolution as yet from Eduardo

Oh, maybe we do have a resolution

scribe: We're going to resolve yes

<francois> LC-2028

<jo> PROPOSED RESOLUTION: ref LC-2028 resolve yes, we have added text to this section that goes some way to addressing your concern

RESOLUTION: ref LC-2028 resolve yes, we have added text to this section that goes some way to addressing your concern

LC-2029 from Eduardo also pending

Jo: I propsoe the same answer as previous comment

<francois> LC-2029

<jo> PROPOSED RESOLUTION: ref LC-2029 resolve yes, we have added text to this section that goes some way to addressing your concern

RESOLUTION: ref LC-2029 resolve yes, we have added text to this section that goes some way to addressing your concern

<francois> LC-2030

LC-2030 - same again, resolve yes

<jo> PROPOSED RESOLUTION: ref LC-2030 resolve yes, we have added text to this section that goes some way to addressing your concern

RESOLUTION: ref LC-2030 resolve yes, we have added text to this section that goes some way to addressing your concern

LC-2015 from Sean Owen

<francois> LC-2015

Jo: I propose we say yes as previous ones

<EdC> It is yes because it has been taken almost as such in the CTG!

<jo> RESOLUTION: ref LC-2015 resolve yes, we have added text to this section that goes some way to addressing your concern

RESOLUTION: ref LC-2015 resolve yes, we have added text to this section that goes some way to addressing your concern

LC-2031 from Eduardo.

<francois> LC-2031

<jo> PROPOSED RESOLUTION: ref LC-2031 resolve yes, we have added text to this section that goes some way to addressing your concern

I think we need the same resolution again. we're agreeing with the comments on HTTPS

RESOLUTION: ref LC-2031 resolve yes, we have added text to this section that goes some way to addressing your concern

<francois> LC-2016

LC-2016 is again similar I think

<jo> PROPOSED RESOLUTION: ref LC-2016 resolve yes, we have added text to this section that goes some way to addressing your concern

RESOLUTION: ref LC-2016 resolve yes, we have added text to this section that goes some way to addressing your concern

<francois> LC-2032

LC-2032 - again, I think, the smae resolution applies

RESOLUTION: ref LC-2032 resolve yes, we have added text to this section that goes some way to addressing your concern

LC-2001 from Luca. Same resolution

RESOLUTION: ref LC-2001 resolve yes, we have added text to this section that goes some way to addressing your concern

<francois> LC-2001

PROPOSED RESOLUTION: ref LC-2033 resolve yes, we have added text to this section that goes some way to addressing your concern

RESOLUTION: ref LC-2033 resolve yes, we have added text to this section that goes some way to addressing your concern

Jo: 2004 the same

RESOLUTION: ref LC-2004 resolve yes, we have added text to this section that goes some way to addressing your concern

<francois> LC-2033

Jo: and 2024

RESOLUTION: ref LC-2024 resolve yes, we have added text to this section that goes some way to addressing your concern

LC-2051 something new from Eduardo

<francois> LC-2004

<francois> LC-2051

<EdC> LC-2051 was handled by Fran�ois many months ago.

Jo: we need a resolution - no - I think

<jo> PROPOSED RESOLUTION: ref LC-2051 resolve no, there was insufficient overlap with this work

RESOLUTION: ref LC-2051 resolve no, there was insufficient overlap with this work

Jo: LC-2047

<scribe> Done

2024 is a editorial comment - I think we agreed that thatwas incorrect but there's a polite response

LC-2064 we resolved yes for Jos�

<francois> LC-2047

LC-2066 we resolved yes to

<francois> LC-2064

LC-2068 from MNot and we resolved yes and updated references as a reult

<francois> LC-2068

LC-2070 - same

<francois> LC-2070

LC-2081 - already resolved yes to this

<francois> LC-2008

LC-2081 already resolved yes. Same comment about moving to informativbe

<francois> LC-2081

<francois> LC-2013

LC-2013 from Jos� resolved yes

<francois> LC-2026

LC-2026 and 2027 need resolving

I suggest the same resolution as on other HTTPS ones.

<jo> PROPOSED RESOLUTION: ref LC-2026 resolve yes, we have added text to this section that goes some way to addressing your concern

<francois> LC-2027

<brucel> Can we have a convo about canvas and SVG for some light relief please?

RESOLUTION: ref LC-2026 resolve yes, we have added text to this section that goes some way to addressing your concern

<jo> PROPOSED RESOLUTION: ref LC-2027 resolve yes, we have added text to this section that goes some way to addressing your concern

RESOLUTION: ref LC-2027 resolve yes, we have added text to this section that goes some way to addressing your concern

Jo: and finally... 2095 from Julian Reschke

<francois> LC-1995

Jo: we agree. The link header was removed a long time ago
... LC comment bashing is finished.

Francois might have missed one or two

<DKA> hallelujah

scribe: I still see one that is opened. DId we do 2053?

<DKA> Can we resolve to "lets roll" now?

Jo: Anything else we need to do on comments, Francois?

Francois: We have missed 2051 which is still pending
... it's on Eduardo.

Jo: It's resoved no when I look at it

Francois: OK, I'll send the LC comments as soon as possible when the spec is published

Jo: Thank you all
... Light confection for next week

PhilA: revises his suggestion for supplement cf. addendum

<brucel> hugs

Jo: Can't do it now. I'm thinking 'companion'