W3C home > Mailing lists > Public > public-bpwg@w3.org > February 2010

Re: New CT Draft 1y (was Re: [minutes] BPWG Teleconference 2010-02-02)

From: Francois Daoust <fd@w3.org>
Date: Tue, 02 Feb 2010 18:15:11 +0100
Message-ID: <4B685D9F.8070404@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:55 UTC