W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > April 2008

[agenda] CT call Tuesday 22 April 2008

From: Francois Daoust <fd@w3.org>
Date: Mon, 21 Apr 2008 12:30:59 +0200
Message-ID: <480C6CE3.70507@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 21 April 2008 10:31:33 GMT