[agenda] CT Call Tuesday 6 May 2008


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, +, +44.117.370.6152
Conference code: 2283 ("BCTF") followed by # key
IRC channel: #bpwg on irc.w3.org, port 6665.

Latest draft:

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.


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

(for content types)
(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)

- 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

- 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 

6. AOB

Received on Monday, 5 May 2008 10:02:09 UTC