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

RE: [Fwd: ACTION-818: Write some text for CT Appendix B.3]

From: Sean Patterson <SPatterson@Novarra.com>
Date: Fri, 25 Jul 2008 15:15:55 -0500
Message-ID: <24889886D84B794A9259323D7354CF3306B6FA1B@novarrainet2.internalnt.novarra.com>
To: "public-bpwg-ct" <public-bpwg-ct@w3.org>

I guess the bigger question here is why Jo has Francois listed in his
spam filter (or is the entire w3.org domain?).  :-) :-)

> -----Original Message-----
> From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org]
> On Behalf Of Jo Rabin
> Sent: Friday, July 25, 2008 6:34 AM
> To: public-bpwg-ct
> Subject: [Fwd: ACTION-818: Write some text for CT Appendix B.3]
> 
> 
> Just a quick note to thank Francois for his contribution, and to
explain
> why I did not acknowledge it when publishing the last draft, and why
his
> text did not make it into the document.
> 
> Well. It's all a terrible mistake. I found it in my spam folder this
> morning.
> 
> Huge apologies to Francois for this terrible insult. In the interests
of
> leaving the document stable before the LC resolution next Thursday,
> Francois has agreed that we can review B.3 later. Any changes we make
to
> it (post last call) won't be substantive (as it is an example) so
won't
> affect progress on the Rec track.
> 
> Jo
> -------- Original Message --------
> Subject: ACTION-818: Write some text for CT Appendix B.3
> Resent-Date: Wed, 23 Jul 2008 13:48:09 +0000
> Resent-From: public-bpwg-ct@w3.org
> Date: Wed, 23 Jul 2008 15:47:32 +0200
> From: Francois Daoust <fd@w3.org>
> To: public-bpwg-ct <public-bpwg-ct@w3.org>
> 
> 
> Hi,
> 
> This is my contribution for Appendix B.3.
> 
> It's a bit long, but it's also the longest scenario we have, I guess.
> Jo, feel free to adjust the wording as necessary for this to be
> considered as real English ;-)
> 
> Francois.
> 
> 
> -----
> Steps 1 to 8 are an example of a series of events that may lead a
proxy
> to choose to optimize its interactions with a Web Site by sending
> requests with altered headers directly.
> Steps 9 to 12 detail how a server may advise the proxy that the
> optimization is not valid for all resources, and the behavior of the
> proxy on receipt of such information.
> Steps 13 to 16 explain the behavior of the proxy for subsequent
requests.
> 
> 1. The user requests resource P on a Web Site S.
> 2. The proxy intercepts the request, and requests resource P with
> original headers.
> 3. The server does not vary its representations for resource P,
> determines that the available representation does not meet e.g. the
> original Accept header, and returns an HTTP Status 406 Not Acceptable
> response.
> 4. The proxy receives the unacceptable response, and re-requests
> resource P with altered headers.
> 5. The server returns the representation of resource P compatible with
> the altered headers.
> 6. The proxy parses the response, may apply transformation if needed
and
> possible, and forwards the response to the user.
> 7. The user browses the response and clicks on a link to resource Q.
> 8. The proxy intercepts the request, determines (by unspecified means)
> that resource Q is on the same Web Site S as resource P, remembers the
> unacceptable response it received for the request on resource P, and
> requests resource Q directly with altered headers.
> 
> 9. The server has available different representations of resource Q
> based on the User-Agent and Accept headers, and returns the
> representation of resource Q adapted to the altered headers served
with
> an HTTP Vary header set to "User-Agent, Accept".
> 10. The proxy detects the HTTP Vary header, and re-requests resource Q
> with original headers.
> 11. The server returns the representation of resource Q adapted to the
> original headers.
> 12. The proxy parses the response, may apply transformation if needed
> and possible, and forwards the response to the user.
> 
> 13. The user browses the response and clicks on another link to
resource
> Z.
> 14. The proxy intercepts the request, determines (by unspecified
means)
> that resource Z is on the same Web Site S as resources P and Q,
> remembers that the server varies its representations for resource Q,
and
> requests resource Z with original headers.
> 15. The server has available different representations of resource Z
> based on the User-Agent and Accept headers, and returns the
> representation of resource Z adapted to the altered headers served
with
> an HTTP Vary header set to "User-Agent, Accept".
> 16. The proxy parses the response, may apply transformation if needed
> and possible, and forwards the response to the user.
> -----
> 
Received on Friday, 25 July 2008 20:15:29 UTC

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