Re: Review of Content Transformation Guidelines Last Call?

Hi Mark,

Thanks for the comments!

I added them to our Tracking System.

The Mobile Web Best Practices Working Group will address them as soon as 
possible and get back to you with some proposed resolutions or requests 
for clarification.

In the meantime, please note that the discussion that these comments may 
trigger on the list takes place between individuals and does not reflect 
the official standpoint of the Mobile Web Best Practices Working Group, 
or of the W3C.

Francois Daoust,
W3C Staff Contact,
Mobile Web Best Practices Working Group.


Mark Baker wrote:
> Here's my comments.  In summary, the group really needs to decide
> whether this is a guidelines document, or a protocol.  It can't be
> both.  A lot of work remains.
> 
> 4.1.1 Applicable HTTP Methods
> 
> "Proxies should not intervene in methods other than GET, POST, HEAD and PUT."
> 
> I can't think of any good reason for that.  If a request using an
> extension method wants to avoid transformation, it can always include
> the no-transform directive.
> 
> 4.1.3 Treatment of Requesters that are not Web browsers
> 
> "Proxies must act as though a no-transform directive is present (see
> 4.1.2 no-transform directive in Request) unless they are able
> positively to determine that the user agent is a Web browser"
> 
> That seems both vague and arbitrary.  What is a Web browser?  What's
> the objective that this guideline is trying to meet?
> 
> Aside: the use of RFC 2119 keywords here seems quite out of place.
> These are guidelines after all, no?  A "guideline" that uses "MUST" is
> more like a protocol.
> 
> 4.1.5 Alteration of HTTP Header Values
> 
> RFC 2616 already says a lot about this. See sec 13.5.2 for example.
> 
> "The theoretical idempotency of GET requests is not always respected
> by servers. In order, as far as possible, to avoid mis-operation of
> such content, proxies should avoid issuing duplicate requests and
> specifically should not issue duplicate requests for comparison
> purposes."
> 
> First of all, do you mean "safe" or "idempotent"?  That you refer only
> to GET suggests safety, but the second sentence suggests you are
> referring to idempotency.  So please straighten that out.  Oh, and
> there's nothing "theoretical" about GET's safety or idempotency; it's
> by definition, in fact.
> 
> Secondly, if the server changes something important because it
> received a GET request, then that's its problem.  Likewise, if it
> changes something non-idempotently because it received a PUT request,
> that's also something it has to deal with.  In both cases though, the
> request itself is idempotent (and safe with GET), so I see no merit to
> that advice that you offer ... unless of course the problem you refer
> to is pervasive which clearly isn't the case.
> 
> I also wonder if most of 4.1.5 shouldn't just defer to 2616.  As is,
> large chunks of this section (as well as others) specify a protocol
> which is a subset of HTTP 1.1.  (see also the RFC 2119 comment above)
> 
> I don't understand the need for 4.1.5.2.  The second paragraph in
> particular seems overly specific, as proxies should obviously not be
> retrying POST requests unless an error - any error - was received.
> PUT messages can be retried because they're idempotent.
> 
> The rest of the 4.1.5.* sections all seem to be basically "Here's some
> things that some proxies do".  By listing them, are you saying these
> are good and useful things, i.e. best practices?  If so, perhaps that
> should be made explicit.
> 
>>From 4.1.5.4, "When requesting resources that form part of the
> representation of a resource (e.g. style sheets, images), proxies
> should  make the request for such resources with the same headers as
> the request for the resource from which they are referenced.".  Why?
> There may be lots of reasons for using different headers on these
> requests.  For example, I'd expect the Accept header to be different
> for a stylesheet than for an image.  What are you trying to accomplish
> with this restriction?
> 
> 4.1.5.5 defines a protocol.  This should be in an Internet Draft, not
> in a guidelines document.
> 
> 4.2.2 "Servers must include a Cache-Control: no-transform directive if
> one is received in the HTTP request."  Why?  What does the
> transformability of a request body have to do with the
> transformability of the associated response body?
> 
> 4.3.2 "If the response includes a Warning: 214 Transformation Applied
> HTTP header, proxies must not apply further transformation. "  Why?
> The transformation indicated by the warning may have been the result
> of a server-side transformation which a client-side proxy may deem
> suboptimal, and so want to retransform.  I see no problem with that.
> 
> Mark.
> 
>

Received on Wednesday, 6 August 2008 08:37:27 UTC