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

[minutes] BPWG Teleconference 2010-02-02

From: Francois Daoust <fd@w3.org>
Date: Tue, 02 Feb 2010 17:08:25 +0100
Message-ID: <4B684DF9.7030200@w3.org>
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

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