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

[agenda] CT Call Tuesday 11 November 2008

From: Francois Daoust <fd@w3.org>
Date: Mon, 10 Nov 2008 15:04:10 +0100
Message-ID: <49183F5A.40902@w3.org>
To: public-bpwg-ct <public-bpwg-ct@w3.org>


Jo polished a new version of the draft that incorporates our 
resolutions. Many thanks, Jo!

Please read it and send your comments to the list.
The agenda below may be changed if there's one or more specific points 
any of you wants to discuss in particular about this draft.


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

Date: 2008-11-11T1500Z 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. New draft is out!

- See also Jo's email:
- Comments?

2. Content-Location
- raised by Rob.
- anything we want to say?

3. OMA Standard Transcoding Interface
- ACTION-868 on fd and LC-2051
- No real overlap between OMA STI and our guidelines.

4. Reminder: draft responses to "resolved no" comments

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.
The document extracts are based on previous drafts, but are still valid 
I think.

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

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

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

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

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

10. AOB
Received on Monday, 10 November 2008 14:04:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:19 UTC