[minutes] BPWG Teleconference 2010-02-02

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[minutes] BPWG Teleconference 2010-02-02

Francois Daoust
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]



Reply | Threaded
Open this post in threaded view
|

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

Jo Rabin
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]
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Francois Daoust
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]
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

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

Eduardo Casais
In reply to this post by Jo Rabin
Some editorial comments -- for the sake of legibility and consistency.

Section 1.1

"[...] it is out of scope to provide a thoroughgoing solution to control
of transforming proxies [...]"

Wording? "a thoroughgoing solution to control transforming proxies is
out of scope"


Section 4.1.5.1

"While complying with this section 4.1.5 Alteration of HTTP Header Field
Values and 4.2.5 Receipt of Vary HTTP Header Field proxies should [...]"

Wording? "these sections" instead of "this section".


Section 4.1.5.2

"A proxy may apply heuristics of various kinds [...]"

Shouldn'it be "A proxy MAY apply ..."?


Section K.6

"[...] and are not included in the IANA registry of HTTP header fields."

Consistency with 4.1.5.5: "... and are not included in the IANA registry
of permanent HTTP header fields."


E.Casais


     


Reply | Threaded
Open this post in threaded view
|

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

Francois Daoust
Just to voice my support to the changes proposed by Eduardo.

The changes in 4.1.5.1 and in appendix K.6 should be done before
publication. If the group approves of the changes during the call, I'm
happy to make the modifications myself in Jo's absence so that we don't
have to postpone the publication by a week.

The rewording of section 1.1 can probably wait for next publication and
should probably be supervised by Jo as it's all about replacing real
English with... er... international English that non-native English
speakers can understand.

Francois.


Eduardo Casais wrote:

> Some editorial comments -- for the sake of legibility and consistency.
>
> Section 1.1
>
> "[...] it is out of scope to provide a thoroughgoing solution to control
> of transforming proxies [...]"
>
> Wording? "a thoroughgoing solution to control transforming proxies is
> out of scope"
>
>
> Section 4.1.5.1
>
> "While complying with this section 4.1.5 Alteration of HTTP Header Field
> Values and 4.2.5 Receipt of Vary HTTP Header Field proxies should [...]"
>
> Wording? "these sections" instead of "this section".
>
>
> Section 4.1.5.2
>
> "A proxy may apply heuristics of various kinds [...]"
>
> Shouldn'it be "A proxy MAY apply ..."?
>
>
> Section K.6
>
> "[...] and are not included in the IANA registry of HTTP header fields."
>
> Consistency with 4.1.5.5: "... and are not included in the IANA registry
> of permanent HTTP header fields."
>
>
> E.Casais
>
>
>      
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Jo Rabin
I've posted a new draft [1] in advance of this afternoon's meeting
addressing Eduardo's comments and also adding a note to the Note on
no-transform, which Francois spotted I had missed.

Diffs from the last draft are linked in line.

Note that this is draft 1z and z is the last letter of the alphabet.

Jo

[1]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/100209

On 09/02/2010 08:18, Francois Daoust wrote:

> Just to voice my support to the changes proposed by Eduardo.
>
> The changes in 4.1.5.1 and in appendix K.6 should be done before
> publication. If the group approves of the changes during the call, I'm
> happy to make the modifications myself in Jo's absence so that we don't
> have to postpone the publication by a week.
>
> The rewording of section 1.1 can probably wait for next publication and
> should probably be supervised by Jo as it's all about replacing real
> English with... er... international English that non-native English
> speakers can understand.
>
> Francois.
>
>
> Eduardo Casais wrote:
>> Some editorial comments -- for the sake of legibility and consistency.
>>
>> Section 1.1
>>
>> "[...] it is out of scope to provide a thoroughgoing solution to control
>> of transforming proxies [...]"
>>
>> Wording? "a thoroughgoing solution to control transforming proxies is
>> out of scope"
>>
>>
>> Section 4.1.5.1
>>
>> "While complying with this section 4.1.5 Alteration of HTTP Header
>> Field Values and 4.2.5 Receipt of Vary HTTP Header Field proxies
>> should [...]"
>>
>> Wording? "these sections" instead of "this section".
>>
>>
>> Section 4.1.5.2
>>
>> "A proxy may apply heuristics of various kinds [...]"
>>
>> Shouldn'it be "A proxy MAY apply ..."?
>>
>>
>> Section K.6
>>
>> "[...] and are not included in the IANA registry of HTTP header fields."
>>
>> Consistency with 4.1.5.5: "... and are not included in the IANA
>> registry of permanent HTTP header fields."
>>
>>
>> E.Casais
>>
>>
>>      
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: New CT Draft 1z

Phil Archer-4
Oh come now, Jo. Surely you're looking forward to 2A? Or is it 1AA?

Phil.

Jo Rabin wrote:

> I've posted a new draft [1] in advance of this afternoon's meeting
> addressing Eduardo's comments and also adding a note to the Note on
> no-transform, which Francois spotted I had missed.
>
> Diffs from the last draft are linked in line.
>
> Note that this is draft 1z and z is the last letter of the alphabet.
>
> Jo
>
> [1]
> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/100209 
>
>
> On 09/02/2010 08:18, Francois Daoust wrote:
>> Just to voice my support to the changes proposed by Eduardo.
>>
>> The changes in 4.1.5.1 and in appendix K.6 should be done before
>> publication. If the group approves of the changes during the call, I'm
>> happy to make the modifications myself in Jo's absence so that we
>> don't have to postpone the publication by a week.
>>
>> The rewording of section 1.1 can probably wait for next publication
>> and should probably be supervised by Jo as it's all about replacing
>> real English with... er... international English that non-native
>> English speakers can understand.
>>
>> Francois.
>>
>>
>> Eduardo Casais wrote:
>>> Some editorial comments -- for the sake of legibility and consistency.
>>>
>>> Section 1.1
>>>
>>> "[...] it is out of scope to provide a thoroughgoing solution to control
>>> of transforming proxies [...]"
>>>
>>> Wording? "a thoroughgoing solution to control transforming proxies is
>>> out of scope"
>>>
>>>
>>> Section 4.1.5.1
>>>
>>> "While complying with this section 4.1.5 Alteration of HTTP Header
>>> Field Values and 4.2.5 Receipt of Vary HTTP Header Field proxies
>>> should [...]"
>>>
>>> Wording? "these sections" instead of "this section".
>>>
>>>
>>> Section 4.1.5.2
>>>
>>> "A proxy may apply heuristics of various kinds [...]"
>>>
>>> Shouldn'it be "A proxy MAY apply ..."?
>>>
>>>
>>> Section K.6
>>>
>>> "[...] and are not included in the IANA registry of HTTP header fields."
>>>
>>> Consistency with 4.1.5.5: "... and are not included in the IANA
>>> registry of permanent HTTP header fields."
>>>
>>>
>>> E.Casais
>>>
>>>
>>>    
>>>
>>
>
>

--


Phil Archer
Open Media Web
http://www.w3.org/

http://philarcher.org/

Reply | Threaded
Open this post in threaded view
|

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

Eduardo Casais
In reply to this post by Jo Rabin
Re-reading 4.1.5.5 and comparing with older versions, I feel that the requirement
of keeping old header field values "as-is", so that they can be re-instated via a
simple copy is no longer explicit.

Thus,

"When forwarding an HTTP request with altered HTTP header fields, in addition
to complying with the rules of normal HTTP operation, proxies must include in
the request copies of the unaltered header field values in the form
"X-Device-"<original header name> so that it is possible to reconstruct the
original header field values."

becomes

"When forwarding an HTTP request with altered HTTP header fields, in addition
to complying with the rules of normal HTTP operation, proxies must include in
the request additional fields in the form "X-Device-"<original header name>
whose values are verbatim copies of the corresponding unaltered header field
values, so that it is possible to reconstruct the original header fields."

Apart from this, I do not see anything more to adjust in
the text.


E.Casais


     


Reply | Threaded
Open this post in threaded view
|

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

Jo Rabin
I reflected that change in an in-place edit of 1z, hence avoiding the
problem of thinking of a new name.

Jo

On 09/02/2010 13:08, Eduardo Casais wrote:

> Re-reading 4.1.5.5 and comparing with older versions, I feel that the requirement
> of keeping old header field values "as-is", so that they can be re-instated via a
> simple copy is no longer explicit.
>
> Thus,
>
> "When forwarding an HTTP request with altered HTTP header fields, in addition
> to complying with the rules of normal HTTP operation, proxies must include in
> the request copies of the unaltered header field values in the form
> "X-Device-"<original header name> so that it is possible to reconstruct the
> original header field values."
>
> becomes
>
> "When forwarding an HTTP request with altered HTTP header fields, in addition
> to complying with the rules of normal HTTP operation, proxies must include in
> the request additional fields in the form "X-Device-"<original header name>
> whose values are verbatim copies of the corresponding unaltered header field
> values, so that it is possible to reconstruct the original header fields."
>
> Apart from this, I do not see anything more to adjust in
> the text.
>
>
> E.Casais
>
>
>      
>
>