- From: Francois Daoust <fd@w3.org>
- Date: Mon, 05 May 2008 12:01:37 +0200
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hi,
This is the proposed agenda for tomorrow's call.
As a direct consequence of multiple public holidays here in France, I'm
late on my actions (yes, but I'm tanned! :-)), and will be out end of
this week as well.
-----
Chair: François
Staff Contact: François
Known regrets: none
Date: 2008-05-06T1400Z 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
1. Issuing two requests, idempotency, comparison, etc (§4.1.2)
--------------------------------------------------------------
We started resolving on that last week.
ACTION-750 on me is still in my TODO list.
Discussion:
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0043.html
Proposed resolutions to discuss (from section 2. in above message):
PROPOSED RESOLUTION 2.1: in §4.1.2, replace "Issue a request with
unaltered headers and examine the response (see 4.4 [...])" with "Issue
a request with unaltered headers and examine the response to check
whether it's a 'request rejected' one"
PROPOSED RESOLUTION 2.2.b: at the end of §4.1.2, complete "the proxy
SHOULD strive to send only one request whenever possible" with "In
particular, it SHOULD NOT issue duplicate requests for comparison
purpose as a generic rule."
2. Content-types and doctypes (§4.4)
------------------------------------
Related action:
ACTION-725 on Sean
Discussion:
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0045.html
(for content types)
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0000.html
(for doctypes)
3. Link element in HTML requests (§4.2)
---------------------------------------
For discussion.
<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)
Note that Phil Archer is preparing a list of use cases to emphasize the
need for a means to point to a resource description without having to
parse the resource itself (the Link HTTP header being the strongest
candidate for such a means). I am to complete this with the CT use case.
4. Examination of URIs (§4.4)
-----------------------------
Discussion:
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0000.html
Pros:
- it addresses a direct need for today's content.
- most CT-proxies already make use of such a list I suppose
- we should err on the side of caution
Cons:
- from a theorical point of view, URIs are supposed to be opaque
- save ".mobi", there's no standardized way to flag a mobile URI.
5. Consistency in the behavior of the CT-proxy
----------------------------------------------
For discussion.
- The "main" response may allow CT, but not the CSS stylesheet for
instance. How should the CT-proxy behave in such a case?
- Are there cases when the guidelines may be waived for the sake of
consistency?
6. AOB
------
Received on Monday, 5 May 2008 10:02:09 UTC