Mobile Web Best Practices Working Group Teleconference

Mobiel Web Application Best Practices

Francois: The spec is ready to ship. We need to organize a transition call.
... I prepared an implementation report template for MWABP.
... Just waiting for the transition call to happen.
... (on what is a transition call) it's an internal review by the W3C Management to approve the transition of the specification to Candidate Recommendation.

Jo: (inaudible)

Jo: The transition requires a formal review.

EdC: Does that mean in principle the [transition] can be rejected?

Francois: Yes - documented in the process document.
... It doesn't happen often. We should be prepared to defend is the review by the external world.

<francois> Process document

Francois: There is one potential change we might need to make. On "how to implement the best practice: cache resources".

<francois> How to implement "cache resources"

<francois> Cache resources BP in MWABP

Adam: I remember seeing the thread - I don't know what we use. I think we use hashcode - that will change when the resource changes - use the timestamp on the resource. Is there a standard hashing algorithm?

Jo: Someone did say that because the same resource may be served in different forms that just using the timestamp may not be enough.

<EdC> I believe there were actually _TWO_ issues in the comments: (a) is the cache of just the HTTP header/transaction meta-information or of the entire resource itself. (b) if the latter, what is the recommended technical solution for a hash mechanism?

Adam: This is only to be seen by the local cache of any given browser. Maybe "which version of the resource" and its timestamp would be adaquate.

Francois: If we plan to update the BP then we should do it right now, before the transition call.
... it's only in the "how to do it" section which is just an example.

Adam: We could add a bullet point to the description.

Francois: It doesn't strike me as substantive so it can wait... We can make it still in the future.

Jo: let's note this and see if we get any more [similarly sized] changes.

EdC: 2 things - what the hash should be on and what technique to use to make the hash.

Adam: I think we can say that metadata is quite sufficient. We could hold off adding that clarification until later.

Jo: I think we just leave it for now and see if we get any other points of clarification.

CT Guidelines

<francois> CT guidelines version 1.x

Jo: ct guidelines 1x version published on monday last week. Francois sent some comments (thanks!)

<jo> Francois's comments

Jo: Francois?
... If it makes your life easier then why don't we agree to take the example out of normative language.

<EdC> Just reply "header field must be added" in the example by "header field is added"

Francois: I don't mind having this normative duplication in there. We understand it's not an additional guideline.

<francois> section 4.1.5.5

<jo> the offending example

<EdC> Just replace "header field must be added" in the example by "header field is added", and all should be well...

Jo: Change "must" for "would."

Francois: Fine.

Jo: (per EdC's suggestion)

<jo> PROPOSED RESOLUTION: Replace "must" with "would" in example under 4.1.5.5

<EdC> +1

+1

<francois> +1

RESOLUTION: Replace "must" with "would" in example under 4.1.5.5

<francois> offending repetition

Francois: Again - repetition for emphasis.
... It looks weird in the conformance statement.

<EdC> So you just want to eliminate the second bullet point in 6.1.1, right?

Jo: The only reason it's not 2 bullets is because of the additional info on removing comments.

<EdC> So you just want to eliminate the second bullet point in 4.1.6, right?

Jo: Don't want to eliminate the 2nd bullet....
... how about rewording the first part of 4.1.6.1 to get around this inelegance.

<jo> PROPOSED RESOLUTION: In 4.1.6.1 replace "Proxies must (in accordance with RFC 2616) include a Via HTTP header field indicating their presence and" with "Proxies"

<francois> +1

+i dunno

<yeliz> +1

<jo> PROPOSED RESOLUTION: In 4.1.6 add appropriately "(in accordance with RFC 2616)" and in 4.1.6.1 replace "Proxies must (in accordance with RFC 2616) include a Via HTTP header field indicating their presence and" with "Proxies"

<EdC> Can we place the "in accordance with RFC2616" in 4.1.6, then?

<jo> as above, EdC

<EdC> +1

+1

<jeffs> +1

<francois> +1

RESOLUTION: In 4.1.6 add appropriately "(in accordance with RFC 2616)" and in 4.1.6.1 replace "Proxies must (in accordance with RFC 2616) include a Via HTTP header field indicating their presence and" with "Proxies"

<yeliz> +1

<francois> splitted guideline between 4.1.5 and 4.1.5.5

Francois: if you read the first normative statement it must be possible for the server to construct the original user agent - so from an implementation perspective and a testing perspective you cannot test one independently of the other.
... We should try not to use the passive form and probably put these 2 guidelines together. It's the same guideline using different wording.

<EdC> I agree with avoidance of passive form. Still thinking about the other aspects...

<jo> PROPSOED RESOLUTION: Under 4.1.5 Remove last sentence of first para, insert "(see 4.1.5.5 Original Header Fields)" in first sentence after "header fields" and insert " so that it is possible to reconstruct the original header field values" at the end of the first sentence of 4.1.5.5

<jo> PROPOSED RESOLUTION: Under 4.1.5 Remove last sentence of first para, insert "(see 4.1.5.5 Original Header Fields)" in first sentence after "header fields" of Ibid and insert " so that it is possible to reconstruct the original header field values" at the end of the first sentence of 4.1.5.5

<jeffs> +1

+1

<SeanP> +1

<francois> +1

<yeliz> +1

<jo> Francois worries about Web site

RESOLUTION: In 4.1.6 add appropriately "(in accordance with RFC 2616)" and in 4.1.6.1 replace "Proxies must (in accordance with RFC 2616) include a Via HTTP header field indicating their presence and" with "Proxies"

<jo> A Web Site by any other name would be ...

Francois: I don't want to start a discussion on what a website is. I just wonder if we can define it for these purposes as a subset of the same origin.

Jo: I don't think it is necessarily though is it?
... Something like www.example.com may have images at images.example.com, right?

(or scripts at script.example.com)

audio dropped out for me...

I'm back.

Jo: hrm...

Francois: if it's common that images get served from another domain then forget about it...

It is common.

<EdC> Are such fine distinctions materially necessary to interpret the guidelines?

Francois: it's not going to be easy to write tests if you cannot scope what a web site is.

Dan: it has to do with scalability issues - why you sometimes server up images off of different servers

<jo> PROPOSED RESOLUTION: In re the matter of testing and Web sites, include a note in the tests that where reference from a made from a Web site to another domain this is not conclusive of anything

(of course, this can more intelligently be done with Apache re-write rules or intelligent http redirection head-ends these days)

<jo> [hope that is vague enough for everyone]

<SeanP> Here's an example: Images on yahoo.com come from l.yimg.com and d.yimg.com

<jo> that was what I was thinking of SeanP

Francois: I'd prefer that we not touch the existing text?

<EdC> I am puzzled. Isn't there some form of useful, formal, and robust definition in a W3C glossary of some sort?

Jo: Francois what can we do?

Francois: Nothing - just forget about my comment.

I suggest a "don't ask, don't tell" approach.

Jo: You could say "anything that is an included resource for a web page constitutes the same website"

Francois: The point is not so much about included resources but about links.
... Honestly I don't think we could be more precise here. We could say for links it's the same origin but for included resources it's not necessary.

Dan: So no action required?

Francois: yes.

<jo> Upshot is that Francois will take a pragmatic stance on this, ref included resource and "same domain" for linked resources

Francois: Might be a bit early now but: I kicked off the work on the CT test suite. I have not included: I won't be able to take the lead on that work. Someone needs to step up and take on the leadership.

[collective heavy sigh]

Jo: Any volunteers?

<jo> PROPOSED RESOLUTION: Dan to take the lead on Tests, OK?

<jo> +1

-1,000,000

Jo: let's take it off line.

Francois: let's think about it - the work won't just magically be done.

Jo: [call closed]

<brucel> hang loose, all

Jo: Let's try to move that fwd to final lc next call.

<SeanP> bye