See also: IRC log
<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
-> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0028.html Proposed text
PROPOSED RESOLUTION: ref. definition of pagination, adopt Eduardo's proposed text in 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 http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0028.html, replacing "fragments" by "documents"
<EdC> +1
RESOLUTION: 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"
-> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0037.html thread on validation against well-formedness
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.
-> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0016.html Thread on alteration of header fields
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> 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