RE: ACTION-604 ACTION-615 Proposed Treatment of Bryan's Contribution in Preparation for a New Draft CT

Jo,
Comments to
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guide
lines/071124. Some of the items from my earlier contribution don't
appear to be covered but I will circle back as needed in the next draft.

Re 2.1 Requirements "I'm not actually sure how useful this is any more,
I think it may have served its purpose in stimulating debate and
thought": I think the section is useful. It helps set the context for
the reader.

Re 2.4 Proxy States "This must steer clear of recommending a deviation
from the HTTP spec which I don't think is acceptable. However there are
parallels with the operation of e.g. child protection mechanisms?": I
think we are OK referring to any case in which a proxy modifies content,
causing that proxy to be considered non-transparent for that particular
request. We might mention that there may be cases where the reason for
transformation overrides the objectives in this document (e.g.
compliance to no-transform directives), and that even in those cases the
other requirements in this document should apply (e.g. disclosing that
the content had been transformed).

3.1 Client Origination of Request 
Re "The client may request that the Content-Type and Content-Encoding
must not be altered in the response by setting the Cache-Control:
no-transform directive.": maybe reword as "The client may set the
Cache-Control: no-transform directive to request that the Content-Type
and Content-Encoding must not be altered in the response." 

Re the "The client may add an..." statements: We should mention which of
these are new parameters (defined here).

Re "[It would be nice if the client were able to indicate what type of
presentational capabilities it has, for example, zoom, linearize,
keyhole ... @@@ client-feature indication]": these should supported via
a DDR ala the DDWG is working on.

Re "[It would also be useful if the client were able to turn off the
User Interaction features of the proxy via HTTP]": do you mean via an
HTTP header, or via a web-based CT user control interface, or both? It
begins to get complicated if we start talking about stateful
requirements on turning features on and off, so I recommend we start at
least with a stateless assumption, i.e. the directives relate to the
current request only. See comments to 3.2.3 below; I have atttempted to
address this but you can see it will get complex.

As I provided in my contribution, do we want to address "A CT proxy MAY
enable a user to select preferences for user agent identification and
capabilities disclosure to CP.", or is that going to far functionally?

3.2 Proxy Receipt, Forwarding or response to a Request
Re "Irrespective of the presence of the no-transform directive, the
proxy must behave transparently (q.v.) if it detects that the user agent
is not a browser [@@open question as to how it does that].": I recommend
we say "CT proxies MUST be capable of recognizing browsers and
non-browsers via the User-Agent header.". We could leave other methods
unspecified.

Re "Proxies must not intervene in HTTPS requests and should not
intervene in methods other than GET and HEAD." We should explain why.
I'm not sure of the reason for restricting POST.

3.2.3 Proxy Interaction with the User when Active

Re "If neither a no-transform nor a [@@ct-aware] directive is present in
a request from the client, the proxy must offer a means of interacting
with it to provide at least basic control (the ability to transition the
proxy to passive role) of its services. Proxies may in addition offer
user interaction when those directives are present - i.e. interaction
with the user is not prohibited if the client is aware of the
conventions of this document, unless the client has requested disabling
them.": I suggest to reword this, as it currently states a general
capability requirement in the context of a particular event. The general
capability requirement needs to be stated first, followed by the
requirements in the specific case. Here is the way I would write the
requirements in this section:

"CT proxies MUST offer a means of user control for CT services for users
of non-CT aware browsers, via a web-based user preferences interface or
through preselection via the CP proxy operator (e.g. by proxy
administration)."

"CT proxies MUST offer a means of user control for CT service related to
the current request".

"CT proxies MAY offer a means of user control for CT service via
persistent CT service preferences, which upon selection, apply to all
requests, unless overridden by client request."

"CT proxies MAY offer a means to scope user control preferences for CT
service to specific domains or other criteria, e.g. for specific content
types."

"If neither a no-transform nor a [@@ct-aware] directive is present in a
request from the client, and no persistent preference for CT services is
defined, CT proxies MUST provide a web-based means of user control for
CT service related to the current request."

(remaining requirements can stay as-is, unless they need to be modified
to be consistent with the above)

3.3 Server Response to Proxy
Re "Servers should distinguish URIs that are intended for access only by
HTTPS from those that are intended for insecure access in order to be
able to detect and reject requests that should have been submitted by
HTTPS but have been re-written in contravention of its directives.":
Note in most cases the proxy will never see the URI anyway as most
clients (especially mobile ones) should be using HTTP CONNECT (if they
are aware that they are using a proxy, otherwise the SSL connection is
direct and the proxy doesn't apply anyway).

Re "If the response contains URIs with the scheme https and the server
is content to allow the scheme to be re-written as the http scheme then
it must indicate this using the [@@allow-https-rewrite] directive,
otherwise rewriting is inhibited.": I don't think its necessary or good
to open this box, as there are serious security implications. The only
valid reason I see for rewriting HTTPS URIs is so that the resource can
appear to be hosted on the CT proxy itself. Even so it should still be
rewritten as a secure URI. Thus the CT proxy recreates the WAP gap in
the interest of transforming content sent over two secure connections in
which it provides the bridge. At least there, the actual request
transmission is secure over each hop.

Re "Note that including a no-transform directive may [@@should actually]
disrupt the behavior of WAP/WML proxies, because this inhibits such
proxies from converting WML to WMLC (because this is a content-encoding
behavior). Adding [@@allow-recoding] or [@@allow-compression] is
unlikely to be recognized in the short-term by such proxies which
predate these guidelines." Note by the time this gets implemented there
are likely to be *very few* WAP1 devices still out there, and you can
count on two things as a result:
1) Most devices support text WML directly, and compression occurs
through GZIP (we are already nearing 95% WAP2 on our network, and this
is the case across the board for WAP2 devices).
2) The vendors and operators of WAP1 proxies will be loathe to make
*any* changes to these products at this time, as there is little value
and a lot of risk (to the stability of the WAP1 gateway functions
overall, since most bugs are unintended side-effects). Also, because any
CT proxy other than a WAP gateway would be on the CP side of the
gateway, its non-conversion of WML would be irrelevant as the WAP1
gateway would still do it.

Re "The server should not choose a Content-Type for its response based
on its assumptions about the heuristic behavior of any intermediaries.
(e.g. it should not choose content-type: application/vnd.wap.xhtml+xml
solely on the basis that it suspects that transforming proxies will
apply heuristics that make them not restructure it).": Maybe rephrase
this, exactly what it means is unclear to me.

Re "406 Response - Note that some clients (MSIE for instance) don't
display the body of a 406 response, this is in contravention of HTTP/1.1
as far as I can see.": Also, most mobile browsers don't actually display
the body of error responses either. This has been a problem since day
one; it has been impossible to create a consistent user experience for
error handling, even when we sent so far as to customize the response
body for compatibility with the clients (which was the main reason that
most ignored it from the beginning).

Can you tell me how you address in this section, the statement I had in
my contribution: "A CT proxy SHALL be capable of detecting CT-awareness
in CP and browsers." Maybe we can add "A CT-aware server MUST indicate
that it understands the conventions of this document by including a
[@@ct-proxy-aware directive] in responses."

Best regards,
Bryan
-----Original Message-----
From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org] On Behalf Of Jo Rabin
Sent: Thursday, January 17, 2008 8:27 AM
To: public-bpwg-ct@w3.org
Subject: ACTION-604 ACTION-615 Proposed Treatment of Bryan's
Contribution in Preparation for a New Draft CT


Hi folks

I have done a write through of Bryan's proposed "requirements" to fit in
with the style of the rest of the document and to make it a little more
discursive, as discussed on various calls. Before weaving this into the
current draft in various places I thought I would put it to the group
for comments and to see if there are any major objections. If not I will
create a new draft tomorrow afternoon (Friday) for discussion on the
call Tuesday.

I have tried to cross reference the section numbers from the present
draft to make sure everything is covered. I know I've missed a couple of
references out accidentally and there are a couple of sections I don't
think fit, exactly, and I have noted those below. I've also included
Bryan's original contribution for easy reference.

thanks
Jo

Current Draft:
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guide
lines/071124

ACTION-604 ACTION-615

Control of Proxy

A proxy may be active or passive. When active, a proxy offers various
[@@] features involving the transformation of content and manipulation
of HTTP headers. When passive a proxy may alter content and headers only
in the respects described in [HTTP] as if a Cache-Control: no-transform
directive were present (with the exception of "Dangerous Content"
below).

[Note: In practice a proxy may be made passive by configuration of the
network such that it is by-passed]

A proxy MUST offer basic control of its features to users, clients and
origin servers and MAY offer more advanced control [2.1.1 MAY-> MUST].
Basic control means transitioning between active and passive roles.  

When active, proxies MUST offer basic control on a per request basis and
MAY allow the registration of persistent user preferences [2.1.1
MUST->MAY].

Behavior When Active

A proxy SHOULD NOT alter HTTP requests unless not doing so would result
in the users request being rejected by the CP [this includes 406 as well
as 200 Your browser is not supported][2.1.4]

A proxy should only alter the format, layout, dimensions [@@how to
better express this] to match the capabilities of the client [2.1.2
"highest Quality"]. For example, when resizing images, they should only
be reduced so that they are suitable for the specific client, and should
not be done on a generic basis.
 
Proxies MUST NOT alter URIs with the https scheme unless specific
consent is granted by both the user and the origin server. [@@How in the
case of the origin server).
 

Interaction with the User (when Active)

If the client is known not to conform to this specification CT Unaware
[@@by ...] the proxy MUST offer a means of interacting with it to
provide at least basic control of its services. Proxies MAY in addition
offer user interaction via CTAware browsers.

Proxies MUST offer, via this interaction, a means of rendering itself
passive for [@@does the following make sense?] the following request
[2.2.2], for the current domain and for all future requests [2.2]. The
proxy MAY offer further features which SHOULD be offered on the same
basis (current domain, all future requests, etc.). Proxies MAY also
offer this interaction to browsers that do conform to this specification
but MUST offer a means of disabling it [@@by interaction as well as via
HTTP? If the latter need further cache control directive]

If content has been transformed proxies MUST indicate this to the user
[2.5.3] and MUST provide a means of retrieving the original content.
Proxies MAY provide a cached copy of the response prior to
transformation in fulfilling this requirement. [@@ should this be
available by some HTTP mechanism too [2.5.4] says yes which requires
further elaboration of current section 4.1]

Note: Further user control of the proxy MAY also be achieved by
administrative means, by providing a specific proxy configuration
facility or by other means.

The proxy MAY annotate hyperlinks with the https scheme noting that it
is unable to offer active service on such a request.

Dangerous Content

[@@note that this must steer clear of recommending a deviation from the
HTTP spec which I don't think is acceptable. However there are parallels
with the operation of e.g. child protection mechanisms]

Proxies MAY offer a feature when passive which MUST be under control of
the user [2.3.1][2.5.1] to block or transform content which it has been
determined would cause serious mis-operation of the client, such as
causing it to crash.

===

2.1.3 detection of CT-awareness
[JR: not sure why is this necessary]

A CT proxy shall be capable of detecting CT-awareness in CP and
browsers.

===


2.4 CT proxy capabilities disclosure to CP [This should be covered in
section 4.2 of the earlier draft ...]

A CT proxy shall disclose its CT capabilities to CT-aware CP without
affecting user agent identification or capabilities disclosure.

===

2.5.2 CT proxy capabilities disclosure to CT-aware browser [This should
covered in section 4.5 of the earlier draft]

A CT proxy shall disclose its CT capabilities to CT-aware browsers
without affecting CP-provided headers.


===

2.7 non-browser user agents

[JR I don't think I understand how the proxy would know this -
especially as non browser user agents would typically masquerade as
browsers so as not to get blocked by proxies]

A CT proxy should be capable of detecting non-browser user agents.

A CT proxy shall be capable of bypassing CT service for detected
non-browser user agents.

=============

Bryan's original text

CT = Content Transformation, CP = Content Provider(s)

An entity that is "CT-aware" is assumed to be specifically designed to
use or provide CT service per these guidelines. A "CT proxy" is assumed
to be CT-aware. A "non-CT proxy" is assumed to be CT-unaware. Browsers
and CP may be CT-aware or CT-unaware.
2.1 general requirements
2.1.1 preferences

A CT proxy may enable a user or user agent to select preferences for CT
service features.

A CT proxy that offers preference selection shall be capable of
retaining the selections.
2.1.2 provision of highest-quality content

When selecting a content representation by default, CT proxies shall
provide the highest-quality representation compatible with the browser.

"Compatible" in this requirement means a representation that the browser
supports, and results in a usable user experience.
2.1.3 detection of CT-awareness

A CT proxy shall be capable of detecting CT-awareness in CP and
browsers.
2.1.4 user agent identification and capabilities disclosure

A CT proxy may enable a user to select preferences for user agent
identification and capabilities disclosure to CP.

A CT proxy shall forward requests to CP without affecting user agent
identification or capabilities disclosure, except as necessary to
provide a user-selected content representation, or as otherwise
specified by user preferences.
2.1.5 original representation availability

A CT proxy shall provide availability of the original representation for
a CP response.

A CT proxy may support local caching of CP responses in their original
representation.
2.2 CT proxy serving CT-unaware CP and browser

A CT proxy shall be capable of providing CT service to CT-unaware CP and
browsers.
2.2.1 CT-unaware browser user selection of content representation

A CT proxy may enable a CT-unaware browser user to select a preference
for a content representation from among those available through the
proxy.

A CT proxy that offers user-selection of content representations should
be capable of user selection of such preferences for specific domains
and globally for all domains.

A CT proxy that offers user-selection of content representations should
be capable of offering the user the ability to switch representations
when viewing a page.
2.2.2 CT-unaware browser user selection of original content
representation

A CT proxy should support the ability of a CT-unaware browser user to
select the original representation for a CP response.
2.2.3 CT-unaware browser user selection of alternate content
representation

A CT proxy shall support the disclosure of available alternate
representations for a CP response to a CT-unaware browser user.

A CT proxy shall support the ability of a CT-unaware browser user to
select an alternate representation for a CP response.
2.3 CT proxy serving CT-aware CP and CT-unaware browser
2.3.1 CP directives

A CT proxy shall recognize and honor CP directives for supported CT
services.

As an exception to the previous requirement, a CT proxy should deny CP
directives that would result in dangerous markup being sent to the
browser.

A CT proxy may enable a user to select preferences for error handing
related to CP directives.
2.4 CT proxy capabilities disclosure to CP

A CT proxy shall disclose its CT capabilities to CT-aware CP without
affecting user agent identification or capabilities disclosure.
2.5 CT proxy serving CT-aware CP and CT-aware browser
2.5.1 browser directives

A CT proxy shall recognize and honor browser directives for supported CT
services.

As an exception to the previous requirement, a CT proxy should deny
browser directives that would result in dangerous markup being sent to
the browser.
2.5.2 CT proxy capabilities disclosure to CT-aware browser

A CT proxy shall disclose its CT capabilities to CT-aware browsers
without affecting CP-provided headers.
2.5.3 CT actions disclosure to CT-aware browser

A CT proxy shall disclose CT actions taken on CP responses to CT-aware
browsers.
2.5.4 CT-aware browser selection of original content representation

A CT proxy shall support the disclosure of the original representation
for a CP response to a CT-aware browser.

A CT proxy shall support the ability of a CT-aware browser to select the
original representation for a CP response.
2.5.5 CT-aware browser selection of alternate content representation

A CT proxy shall support the disclosure of available alternate
representations for a CP response to a CT-aware browser.

A CT proxy shall support the ability of a CT-aware browser to select an
alternate representation for a CP response.
2.6 security considerations

A CT proxy shall not rewrite secure links as a way to enable CT service
for those links, without the consent of the CP and user.

A CT proxy that does not support or is not allowed to provide CT service
for secure links should disclose to the user that the CT service will be
unavailable for those links.
2.7 non-browser user agents

A CT proxy should be capable of detecting non-browser user agents.

A CT proxy shall be capable of bypassing CT service for detected
non-browser user agents.

Received on Tuesday, 22 January 2008 19:06:53 UTC