W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > November 2008

Regrets for CT Call Tuesday 4 November 2008

From: Swainston, Andrew, VF UK <Andrew.Swainston@vodafone.com>
Date: Tue, 4 Nov 2008 10:59:50 +0100
Message-ID: <CD0F3C880994B7449029DDA3AB907949125E30@VF-MBX22.internal.vodafone.com>
To: "Francois Daoust" <fd@w3.org>, "public-bpwg-ct" <public-bpwg-ct@w3.org>

I regret that I will not be able to attend today's call.

Best regards,


-----Original Message-----
From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-request@w3.org] On Behalf Of Francois Daoust
Sent: 31 October 2008 17:58
To: public-bpwg-ct
Subject: [agenda] CT Call Tuesday 4 November 2008


This is an early agenda for next CT call.

I will try my best but may have to send my regrets for the call.
Jo, would you mind chairing if I can't join?

I think we'll all have switched to winter time by Tuesday. The call is at your usual local time.


Chair: François or Jo
Staff Contact: François
Known regrets: none

Date: 2008-11-04T1500Z 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.

1. Where we are
- We reviewed and resolved most of the remaining Last Call comments.
  Minutes and resolutions:
  Any questions?
- Jo to work on an updated draft
- Responses need to be drafted for comments for which we resolved no:

Resolutions we took during the F2F on 4.1.5 Alteration of HTTP Header Values address most of the comments, but not all of them. The remaining ones are below.

[Note: the links to the LC Tracker below are Member-only, the last call comments I refer to are publicly available using the annotated view:
  http://tinyurl.com/634lue ]

2. LC-2038 - is it a list of Best Practices? Be explicit it that's the case

3. LC-2049 - forbid the alteration of the request when the URI follows some mobile pattern (*.mobi, wap.*, ...)

4. LC-2053 - classes of devices

5. LC-2072 - what is a restructured desktop experience?

6. LC-2073 - heuristics and web sites

7. LC-2040 - X-Device-* should be in an Internet Draft

Following items are triggered by a discussion with Eduardo on the list:

Bullet points quickly attempt to summarize some of the ideas exchanged. 
Please refer to the emails for a more accurate description.

8. Unclear form encoding must be preserved for the server
... Search for "2. Matching the capabilities of the user agent is necessary"

- Current wording makes it unclear that we do not envision that a server 
may receive an encoding different from the one it expects when a form is 
- Proposal: clarify the text along the lines of what we had in a 
previous draft:
  "Proxies should not alter HTTP requests unless: [...]
     2. an unaltered request body is not consistent with the origin
server's requirements in respect of Internet content type or character
encoding (as may happen, for example, if the proxy has transformed an
HTML form that results in this request);"

9. Character encoding

- changing character encoding is not reliable, problematic when there's 
a form involved (on-line orders, banking, e-mail, timetable).
- changing the encoding to another one that is also supported by the 
client is not forbidden.

10. User experience

- algorithm proposed to precise what "improving the user experience" may 
mean from a technological point of view based on HTTP headers, UAProf, 
and DDR, and priorities among capabilities.
- cannot and does not attempt to cover everything.
- points of disagreement on the details
- we resolved to leave this out of scope

11. Keep it dry
- Normative statements must be testable.
- Focus on the statements, leave ambiguous statements out of the spec.
- Either we define precise algorithms based on heuristics, either we 
stay silent. If we can't define heuristics, then remove feel-good 
sentences altogether.
- In short, don't mention something if we don't address it completely

- "A proxy SHOULD strive for the best possible user experience that the 
user agent supports"... not good.
- "It SHOULD only alter the format, layout, dimensions etc. to match the 
specific capabilities of the user agent"... what are we trying to say?

- On the other hand, we could come up with a full appendix (?) on common 
dangers associated with re-structuring:
(end of the email).

12. Capability negociation on the client side
- not mentioned in Scope for Future Work
- add a reference to CC/PP?

13. AOB

PS: Title is still not good
But that's not on the agenda
We'll see in the end if some magic title reveals itself.
Received on Tuesday, 4 November 2008 10:00:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:30 UTC