RE: New draft 1h of Content Transformation Guidelines - Candidatefor FPWD

Dom thanks and thanks also for your other one.

The reason they are editorial notes, is, in the main, that we haven't had time to agree them, though they have been discussed. I think we might find that time on the CT call on Tuesday providing the BPWG has enough time to reconsider any changes that result. 

I'd actually strongly prefer to include a POWDER based solution as part of the Rec. I appreciate that time is probably not on my side.

Jo


> -----Original Message-----
> From: Dominique Hazael-Massieux [mailto:dom@w3.org]
> Sent: 04 April 2008 14:50
> To: Jo Rabin
> Cc: public-bpwg-ct
> Subject: Re: New draft 1h of Content Transformation Guidelines -
> Candidatefor FPWD
> 
> 
> 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
> document."
> -> 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.
> 
> Dom
> 
> > [1]
> > http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-
> drafts/Guidelines/080403

Received on Friday, 4 April 2008 22:06:16 UTC