- From: Francois Daoust <fd@w3.org>
- Date: Mon, 23 Jun 2008 12:17:28 +0200
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hi,
Back to the usual weekly call!
We've spent one complete day during last week's F2F on Content
Transformation, and resolved all the issues but one.
-----
Chair: François
Staff Contact: François
Known regrets: none
Date: 2008-06-24T1400Z 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/080606
... which obviously doesn't reflect the resolutions taken during the F2F!
1. Where we stand: a quick review of the F2F
--------------------------------------------
See the minutes of Day 1, entirely spent on Content Transformation:
http://www.w3.org/2008/06/16-bpwg-minutes.html
a) The group will be rechartered to switch the document from informative
to normative.
b) Using the link element to "link to self" was emphasized as being a
way to determine that an HTTP Status 200 response is not a "rejected"
response. A handheld "link to self" such as:
<link rel="alternate" media="handheld" href="" />
...has 2 meanings: I "am" the handheld representation of the resource,
or I "can be" a handheld representation if I detect that the device is a
handheld device. To clearly identify the first case, some way of saying
"this particular" representation was required. We agreed to say that
when the "href" attribute refers to a location within the current
representation (by use of a fragment such as "#top"), then the
representation is a handheld representation. We'll include a note to
explain that the meaning of an empty "href" is ambiguous.
c) Current section 4.1.2 is to be rewritten in a clearer algorithm that
explains how a CT-proxy should handle HTTP requests, as detailed in the
minutes:
http://www.w3.org/2008/06/16-bpwg-minutes.html#item_issue257
d) The use of OPTIONS will be mentioned in the "Scope for Future Work"
appendix.
e) We'll remain silent on whether CT-proxies should be mobileOK.
f) It's not forbidden to transform mobileOK content but that should be
part of the heuristics to determine if a page is mobile-friendly
g) No mention of the confusing term "session" in the doc. We'll use the
notion of "web site", leaving the scoping of "web site" boundaries up to
CT-proxy vendors. Content tasting may not be done on different pages of
the same web site, but should be done whenever a request is made for a
linked resource that is on a new web site.
h) As far as the CT guidelines are concerned, there is no difference
between a URI-rewriting proxy and a regular non-transparent one
i) Section 3.1 on requirements is to be moved (and refreshed) to the
Scope section. Requirements that could not be addressed are to be moved
to the "Scope for Future Work" appendix.
j) Remaining issue: persistent expression of user preferences
2. Any other comments?
----------------------
3. Close without much discussion
--------------------------------
ACTION-769 on fd to ping Soonho on providing feedback about CT
ACTION-711 on Soonho to provide feedback on the document
Soonho was moved to another position and cannot work on the document
for the time being
4. ISSUE-242: Persistent expression of user preferences
-------------------------------------------------------
We started the discussion during the F2F, but were both too tired and
running out of time to come to a conclusion...
What we've resolved so far:
- It is permissible for the proxy to offer the user a restructured
desktop presentation on a 'site' by 'site' basis
- If there is a blanket user preference asserted for any specific
representation option and multiple representations are found to exist
then the CT proxy server SHOULD inform the user of this fact and provide
the user with an option to change to one of the alternative representations.
- Clarification that a CT-proxy for which there exists an arrangement
with a content provider is an adaptation solution part of the origin
server of the content provider, and as such out of scope.
- Clarification that HTTP redirects is one way to go for a URI-rewriting
proxy to behave transparently on receipt of a Cache-Control:
no-transform directive (internal clarification, "transparent" should be
enough, we probably won't mention it in the guidelines)
- Emphasis on the need for a strong Cache-Control: no-transform directive
- Alternative representations of a resource should be indicated with
link elements/headers.
Some remaining points to address (taken from the minutes):
a. how the CT proxy should react against specific user preferences when
a site becomes more capable
b. that the default experience should be for the mobile experience
c. that blanket expression of preferences should be interpreted in the
context that if an origin server can provide a choice of experience then
it should do so
d. that CT proxies should, in restructured content, provide links to
alternative representations
e. how would a CP indicate to a CT Proxy that it offers user choice of
representation?
f. allow users to change previously expressed preferences
In terms of sections, what we're talking about is section 3.2 Control of
the Behavior of the Proxy, and its possible merging with other parts of
the document for the sake of clarity.
5. Schedule
-----------
- Updated draft?
- Last Call?
6. AOB?
-------
Received on Monday, 23 June 2008 10:18:03 UTC