- 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