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

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 16:49:11 UTC