[agenda] CT Teleconference Tuesday 1 April 2008


We've been working on the guidelines for some time, making good 
progress. The more I look at it, the more details I find that may 
require fine-tuning, but, save a few resolutions and some editorial 
cleaning, we now have something that shows the direction we're aiming 
at, so what about moving forward and publishing our guidelines as First 
Public Working Draft (FPWD)? The following agenda is to hopefully make 
this happen...

NB: the goal is neither to close any on-going discussion, action or 
issue prematurely, nor to say that we're done with what's already 
written. It's simply to get more exposure and receive feedback from the 
community on the main lines of our guidelines.

Note to US residents: the call's hour is back to "normal" for you! Sorry 
if that means you need to wake up earlier ;)

Chair: François
Staff Contact: François
Known regrets: kemp

Date: 2008-04-01T1400Z 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:

Proposed agenda:

1. Targeted schedule
+ resolve during the call on remaining "hot" topics (2, 3, 4, and 5 below).
+ editor's meeting on Wednesday to "clean" the doc (well, provided 
you're available for that, Jo!)
+ presentation to BPWG on Thursday's call
+ one week for review by BPWG (this includes CTTF, obviously)
+ publication as FPWD shortly after

-> whenever we start running out of time during the call, let's see if 
we're OK to proceed along this schedule.

2. ACTION-685: how to embed original headers (§3.1.4)
Resolve on one of the following:
- use the Warning HTTP header
- use a new X- HTTP header
- don't send the original headers

3. Proxy response to User Agent (§3.4)
- list of heuristics. Proposal: leave it as it is for the time being
- ACTION-717 on Martin. Proposal: use Martin's text as it is
- Resolve on dangerous content. Why not something along the lines of:
"[when dangerous] the proxy MAY warn the user, and give the user the 
choice to see a transformed version of the resource"?

4. Proxy Receipt and Forwarding of Response from Server (§3.3)
- Vary: link to content tasting?

5. Summary of requirements (§2.1)
- Not that much outdated, save, maybe:
  + 1. -> b and (part of) c don't apply to the origin server.
  + 2.a -> remove "some degree of"
  + 3.b -> remove "of various kinds"
  + 4.a -> remove "of various kinds"
(there may be a way to be more precise about transformations that may be 
applied using POWDER, so the last 3 points may remain)
- What do we do with that part?

6. On the Link HTTP header ($3.2)
The Link HTTP header may come back:
Proposal: put in a note that we'd like to recommend the use of the HTTP 
Link header but that it's pending its official resurrection

7. Proxy indication of its presence to server (§3.1.3)
- Via HTTP header, which format if no POWDER?
- Resolve on the mention of the CT-proxy's intention to transform:
      + using the Via HTTP header
      + don't advertise

8. Proxy decision to transform (§3.1.2)
- Remove "type" in "the type and HTTP method of the request?
- In linearization or zoom capability text, "restructure or recode" 
note, shouldn't we simply say "transform"?
- Notes on GET and discouraging the sending of 2 requests for 
comparison, OK to leave the text up to the editor?

9. Objectives (§2.2)
- OK to remove the "other principles" note?

Received on Monday, 31 March 2008 09:25:16 UTC