- From: Francois Daoust <fd@w3.org>
- Date: Tue, 09 Dec 2008 17:57:01 +0100
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hi,
Today's minutes are available at:
http://www.w3.org/2008/12/09-bpwg-minutes.html
... and copied as text below.
Resolutions taken during the call:
- ref. definition of pagination, adopt Eduardo's proposed text in
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0028.html,
replacing "fragments" by "documents"
- Adopt the wording validate ... and if XML MUST be well formed.
- Modify the current text to say: It must be possible for the origin
server to reconstruct the original UA originated headers (see 4.1.5.5
Original Headers) by copying directly from corresponding X-Device header
field values.
- Spell out the exact headers 4.1.5 (i.e. the exact accept-*)
Francois.
-----
09 Dec 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0029.html
See also: [3]IRC log
[3] http://www.w3.org/2008/12/09-bpwg-irc
Attendees
Present
Francois, EdC, jo, rob, SeanP
Regrets
tom
Chair
francois
Scribe
francois
Contents
* [4]Topics
1. [5]Pagination definition
2. [6]Validation against formal published grammar
3. [7]Alteration of header fields
* [8]Summary of Action Items
_________________________________________________________
<EdC> any dependencies on other work? e.g. mobileOK, Best practices,
etc...?
<Zakim> jo, you wanted to say that I plan to work on a new draft
over christmas, and that the draft after that should be the new LC
draft
<scribe> Scribe: francois
Pagination definition
->
[9]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0028.h
tml Proposed text
[9]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0028.html
PROPOSED RESOLUTION: ref. definition of pagination, adopt Eduardo's
proposed text in
[10]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0028.
html
[10]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0028.html
<jo> +20
+1
PROPOSED RESOLUTION: ref. definition of pagination, adopt Eduardo's
proposed text in
[11]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0028.
html, replacing "fragments" by "documents"
[11]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0028.html
<EdC> +1
RESOLUTION: ref. definition of pagination, adopt Eduardo's proposed
text in
[12]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0028.
html, replacing "fragments" by "documents"
[12]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0028.html
Validation against formal published grammar
->
[13]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0037.
html thread on validation against well-formedness
[13]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0037.html
fd: strong positions in favor of a guideline along the lines of "The
altered content MUST be well-formed"
... not too strong positions against it.
<EdC> for xml-based content.
fd: What are your thoughts about it?
jo: not very compelling in my view. I think that the guideline "The
altered SHOULD validate to an appropriate formal grammar" is strong
enough.
... Even if we don't know about any example today, it is conceivable
that there may be cases where this is not such a good idea. I'm a
bit nervous about putting a MUST here.
rob: is this covered in the best practices somewhere?
jo: I don't think so. We do talk about validation against formal
grammars, but there is no mention of well-formedness anywhere.
... not even in mobileOK.
EdC: mobileOK is much stronger.
jo: Indeed. It's a MUST validate against published grammar which
encompasses well-formedness.
SeanP: I don't feel so strongly one way or the other. If a CT-proxy
generates content that is not well-formed but that works on the end
device, then that may be not such a big deal.
... I don't see that much benefit to have this in there.
EdC: the point is I have been at the receiving end of transcoding
services, and broken content is a great problem to start with.
... I think you Francois pointed out the MAMA findings that shows
that more than 95% of Web content does not validate, so by saying
SHOULD we do not say a lot.
<Zakim> jo, you wanted to wonder about validation?
jo: I am wondering if any case discussing validation is not out of
scope, because it's the way CT-proxies perform transformation. We're
spending too much time. Either we should delete the guidelines
altogether, either we should take into account Eduardo's proposal.
Rob: don't mind so strongly either.
<jo> PROPOSED RESOLUTION: Adopt the wording validate ... and if XML
MUST be well formed.
<jo> 0
0
<EdC> +1
<SeanP> 0
<EdC> it matches the proposal of Rotan...
[no objection from rob]
RESOLUTION: Adopt the wording validate ... and if XML MUST be well
formed.
Alteration of header fields
->
[14]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0016.
html Thread on alteration of header fields
[14]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0016.html
fd: current idea is to define capability header fields
... User-Agent, Accept-* fields
... and to construct a precise algorithm out of it
jo: I think we'll have a problem with IETF in that it is profiling
HTTP.
... not quite sure about the benefits
<EdC> benefit of accuracy explained in the rationale...
fd: accuracy would be the main benefit.
jo: I think it's too detailed to be in the round of the text. Don't
mind to put it in an explanatory appendix
SeanP: I agree we should change the text in 4.1.5. Current text says
"do not change headers other than User-Agent and blah", which could
confuse readers, since other headers such as the Via header may need
to be changed by the proxy.
... so we could add "other headers may be changed according to the
HTTP RFC"
<inserted> Current Text:
<jo> Proxies should not change headers other than User Agent and
Accept(-*) headers and must not delete headers. It must be possible
for the server to reconstruct the original UA originated headers
(see 4.1.5.5 Original Headers).
<jo> Other than to comply with transparent HTTP operation, proxies
should not modify any request headers unless:
<jo> 1.
<EdC> Isn't it what stands in the proposal? "except as specified in
sections... and except as prescribed by RFC2616 and other
<EdC> published standards in force, a proxy..."
fd: one proposal could be to prefix that with Eduardo's proposal:
"Except as specified in sections 4.1.6, 4.1.6.1, 4.2.4 of the
present document, and except as prescribed by RFC2616, proxies
should not change headers [blah]"
fd: trying to summarize. The problem is that we cannot prescribe
things for fear of profiling HTTP.
EdC: how can we say that it MUST be possible to reconstitute the
original values if we don't prescribe things precisely?
<jo> Other than to comply with transparent HTTP operation, proxies
should not modify any request headers unless:
EdC: Suppose the headers get modified by a first CT-proxy, then go
through a second one
fd: multiple transcoding proxies are out of scope.
EdC: Well, that's the easy way out...
fd: indeed.
jo: What Eduardo is suggesting is that the first proxy can modify
and further proxies cannot. Further proxies may want to put back the
original headers and that is acceptable in my view.
EdC: that's not really the case.
... modified headers must be modified in a predictable way.
jo: cannot we say that the origin server must be able to reconstruct
the original headers?
<jo> PROPOSED RESOLUTION: Modify the current text to say: It must be
possible for the origin server to reconstruct the original UA
originated headers (see 4.1.5.5 Original Headers) directly from
corresponding X-Device headers.
<jo> PROPOSED RESOLUTION: Modify the current text to say: It must be
possible for the origin server to reconstruct the original UA
originated headers (see 4.1.5.5 Original Headers) directly from
corresponding X-Device header values.
EdC: the point is that the origin server should be able to
reconstruct http headers directly.
SeanP: I think current text bottoms down to the second proxy cannot
change the headers.
<SeanP> +1
<EdC> ...by copying directly the corresponding X-device header field
values.
<jo> PROPOSED RESOLUTION: Modify the current text to say: It must be
possible for the origin server to reconstruct the original UA
originated headers (see 4.1.5.5 Original Headers) directly from
corresponding X-Device header field values.
+1
<SeanP> +1
<jo> PROPOSED RESOLUTION: Modify the current text to say: It must be
possible for the origin server to reconstruct the original UA
originated headers (see 4.1.5.5 Original Headers) by copying
directly from corresponding X-Device header field values.
<SeanP> +1
+1
[+1 from rob on the phone]
<jo> +1
RESOLUTION: Modify the current text to say: It must be possible for
the origin server to reconstruct the original UA originated headers
(see 4.1.5.5 Original Headers) by copying directly from
corresponding X-Device header field values.
fd: Wonder about the purpose of the guideline: Proxies SHOULD NOT
change headers"
<jo> PROPOSED RESOLUTION: Spell out the exact headers 4.1.5.5
jo: limits the scope of work to reconstruct the original values
<jo> PROPOSED RESOLUTION: Spell out the exact headers 4.1.5
+1
<EdC> +1
<jo> PROPOSED RESOLUTION: Spell out the exact headers 4.1.5 (i.e.
the exact accept-*)
<SeanP> +1
<jo> +1
<EdC> and user-agent...
+1
RESOLUTION: Spell out the exact headers 4.1.5 (i.e. the exact
accept-*)
ACTION-843
ACTION-843?
<trackbot> ACTION-843 -- Jo Rabin to see if he can come up with
wording on this section that might accommodate everyone -- due
2008-09-16 -- PENDINGREVIEW
<trackbot>
[15]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/843
[15] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/843
Close ACTION-843
<trackbot> ACTION-843 See if he can come up with wording on this
section that might accommodate everyone closed
Summary of Action Items
[End of minutes]
Received on Tuesday, 9 December 2008 16:57:35 UTC