[minutes] BPWG F2F - Day 2/3

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

[minutes] BPWG F2F - Day 2/3

Francois Daoust
Hi,

Here is a short summary and a copy of the minutes of the second day of
last week's F2F.

The group addressed the Last Call Comments received on the Guidelines
for Web Content Transformation Proxies, and resolved to make a
significant number of changes to the document. The changes are
substantive and the group agreed that another Last Call working draft of
the document will have to be published.

Next short-term steps:
1. an update of the draft based on the resolutions of the F2F.
2. the replies to the reviewers are to be drafted.

Next publication planned mid-January 2010.

The minutes of day 2/3 are available at:
  http://www.w3.org/2009/12/10-bpwg-minutes.html
... and copied as text below.

Note that the work on a test suite for the guidelines was discussed
during day 3/3.

Thanks,
Francois.


-----
10 Dec 2009

    [2]Agenda

       [2]
http://www.w3.org/2005/MWI/BPWG/Group/Meetings/London4/logistics.html#agenda

    See also: [3]IRC log

       [3] http://www.w3.org/2009/12/10-bpwg-irc

Attendees

    Present
           jo, achuter, Sean, Eduardo(phone), PhilA, francois, DKA,
           chaals(morning)

    Regrets
           none

    Chair
           DKA

    Scribe
           Sean, francois, PhilA

Contents

    The group addressed the [4]list of last call comments on Guidelines
    for Web Content Transformation Proxies. Changes brought to the
    document are substantive and the group agreed to publish another
    Last Call Working Draft.
      * [5]Topics
          1. [6]LC-2289, LC-2323 - Usefulness of the document
          2. [7]LC-2321, LC-2324, response to LC-2036 - Content Tasting
             approach
          3. [8]LC-2316, response to LC-2034 - HTTP methods
          4. [9]LC-2327 - Re-issuing POST requests
          5. [10]LC-2269 - MIME types for data exchanges
          6. [11]LC-2270 - Servers preferences regarding HTTPS links
             re-writing
          7. [12]HTTPS links rewriting - 2 conformance levels?
          8. [13]LC-2317 - User notification
          9. [14]LC-2318 - Cache-Control: no-transform precedence
         10. [15]LC-2320 - Driving a truk through the guidelines
         11. [16]LC-2328 - Ignoring no-transform
         12. [17]LC-2329 - Blurring the semantics of a 200 response
         13. [18]LC-2319 - Clarification on "aside from"
         14. [19]LC-2322 - Processing "handheld" links
         15. [20]LC-2268 - Using a desktop browser over a mobile network
         16. [21]LC-2267 - Enforcing same-origin policy
         17. [22]Back to LC-2289 and LC-2323 - Usefulness of the
             document
         18. [23]Decision to publish another Last Call Working Draft
      * [24]Summary of Action Items

       [4]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/

Minutes of the F2F

      * [25]Day 1/3
      * [26]Day 2/3 (this page)
      * [27]Day 3/3
      _________________________________________________________

      [25] http://www.w3.org/2009/12/09-bpwg-minutes.html
      [26] http://www.w3.org/2009/12/10-bpwg-minutes.html
      [27] http://www.w3.org/2009/12/11-bpwg-minutes.html

    <EdC> Is there going to be a formal (i.e. recorded in minutes)
    discussion about the continuation of the group? I can not really
    follow everything that is being said right now.

    <DKA> Yes - there will be -

    <EdC> My prioritization: 2316+2034, then 2269, 2270, remark 406,
    2318, then the rest.

    FD: Suggest we follow the order listed in the agenda, inserting
    HTTPS issues ASAP (before Chaals leaves)

    <EdC> ok with me. Go on calling out which LC is being handled.

    <francois>
    [28]http://www.w3.org/2005/MWI/BPWG/Group/Meetings/London4/logistics
    .html#agenda

      [28]
http://www.w3.org/2005/MWI/BPWG/Group/Meetings/London4/logistics.html#agenda

LC-2289, LC-2323 - Usefulness of the document

    [29]LC-2289 from Luca Passani
    [30]LC-2323 from Mark Nottingham

      [29]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2289
      [30]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2323

    FD: We should take a step back and see if we agree that this
    document is useful for the community

    DKA: What is "imprecise terminology" in Mnot's comment?

    FD: There was some more email clarifying this

    SP: He gives a few examples, but doesn't clarify it completely

    DKA: This is HTTP fundamentalism?

    FD: Yes.

    DKA: The problem is that reality isn't the same as what HTTP claims.
    This is a field manual, not an academic treatise.

    JR: I think it is inappropriate to say MNot doesn't understand the
    wild

    DKA: Sure...

    FD: I think HTTP(bis) was chartered because the HTTP spec could be
    interpreted in too many different ways. In that regard we are doing
    similar things, imprecisely interpreting HTTP.
    ... I think the question is whether we are really willing to push
    this document because we strongly believe that it is useful.

    <EdC> What are these interpretations (imprecise) that are relevant
    to the current work?

    JR: I think there needs to be a sounder basis of the premise on
    which we are doing this, in view of the comments of Mark and Luca
    ... right now we see egregious disregard of HTTP, and requirements
    that go beyond what HTTP formally allows.
    ... we are trying to encourage people to comply with HTTP more
    closely. The question is are we sufficiently successful to warrant
    continuing the document.
    ... the further point is that whatever we say is not the last word.
    It is an attempt right now to make things better right now. We are
    not creating new technology to answer the problem formally, we are
    trying to reconcile the competing objectives of "HTTP compliance is
    a Good Thing™" but we cannot answer the requirements of application
    developers completely in that way.
    ... I believe the contribution is sufficiently sound to be valuable,
    but I am more than willing to listen to people who do not think it
    is sufficiently sound.

    DKA: So what bits of what you said go into the document, and what
    bits are comment to MNot/Luca

    <EdC> Regarding imprecise terminology: this is relevant to section
    2.2, but there was a decision already not to formalize the concepts
    further. So this might be made clear with one sentence?

    JR: I am not the person to answer that question... I am too close to
    the text

    FD: MNot says we are too loose. We should read the document and try
    to be as precise as possible - either drop things or make them more
    precise. That is the gist of the change proposals I tried to send
    before coming to this meeting.
    ... I think if we can make this as precise as possible, the document
    is useful

    DKA: IF we can tighten it up, that is good.

    FD: One way to do so is to extract requirements to build a test
    suite, as a way to discover what needs tightening. "THIS" shows that
    there are various pieces which need to be tightened.

    DKA: Do you think those are substantive changes

    FD: I think we will see that by going through the pieces

    [DKA calls the dutch guys again to find out if we can make the
    screen and the phone work at the same time]

    EC: Referring to imprecise terminology - a point I had already
    raised in regards to 2.2 but there had been a decision not to
    formalise the definitions of those concepts...
    ... but that decisions is not reflected clearly in the document.
    Maybe a sentence there would clarify that the vagueness here is a
    deliberate choice.

    <Jo> PROPOSED RESOLUTION: add a comment to sect 2.2 stating that
    these are generic concepts which we choose not to formalise further

    <Jo> +1

    <EdC> +1

    <SeanP> +1

    <francois> I note that the notion of restructuring is used in a
    normative statement in 4.1.5: "the user has specifically requested a
    restructured desktop experience"

    <francois> ... so this particular definition should be as precise as
    possible. I think it is.

    <EdC> We can state: anything that changes the body of the HTTP
    response, or any of its elements that implies a modification of the
    HTTP header fields listed last in RFC2616, section 13.5.2.

    <DKA> +1

    FD: On the proposed resolution, the notion of restructuring is used
    in the document, referring back to this definition. So I think it
    should be precise, but I think it is sufficiently clear. The other
    concepts defined are not referred to by the document.

    <francois> +1

    RESOLUTION: add a comment to sect 2.2 stating that these are generic
    concepts which we choose not to formalise further

    JR: Ultimately normative concepts have to be based on language, so
    we cannot rely on some attempt t make everything normative.
    ... IMO this does not represent a substantive change
    ... We have two comments. On the one hand there is too much said, in
    a way that is too imprecise, and on the other hand "you are not
    saying enough"
    ... displeasing everyone equally might mean we are right. But there
    is not much more we can do to reconcile those points of view. I
    think that the experience of dealing with Luca suggests that nothing
    less than simply copying everything he says word for word will
    satisfy him. Noting that we are not intending to do that, I do not
    see that there is much point in following up the request

    <Jo> CMN: There are some points of Luca's comment that I think we
    can do this. "Content Providers don't want their content messed
    with". Somehow assuming that they can gurantee that their content
    won't be altered is unrealistic, so we can dismiss that point. His
    statement about telcos avoidiung liability is out of scope in a
    techincal document. This document does not describe how mobile
    develops...

    <Jo> ...should develop apps so the first point is irrelevant to the
    document at hand.

    <Jo> DKA: surely it is for developers

    <Jo> CMN: no it is not it is for transformation deployments.
    Developers can infer the behaviour that platforms will exhibit

    EC: A few comments...
    ... regarding the comment "it is not good for content owners", 'not
    quite'. We will see that under testing.
    ... Arguing that it is a technical document and liability is out of
    scope is debatable. Laws on liability refer to technical ways of
    protecting content.
    ... "The document is not for developers" is a kind of sophistry. Of
    course it is.

    <Jo> PROPOSED RESOLUTION: Have the document make explicit, if it
    does not do so sufficiently already, that moral and legal questions
    are out of scope

    EC: otherwise why would we explain how developers can ensure that
    their content is handled a specific way by content transformation
    proxies

    <Jo> CMN: Refine document is not for developers comment. Luca's
    comment is predicated on his assumption that developers can
    guarantee a certain treatment of their content. Doc is not about
    that it's about how devs can request specific treatment, and a
    request that proxies respect thsoe requests. They can't be
    guaranteed - so this isn't guaranteeing the platform that Luca would
    like to have.

    <inserted> CMN: I think the decision to avoid trying to make
    statements based on a clear understanding of the current and future
    legal systems of all the jurisdictions in which the Web is used
    would be a pointless exercise

    DKA: I think that a lot of this stuff is outside the realm of
    current laws. It has nothing to do with anything we can talk about
    it here.

    <Jo> PROPOSED RESOLUTION: Have the document make explicit, if it
    does not do so sufficiently already, that moral and legal questions
    are out of scope and that this group does not ahve the authority or
    expertise to comment one way or another about setting precent or
    authorising any specific behavior or its absence.

    EC: That is reasonable. Please put an explicit sentence in the
    document.

    <DKA> +1

    <SeanP> +1

    <francois> +1

    DKA: We're not lawyers. It isn't clear that we have the expertise to
    do this

    <achuter> +1

    <EdC> +1

    CMN: It isn't a question of authority and expertise, it is simply an
    unrealistic aim

    JR: So add that it is an unrealistic aim?

    CMN: sure

    <EdC> No. There are IPR laws, so we could refer to normative specs
    (legal ones that is).

    Proposed RESOLUTION: Have the document make explicit, if it does not
    do so sufficiently already, that moral and legal questions are out
    of scope and that this group does not have the authority or
    expertise to comment one way or another about setting precedent or
    authorising any specific behavior or its absence - nor is such a
    task feasible in this group.

    JR: Do we want to add further clarity that this is not an answer to
    all the world's problems, but an attempt to provide guidance towards
    ameliorating a bad situation

    EdC: I wouldn't say that. Would you say "this document was produced
    by lazy slobs who didn't work out the problem?"
    ... the only requirement is to state what is important about this
    document. That it is based on the state at a point in time and may
    need to be refined in the future, rather than being the last word on
    the topic.

    JR: "Is unlikely to be the last word on the topic"

    SP: We say that, right?

    JR: Sure. We could say it until it swamps the document...

    SP: Do not think we need more disclaimers

    <Jo> +1

    <francois> +1

    <achuter> +1

    <DKA> +1

    <SeanP> +1

    <EdC> +1

    RESOLUTION: Have the document make explicit, if it does not do so
    sufficiently already, that moral and legal questions are out of
    scope and that this group does not have the authority or expertise
    to comment one way or another about setting precedent or authorising
    any specific behavior or its absence - nor is such a task feasible
    in this group.

    [CMN notes that "precedent" refers to "legal precedent"]

    <Jo> PROPOSED RESOLUTION: Editor to add further text to scope
    section along lines of his earlier minuted statement and Eduardo's
    recapitualtion of it above

    [... and authorising is used in a legal rather than technical sense
    here]

    <EdC> [.. and stating that "while there is indeed a body of IPR
    laws, the group does not have...]

    <SeanP> +1

    <francois> +1

    SP: Isn't that implied already?

    FD: Yeah, but this is about being explicit

    RESOLUTION: Editor to add further text to scope section along lines
    of his earlier minuted statement and Eduardo's recapitualtion of it
    above

    JR: So, response to Luca and MNot

    DKA: Don't we need to go through FD's precision stuff before
    responding to MNot?

    FD: Should create specific comment issues in tracker based on Mark's
    stuff.

    <EdC> should we not recapitulate the LC and summarize answers to all
    of them at the end of the session?

    <scribe> ACTION: Francois to enter specific issues from Mark into
    tracker, due now [recorded in
    [31]http://www.w3.org/2009/12/10-bpwg-minutes.html#action01]

    <trackbot> Created ACTION-1027 - Enter specific issues from Mark
    into tracker, due now [on François Daoust - due 2009-12-17].

    <EdC> I would prefer to handle the concrete issues first.

    EC: Let's deal with the concrete issues rather than trying to
    formalise something that may change based on what we discuss
    afterwards?

    <francois> [I just created LC-2327, LC-2328 and LC-2329 for
    ACTION-1027]

    [fire alarm. Instructions are *not* to leave... but we are taking a
    break anyway]

    <EdC> Fran�ois. please note that there are no trackers for 2034 and
    2036 (listed in the agenda).

    <francois> EdC, I'll update the broken links, that's because the
    comments applied to the previous version of the spec:

    <francois>
    [32]http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidel
    ines-20080801/2034

      [32]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2034

    <francois>
    [33]http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidel
    ines-20080801/2036

      [33]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2036

    <francois> Scribe: SeanP

    <Jo> [back from enforced break due to fire alarm]

    Jo: We've decided that we have enough to answer Luca's comments. We
    will defer comming up with a response to Mark's comment until we've
    covered the rest of the comments.

    [Added during minutes cleanup: see resolutions at the end of the
    minutes]

LC-2321, LC-2324, response to LC-2036 - Content Tasting approach

    [34]LC-2321
    [35]LC-2324
    [36]LC-2036

      [34]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2321
      [35]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2324
      [36]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2036

    Francois: Let's talk about the content tasting comments

    <EdC> Which exact section is being discussed here? Only 4.1.5.1 ?

    Francois: My suggestion is to remove the first part of 4.1.5.1.
    Remove the phrase about "theoretical idempotency" and put something
    in that some servers have trouble with dup requests.

    EdC: Why is the "theoretical idempotency" a problem?

    Jo: The server statistics could get messed up.

    <EdC> From RFC2616, sec 9.1.2:

    <EdC> However, it is possible that a sequence of several requests is
    non-

    <EdC> idempotent, even if all of the methods executed in that
    sequence are

    <EdC> idempotent. (A sequence is idempotent if a single execution of
    the

    <EdC> entire sequence always yields a result that is not changed by
    a

    <EdC> reexecution of all, or part, of that sequence.) For example, a

    <EdC> sequence is non-idempotent if its result depends on a value
    that is

    <EdC> later modified in the same sequence.

    Francois: I'm not sure we're solving any specific problem, so we
    should go along with the commenters.

    Jo: We could just delete this whole section.

    <francois> [Choices for 4.1.5.1:

    <francois> - remove the whole section

    <francois> - remove the first normative statement

    Jo: Eduardo, what would you like to see changed about this section?

    <francois> ... and rephrase the incriminated "theoretical
    idempotency" sentence is less affirmative form]

    <Jo> PROPSOED RESOLUTION: Remove initial part of sect 4.1.5.1 up to
    "such content" - i.e. Proxies should avoid issuing ... and
    specifically should not <insert>on a routine basis, other than as
    desribed in 4.1.5 and 4.2.6</insert> issue duplicate requests for
    comparison purposes

    Sean: It seems like the main part is that proxies should not issue
    duplicate requests for comparison purposes.

    <Jo> PROPSOED RESOLUTION: Remove initial part of sect 4.1.5.1 up to
    "such content" - i.e. Proxies should avoid issuing ... and
    specifically should not <insert>on a routine basis, other than as
    desribed in 4.1.5 and 4.2.6</insert> issue requests for the same
    resource for comparison purposes

    Francois: The objection was about the phrase "theoretical
    idempotency" and the other objection is that saying that proxies
    should not issue duplicate requests forbids sending a request with
    the unaltered headers and then sending a request with the altered
    headers.

    EdC: Does "duplicate requests" mean exactly the same request twice?

    Francois: That's a good point. Should clarify that.

    <Jo> PROPSOED RESOLUTION: replace 4.1.5.1 with:. Other than to
    respect 4.1.5 and 4.2.6 proxies should avoid making repeated
    requests for the same resource and should not on a routine basis,
    issue requests for the same resource for comparison purposes

    <Jo> PROPSOED RESOLUTION: replace 4.1.5.1 with:. Other than to
    respect 4.1.5 and 4.2.6 proxies should avoid making repeated
    requests for the same resource

    Francois: What is it we are trying to say here.

    Jo: We're saying that if you think you know or should know the
    result, then don't re-request it.

    Chaals: If you think you know, then why re-request?

    Jo: They have done it.

    <EdC> For comparing the results, as stated in the initial resolution
    proposal. Why compare results? Ask the proxy implementors about
    it...

    <Jo> PROPOSED RESOLUTION: replace 4.1.5.1 with:. In complying with
    4.1.5 and 4.2.6 proxies should, where possible, avoid making
    repeated requests for the same resource using the same headers

    <EdC> It does not make much sense, does it?

    Francois: It is not repeated requests with the same headers; it is
    requests for the same resource.
    ... Shouldn't send multiple requests for the same resource just to
    compare.
    ... Sending the same request with the same headers has nothing to do
    with transcoding.

    <EdC> Why would you actually duplicate a request? Except if the
    idempotency is not respected by the server, of course, you will
    receive a duplicate, i.e. identical (up to timestamps), response.

    <Jo> PROPOSED RESOLUTION: replace 4.1.5.1 with:. In complying with
    4.1.5 and 4.2.6, when forwarding a request, proxies should minimize
    making repeated requests for the same resource

    <chaals> Proposed Resolution: Delete 4.1.5.1

    <EdC> Not testable -- except if minimize == make no repeated
    requests.

    <EdC> I liked the original proposal Other than to respect 4.1.5 and
    4.2.6 proxies should avoid making repeated requests for the same
    resource and should not on a routine basis, issue requests for the
    same resource for comparison purposes

    Sean: In section 4.1.1 we also say that multiple requests for the
    same resource can be sent.

    Chaals: I have another proposal: delete 4.1.5.1

    <EdC> no.

    DKA: I don't support that.
    ... We want to avoid substantive changes to avoid another last call.

    Chaals: You're saying avoid making repeated requests to the server?
    I can live with that. It's fairly untestable.

    Jo: We need to recognize what Luca is saying. We don't want to
    contradict ourselves.

    <Jo> PROPOSED RESOLUTION: While complying with sects 4.1.5 and 4.2.6
    proxies should minimise requests to the server.

    <francois> +1 (but agree with chaals about testability)

    <EdC> minimize == ? How to test it.

    Phil: Are we trying to produce testable guidelines?

    DKA: Ideally, yes.

    Francois: We receive comments about that.

    <EdC> Well, we tried to enforce testability so far.

    <EdC> We should continue in this way.

    DKA: It is testable if you are sending the same request for the same
    resource with the same headers, then it is testable.

    Chaals: We are no longer saying that.

    DKA: It's a "should" not a "must".

    EdC: The proposed resolution doesn't say anything about avoiding
    requests for the "same resource".

    <Jo> PROPOSED RESOLUTION: While complying with sects 4.1.5 and 4.2.6
    proxies should avoid making repeated requests for the same resource.

    EdC: About "minimise": what are you going to compare it with?

    <francois> +1 (but still hard to test)

    Jo: It's one of those things "I'll know it when I see it". You can
    tell when a proxy is making to many requests, but it is hard to
    define.

    EdC: "Minimize" says that proxies should optimize as much as
    possible; compared to what?

    Francois: In the conformance statement, CT operators would need to
    say how they are minimizing.
    ... We could just remove the paragraph.

    <Jo> PROPOSED RESOLUTION: While complying with sects 4.1.5 and 4.2.6
    proxies should avoid making repeated requests for the same resource.

    <Jo> +1

    <EdC> +1

    <francois> +1 (and still hard to test)

    Jo: That would ignore one of the few data points that we have:
    multiple requests have been sent.

    DKA: What is your objection?

    Chaals: It is not testable. It's not clear that the justification
    for sending multiple requests would be a valid reason.
    ... everyone has a reasonable justification for what they do.

    <EdC> Yes, but this is an argument against all SHOULD as well...

    Francois: We could take this resolution; we could add a section to
    the document that the feature was at risk.

    Jo: It's too late for that.

    Francois: Yes, your right.

    <EdC> So, has the poll been taken?

    DKA: Chaals can you live with it?

    Chaals: I can live with it, but we'll get comments that say this is
    meaningless.

    Jo: I think we need to say more than "think and behave courteously".

    EdC: Wasn't the original justification for the sentence to avoid
    mult requests for comparison purposes.

    Jo: We seem to be saying other than to make comparisons, don't issue
    mutiple requests for comparison purposes.

    Chaals: Unclear guidelines won't help the web.

    <EdC> which indeed sounds odd.

    <Jo> [which I agree is unclear]

    DKA: How about you should only make repeated requests to satisfy
    4.1.5 and 4.2.6?

    Chaals: Doesn't change the semantics of the statement.

    Francois: I think that does help.

    <EdC> I think this goes into the right direction, though it is just
    a step.

    <DKA> proxies should only make repeated requests for the same
    resource in the context of complying with 4.1.5 and 4.2.6

    Francois: Mark's comments are that proxies already send repeated
    requests.

    Chaals: What we should do is recommend that proxies not send
    unnecessary multiple requests, but not as a requirement.

    Phil: Is this more normative than the BP?

    Francois: Yes, this is a normative document.

    <Jo> PROPOSED RESOLUTION: Change 4.1.5.1 to say: Content providers
    have found unnecessary repeated requests for the same resource
    operationally difficult, so proxies should (non normative) take
    steps to respect this and as far as possible minimise requests. The
    working group has not found a meaningful way to make a normative
    requirement around this stated objective.

    Phil: I've never seen a spec that says something like that: We don'
    know how to work out what we want to say.

    DKA: Let's table this and come back to it?

    <EdC> We identify a problem (...operationally difficult...) but we
    state we are not solving it?

    <Jo> +1 to what Dan just said as scribed below

    <DKA> PROPOSED RESOLUTION: While complying with sects 4.1.5 and
    4.2.6 proxies should avoid making repeated requests for the same
    resource.

    <DKA> +1

    <EdC> +1

    <DKA> (to Jo's +1 of my +1)

    RESOLUTION: While complying with sects 4.1.5 and 4.2.6 proxies
    should avoid making repeated requests for the same resource.

    <DKA> Scribe: Phil

    <DKA> ScribeNick: PhilA

    <francois> PROPOSED RESOLUTION: Ref. LC-2321 and LC-2036, resolve
    partial, noting that we do not talk about "theoretical idempotency
    of GET requests" anymore, but that we are still advising to reduce
    the number of requests sent for the same resource.

    <EdC> +1

    <DKA> +1

    <Jo> +1

    RESOLUTION: Ref. LC-2321 and LC-2036, resolve partial, noting that
    we do not talk about "theoretical idempotency of GET requests"
    anymore, but that we are still advising to reduce the number of
    requests sent for the same resource.

    <SeanP> +1

    <francois> [37]reply to LC-2036

      [37]
http://lists.w3.org/Archives/Public/public-bpwg-comments/2009OctDec/0067.html

    <francois> PROPOSED RESOLUTION: Ref. LC-2324, resolve yes, the
    inconsistency was removed in 4.1.5.1

    FD: Mark's comment says more than he said in LC-2036

    <DKA> +1

    <francois> +1

    <Jo> +1

    RESOLUTION: Ref. LC-2324, resolve yes, the inconsistency was removed
    in 4.1.5.1

    Jo: So in addition to the text we just agreed, should we add an
    explanatory note so that we can say to Mark that we agree

    <Jo> PROPOSED RESOLUTION: In addition to above add a note to 4.1.5.1
    stating that while HTTP does not prohibit repetition of GET requests
    servers find this troublesome and so it should be avoided

    <francois> +1

    <EdC> should as SHOULD ?

    <Jo> this is a note, so inherently non normative, I think, but
    indeed for clairty that is should (non normative)

    <SeanP> +1

    <EdC> +1

    <Jo> +1

    RESOLUTION: In addition to above add a note to 4.1.5.1 stating that
    while HTTP does not prohibit repetition of GET requests servers find
    this troublesome and so it should be avoided

    <DKA> +1

    <Jo> replace troublesome in the above with p"places an unnecessary
    load on the network and server"

    PhilA: That makes more sense, yes.

    <EdC> Not just that, if I understand correctly the comments; they
    also might confuse some servers.

    <Jo> edc-? yes but we can't state this precisely

    RESOLUTION: Rephrase previous resolution (In addition to above add a
    note to 4.1.5.1 stating that while HTTP does not prohibit repetition
    of GET requests servers find this troublesome and so it should be
    avoided) to talk about places an unnecessary load on the network and
    server and not 'troublesome'.

    <EdC> What about this -- distorts statistics about traffic.

    <Jo> Chaals who just left said "that's not a problem" when I raised
    it earlier, EdC

    <Jo> fwiw I don't agree with Chaals on tis (as in so much else :-) )
    but think the text is sufficient as it stands

LC-2316, response to LC-2034 - HTTP methods

    [38]LC-2316
    [39]LC-2034

      [38]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2316
      [39]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2034

    FD: Suggest we jump to LC-2316

    <francois> ... and response to LC-2034:
    [40]http://lists.w3.org/Archives/Public/public-bpwg-comments/2009Oct
    Dec/0067.html

      [40]
http://lists.w3.org/Archives/Public/public-bpwg-comments/2009OctDec/0067.html

    <EdC> Regarding 2316, intervene can be a) modify HTTP header fields
    b) modify body c) modify method.

    We have a reply from Mark Baker that we list the methods that a
    proxy may play with and he's saying it's unnecessarily restrictive

    scribe: MNot says the server shouldn't intervene and should always
    behave transparently
    ... the argument as ever is that we shouldn't restrict ourselves

    Jo: We have scoped this to talk about traditional web browsers and
    we say that proxies shouldn't mess around with non-traditional web
    browsers
    ... PUT is a bit of a problem...

    Sean: MNot may be misunderstanding the scope of the document

    FD: Maybe we should just say that the scope is just GET nad HEAD

    DKA: Maybe we should say that proxies should be transparent to PUT?
    ... Could we add to 1.3 scope that clarifies the scope?

    Jo: We don't need to

    <EdC> What is the detailed issue with PUT? I just could not hear.

    <EdC> So is the opinion here to delete the very first sentence of
    4.1.1?

    <Jo> ed, no

    <DKA> PROPOSED RESOLUTION: We add language calling out HEAD, POST,
    and GET methods as being in scope into the Scope section.

    <Jo> we are saying that the scope of the document is Web browsing
    and that PUT is not part of that

    FD: If we take the resolution -which I agree with then that makes
    the whole thing moot

    EdC: There is a difference between the proposed resolution and what
    is in the doc now
    ... the proposer resolution means only POST HEAD and GET are in
    scope and everything else is out of scope and I'm not sure that's
    what's intended?

    FD: Yes it is. And I think that's what Mark and Mark are saying. We
    will therefore avoid restricting other HTTP methods
    ... WE don't want to play with options, for example with an OPTIONS
    response, as the body is not defined

    <SeanP> +1 to the resolution

    DKA: I retract my proposed resolution since it's already in the
    document

    Jo: We used to say 'unless you're sure it's traditional web
    browsing, don't mess with it' Then we realised that's not realistic
    ... then we said don't mess with anything other than GET POST and
    HEAD.
    ... Mark & Mark would be happy with saying 'this doc only applies to
    GET POST & heAD'.
    ... Would you be unhappy if we said that?

    <DKA> Eduardo - can you live with us scoping the document to GET
    POST and HEAD.

    Sean: I can live with it since we really haven't thought about other
    things

    EdC: Are there any generic references to HTTP Methods?

    DKA: 4.1.1

    EdC: That's the only place
    ... look at 4.2.1 as well

    FD: It's symmetry since one is about requests and one about
    responses

    Jo: this is a substantive change

    DKA: How can we change the sentence about PST GET and HEAD to say
    that those that do handle such methods do so outside the scope of
    this document

    Jo: How about this (we wait...)

    <EdC> General question -- it is possible to define PUT methods in
    forms within web pages, is it? Are there browsers that do not
    respect this?

    Jo: Call this casuistry ... if the scope of the doc is traditional
    web browsing, we find that comments about 4.1.1 and 4.2.1 allow us
    to change the doc without it being a substantive change as it's out
    of scope.

    <Jo> edc - I thought not - let's check

    <EdC> not in HTML 4.0.1, checking others...

    <EdC> HTML 4.0.1 only accepts post and get. Checking HTML 5.0,
    XHTML...

    Jo: if HTML does not provide a mechanism for PUTting a form then PUT
    is out of scope

    FD: What, like HEAD?

    Jo: Ah...

    <francois> [41]Form possible methods in HTML4

      [41] http://www.w3.org/TR/html4/interact/forms.html#adef-method

    FD: I'm fine with the scope being HEAD GET and POST
    ... It doesn't change anything with the proposed resolution

    <DKA> PROPOSED RESOLUTION: While complying with sects 4.1.5 and
    4.2.6 proxies should avoid making repeated requests for the same
    resource.

    Jo: The binding between HTMl and HTTP is unspecified

    <DKA> PROPOSED RESOLUTION: We add language calling out HEAD, POST,
    and GET methods as being in scope into the Scope section.

    FD: true

    <EdC> XHTML 1.1 -- only post, get.

    <DKA> PROPOSED RESOLUTION: Remove scoping statements from 4.1.1 and
    4.2.1 on the basis that these are redundant; add a note in the scope
    section that the scope of the document is EAD, POST, and GET
    methods.

    <EdC> WML 1.3 -- only post, get.

    PROPOSED RESOLUTION: Remove scoping statements from 4.1.1 and 4.2.1
    on the basis that these are redundant; add a note in the scope
    section that the scope of the document is HEAD, POST, and GET
    methods.

    <DKA> PROPOSED RESOLUTION: Remove scoping statements from 4.1.1 and
    4.2.1 on the basis that these are meaningless recapitulation; add a
    note in the scope section that the scope of the document is EAD,
    POST, and GET methods.

    FD: Why redundant?

    PROPOSED RESOLUTION: Remove scoping statements from 4.1.1 and 4.2.1
    on the basis that these are meaningless recapitulation; add a note
    in the scope section that the scope of the document is HEAD, POST,
    and GET methods.

    <EdC> Why EAD again.

    Jo: I don't think we should specify the methods we talk about as
    that could open unnecessary comments

    <DKA> PROPOSED RESOLUTION: Remove scoping statements from 4.1.1 and
    4.2.1.

    <EdC> Serious problem -- HTML 5.0:

    <EdC> The method and formmethod content attributes are enumerated
    attributes with the following keywords and states:

    <EdC> The keyword GET, mapping to the state GET, indicating the HTTP
    GET method.

    <EdC> The keyword POST, mapping to the state POST, indicating the
    HTTP POST method.

    <EdC> The keyword PUT, mapping to the state PUT, indicating the HTTP
    PUT method.

    <EdC> The keyword DELETE, mapping to the state DELETE, indicating
    the HTTP DELETE method.

    <EdC> Hey, I just consult the standards...

    <francois> +1

    <DKA> +1

    <SeanP> +1

    RESOLUTION: Remove scoping statements from 4.1.1 and 4.2.1.

    <Jo> PROPOSED RESOLUTION: Remove scoping statements from 4.1.1 and
    4.2.1. as they are unnecessary given the scoping statement in 1.3

    Jo: We're removing first sentence of 4.1.1 and 4.2.1. This is a non
    substantive change on the basis that 1.3 (scope) already covers
    this. We're not saying anything about specific methods
    ... What is the response to the comments?

    DKA: I think it' resolved partial as we are making a clarification

    <francois> PROPOSED RESOLUTION: ref. LC-2316, resolve yes, we have
    removed the mention of HTTP methods in 4.1.1 and 4.2.1

    <francois> PROPOSED RESOLUTION: ref. LC-2316, resolve yes, we have
    removed the mention of HTTP methods in 4.1.1 and 4.2.1 because they
    are not in scope of this document as stated in 1.3.

    Jo: can we say "because they're not in scope, as stated in 1.3?"

    <francois> +1

    <DKA> +1

    <EdC> It is not that they are not in scope (some are), it is that
    the scope is dealt with in 1.3 !

    <SeanP> +1

    RESOLUTION: ref. LC-2316, resolve yes, we have removed the mention
    of HTTP methods in 4.1.1 and 4.2.1 because they are not in scope of
    this document as stated in 1.3.

    <francois> PROPOSED RESOLUTION: ref. LC-2034, resolve yes, we have
    removed the mention of HTTP methods in 4.1.1 and 4.2.1 because they
    are not in scope of this document as stated in 1.3.

    <Jo> (edc agree)

    <francois> PROPOSED RESOLUTION: ref. LC-2034, resolve yes, we have
    removed the mention of HTTP methods in 4.1.1 and 4.2.1 because it is
    unnecessary to mention this in this document.

    <Jo> which is scoped to traditional web browsing

    <EdC> With the addendum by Jo, it seems ok.

    <francois> PROPOSED RESOLUTION: ref. LC-2034, resolve yes, we have
    removed the mention of HTTP methods in 4.1.1 and 4.2.1 because it is
    unnecessary to mention this in this document which is scoped to
    traditional web browsing.

    <EdC> +1

    <francois> +1

    <DKA> +1

    RESOLUTION: ref. LC-2034, resolve yes, we have removed the mention
    of HTTP methods in 4.1.1 and 4.2.1 because it is unnecessary to
    mention this in this document which is scoped to traditional web
    browsing.

    10 minute break

    <Jo> -- 10 min break --

LC-2327 - Re-issuing POST requests

    [42]LC-2327

      [42]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2327

    FD: And we have LC-2327
    [43]http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidel
    ines-20091006/2327?cid=2327
    ... COmplaint is about imprecise language
    ... Explains the problem in more detail. A 406 response does not
    mean that the server hasn't processed the request

      [43]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2327?cid=2327

    Sean: That doesn't make sens

    FD: It says the response is unacceptable

    DKA: But I did it anyway??
    ... Are you saying that your understanding of HTTP is in alignmnt
    with that?

    <EdC> Strictly speaking, it means (from RFC2616): The server
    understood the request, but is refusing to fulfill it.

    FD: Yes. And I don't think this brings a lot to teh doc. If it's a
    problem, let's just remove it

    Sean; 406 is pretty rare, right?

    FD: yes in practice no one sends a 406

    <DKA> PROPOSED RESOLUTION: Remove language on issuing repeated POST
    requests on 406 responses and resolve yes on LC-2327.

    FD: and secondly I can't see where a proxy would want to repeat a
    POST request
    ... Let's stick with proxy must not repeat a POST request when
    received a 406

    Jo: This is again in response to real world situations

    Jo and Francois continue discussion

    Sean: This is so unlikely

    FD: yes
    ... that's why I think we can remove it

    <EdC> Where does RFC2616 state that repeating a POST on 406 is
    disallowed? This is the case for 403, but I cannot find it for 406.

    <francois> PROPOSED RESOLUTION: replace final paragraph in 4.1.5.2
    with "A proxy MUST NOT reissue a POST request".

    <francois> (The guidelines could be fine-tuned to say "In accordance
    with the HTTP RFC" or to add "even with altered HTTP headers".

    <DKA> +1

    <EdC> +1

    <SeanP> +1

    Jo: It looks as if HTTP does not specify a way to say that a post
    was not actioned
    ... I think it's probably unsafe to take this resolution

    DKA: Can you live with it?

    <EdC> where does the danger lurk?

    FD: Should we strike the whole paragraph?

    <EdC> What is the issue?

    FD: I think we should clarify the doc as much as possible

    DKA: Yes but what are saying about this thing?
    ... You want to rephrase to say that a proxy shouldn't issue a
    repeated POST request without alerting the user?

    <Jo> I think that saying that it MUST not reisuuse a POST is
    contrary to HTTP - probably best to say MUST NOT without informing
    the user of the possible consequences

    <EdC> informing and giving a choice to the user, or just telling him
    "this may be bad, hold on while I do it" ?

    <Jo> solicit the users approval is what I meant, though did not say
    so explicitly

    Sean: would this also apply if the user went back?

    <francois> I note we will have to go back to the notion of "user
    interaction" as it is defined in several places in the spec.

    Jo: That's a browser function

    Sean: yes but the proxy would be re-issuing the same request

    <EdC> Not exactly the same, I gather. To the same resource with the
    same arguments, but with different HTTP header fields.

    <Jo> the point, I think, Edc, is that a 406 response does not
    indicate that the original POST has not beein actioned

    <EdC> Well, this is what it states: The resource identified by the
    request is only capable of generating response entities which have
    content characteristics not acceptable according to the accept
    headers sent in the request.

    <EdC> Unless it was a HEAD request, the response SHOULD include an
    entity containing a list of available entity characteristics and
    location(s) from which the user or user agent can choose the one
    most appropriate. The entity format is specified by the media type
    given in the Content-Type header field.

    FD: Can we say that a proxy shouldn't reissue a POST request and
    check it with MNot?

    <Jo> edc: The action performed by the POST method might not result
    in a

    <Jo> resource that can be identified by a URI. In this case, either
    200

    <Jo> (OK) or 204 (No Content) is the appropriate response status,

    <EdC> Now are you stating that the server would go in a mode where
    it first applies side-effects and then attempts to generate content
    just to find out it cannot do so with an appropriate format?

    <Jo> depending on whether or not the response includes an entity
    that

    <Jo> describes the result.

    <Jo> we are only responding to MNot's comment about the semantic of
    406

    <francois> Comment is: "e.g. it allows retrying a POST request upon
    a 406, even though this isn't allowed in HTTP."

    <Jo> I don 't see a reference in HTTP where it is not allowed, but
    he is the expert

    <EdC> Well, as I said, this is true for 403, but I cannot find
    anything conclusive about such a prohibition for 406.

    <Jo> edc - agree

    <Jo> but equally 406 doesn't specifically mean that the change had
    not been applied

    Further discussion around the topic continues

    Jo begins to come to a conclusion

    <EdC> OK, so the situation is that repeating a POST might have
    unintended (cumulative) side effects. On the other hand, a 406
    response SHOULD include a list of alternative resources to select
    from. So couldn't the CT proxy deal with that -- i.e. either select
    the best one, or failing which, sending back a generic "no response
    available" to the client?

    Jo: apologises for taking so long but having discussed around the
    subject I now agree with the resolution.

    FD: Ah but I disgree with it now
    ... (kidding)

    <Jo> edc - this discussion is limited to 406 in response to a POST

    <EdC> indeed, but 406 applies to POST as well: Unless it was a HEAD
    request, the response SHOULD include an entity

    <EdC> containing a list of available entity characteristics and
    location(s)

    <EdC> from which the user or user agent can choose the one most

    <EdC> appropriate.

    <francois> PROPOSED RESOLUTION: replace final paragraph in 4.1.5.2
    with "A proxy MUST NOT reissue a POST request as it is unsafe (see
    section 9.1.1 of RFC 2616)"

    <SeanP> +1

    <Jo> right, but then reissuing the POST is still not edc, right

    <EdC> +1

    <DKA> +1

    <EdC> I was not sure whether the topic was 406 as such, or being
    allowed to reissue a POST, or whether it was safe. It's ok now.

    <francois> +1

    RESOLUTION: replace final paragraph in 4.1.5.2 with "A proxy MUST
    NOT reissue a POST request as it is unsafe (see section 9.1.1 of RFC
    2616)"

    <Jo> +1

    <francois> PROPOSED RESOLUTION: ref. LC-2327, resolve yes, and note
    that we have removed the exception.

    <Jo> +1

    <francois> +1

    <DKA> +1

    RESOLUTION: ref. LC-2327, resolve yes, and note that we have removed
    the exception.

    <SeanP> +1

LC-2269 - MIME types for data exchanges

    [44]LC-2269 from EdC

      [44]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2269

    FD: it's about avoiding interference with data MIME type exchanges

    <Jo> given that we are in substantive changes already I agree with
    Edc and further think a note is needed to watch out for new MIME
    types as circumstances move on

    <EdC> Basically, the problem is acknowledged in 4.1.3.
    Unfortunately, there is no guidance about how to do it with two
    important applications based on HTTP.

    <Jo> PROPOSED RESOLUTION: Adopt the additional MIME types suggested
    by EdC and make note about this list not being complete

    <EdC> With respect to the original comment on SOAP, proxies should
    handle as SOAP forwarding proxies (SOAP specs, 2.7.2).

    <Jo> ref soap - it's out of scope

    <EdC> These allow some manipulations that transparent proxies do not
    perform. But they are defined in a standard.

    <EdC> This is a similar point as with WAP gateways (they can perform
    some standard manipulations).

    <Jo> this is about Web browsing as previously discussed, not SOAP or
    WAP or Thought Transference or ...

    <DKA> +1 to Jo

    [[ List of proposed MIME types:

    application/json

    application/xml

    text/xml

    application/soap+xml

    application/soap+fastinfoset

    application/fastsoap

    application/fastinfoset

    ]]

    <Jo> mea culpa, as previously discussed ad nauseam, pls srike
    application/xml from the list

    francois: I think we should remove application/xml and text/xml as
    previously discussed.
    ... They may be used to serve XHTML content, even though this is not
    encouraged.

    sean: Where would this go? In 4.2.9?

    francois: We need to discuss the SHOULD/MUST level, as EdC suggests
    that it should be a MUST.

    <EdC> (and they do not exactly fit into the list of "Internet
    Content Types associated with Mobile Content")

    jo: aren't they out of scope? They're not associated with
    traditional Web browsing.

    <EdC> (although... It is Internet content, though not browsing).

    dka: they can't be out of scope because Web applications more and
    more involve JSON parsing.

    <EdC> But they are carried over HTTP (raw) and this is acknowledged
    as a problem in 4.1.3.

    jo: on that basis, almost any kind of MIME type could be listed
    here.

    dka: no, we're just listing MIME types that are commonly associated
    and used with data exchanges.

    jo: isn't XHTML extensible so that it can be used to transport data?

    <EdC> AJAX is becoming widespread -- as elements of Web pages and
    applications.

    francois: I agree that we cannot address the XHTML case that is
    common: retrieving some XHTML fragment and including it in the page.

    jo: I think we are opening a can of worms here.

    <EdC> Is this specific XHTML case not homologous to the types
    application/xml text/xml ?

    sean: This would naturally fit in 4.1.3

    francois: 4.1. is about HTTP requests, 4.2 is about HTTP responses.
    This should go to 4.2

    <EdC> Wait. Do AJAX pages not send also snippets to servers?

    <EdC> In this situation, it applies both to request and response.

    francois: I propose to add a bullet point to 4.2.9 with "the
    Content-Type has a value listed in [an appendix with data MIME
    types]"

    <DKA> PROPOSED RESOLUTION: add a bullet point to 4.2.9 for "content
    that is data - e.g. [list of mime types]"

    <DKA> PROPOSED RESOLUTION: add a bullet point to 4.2.9 for "content
    that is data - [list of mime types]"

    <EdC> The list of mime types being?

    <DKA> PROPOSED RESOLUTION: add a bullet point to 4.2.9 for "content
    that is data - [appendix with list of data mime types]"

    <EdC> (this must be included in a resolution).

    <DKA> PROPOSED RESOLUTION: add a bullet point to 4.2.9 for "content
    that is data - [appendix with list of data mime types]";
    application/json ; application/soap+xml ;
    application/soap+fastinfoset ; application/fastsoap ;
    application/fastinfoset

    <Jo> PROPOSED RESOLUTION: Under 4.1.3 add "and responses" to
    alteration of requests and add also the sentence, Increasingly
    browser based applications involve exchanges of data using
    XmlHttpRequest(see 4.2.9 bullet x) and alteration of such exchanges
    is likely to cause misoperation.

    <EdC> Make sure the spelling is XMLHttpRequest .

    dka: both proposed resolutions are compatible and on the table

    <DKA> +1 to both

    <EdC> +1 to both.

    <SeanP> +1 to both

    <Jo> +1 to everything

    francois: I am not sure that I understand the need to add a
    reference to HTTP responses in 4.1.3, but that looks good

    +1

    jo: [explaining to francois]

    RESOLUTION: add a bullet point to 4.2.9 for "content that is data -
    [appendix with list of data mime types]"; application/json ;
    application/soap+xml ; application/soap+fastinfoset ;
    application/fastsoap ; application/fastinfoset
    ... Under 4.1.3 add "and responses" to alteration of requests and
    add also the sentence, Increasingly browser based applications
    involve exchanges of data using XmlHttpRequest(see 4.2.9 bullet x)
    and alteration of such exchanges is likely to cause misoperation.

    PROPOSED RESOLUTION: ref. LC-2269, resolve yes, and note that we
    have added a bullet point under 4.2.9, an appendix and a reference
    in 4.1.3 to address this situation

    <SeanP> +1

    <DKA> +1

    +1

    <EdC> 0 (I am on the receiving side on this one).

    RESOLUTION: ref. LC-2269, resolve yes, and note that we have added a
    bullet point under 4.2.9, an appendix and a reference in 4.1.3 to
    address this situation

    <Jo> PROPOSED RESOLUTION: Add a cautionary not under 4.2.9 that the
    list is not exhaustive and is likely to change

    jo: I have a further point to make on this, see proposed resolution

    <EdC> Alternatively, the cautionary note can be put in the relevant
    appendix.

    francois: this comment applies to multiple appendices

    <DKA> +1

    <EdC> +1

    <Jo> PROPOSED REVOLUTION: Add the above-mentioned cautionary note to
    all applicable appendices

    +1

    <EdC> +1

    <SeanP> +1

    RESOLUTION: Add the above-mentioned cautionary note to all
    applicable appendices

LC-2270 - Servers preferences regarding HTTPS links re-writing

    [45]LC-2270

      [45]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2270

    francois: comment is from Eduardo on the need for proxies to give
    the possibility to servers to express their preference re. HTTPS
    links re-writing

    [[ "Proxies must provide a means for servers to express preferences
    for inhibiting

    HTTPS URL rewriting regardless of the preferences expressed by the
    user.

    Those preferences must be maintained on a Web site by Web site
    basis." ]]

    jo: chaals wanted to comment on that. I think he wanted to disagree,
    but he's not here anymore.

    <EdC> Did he write down something?

    francois: one objection we had is that it is not testable.

    <EdC> Does this objection apply to 4.2.2 as well then?

    I don't think so in the sense that we are going to (or we should at
    least) try to precise what we mean with user interaction. There is
    no real way for a proxy to interact with servers.

    dka: so what do we do with this question?

    jo: what does Eduardo suggest?

    <EdC> This specification reserves the method name CONNECT for use
    with a

    <EdC> proxy that can dynamically switch to being a tunnel (e.g. SSL

    <EdC> tunneling [$1\47]).

    EdC: does anyone know the internals of the CONNECT HTTP method?

    <Jo> 9.9 CONNECT

    <Jo> This specification reserves the method name CONNECT for use
    with a

    <Jo> proxy that can dynamically switch to being a tunnel (e.g. SSL

    <Jo> tunneling [$1\47]).

    Sean: I know a little bit on that, yes.

    fd: what are you getting at, EdC?

    EdC: if we provide a very precise mechanism, we're going to do
    non-standard things. If we leave it out, then we say that it is not
    testable and that we have to remove it.

    francois: what is the relationship with CONNECT here?
    ... The CONNECT request occurs after HTTPS URL rewriting, not
    before.

    EdC: right, so that's off the table.
    ... My proposal remains.

    DKA: can you turn that into a proposed resolution, EdC?

    <EdC> PROPOSED RESOLUTION: add to 4.2.9.4 "Proxies must provide a
    means for servers to express preferences for inhibiting

    <EdC> HTTPS URL rewriting regardless of the preferences expressed by
    the user. Those preferences must be maintained on a Web site by Web
    site basis."

    <EdC> PROPOSED RESOLUTION: add to 4.2.9.4 "Proxies must provide a
    means for servers to express preferences for inhibiting HTTPS URL
    rewriting regardless of the preferences expressed by the user. Those
    preferences must be maintained on a Web site by Web site basis."

    <SeanP> -1

    -1 because it can be interpreted freely by proxy implementers

    jo: what Eduardo seems to be saying is that proxies should be
    maintaining whitelists, which is contrary to the spirit of what we
    are trying to do in my view.

    <EdC> The preferences must not necessarily be maintained by proxies.
    There can be a "favicon/robots.txt" mechanism -- which servers
    maintain.

    <DKA> +1 to jo -1 to this proposal

    <Jo> the point being tnhat those whitelists have to be maintained by
    arbitrary and opaque mechaniusms for each of the 600 odd operators
    around the world

    francois: may I suggest that we add this to "Scope for Future Work"
    as we're talking about things that do not exist yet.

    <Jo> robots.txt etc. looks to me like "new technology" so not in
    scope for this WG

    <DKA> Eduardo - can you live with it if we move this to a scope for
    future work?

    <EdC> OK, if the scope includes a specific statement about
    requirements as in proposed resolution.

    jo: I think there's already some text about this in that appendix.

    <EdC> I.e. preferences of server regardless of user preferences,
    website by website basis.

    jo: so the note under 4.2.9.3 could be completed to reference to the
    scope for future work section.

    francois: not sure I see what we're going to put under section J.
    though.

    jo: let me type in some proposed resolution

    <Jo> PROPOSED RESOLUTION: Add a section under J saying that a
    mechanism for establishing two party consent as discussed under
    4.2.9.3 is needed

    <SeanP> +1

    francois: EdC wants to add some more precise text as written in IRC.

    jo: I believe it is implicit in "two party consent".

    <Jo> suggest EdC proposes a phrase containing "two party consent" to
    have more precise semantics that he requires

    <EdC> I missed something there about two party consent... Basically,
    a requirement is that the server must have a possibility to
    negotiate or deny HTTPS link rewriting.

    <EdC> And this in a handshake of some sort with the proxy.

    francois: I think you are both talking about the same thing

    jo: let me try to rephrase the proposed resolution

    <Jo> edc - see the note under 4.2.9.3 referring to two party consent
    that is to be linked to a new section in J that states that such a
    mecahnism is needed

    EdC: I wanted to make sure that the rationale of my comment was not
    lost, i.e. why a server must be granted the possibility to deny
    HTTPS links rewriting.

    jo: all I want is some proposed text as I don't quite get where the
    problem here is with the current proposal to add a further section
    in Appendix J.
    ... and link to it from 4.2.9.3.
    ... mentioning two-party consent.

    <DKA> PROPOSED RESOLUTION: Add a section under J saying that a
    mechanism for establishing two party consent (that the server must
    have a possibility to negotiate or deny HTTPS link rewriting) as
    discussed under 4.2.9.3 is needed.

    <EdC> One point: but such mechanisms do not exist at the time of
    writing of this document should actually be but such _standard_
    mechanisms do not exist at the time of writing of this document.

    <Jo> OK, let's take that precision on board

    <Jo> PS - in English we don't use the word precision in that sense,
    but we should

    PROPOSED RESOLUTION: Add a section under J saying that a standard
    mechanism for establishing two party consent (that the server must
    have a possibility to negotiate or deny HTTPS link rewriting) as
    discussed under 4.2.9.3 is needed.

    +1

    <EdC> +1

    <DKA> +1

    <SeanP> +1

    <Jo> +1

    RESOLUTION: Add a section under J saying that a standard mechanism
    for establishing two party consent (that the server must have a
    possibility to negotiate or deny HTTPS link rewriting) as discussed
    under 4.2.9.3 is needed.

    PROPOSED RESOLUTION: ref. LC-2270, resolve partial, and note that no
    standard mechanism can be used for establishing two party consent at
    the time of writing of this document and that a section was added in
    the Scope for Future Work appendix.

    <DKA> +1

    <EdC> 0

    <SeanP> +1

    +1

    <Jo> +1

    RESOLUTION: ref. LC-2270, resolve partial, and note that no standard
    mechanism can be used for establishing two party consent at the time
    of writing this document and that a section was added in the Scope
    for Future Work appendix.

    <DKA> 5 minutes

HTTPS links rewriting - 2 conformance levels?

    <Jo> I am suggesting two confromance levels:

    <Jo> one which treats 4.2.9.2 as MUST NOT

    <Jo> the other demans a conformance statement regarding NOT
    RECOMMENDED specifying when and how it does it

    <EdC> Are you sure it is 4.2.9.2, and not rather 4.2.9.3?

    <Jo> no, I am sure I am wrong and you are right

    dka: We're back on. Jo, can we leave that aside for the moment and
    deal with last call comments first?

    <Jo> if there is no support for this I will move on in the interests
    of being able to live with the conformance classes as it stands

    francois: are we getting back to this later, or throwing the
    proposal away?

    jo: if there's no support, let's drop it.

    dka: I'm not saying I approve or not, just that we should deal with
    LC first.

    jo: I am suggesting that we have one class of product for which
    re-writing HTTPS links is a "MUST NOT", and one class of product for
    which re-writing HTTPS links is a "STRONGLY NOT RECOMMENDED" and
    needs to be explained in the ICS.

    EdC: but you would have to add this second level

    jo: yes, that's precisely the idea

    francois: I note that we would have to find implementations of both
    levels to move the document forward

    dka: good point. I don't support things that would delay us any
    further.
    ... can we drop it for now and move on to the next LC comment?

LC-2317 - User notification

    [46]LC-2317

      [46]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2317

    <EdC> This is what Rotan proposed
    [47]http://lists.w3.org/Archives/Public/public-bpwg/2009Dec/0008.htm
    l

      [47] http://lists.w3.org/Archives/Public/public-bpwg/2009Dec/0008.html

    DKA: that's about user notification

    francois: yes, we need to precise what "user interaction" means when
    we mention it in the guidelines, because it can be interpreted in
    many different ways. Mark suggests that a Warning HTTP header could
    then be enough. And this is not what we want, clearly.
    ... Rotan suggested some text.

    jo: so that's another LC?

    <EdC> Probably, in the same category as LC2317.

    francois: no, I just referenced more guidelines than Mark, but it's
    the same comment as LC-2317

    jo: I wouldn't use exactly Rotan's wording.

    dka: can we action you to do that, jo?

    jo: you can.

    <EdC> So a resolution proposal is in the making?

    PROPOSED RESOLUTION: ref. LC-2317, resolve yes, and add a definition
    of user interaction that mentions the communication channel. Exact
    wording to be defined by the Editor. This definition should be used
    in all the guidelines that mention user interaction.

    <EdC> I would prefer to define it once, give it a standard name, and
    use the standard name wherever needed in the guidelines.

    <Jo> PROPOSED RESOLUTION: ref. LC-2317, resolve yes, and add a
    definition of user interaction that mentions the communication
    channel. Exact wording to be defined by the Editor. This definition
    should be used in all the guidelines that mention user interaction
    similarly to Rotan's proposal in
    [48]http://lists.w3.org/Archives/Public/public-bpwg/2009Dec/0008.htm
    l

      [48] http://lists.w3.org/Archives/Public/public-bpwg/2009Dec/0008.html

    <EdC> +1

    That is also what I have in mind, EdC.

    <DKA> +1

    <Jo> +1

    <SeanP> +1

    +1

    <EdC> It is ok.

    RESOLUTION: ref. LC-2317, resolve yes, and add a definition of user
    interaction that mentions the communication channel. Exact wording
    to be defined by the Editor. This definition should be used in all
    the guidelines that mention user interaction similarly to Rotan's
    proposal in
    [49]http://lists.w3.org/Archives/Public/public-bpwg/2009Dec/0008.htm
    l

      [49] http://lists.w3.org/Archives/Public/public-bpwg/2009Dec/0008.html

LC-2318 - Cache-Control: no-transform precedence

    [50]LC-2318

      [50]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2318

    francois: it's a request to clarify section 4.1.5 and in particular
    the fact that Cache-Control: no-transform takes precedence.

    jo: fair enough.

    <Jo> PROPOSED RESOLUTION: re LC-2318 resolve yes and add text to
    clarify

    <Jo> +1

    <SeanP> +1

    +1

    <DKA> +1

    <EdC> +1

    RESOLUTION: re LC-2318 resolve yes and add text to clarify

LC-2320 - Driving a truk through the guidelines

    [51]LC-2320

      [51]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2320

    francois: the comment is about the third bullet point in 4.1.5
    ... first thing we can do is to add a link to 4.1.5.4 on Sequences
    of requests that contain some normative statements.

    <EdC> I get the justification for the second part of the sentence,
    but does anybody have a clear example where "it is technically
    infeasible not to adjust the request because of earlier interaction"
    ?

    jo: I agree that you can certainly get a wide van through this.

    francois: I agree with EdC here. Let's drop this part if it doesn't
    address any real use case.

    jo: I agree. I had made a mental note to add a backward reference in
    4.1.5.4 anyway.

    PROPOSED RESOLUTION: ref LC-2320, resolve yes, remove "it is
    technically infeasible not to adjust the request because of earlier
    interaction", and add a link to 4.1.5.4 on sequence of requests.

    <DKA> +1

    <EdC> +1

    <Jo> PROPOSED RESOLUTION: remove all following Web site in bullet 3.
    of 4.1.5 and add a reference to 4.1.5.4

    +1 to jo's proposed resolution

    <Jo> +1 to me, I rock

    <SeanP> +1 to either resolution

    <DKA> +1

    <DKA> +1 to rock

    <Jo> remove all following "Web site" in bullet 3. of 4.1.5 and add a
    reference to 4.1.5.4

    <DKA> "can you live with it?"

    EdC: you are broadening the bullet point, right?

    francois: no, because the "see 4.1.5.4" will define the context

    EdC: 4.1.5.4 is about included resources, here it's about sequences
    of requests in the same Web site.

    francois: oops. You're right.

    <EdC> 4.1.5.4 deals with included and linked resources.

    dka: so how can we rephrase this

    jo: I think it's fine, actually.

    <EdC> "the request is part of a sequence of requests to retrieve
    linked or included resources from the same Web site as in 4.1.5.4".

    <Jo> 3. the request is part of a sequence of requests to linked and
    included resources (see 4.1.5.4)

    <EdC> And actually we can drop "same web site" really.

    <EdC> since included or linked resources might be on another web
    site.

    <Jo> edc - agree, that is what we are saying

    <Jo> but

    <Jo> in 4.1.5.4 linked resources on another Web site are carved out

    <EdC> OK, so the sequence only referes to included resources.

    jo: I think we can drop "same Web Site" indeed

    <Jo> no, linked resources on same Web site are included

    <Jo> so it is included resources or linked resources on same site?

    PROPOSED RESOLUTION: remove all following "sequence of requests" in
    bullet 3. of 4.1.5 and add a reference to 4.1.5.4

    <Jo> PROPOSED RESOLUTION: replace bullet 4 of 4.1.5 with: 3. the
    request is part of a sequence of requests to included resources AND
    LINKED RESOURCES ON THE SAME wEB SITE (see 4.1.5.4)

    <SeanP> +1

    <Jo> PROPOSED RESOLUTION: replace bullet 4 of 4.1.5 with: 3. the
    request is part of a sequence of requests to included resources and
    linked resources on the same Web site (see 4.1.5.4)

    <EdC> substitute AND with OR?

    <Jo> +1

    <EdC> included resources or to linked resources...

    <SeanP> +1

    <EdC> OR=> either one, or the other, or both.

    <EdC> The sequence of requests must be for both, if with AND.

    <Jo> PROPOSED RESOLUTION: replace bullet 4 of 4.1.5 with: 3. the
    request is part of a sequence of requests comprising either
    iincluded resources or linked resources on the same Web site (see
    4.1.5.4)

    +1

    <Jo> not in english, EdC

    <SeanP> +1

    <EdC> +1

    <DKA> +1

    <Jo> +1

    +1

    <Jo> +1

    RESOLUTION: replace bullet 4 of 4.1.5 with: 3. the request is part
    of a sequence of requests comprising either included resources or
    linked resources on the same Web site (see 4.1.5.4)

    PROPOSED RESOLUTION: ref. LC-2320, resolve yes, and point to the
    changes just resolved

    +1

    <Jo> +1

    RESOLUTION: ref. LC-2320, resolve yes, and point to the changes just
    resolved

    <SeanP> +1

    <DKA> +1

LC-2328 - Ignoring no-transform

    [52]LC-2328

      [52]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2328

    <phila> FD: MNot didn't make any specific reference in the spec

    <phila> FD: I think he means 4.2.3

    <phila> scribe: PhilA

    <scribe> scribeNick: PhilA

    Sean: That seems reasonable to me

    FD: I agree
    ... does it occur in practice? Who uses cache control no transform
    now?

    Jo: it was added y Bryan Sullivan

    <EdC> Does the comment apply to the first or the second paragraph of
    2.4.3?

    Sean: It allows proxies to tell the client that there could be a
    problem

    Jo: I'm more than happy to strike this paragraph which I've never
    been happy with

    Sean: I don't think we've ever done this
    ... I think this is more of a forward-looking thing

    Jo: There are probably more effective remedies.

    <Jo> PROPOSED RESOLUTION: Remove 2nd para of 4.2.3 and adjust end of
    first para to suit

    <DKA> +1

    <Jo> +1

    <EdC> +1

    <SeanP> 0

    <francois> +1

    Sean: proxies are going to ignore this if they think it's going to
    cause problems for the user - and I think that's reasonable
    behaviour

    Jo: I sort of agree
    ... they must provide the option of delivering the content unaltered
    which reduces the power of the statement
    ... the primary use case is if the proxy thinks that some stuff is
    intended for display even though it's not

    Sean: I would think it could kick in if the server sends a large
    page that the proxy knows will be too large for the client

    FD: But we're restricted to cache-control: no transform

    Sean: That's why I say 0 not -1

    <Jo> no objections then

    RESOLUTION: Remove 2nd para of 4.2.3 and adjust end of first para to
    suit

    <francois> PROPOSED RESOLUTION: ref. LC-2328, resolve yes, exception
    to the rule in 4.2.3 was removed.

    <Jo> +1

    <DKA> +1

    RESOLUTION: ref. LC-2328, resolve yes, exception to the rule in
    4.2.3 was removed.

LC-2329 - Blurring the semantics of a 200 response

    [53]LC-2329

      [53]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2329

    FD: he saying we blur the semantics of the 200 response
    ... what we could do is say that you should use something other than
    406

    Sean: We're not really breaking any HTTP rules here are we?

    <EdC> I suspect his objection is that the procedure to determine
    that the content is equivalent to a response with an HTTP 406 Status
    is not undetermined and not specifiable.

    FD: We could link to the subsequent sections which contain details
    of when the 200 response should not be touched
    ... the bullet points in 4.2.9 - if they're included then you can
    interpret that the browser browser isn't supported

    Jo: My feeling is that...
    ... subject to and notwithstanding...
    ... taking into account various salient points and the full
    context...

    <EdC> .. and with due consideration to all relevant aspects ...

    <Jo> ... er

    <Jo> ... um

    <DKA> Can we proceed with alacrity please?

    Jo: It is not us that is blurring the distinction. It's the content
    providers who are using 200 to say "your browser is not supported"

    <Jo> ... so we are responding to a dsitinction that is already
    blurred rather than blurring it

    FD: So do you have some proposed text?

    <Jo> PROPSOED RESOLUTION: In respect of LC-2329, resolve no, we take
    your point, but pragmatically speaking the distinction is blurred by
    Web site owners

    <EdC> Do we want to state that servers SHOULD NOT use a 200 response
    to indicate that the browser or the user agent characteristics are
    unsupported?

    <francois> we already say that, EdC

    <EdC> Retract this.

    <SeanP> +1 to the resolution

    <DKA> +1

    <Jo> EdC, out of scope but referred to in the appendices

    <Jo> +1

    <francois> +1

    RESOLUTION: In respect of LC-2328, resolve no, we take your point,
    but pragmatically speaking the distinction is blurred by Web site
    owners

    FD: We're done with LC comments AFAICS

    <Jo> sound oif champagne corks popping

    <EdC> WAIT !! what about that 406 issue?

    FD: But I have more to say....

    Jo: I would like us to write a formal position on 406 and I'm happy
    to do it so let's deal with it

    <Jo> PROPOSED RESOLUTION: In respect of the 406 issue, having taken
    everything that I have been made aware of into consdieration, and
    after due reflection, my view is that not using 406 on the basis of
    consultion a DDR is not technically determining that the conclusion
    has been drawn from the accept headers specifically, as stated in
    sthe specification of the 406 status, is silly

    <EdC> What is a "consultion a DDR"?

    FD: Je pense que je suis d'accord
    ... I just want record that we think we're using 406 correctly and
    that no one is saying otherwise

    <EdC> I remind that 403 can be used in a general case.

    <EdC> We can just add this to the relevant section of the appendix.

    <Jo> PROPOSED RESOLUTION: In respect of the 406 issue, HTTP says
    that 406 means "The resource identified by the request is only
    capable of generating response entities which have content
    characteristics not acceptable according to the accept headers sent
    in the request." To use a different code on the basis that
    incompatibility has been estaqblished by some means other than the
    accept headers...

    <Jo> ...seems silly and pedantic to me.

    <francois> +1

    <DKA> +1

    RESOLUTION: In respect of the 406 issue, HTTP says that 406 means
    "The resource identified by the request is only capable of
    generating response entities which have content characteristics not
    acceptable according to the accept headers sent in the request." To
    use a different code on the basis that incompatibility has been
    estaqblished by some means other than the accept headers...

LC-2319 - Clarification on "aside from"

    [54]LC-2319

      [54]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2319

    FD: we are already going to say cache-control: no transform trumps
    all

    <Jo> PROPOSED RESOLUTION: In re LC-2319, resolve yes and modify the
    text to say Other than the fields that RFC 2616 says must be
    modified ...

    <SeanP> +1

    <EdC> I would prefer "other than the modifications required by
    RFC2616, ..." I am not sure, but the method or body might be
    modified as well as the fields.

    <Jo> PROPOSED RESOLUTION: In re LC-2319, resolve yes and modify the
    text to say Other than the modifications required by RFC 2616

    <francois> +1

    <SeanP> +1

    <Jo> +1

    <EdC> +1

    <DKA> +1

    RESOLUTION: In re LC-2319, resolve yes and modify the text to say
    Other than the modifications required by RFC 2616

LC-2322 - Processing "handheld" links

    [55]LC-2322

      [55]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2322

    Jo: I regard it as obvious from the context that we're talking about
    mobile

    FD: yes but it needs clarification. It's right to put 'process'
    between quotes as it is vague
    ... Clarification - he, MNOt, is right to put 'process' in quotes

    <Jo> PROPOSED RESOLUTION: in re LC-2322 - add to 4.2.7, in
    parentheses, If the user agent is determined as being "handheld"

    <SeanP> +1

    <EdC> +1

    <DKA> +1

    <Jo> +1

    <francois> +1

    RESOLUTION: in re LC-2322 - add to 4.2.7, in parentheses, If the
    user agent is determined as being "handheld"

LC-2268 - Using a desktop browser over a mobile network

    [56]LC-2268 from Thomas

      [56]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2268

    FD: I don't think it's a real problem

    Jo: +1
    ... How about we change the 2nd bullet of 4.2.9

    <Jo> PROPOSED RESOLUTION: Change "the user agent has features (such
    as linearization or zoom) that allow it to present the content
    unaltered;" to "the user agent has features (such as linearization
    or zoom, is a desktop device using a mobile network for access) that
    allow it to present the content unaltered;"

    <francois> +1

    <Jo> +1

    <francois> +1

    <SeanP> +1

    <EdC> "desktop device using a mobile network for access" what if I
    am using a mobile browser for testing on a desktop?

    <Jo> PROPOSED RESOLUTION: Change "the user agent has features (such
    as linearization or zoom) that allow it to present the content
    unaltered;" to "the user agent has features (such as linearization
    or zoom, is a desktop device using a mobile network for access) that
    allow it to present the content without the need for alteration by
    the proxy;"

    <DKA> +1

    <francois> +1

    <Jo> "including but not limited to!"

    <Jo> +1

    RESOLUTION: Change "the user agent has features (such as
    linearization or zoom) that allow it to present the content
    unaltered;" to "the user agent has features (such as linearization
    or zoom, is a desktop device using a mobile network for access) that
    allow it to present the content without the need for alteration by
    the proxy;"

    <SeanP> +1

    <francois> PROPOSED RESOLUTION: ref LC-2268, resolve yes, and point
    to the updated bullet in 4.2.9

    <DKA> +1

    <Jo> +1

    <SeanP> +1

    <francois> +1

    RESOLUTION: ref LC-2268, resolve yes, and point to the updated
    bullet in 4.2.9

LC-2267 - Enforcing same-origin policy

    [57]LC-2267 from Thomas

      [57]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2267

    FD: First part of the reply could be 'thank you'

    Jo and Francois discuss options

    Jo: Tlr is essentially asking us to add a note to say "don't
    underestimate how hard this is"
    ... I think we say we don't want to do this as we' d be stepping
    into the internal processes used by proxies

    <Jo> PROPOSED RESOLUTION: ref LC-2267, resolve no, the document does
    not specify the internal operation of transforming proxies so we
    find it hard to think of anything useful to say

    <francois> +1

    <EdC> +1

    <DKA> +1

    <SeanP> +1

    RESOLUTION: ref LC-2267, resolve no, the document does not specify
    the internal operation of transforming proxies so we find it hard to
    think of anything useful to say

    <EdC> What is the current issue?

Back to LC-2289 and LC-2323 - Usefulness of the document

    <francois> PROPOSED RESOLUTION: ref LC-2323, resolve partial, we
    have added text to clarify some guidelines and do not think this is
    the final word on the subject, though we think it is a valuable
    contribution on the subject.

    <SeanP> +1

    <Jo> +1

    <francois> +1

    RESOLUTION: ref LC-2323, resolve partial, we have added text to
    clarify some guidelines and do not think this is the final word on
    the subject, though we think it is a valuable contribution on the
    subject.

    <francois> PROPOSED RESOLUTION: ref LC-2289, resolve no, as it is
    not the intention of the document to address legal, moral or
    liability issues.

    <SeanP> +1

    <DKA> +1

    <Jo> +1

    RESOLUTION: ref LC-2289, resolve no, as it is not the intention of
    the document to address legal, moral or liability issues.

Decision to publish another Last Call Working Draft

    <Jo> PROPOSED RESOLUTION: The WG reluctantly accepts that the
    changes agreed today constitute Substantive Modification, and hence
    requires to enter Last call a further time

    <francois> +1

    <EdC> +1

    <SeanP> +1

    <Jo> ACTION: Jo to enact changes resolved today with minimal
    possible casuisitry [recorded in
    [58]http://www.w3.org/2009/12/10-bpwg-minutes.html#action02]

    <trackbot> Created ACTION-1028 - Enact changes resolved today with
    minimal possible casuisitry [on Jo Rabin - due 2009-12-17].

    <DKA> +1 with lachramousity

    RESOLUTION: The WG reluctantly accepts that the changes agreed today
    constitute Substantive Modification, and hence requires to enter
    Last call a further time

    <francois> ACTION: fd to draft responses to reviewers based on
    resolutions taken during the F2F [recorded in
    [59]http://www.w3.org/2009/12/10-bpwg-minutes.html#action03]

    <trackbot> Created ACTION-1029 - Draft responses to reviewers based
    on resolutions taken during the F2F [on François Daoust - due
    2009-12-17].

    <EdC> I suspect lacrimosity

    <EdC> From latin lacrima -- tear.

    <Jo> Issue: Jo may not be able to devote very much time to this
    document so if modifications are needed beyond what has been
    discussed today a further editor is needed

    <trackbot> Created ISSUE-301 - Jo may not be able to devote very
    much time to this document so if modifications are needed beyond
    what has been discussed today a further editor is needed ; please
    complete additional details at
    [60]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/301/edit .

      [60] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/301/edit

    EdC: what is there now to do?

    DKA: We wait for Jo to complete the changes
    ... I think the only CT issue for tomorrow may be logistics,
    publishing moratorium, timing etc

    Jo: I'm wondering when I'm going to be able to make these changes.
    Not tonight, probably not next week.

    DKA: Before Friday 18th?

    Jo: Is decidedly noncomittal

    FD: Publishing over Christmas doesn't affect timing that much since
    you probably should not include the moratorium in the minimum LC
    period.

    Beer is required all round.

    Meeting adjourned

Summary of Action Items

    [NEW] ACTION: fd to draft responses to reviewers based on
    resolutions taken during the F2F [recorded in
    [61]http://www.w3.org/2009/12/10-bpwg-minutes.html#action03]
    [NEW] ACTION: Francois to enter specific issues from Mark into
    tracker, due now [recorded in
    [62]http://www.w3.org/2009/12/10-bpwg-minutes.html#action01]
    [NEW] ACTION: Jo to enact changes resolved today with minimal
    possible casuisitry [recorded in
    [63]http://www.w3.org/2009/12/10-bpwg-minutes.html#action02]

    [End of minutes]