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

Agenda for the Content Transformation session during the upcoming F2F

From: Francois Daoust <fd@w3.org>
Date: Thu, 16 Oct 2008 17:35:11 +0200
Message-ID: <48F75F2F.7010203@w3.org>
To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>

Hi, in preparation of next week's F2F, this is the agenda I'd like to 
follow during the half-day session we'll have on Content Transformation 
on Monday morning. Comments welcome.

I use stars below to spot topics according to the probable amount of 
discussion that will be needed to address them:
  [*] means discussion should be fairly limited
  [**] means a bit of discussion is likely to be needed
  [***] means a fight might take place. Bring your axes. Chainsaws not 
allowed.

I grouped Last call comments where it made sense.
I wrote some proposed resolutions where I thought we could quickly agree 
without much discussion or where I thought an initial proposed 
resolution would trigger some useful discussion.

Francois.


Short introduction (10mn)
-----
- Where we are.
- Things we already agreed on.
- How we'll proceed: parsing the document using the annotated view of 
the document and resolving on comments:
    http://tinyurl.com/634lue



LC-2066 - missing RFC 2616 section - 2.1 Types of Proxy [*]
-----
PROPOSED RESOLUTION: re. LC-2066, resolve yes, add missing section reference



LC-2003 - whitelists - 4.1 Proxy Forwarding of Requests [***]
-----
http://www.w3.org/2008/09/23-bpwg-minutes.html#item06
ACTION-850 on Bryan to provide some text on whitelists



LC-2044, LC-2069 - 4.1.3 Treatment of Requesters that are not Web
Browsers [**]
-----
- how to identify browsers: specific values in e.g. the User-Agent header?
- a MUST statement for something that relies on heuristics seems odd.



LC-2070 - Proxies SHOULD follow standard HTTP procedures - 4.1.4 Serving
Cached Responses [*]
-----
PROPOSED RESOLUTION: re. LC-2070, resolve yes, and reformulate the text 
to "..."



LC-so-many - 4.1.5 Alteration of HTTP Header Values [***]
-----
LC-1996, LC-2071, LC-2072, LC-2073, LC-2049, LC-2017, LC-2036, LC-2053,
LC-2005, LC-2038, LC-2054
... and also LC-1997, LC-2006, LC-2014, LC-2046 on 4.1.5.5 Original headers
... and then LC-2077, LC-2040 on 4.1.5.5 Original headers

See: http://www.w3.org/2008/10/14-bpwg-minutes.html#item04
- List of HTTP headers that may need to be changed: User-Agent, UAProf, 
Accept and other Accept-* headers
- No identified need to delete a HTTP header
- No strong problems raised by modifications of the Accept family of headers
- Need to change User-Agent and UAProf because of the "long-tail" of 
legacy Web pages, main target of CT
- If there's an original request sent with the original headers, what is 
the need to send the original headers in a X-Device-* header in the 
modified request?
- X-Device-* requires an internet draft



LC-2074 - profiling HTTP, idempotency of GET requests - 4.1.5.1 Content 
Tasting [**]
-----
- Servers are indeed the ones to blame for not respecting the 
idempotency of GET.
- That doesn't mean however that proxies should take that for granted in 
practice.
PROPOSED RESOLUTION: re. LC-2074, resolve partial, keep the warning for 
CT-proxies vendors about the situation in practice, but downgrade the 
normative statement to a note.



LC-2075 - Heuristics for 200 rejected responses - 4.1.5.2 Avoiding 
"Request Unacceptable" Responses [**]
-----
- Not specifying heuristics leaves CT-proxies vendors free for product
differentiation
- We do restrict ourselves to POST here because the whole guidelines
only apply to GET/POST/HEAD.



LC-2037 - POST retry - 4.1.5.2 Avoiding "Request Unacceptable" Responses [*]
-----
- PUT removed
- Is the statement so obvious we don't need to write it down?



LC-2076, LC-2039 - same headers for all resources - 4.1.5.4 Sequence of 
Requests
-----
- "representation" is used in its supposed definition
- clarification needed to state that proxies must behave consistently 
across requests for embedded resources



LC-2079 - Servers SHOULD respond with 406 - 4.2.1 Use of HTTP 406 Status [*]
-----
- The whole section 4.2 will be switched to informative



LC-2041, LC-2080 - Use of MUST for servers - 4.2.2 Server Origination of 
Cache-Control: no-transform [*]
-----
- The whole section 4.2 will be switched to informative



LC-2045 - Respect of RFC2616 - 4.2.2 Server Origination of 
Cache-Control: no-transform [*]
-----
- We shouldn't restate the RFC 2616
- Maybe clarify in the introduction that conformance with RFC2616 is 
implied?



LC-2081 - About not basing actions on knowledge - 4.2.3.1 Use of Vary 
HTTP header [*]
-----
PROPOSED RESOLUTION: re. LC-2081, resolve partial, clarify that servers 
should not change their behavior because there is a CT-proxy on the line



LC-2009, LC-2010, LC-2011 - Use of the link element - 4.2.3.2 Indication 
of intended presentation media type of presentation [?]
-----
- Pending a reply from the TAG?



LC-2020 - Copyright - 4.3 Proxy forwarding of response to user agent [*]
-----
PROPOSED RESOLUTION: re. LC-2020, resolve no, we do not want to step 
into legal matters



LC-2082, LC-2042 - Cascading proxies - 4.3.2 Receipt of Warning: 214 
Transformation Applied [*]
-----
PROPOSED RESOLUTION: re. LC-2082, LC-2042, resolve no, cascading proxies 
are not as easy as they seem, and the "MUST NOT" only applies to "CT" 
proxies, not proxies in general.



LC-2083 - Sniffing rejected responses - 4.3.3 Server Rejection of HTTP 
Request [*]
-----
PROPOSED RESOLUTION: re. LC-2083, resolve partial, we are addressing 
legacy content, there is no way to be more precise. Remove the part on 
"servers that do not implement this Recommendation".



LC-2084 - purpose of behavior - 4.3.4 Receipt of Vary HTTP Header [*]
-----
PROPOSED RESOLUTION: re. LC-2084, resolve partial, and add a link back 
to 4.1.5.2 that explains the use case



LC-many - Heuristics - 4.3.6 Proxy Decision to Transform [**]
-----
- I think the point is mostly that we only list examples of heuristics 
where commenters want to see guidelines.
LC-1998: no transformation for application/xhtml+xml
LC-1999: no transformation for small pages
LC-2048, LC-2002: more URIs patterns
LC-2052, LC-2021: more doctypes and content types



LC-2022 - i-mode content - 4.3.6 Proxy Decision to Transform [*]
-----
- we only list examples of heuristics.
- should we add an example of heuristic for i-mode content?



LC-2090, LC-2000 - No extra content without the consent of the content 
owner - 4.3.6 Proxy Decision to Transform [**]
-----
- out of scope, copyright issue, legal matters?



LC-2013 - meta http-equiv - 4.3.6 Proxy Decision to Transform [*]
-----
PROPOSED RESOLUTION: re. LC-2013, resolve yes, and clarify that we mean 
"in the absence of a Vary HTTP header and in the absence of a 
no-transform directive defined at the HTTP level or using a meta 
http-equiv element containing Cache-Control: no-transform"



LC-2051 - Open Mobile Alliance Standard Transcoding Interface work - 
Appendix A and D [**]
-----
- review the STI specs?



LC-1995 - About "recent" HTTP "drafts" - Appendix D.2 [*]
-----
PROPOSED RESOLUTION: re. LC-1995, resolve yes, and replace "recent draft 
of HTTP" by "HTTP 1/1"



LC-2047 - Cascading proxies - Appendix D.4 Inter Proxy Communication [**]
-----
PROPOSED RESOLUTION: re. LC-2047, resolve no, and point out a specific 
example of why it's not that simple to the commenter



LC-2043 - Guidelines vs. protocol - General [*]
-----
- guidelines.
- review at the end to make sure we're on firm grounds there.



LC-2097 - Internet Architecture Board - General [*]
-----
- review RFC 3238
Received on Thursday, 16 October 2008 15:35:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:59 UTC