- From: Francois Daoust <fd@w3.org>
- Date: Tue, 02 Feb 2010 17:08:25 +0100
- To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
Hi,
The minutes of today's call are available at:
http://www.w3.org/2010/02/02-bpwg-minutes.html
... and copied as raw text below.
Main topics discussed:
* Resolved on the guidelines for Web Content Transformation Proxies:
- Replace "must" with "would" in example under 4.1.5.5
- 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"
- 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 is to issue an updated draft based on these resolutions, with a
view to resolving to publish it as a third last call working draft next
week.
* Someone's needed to lead the work on the test suite for the Guidelines
for Web Content Transformation Proxies.
Francois.
-----
02 Feb 2010
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-bpwg/2010Feb/0000.html
See also: [3]IRC log
[3] http://www.w3.org/2010/02/02-bpwg-irc
Attendees
Present
jo, francois, adam, EdC, DKA, Alan_Chuter, brucel, yeliz,
SeanP
Regrets
tomhume, miguel, nacho, kai
Chair
Jo
Scribe
Dan
Contents
* [4]Topics
1. [5]Mobile Web Application Best Practices
2. [6]CT Guidelines
* [7]Summary of Action Items
_________________________________________________________
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> [8]Process document
[8] http://www.w3.org/2005/10/Process-20051014/tr.html#Reports
Francois: There is one potential change we might need to make. On
"how to implement the best practice: cache resources".
<francois> [9]How to implement "cache resources"
[9] http://lists.w3.org/Archives/Public/public-bpwg/2010Jan/0013.html
<francois> [10]Cache resources BP in MWABP
[10]
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20100114#bp-conserve-fingerprint
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> [11]CT guidelines version 1.x
[11]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/100125.html
Jo: ct guidelines 1x version published on monday last week. Francois
sent some comments (thanks!)
<jo> [12]Francois's comments
[12] http://lists.w3.org/Archives/Public/public-bpwg/2010Jan/0023.html
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> [13]section 4.1.5.5
[13]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/100125#sec-original-headers
<jo> [14]the offending example
[14]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/100125.html#sec-original-headers
<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> [15]offending repetition
[15]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/100125#sec-additional-headers
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> [16]splitted guideline between 4.1.5 and 4.1.5.5
[16]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/100125#sec-altering-header-values
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> [17]Francois worries about Web site
[17] http://lists.w3.org/Archives/Public/public-bpwg/2010Jan/0025.html
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
Summary of Action Items
[End of minutes]
Received on Tuesday, 2 February 2010 16:08:57 UTC