- From: Francois Daoust <fd@w3.org>
- Date: Mon, 21 Apr 2008 12:30:59 +0200
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
-----
Chair: François
Staff Contact: François
Known regrets: none
Date: 2008-04-22T1400Z for 60mn
Phone: +1.617.761.6200, +33.4.89.06.34.99, +44.117.370.6152
Conference code: 2283 ("BCTF") followed by # key
IRC channel: #bpwg on irc.w3.org, port 6665.
Latest draft:
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080410
Proposed agenda:
1. Comments on FPWD
-------------------
http://lists.w3.org/Archives/Public/public-bpwg-comments/2008AprJun/0000.html
Is there a clear and simple way to state that a transformed response
should be as valid as the original one?
2. Linearization/zoom/format support and CT
--------------------------------------------
Follow-up on last week's call and mailing-list discussion starting at:
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0032.html
- remove the paragraph from §4.1.2
- add the paragraph to §4.4
- change the wording?
3. ACTION-718: Summarize and continue discussion re Ajax/XHR requests
---------------------------------------------------------------------
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0028.html
- write a note (end of §4.2?) mentioning that responses sent to XHR
calls should not use a content type that may be subject to transformation?
- append something like "the response contains client-side scripts that
may break if the page gets adapted" to the list of heuristics in §4.4?
4. Comments that MAY be stripped in a VIA header (§4.1.3)
---------------------------------------------------------
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0027.html
- proxies should never strip comments in practice, but they still MAY...
- something along the lines - and clearer, as usual - of:
According to the HTTP RFC (§14.45), Via headers comments "MAY be
removed by any recipient prior to forwarding the message". Noting that
the justification for removing such comments is memory-based, that most
modern proxies are able to handle that amount of information and that
comments are useful for CT, the BPWG recommends that Via headers
comments SHOULD NOT be removed.
Related actions:
ACTION-722 on fd: Check why HTTP RFC states comments MAY be removed from
a VIA header.
ACTION-684 on jo: Include a note that we think it is bad practice to
strip the comment from downstream via header fields
5. Altering header Values (§4.1.4)
----------------------------------
- header values altered: append a Warning header?
- intention to transform: Warning headers (see HTTP RFC §14.46) are to
carry info "about the status or transformation of a message". Not sure
we should use a Warning for that. Use the Via comment to specify that
the CT proxy intends to transform or to be transparent?
(note that if we use a Warning header, we'll need to investigate how to
"register" for a warning code)
6. Via header comment format (§4.1.4)
-------------------------------------
- define a vocabulary namespace specific to CT, such as:
http://www.w3.org/2008/04/ct/ ?
(it could be used directly in the header or referenced in a POWDER-like
resource)
7. Link element in HTML requests (§4.2)
---------------------------------------
<link rel="alternate" media="handheld" type="[content-type]" href="[uri]" />
- that's a link to an external resource, anything we may use to flag the
medium of which the resource in itself is intended?
- state that the CT-proxy SHOULD redirect the user to the URI instead of
forwarding/adapting the response when such a link is detected (in §4.3
or §4.4)? (it's in the list of heuristics, but doesn't have much to do
with restructuring and recoding IMO)
8. Issuing duplicate requests as a matter of course to compare responses
(§.4.1.2)
----------------------------------------------------------------------------------
- include a "CT-proxies SHOULD/MUST NOT issue duplicate requests for the
sake of comparison" guideline?
- (list some reasons in a note: network bandwidth, difference between
theory and practice in the use of the GET method, ...)
9. Other TODOs
--------------
Content:
- distinction between CT proxies and say Opera mini for §2.1 (ACTION-678
on Sean)
- persistent/semi-persistent, session for §3.2.1 (ACTION-723 on fd)
- scoping bogus 200 responses for §4.1.2 (ACTION-673 on Aaron)
- X-Device-[original header name]: final name, for §4.1.4
- heuristics that a CT-proxy should use, for §4.4 (ACTION-725 on Sean
for content-types)
Structure:
- merge §3.1 and §3.2
- clarify §3.2.4 (ACTION-724 on jo)
- clarify §4.3
- rewrite §4.1.2 in a more logical way?
And then:
- POWDER
- HTTP Link header
+ some other issues and actions that we need to discuss:
http://www.w3.org/2005/MWI/BPWG/Group/track/products/12
10. AOB
------
Received on Monday, 21 April 2008 10:31:33 UTC