ACTION-628 Contribution for draft 1d [was ...]

Oops, sorry about spam, this is an update of the ACTION number plus I
should have spelled out that I have comments in line with Bryan's
original.

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 16:01:34 UTC