- From: Francois Daoust <fd@w3.org>
- Date: Tue, 02 Feb 2010 18:15:11 +0100
- To: Jo Rabin <jo@linguafranca.org>
- CC: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
Thanks Jo, I have updated the Implementation Conformance Statement (ICS) and the link to the ICS consequently: http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/ics-100202.html Francois. Jo Rabin wrote: > Just to note that the third resolution today was not a duplicate of the > second, but was: > > 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 > > That said, the new version of CT is at > > http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/100202 > > > for review and for request for advancement to Last Call on next week's > call. > > Jo > > On 02/02/2010 16:08, Francois Daoust wrote: >> 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 17:15:45 UTC