[agenda] Tuesday 3 June 2008

Hi guys, although there are still some stuff to discuss, I don't see 
much more things to add once we've resolved the following items, and 
updated the document consequently. See 6. below for a targeted schedule 
for publication of the doc as a Last Call Working Draft. I don't see how 
we may publish it _before_ the F2F, but we're still on track to publish 
it _during_ the F2F...


-----
Chair: François
Staff Contact: François
Known regrets: Murari, (Pontus)

Date: 2008-06-03T1400Z 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. Via header comment format
----------------------------
Related action:
  ACTION-750 on fd

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

Summary:
- No easy way to define multiple values within one URI
- Suggestion is to "keep it simple": no attempt to define multiple values.


2. X-Device- header: final name
-------------------------------
Discussion:
  http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0038.html

Summary:
- X-Device and X-Original seem to be already used in practice, although 
I suspect the former is more used than the latter.
- X-Original is better in terms of the message it carries.

PROPOSED RESOLUTION: Final name for the "X-Device" header is "X-Original"
PROPOSED RESOLUTION: If the HTTP request defines a "X-Device" header, 
the proxy MUST NOT apply further transformation.


3. Link element
---------------
Related issue:
  ISSUE-222

Discussions:
  http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0021.html 
(and replies)
  http://www.w3.org/2008/05/27-bpwg-minutes.html#item04

Summary:
- no real support for the use of the link element to self-flag a page as 
"handheld" as it doesn't tell much in practice.
- we may still want to add that the CT-proxy should redirect the user to 
the handheld version if it's referenced in a Link element.

PROPOSED RESOLUTION: if an HTML response includes a <link 
rel="alternate" media="handheld" type="[content-type]" href="[uri]" /> 
tag, the CT-proxy SHOULD request and return the resource pointed to by 
[uri] instead of the current one.


4. Vary, cache efficiency and Content-Location
----------------------------------------------
Related issue:
  ISSUE-222

Discussion:
  http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0022.html 
(and replies)

Summary:
- "Vary: User-Agent" generates too many cache entries whereas there 
usually are a limited number of representations for a resource (even 
when tweaks are being taken into account)
- the need to have the different representations of a resource available 
at specific locations is a burden for content providers
- the "Content-Location" header makes representations available to 
caches without requiring any redirect and should probably be promoted.

PROPOSED RESOLUTION: to promote the use of the Content-Location header, 
complete the part on the "vary" HTTP header in 4.2 with a note along the 
lines of:
"When varying representations based on received HTTP headers, 
cache-efficient techniques should be used. For example, if the total 
number of representations is limited whereas the number of values for a 
HTTP header used for varying representation is high [typically the case 
when varying representations based on the User-Agent string], the 
different representations should be made available at specific URIs and 
the request to the generic resource should return the specific 
representation along with a Content-Location header that identifies the 
representation being served."


5. Warning header in requests
-----------------------------
I don't think we've ever resolved anything on that.

Summary:
- Although a global header, the "Warning" header was more designed with 
responses in mind. That doesn't prevent us from using it anyway.
- Kind of redundant with the X-Device header. It the request is altered, 
there should also be an X-Device header (and actually it's a "must"). 
The less HTTP headers, the merrier.
- We would need a specific value code as "214 Transformation Applied" is 
supposed to apply to the response.

PROPOSED RESOLUTION: don't recommend the addition of a "Warning" HTTP 
header to the request.


6. What's next
--------------
Content:
- distinction between CT proxies and say Opera mini for §2.1 (ACTION-678 
on Sean)
- scoping bogus 200 responses for §4.1.2 (ACTION-673 on Aaron)
- some more investigations based on remaining issues.
My gut feeling is that none of these are likely to introduce any 
substantive changes.

Structure:
- merge §3.1 and §3.2
- clarify §3.2.4 (ACTION-724 on jo)
- clarify §4.3
Any actions/resolutions needed on that?

Anything you'd like to add/change before moving to Last Call?

Targeted schedule:
- By Tuesday 10: an updated draft, and comments by email!
- Tuesday 10: review of the draft
- Tuesday 10: review of remaining issues to check we've addressed them
(- By Thursday 12: possible slight update of the draft based on task 
forces comments)
- Thursday 12: presentation of the draft to the main body of the working 
group
- Monday 16 (F2F): decision to publish as Last Call
- Thursday 19: publication as Last Call

NB: I'm not forgetting any potential decision to switch the doc from an 
informative rec to a normative one, but that doesn't prevent us from 
publishing the doc as Last Call right away.


7. AOB
------

Received on Monday, 2 June 2008 08:38:12 UTC