- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Fri, 07 Nov 2008 18:40:07 +0000
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hello everyone
I have updated the CT Guidelines according to all the resolutions I
could find in minutes of meetings.
Francois: I have yet to update the LC tracker with "Resolution
implemented" where appropriate
You will find the shiny new draft at
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107
There's no much point in a diff, but you'll find a link to one under
"Previous Revisions".
Enjoy.
Jo
===================
Detailed Change Log
===================
LC-2007
RESOLUTION: remove "Content Deployment" class of product and move
section 4.2 Server Response to Proxy to an informative section. No
more normative guidelines on Content Providers.
Summary of requirements removed as not consistent with the document
describing only the proxy's behavior.
Audience section reworded to reflect change.
Changed Conformance Section.
Previous Guidelines included as an Appendix and heavily reworded.
*** Note that the meaning of many of the sections is altered ***
Removed normative *recommended* from non-normative appendix
"Applicability to Transforming Solutions which are Out of Scope"
---
LC-2067
RESOLUTION: re. LC-2067, state that conformance applies to SHOULD
statements as well. A justification is required for each
circumstance in which a SHOULD statement is not followed. Prepare an
Implementation Conformance Statement to be filled out by
Transformation Deployments willing to claim conformance to the spec.
Reworded Conformance to make it clear that SHOULD needs to be observed
too. Reference the following too.
It was Francois's ACTION-846 to prepare a draft conformance statment.
I've made a nice space as an Appendix and I'm sure we are all looking
forward to seeing it :-) .
---
LC-2050
RESOLUTION: Re LC-2050 move definitions to scope to clarify that we
are talking only about restructuring
*** on reflection, I don't think this makes sense. So I left the
definitions where they are. In reality, we are talking about both
restructuring and recoding and optimizing. I think perhaps we should
take this back to Eduardo when he joins the group.
RESOLUTION: re LC-2050 we don't intend to define these concepts any
more formally than we do now
(no edits required)
---
LC-2018
RESOLUTION: The title of the spec will be "Guidelines for Web
Content Transformation Proxies"
And so it is.
LC-2012
RESOLUTION: re. LC-2012, use Tom's wording above, (and note we may
have to further clarify the introduction for other reasons anyway)
... re. LC-2012, use Tom's wording above, (and note we may have to
further clarify the introduction for other reasons anyway)
overtaken by events ...
RESOLUTION: re. LC-2012, replace the sentence deemed obscure by
"Within this document content transformation refers to the
manipulation of requests to, and responses from, an origin server.
This manipulation is carried out by proxies in order to provide a
better user experience of content that would otherwise result in an
unsatisfactory experience on the device making the request."
---
LC-2064
RESOLUTION: LC-2064 is a mistake. There are no duplicated IDs in the
document.
(no edit required)
---
LC-2068
RESOLUTION: re. LC-2068, we think the text is as clear as possible.
Stick to the text in the spec.
(no edit required)
---
LC-2008
RESOLUTION: re. LC-2008, update the text according to Jo's proposal,
as pasted above
Text on vary headers ... slightly differently put in the Appendix as it
is now informative.
---
LC-2090 and LC-2091
RESOLUTION: The manner in which transformation is carried out, when
it is permitted, including any additional navigational or other
material that is included, aside from where explicitly stated
(insecure links etc.) will be noted in an "out of scope section" in
the document. And resolve no to LC-2090 and LC-2091
Amended "Scope" to refer to this question and to mention internal
operation being out of scope.
---
LC-2068
RESOLUTION: re. LC-2068, amend the text in section 4.1.2 with
references to RFC HTTP sections. Final text: "If the request
contains a Cache-Control: no-transform directive, proxies must not
alter the request other than to comply with transparent HTTP
behavior defined in HTTP RFC 2616 sections 14.9.5 and 13.5.2. and to
add headers as described in 4.1.6 Additional HTTP Headers below."
done
---
LC-2023
RESOLUTION: On character encoding mention this under 4.3.6.1 and
respond "Yes partial" to LC-2023
Added as a note under what was 4.3.6.1
<p>Other than as noted in this section the nature of restructuring that
is carried out, any character encoding alterations and what is omitted
and what is inserted is, as discussed in <specref ref="sec-scope"/>, out
of scope of this document.</p>
whereas the text discussed was:
Other than as noted in this
section the nature of restructuring that is carried out, what is
omitted and what is inserted may be a copyright issues and is in any
case out of scope of this document
RESOLUTION: Mention the out of scope nature of the details of
restructuring under 4.3.6 somewhere (cf insertion of headers,
footers etc.)
See above under LC-2090 and previous inserted text.
---
LC-2065
RESOLUTION: Move content from Appendix E to 4.3.6 somewhere and
reword appropriately (and yes, partial to LC-2065)
As follows as a new 4.x.6.1
<head>User Preferences</head>
<p>Proxies <rfc2119>must</rfc2119> provide a means for users to express
preferences for inhibiting content transformation. Those preferences
<rfc2119>must</rfc2119>be maintained on a user by user and Web site by
Web site basis. Proxies <rfc2119>must</rfc2119> solicit re-expression of
preferences in respect of a server if the server starts to indicate that
it offers varying responses as discussed under <specref
ref="sec-receipt-of-vary-header"/>.</p>
---
LC-2026, LC-2027, LC-2085, LC-2028, LC-2029, LC-2030, LC-2015, LC-2031,
LC-2016, LC-2032, LC-2001, LC-2033, LC-2004, LC-2024
(phew!)
RESOLUTION: Accept the thrust of Tom's submission on HTTPS, and
editor to make sure that the wording is beefed up (e.g. by saying
that if a proxy rewrites HTTPS ... rather than saying a proxy MAY)
to make it clear that if you _must_ do it the user MUST know and
MUST have a choice
ACTION-860 - Add clarification to HTTPS rewriting
to make it clear that the via header MUST be added
ACTION-864 - Redraft HTTPS section for discussion
on list [on Jo Rabin - due 2008-10-21]
Tom's Submissions:
1. http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0013.html
2. http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Oct/0012.html
Pending
Francois's ACTION-859 - Contact IETF TLS group and advise
them of what we are thinking and ask for guidance on what to
recommend to Content Provider about detecting the presence of a
man-in-the-middle proxy
Pending
Discussion with Thomas Roessler about his concerns ref applications
and possible security risks relating to the client thinking that all
hosts are the same (i.e. that they are the proxy).
Discussion: http://www.w3.org/2008/10/07-bpwg-minutes.html#item02
The amended text so far:
4.2.7.2 HTTPS Link Re-writing
Note:
The BPWG does not condone link rewriting, but notes that in some
circumstances HTTPS is used in situations where the user is prepared to
trade usability provided by a transforming proxy for the loss of
end-to-end security. Servers can prevent users from exercising this
choice by applying a Cache-Control: no-transform directive.
If a proxy rewrites HTTPS links, it must advise the user of the security
implications of doing so and must provide the option by-pass it and to
communicate with the server directly.
Notwithstanding anything else in this document, proxies must not rewrite
HTTPS links in the presence of a Cache-Control: no-transform directive.
If a proxy re-writes HTTPS links, replacement links must have the scheme
https.
When forwarding requests originating from HTTPS links proxies must
include a Via header as discussed under 4.1.6.1 Proxy Treatment of Via
Header.
When forwarding responses from servers proxies must notify the user of
invalid server certificates.
Add some stuff below under guidance for servers
Note:
For clarity it is emphasized that it is not possible for a transforming
proxy to transform content accessed via an HTTPS link without breaking
end-to-end security.
---
LC-2078
RESOLUTION: Rewrite section 4.1.6.1 to clarify that inclusion of a
via comment of the form indicated is not a conformance claim, but is
an indication that the proxy may restructure or otherwise modify
content
Replace "indicate their conformance ..." with "indicate their ability to
transform content"
---
LC-2019
RESOLUTION: re. LC-2019, amend text on conversion between HEAD and
GET to say that other conversions are not allowed, and resolve
partial to LC-2019
Other than to convert between HEAD and GET proxies <rfc2119>must
not</rfc2119> alter request methods.
---
LC-2034: Applicable HTTP methods (§4.1.1)
RESOLUTION: ref LC-2034, we clarify that the scope of
the document is limited to GET, POST, HEAD requests and their
responses and resolve "no"
Modified to remove PUT: <p>Proxies <rfc2119>should not</rfc2119>
intervene in requests with methods other than GET, POST, HEAD.</p>
Added:
<div3 id="sec-ApplicableResponses">
<head>Applicable Responses</head>
<p>Proxies <rfc2119>should not</rfc2119> intervene
in response if the request method was not HEAD, GET or POST.</p>
</div3>
---
LC-1997, LC-2006, LC-2014, LC-2046
*** Discussed on 14th but no resolution that day ***
---
LC-2066
RESOLUTION: Accept LC-2066 and add the reference
Added reference to HTTP section 14.9.5
---
LC-2044
RESOLUTION: Ref LC-2044 Resolve yes, and change the text to say
"*values* of User Agent and Accecpt headers", and clarify that we do not
propose guidance for new user agents' use of these headers, it is out of
scope
*** I didn't add the clarification, it seems out of place ***
And anyway
RESOLUTION: re LC-2044, resolution on LC-2069 removes the part that
required clarification, resolve partial, we won't talk about "use of
evidence"
---
LC-2070
RESOLUTION: Ref LC-2070, resolve yes, and change para 1 to say "Aside
from the usual caching procedures defined in RFC 2616, in some
circumstances ..."
done
---
LC-2069
RESOLUTION: ref LC-2069. Resolved yes, with the replacement text: Before
altering aspects of an HTTP request proxies ought to take account of the
fact that HTTP is used as a transport mechanism for many other
applications than "Traditional Browsing" and that alteration of HTTP
requests for those applications can cause serious misoperation.
Used the words "need to"
---
LC-2003
RESOLUTION: Make a note about the reasons for not referring to lists, of
whatever hue, because the preumption about the internal operation of
proxies is not in scope, as far as we are concenred these are "black boxes"
Text included in Scope per the above LC-2090
---
LC-1996 et al (section 4.1.5)
RESOLUTION: WRT 4.1.5 Text remains substantially as is but is reinforced
by saying that the CT proxy SHOULD NOT change headers and values other
than User Agent and Accept(-*), MUST NOT delete headers and it MUST be
psosible for the server to reconstruct the original UA originated
headers by using X-Device etc.
done
---
LC-2074
RESOLUTION: re. LC-2074, resolve no. Based on our experience and
feedback from servers whose operators take strong exception to this
practice, we think it's reasonable to advise CT-proxies operators of
this situation
No change needed
---
LC-2037
RESOLUTION: ref LC-2037 yes, we have removed PUT partly in response to
your comment
Done
PROPOSED RESOLUTION: ref LC-2037 ref retrying POSTs, no, we agree that
it shouldnot be necessary to point this out, but sadly it is
No actual resolution but no change needed.
See http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Oct/0052.html
---
LC-2075
RESOLUTION: LC-2075 differences in behaviour: the internal operation of
the proxy is not open to our specification, we need to point out to CT
proxies that in practice 406 responses are not the only way in which
content proivders signal that they can't or won't handle a request,
though we do say that this is the preferred way of them doing so
*** actually the text in what is now the appendix doesn't say it's the
preferred way any more ***
but no change needed at this section
RESOLUTION: ref LC-2075, we have changed the text to refer only to POST
and we acknowledge that this should not need restatement from RFC 2616
but we are aware of this kind of misoperation "in the wild"
Removed PUT
---
LC-2076, LC-2039
RESOLUTION: Ref LC-2076 - yes, we will change the use of the word
representation and use something like "included resources"
done with reference to mobileOK basic test 1.0 (sic)
RESOLUTION: ref LC-2039 and LC-2076: Yes, we will clarify that we are
talking about keeping the User Agent Header consistent
done
---
LC-2079, LC-2041, LC-2080 - 4.2.1 Use of HTTP 406 Status - 4.2.2 Server
Origination of Cache-Control: no-transform
RESOLUTION: ref LC-2041, LC-2080 and LC-2079, yes, we intend to move
server behaviour into a non-normative section and point out that servers
may wish to respond with no-transform if they think that this respects
the intention of the requester and that for the sake of clarity use of
406 is clearer than using a default representation using 200 and the
text "your browser is not supported"
*** done-ish ***
---
LC-2045 - Respect of RFC2616 - 4.2.2 Server Origination of
Cache-Control: no-transform
RESOLUTION: re. LC-2045, resolve partial, comment actually applies to
4.3.1 where it is emphasized that proxies MUST behave "transparently"
with a link to the definition that contains links to sections 13.5.2 and
14.9.5 of RFC2616
done
---
LC-2081
RESOLUTION: Change second second para of 4.2.3.1 to say "don't
systematically misrepresent your content, even if you think that will
avoid it being transformed"
Something like the above, anyway
---
LC-2009, LC-2010, LC-2011 - Use of the link element - 4.2.3.2 Indication
of intended presentation media type of presentation
RESOLUTION: LC-2010 is a reasonable comment but is now overtaken by
events - namely that we don't propose to use fragment identifiers as a
method to achieve this anymore.
RESOLUTION: Ref LC-2011 in 4.2.3.2 (and elsewhere as suits clarity and
editorial convenience) at para 3 and the following note. Make it clear
that where more than one representation is available from the same URI
this ought to be represented by using a Vary header and can't be
represented using <link rel="alternate">. In other cases the link header
should be used to reference alternative representations (i.e. where the
Base URI, ref RFC 3986 secs 5.5 and 5.1 does not indicate a same
document reference)
Hope I have done this according to expectations
RESOLUTION: re. LC-2009, resolve yes, acknowledge RFC3986 section 4.4
and remove the part on fragment identifiers
Yup
---
LC-2020 - Copyright - 4.3 Proxy forwarding of response to user agent
RESOLUTION: re. LC-2020, resolve no, the presence or absence of a
Copyright is not a clear indication of the rights associated with the page
---
LC-2082, LC-2042 - Cascading proxies - 4.3.2 Receipt of Warning: 214
Transformation Applied
RESOLUTION: WRT LC-2082, LC2042: resolve_yes and remove 4.3.2 replace
with a section noting that intermediate proxies should send no-transform
if they want to inhibit further transformation
---
LC-2083
RESOLUTION: ref LC-2083, no, it is an important part of the mechanism
described in 4.1.5 so has to be here in some form. We don't mean to
propose this as a fail safe mechanism, we merely mean to indicate that
CT proxies may need to employ heuristics to provide an improved service
for their users. Remove reference to conforming servers.
Done
---
LC-2084 - purpose of behavior - 4.3.4 Receipt of Vary HTTP Header
RESOLUTION: re. LC-2084, resolve partial since this is part of the fail
safe mechanism defined in 4.1.5.2 that explains the use case. Move
reference to 4.1.5.2 earlier int he sentence and simplify wording, add
reference to example kindly to be re-provided by Francois
*** noting that the example is needed from Francois! ***
Hope that the revised text is clearer
---
LC-1998 - No transformation for application/xhtml+xml - 4.3.6 Proxy
Decision to Transform
RESOLUTION: Remove examples of heuristics from the main run of text and
include Appendices to list in a *non-endorsed* way lists of stuff that
other people have used but are No-endorsed by us, and did I mentionthat
they are not endorsed
Created Examples Appendices, moved example doctypes there
RESOLUTION: re. LC-1998, resolve no and point out to commenter that this
assumption is unsafe without other supporting evidence.
No change needed
---
LC-1999 - No transformation for small pages - 4.3.6 Proxy Decision to
Transform
RESOLUTION: Ref LC-1999 Resolve no commenter and point out to commenter
that size on its own is unsafe as an indicator of mobile friendlines e.g
content with embedded flash
---
LC-2048, LC-2002, LC-2052, LC-2021 - Heuristics - 4.3.6 Proxy Decision
to Transform
RESOLUTION: Ref LC-2048 and LC-2002, LC-2052 and LC-2021, resolve
partial, and say that we include these examples as non-endorsed
heuristics in the non endorsed heuristics appendix
now there are some long lists
---
LC-2022 - i-mode content - 4.3.6 Proxy Decision to Transform
RESOLUTION: Ref LC-2022 resolve partial, we agree that this was not
included and have added it as a non-endorsed heuristic in the relevant
appendix
already dealt with above
---
LC-2090, LC-2000 - No extra content without the consent of the content
owner - 4.3.6 Proxy Decision to Transform
RESOLUTION: Ref LC-2090 and LC-2000, resolve no, other than to note that
adding extra content is forbidden where no-transform is present and
content providers should use this if they want to be sure their content
is not added to
nothing to do
---
LC-2013 - meta http-equiv - 4.3.6 Proxy Decision to Transform
RESOLUTION: Ref LC-2013, resolve yes, clarify in 4.3.1 and 4.3.6 and in
other relevant sections that meta http-equiv should be consulted if the
relevant actual HTTP header is not present
Included as a preface to what is now 4.2
---
LC-2051 - Open Mobile Alliance Standard Transcoding Interface work -
Appendix A and D
ACTION-868 - Review OMA STI to see if there's something relevant for CT
for LC-2051
Francois concluded that it was not relevant
---
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"
This resolution deemed taken (like the other one Francois mentioned)
done
---
LC-2047 - Cascading proxies - Appendix D.4 Inter Proxy Communication
RESOLUTION: ref LC-2047 part a. No. We do not view the CT proxy as being
a user agent in its own right, it is a proxy like any other. Knowing
that it is upstream of other proxies doesn't alter it's prescibed
behaviour according to this document
RESOLUTION: ref LC-2047 part b. we think that this is defined in HTTP
and don't need to elaborate on it unless there are specific examples of
misoperation that we can refer to
RESOLUTION: ref LC-2047 part c. we disagree and think that this is very
complex and requires a substantial use case analysis to achieve a
complete understanding. We think that a more complex HTTP vocabulary for
inter proxy operation is likely to be required to achieve useful
results, and we are not chartered to create technology of that kind
no action required
RESOLUTION: Add a section with a diagram explaining which proxies are in
scope
*** not done *** needs to be done *** any offers? ***
---
LC-2038 - is it a list of Best Practices? Be explicit it that's the case
RESOLUTION: ref LC-2038, resolve partial. Answer "no, these are not best
practices, but guidelines". Don't change the text.
Fair enough, I didn't
---
LC-2049 - forbid the alteration of the request when the URI follows some
mobile pattern (*.mobi, wap.*, ...)
RESOLUTION: ref LC-2049 resolve no, URI patterns can never be more than
a heuristic, but we will move the list of examples to a non normative
appendix
Already done up there ^^ somewhere
---
LC-2053 - Classes of devices
*** Not done, awaiting clarification
---
LC-2072 - what is a restructured desktop experience?
RESOLUTION: ref LC-2072, resolve yes, and insert a termref to
restructured and an Xref to 4.1.5.3
as noted
---
LC-2073 - heuristics and web sites
RESOLUTION: Ref LC-2073, resolve no, we are not aware of any
satisfactory heuristics, but understand that CT Proxy vendors will need
to adopt heuristics of some kind so we have no choice but to leave it open
No change needed
---
LC-2040 - X-Device-* should be in an Internet Draft
Pending ACTION-879 - Ask [someone] about adding IETF headers [on
François Daoust - due 2008-11-11].
---
ends
Received on Friday, 7 November 2008 18:41:03 UTC