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

Prior to making changes for the next draft I guess we could benefit from
a round trip or two on this.

Cheers
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.

OK I will flesh this out as discussed on the call.
> 
> 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).

I think the problem is that it is not OK to condone the idea that a
no-transform directive may be ignored, a) because that would be a
deviation from the spec and b) it would mean that a content provider had
no means of sending the content in exactly the form they intended,
whether the proxy understands that intention or not. There are plenty of
good reasons why a CP might want to do that. 

On the other side I can see that it seems like a good idea to stop users
having unexpected experiences when the CP did not do it intentionally. 

Reconciling those perspectives is one of the reasons why we need to
enrich the no-transform vocabulary.

> 
> 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).

Yes, as things stand that is clear because the old ones are named and
the new ones are all referred to as the @@xxx directive. I think there
is a case for discussing the limits of what can be achieved using just
no-transform and Vary and to make that a separate section.

> 
> 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.

Um yes, I suppose. I think I was more getting at the user agent being
able to express presentational preferences in a dynamic way, but I agree
that is not the way it reads now.

> 
> 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? 

I meant by HTTP header. It's discussed later that it must be available
as a user interaction. That could do with clarification.

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.
> 

I think that we need to be able to tell the proxy to act transparently
"while on this site" whatever this means. I don't think this is
especially stateful, or at least no more so than the default
presentation of credentials following a 401 response from a site.

> 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?

I would prefer to leave that buried in the generic statement that
proxies may off more features than are discussed in the document and may
offer control over them via user interactions. I think if we start
naming additional optional features we could get buried in a morass of
HTTP signalling to control them.
> 
> 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.

I think there is a problem with this as there is nothing in the user
agent header that specifically identifies the user agent as a browser,
is there? So the best we could do would be to say that the proxy SHOULD
make "reasonable efforts" to determine whether a user agent is a
browser, using heuristics applied to an a priori knowledge base (or
perhaps we should just recommend they use dotMobi's DeviceAtlas product
:-) )

> 
> 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.
> 
Heiko mentioned this too. Clearly the proxy shouldn't interfere with any
POST body, but that is probably it ... we should probably mention PUT
and all the other methods too for that matter, at least to say that they
are out of scope.


> 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)

I am trying to avoid using the terminology CT aware etc which I think
leads us down a path of discussion about how aware you have to be to be
considered aware. From a specification point of view, we have already
stated the reason for requiring user interaction in the previous main
section and so in this section I want to concentrate on the events that
trigger behaviour of certain kinds, and that is the reason for writing
it this way round.

So I know that it says "when x happens, do [that voodoo that you do so
well]" but that seems fine to me.


> 
> 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).
Agreed that proxy will never see the request in the first place (or
rather will have no choice but to act transparently at the TCP level) -
but this is here specifically to catch the case where a proxy has
converted https://example.mobi/aservice to http://example.mobi/aservice
the server should just take into account that it may not want to serve
the content in an insecure way. A stupid point in many ways, but
possibly worth making.

> 
> 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.

OK I thought I was reflecting what you had written earlier. As you say
it should at least be rewritten as must rewrite as an https, and
probably also only with the permission of the CP and the user. 

> 
> 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.

We are seeing problems of this kind in the field actually - seems that
there are a number of WAP gateways that act on this directive, as they
should according to the spec - with the result that the users browser
becomes very confused. [Ironic perhaps that proxies the directive is
aimed at ignore it and the ones it is not aimed at don't ignore 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.

Hmmm, yup, it's not clear is it. I am trying to say that we having the
proxy second guessing the server and the server second guessing the
proxy is a situation we'd like to avoid. So if the server wants to
control the proxy it should do so by the means indicated in this rec -
and not try to guess the heuristics any proxy might be employing. I am
prepared to believe that this is not correct and that we should
encourage the server to serve with distinctively mobile content-type and
with the various uses of <link> in order to work around non CT protocol
aware CT proxies (like all the ones out there today)

> 
> 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).

Well that should not stop us recommending that the response is
constructed sensibly and maybe life will improve one day :-(

> 
> 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."

I don't see where the proxy's behaviour would change as a result of
knowing this - or another way of looking at it is to say that the
server's use of no-transform and vary indicate that it is ct aware,
though not that it know about or uses any other aspect of the spec.

On the user agent side, I suggest a @@ct-aware directive which means "I
didn't say no to transformation of any kind", not sure this is actually
necessary though one part of the description of the proxy's behaviour
refers to it.

> 
> 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 15:52:50 UTC