W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > April 2008

Re: New draft 1h of Content Transformation Guidelines - Candidate for FPWD

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Fri, 04 Apr 2008 15:50:16 +0200
To: Jo Rabin <jrabin@mtld.mobi>
Cc: public-bpwg-ct <public-bpwg-ct@w3.org>
Message-Id: <1207317016.5148.280.camel@localhost>

Le jeudi 03 avril 2008 à 17:34 +0100, Jo Rabin a écrit :
> there are still plenty of editorial comments where the Task Force
> requests input or has concerns.

My comments on (some of) the editorial notes (which again shouldn't hold
it from moving to FPWD):
* "The BPWG requests feedback on the degree to which it is necessary to
distinguish between Content Transformation proxies that interact with
user agents using HTTP, and other types of arrangements [...]"
-> I think we should note that some of the guidelines may apply to other
types of content transformation, but stay clear from widening the scope
of the document

* "The BPWG is also considering the possible use of other techniques,
such as [POWDER] [...]"
-> I think this should be part of the "Future work" appendix

* "The BPWG notes that the use of allow and disallow lists is common
practice, but that it is usually impractical for content providers to
affect their entries in such lists and that it is difficult for
operators to maintain such lists accurately."
-> is that really an editorial note? sounds like a "normal" note to me.

* "The principle behind this is that it is consistent with the
operation, for example, of CSS, where the user may override a content
provider's presentation choice".
-> same here

* " POWDER would provide an additional and potentially more definitive
means ascertaining server preferences."
-> same here, with a link to the future work section :)

* "The BPWG is studying heuristics for determining when a response with
a 200 Status should be treated as a response with a 406 Status"
-> I think we shouldn't bother with defining heuristics there, unless
someone has already a good idea of what they could be.

* "Further discussion is needed on the fact that this technique can
cause two requests for the same resource. It is noted that GET is
supposed to be "idempotent" i.e. not change the state of the server,
however, it is also noted that there are circumstances in which GET must
be used for such purposes, e.g. following a link from email."
- idempotent is different from not change the state of the server;
idempotent means roughly doing twice the request won't cause two
separate operations; GET is supposed to both be idempotent and not
change the state of the resource
- I don't think there is any case where GET must be used (even when
following a link from email) for non-idempotent operations, although
clearly we can't ignore the fact that it frequently is.
- presumably, if the proxy analyses the response and determines that it
wasn't successful, the request didn't successfully change the state of
the server

* "The BPWG notes that some transforming proxies issue duplicate
requests as a matter of course in order to compare responses. This
practice may specifically be deprecated in a future revision of this
-> I'm not sure if this is meant to say that this may deprecated before
the doc reaches REC, or in a new version altogether; if the former, it
would be helpful to have more context on why, if the latter, I suggest
turning it into a regular note.


> [1]
> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080403
Received on Friday, 4 April 2008 13:51:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:29 UTC