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

Bryan

Thanks as usual for your detailed and useful comments. I'll try to weave
them into the next draft - but may come back to you on a couple of
points. I'm sorry if some of your earlier points seem to have been
dropped but let's make sure they are covered.

Jo


> -----Original Message-----
> From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org]
> On Behalf Of Sullivan, Bryan
> Sent: 22 January 2008 19:06
> To: public-bpwg-ct@w3.org
> Subject: 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 Wednesday, 23 January 2008 09:10:26 UTC