I would also recommend providing a reference rather than duplicating specification, so there is no possibility of conflict between this and the normative spec. -- David Harrington Internet Engineering Task Force (IETF) [email protected] +1-603-828-1401
On 5/2/12 11:59 PM, "Ben Niven-Jenkins" <[email protected]> wrote: >Rich, > >On 3 May 2012, at 06:22, Richard Alimi wrote: > >> On Wed, May 2, 2012 at 12:29 PM, Ben Niven-Jenkins >> <[email protected]> wrote: >>> >>>> As you asked so nicely, I wonder if the following (slightly wordy) >>>>change would address Ted's comment: >>>> >>>> OLD: >>>> Note that it is possible for an ALTO Server to employ caching for >>>>the >>>> response to a POST request. This can be accomplished by returning >>>>an >>>> HTTP 303 status code ("See Other") indicating to the ALTO Client >>>>that >>>> the resulting Cost Map is available via a GET request to an >>>>alternate >>>> URL (which may be cached). >>>> NEW: >>>> Note that it is possible for an ALTO Server to leverage caching HTTP >>>>intermediaries for responses to both GET and POST requests by >>>>including explicit freshness information (see Section 2.3.1 of >>>>[HTTPBIS Part6]). >>>> >>>> Caching of POST requests is not widely implemented by HTTP >>>>intermediaries, however an alternative approach is for an ALTO Server, >>>>in response to POST requests, to return an HTTP 303 status code ("See >>>>Other") indicating to the ALTO Client that the resulting Cost Map is >>>>available via a GET request to an alternate URL. HTTP intermediaries >>>>that do not support caching of POST requests could then cache the >>>>response to the GET request from the ALTO Client following the >>>>alternate URL in the 303 response (if the response to the subsequent >>>>GET request contains explicit freshness information). >>>> END >> >> This seems reasonable to me, except would it be appropriate to have >> this kind of document dependency? Would it be more appropriate to >> just reference RFC2616? > >Up to you. HTTPBIS is in the process of putting the HTTPBIS specs through >WG LC so there is light at the end of the tunnel for them popping out as >RFCs. I referred to the HTTPBIS document because it's easier to find an >appropriate reference but similar material is in 2616. > >>>> Ted went on to say: >>>>> Since cachability >>>>> is a major reason cited for the re-use of HTTP, some additional text >>>>> on the use cache control directives ("public" and "Max-age" seem >>>>> particularly important in this context) might also be useful. >>>> >>>> I wonder whether a reference to Section 3.2 of HTTPBIS Part6 would >>>>suffice? >> >> Once upon a time, we used to have more detail about how to use HTTP >> (caching in particular) in the ALTO Protocol draft itself. The >> recommendation at that point was to strip out the large majority of it >> and rely on the reference to the HTTP specs being sufficient. > >I seem to remember being one of the people saying to strip it out and >just provide a reference :-) > >Ben > >> >> That said, any pointers to help out implementers are fine with me as >> long as we don't to back to where we were before :) A concise hint or >> direct reference pointing to the cache control directives seems >> reasonable to me unless there are objections. >> >> Thanks for the feedback, >> Rich >> >>>> >>>> Ben >>>> >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >>> _______________________________________________ >>> alto mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/alto > >_______________________________________________ >alto mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
