RE: [agenda] CT call Tuesday 29 April 2008

Regrets for today's conference call. 


Best regards,

Andrew Swainston


-----Original Message-----
From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-request@w3.org] On Behalf Of Francois Daoust
Sent: 28 April 2008 10:56
To: public-bpwg-ct
Subject: [agenda] CT call Tuesday 29 April 2008


Hi,

This is the proposed agenda for tomorrow's call.
Topics 1 to 4 are for "resolution", but if you feel you need more time to comment on these points, feel free to say so.
Topics 5 to 6 are for "discussion", but if you feel you know how the doc should address them, feel free to say so as well. ;-)


-----
Chair: François
Staff Contact: François
Known regrets: none

Date: 2008-04-29T1400Z 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. Ajax/XHR requests and CT
---------------------------
Related actions:
  ACTION-718 on fd
  ACTION-739 on fd

Discussion:
  http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0042.html

Proposed resolutions (from above thread):
  PROPOSED RESOLUTION 1.1: in §4.4, add a bullet point to the list of heuristics that says "examination of the content reveals that the page contains client-side scripts that may break if the page gets adapted"
  PROPOSED RESOLUTION 2.3: in §??? (I don't really know where to put that), "Asynchronous HTTP requests sent from within a Web page (e.g. XHR
calls) SHOULD include a no-transform directive"
  PROPOSED RESOLUTION 2.5: in §4.4, precise the list of content-types that a CT-proxy may transform (there's a pending ACTION-725 on Sean)

and possibly (but also possibly not really important):
  PROPOSED RESOLUTION 2.1: in §4.2, "The server SHOULD add a no-transform directive in responses to Ajax and HTTP-based applications requests"

+ make a last call comment to the XHR doc about the need to distinguish
between an XHR call and a regular browser's call?


2. Via header comment format (§4.1.4)
-------------------------------------
Related actions:
  ACTION-741, ACTION-742 on fd

Discussion:
  http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0040.html

Proposed resolution (from above message):
  PROPOSED RESOLUTION: format of the VIA header comments: [a URI to a 
POWDER resource that describes the CT-proxy's capabilities using the 
vocabulary-to-be when we're ready to switch to POWDER or] the CT 
namespace's URI "http://www.w3.org/2008/04/ct#". Intention to transform 
must be indicated using the "active" property: 
"http://www.w3.org/2008/04/ct#active".

+ another property to indicate "I don't intend to transform"?


3. Session vs persistent settings (§3.2.1)
------------------------------------------
Related action:
  ACTION-723 on fd

Discussion:
  http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0036.html

Proposed resolution (from above message):
  PROPOSED RESOLUTION: Rewrite §3.2.1 roughly based on what it was 
before: "They MAY also provide the ability for their users to make a 
persistent expression of preferences."


4. Issuing two requests, idempotency, comparison, etc (§4.1.2)
--------------------------------------------------------------
No related action.

Discussion:
  http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0043.html

Proposed resolutions (from above message):
  PROPOSED RESOLUTION 1.1: at the end of §4.1.2, add "The proxy MUST NOT 
issue a POST/PUT request with altered headers when the response to the
unaltered POST/PUT request contains an HTTP status code 200" (in other 
words, it may only send the altered request for a POST/PUT request when 
the unaltered one was refused with a clear 406)
  PROPOSED RESOLUTION 1.2.a: at the end of §4.1.2, add a "The 
theoretical idempotency of GET requests is unfortunately not always 
respected in practice. Not to break existing content, the proxy SHOULD 
strive to send only one request whenever possible."
  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."


5. 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)


6. 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?


7. AOB
------

Received on Tuesday, 29 April 2008 13:49:02 UTC