W3C

BPWG F2F, London December 2009, Day 2/3

10 Dec 2009

Agenda

See also: IRC log

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 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.

Minutes of the F2F


<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> http://www.w3.org/2005/MWI/BPWG/Group/Meetings/London4/logistics.html#agenda

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

LC-2289 from Luca Passani
LC-2323 from Mark Nottingham

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 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> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2034

<francois> 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 Back to LC-2289 and LC-2323 - Usefulness of the document at the end of these minutes]

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

LC-2321
LC-2324
LC-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> reply to LC-2036

<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

LC-2316
LC-2034

FD: Suggest we jump to LC-2316

<francois> ... and response to LC-2034: 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> Form possible methods in HTML4

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

LC-2327

FD: And we have LC-2327 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-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

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

LC-2269 from EdC

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

LC-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 [44]).

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 [44]).

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

LC-2317

<EdC> This is what Rotan proposed 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 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 http://lists.w3.org/Archives/Public/public-bpwg/2009Dec/0008.html

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

LC-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

LC-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

LC-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

LC-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"

LC-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

LC-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

LC-2268 from Thomas

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

LC-2267 from Thomas

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

Continuation of the discussion of LC-2289, LC-2323 - Usefulness of the document started at the beginning of the day.

<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 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 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 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 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 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 http://www.w3.org/2009/12/10-bpwg-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/12/15 11:19:54 $