- From: Francois Daoust <fd@w3.org>
- Date: Mon, 14 Dec 2009 14:41:32 +0100
- To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
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]
Received on Monday, 14 December 2009 13:42:08 UTC