Re: [apps-discuss] [alto] Review of draft-ietf-alto-protocol-11.txt

Ben Niven-Jenkins <ben@niven-jenkins.co.uk> Thu, 03 May 2012 06:59 UTC

Return-Path: <ben@niven-jenkins.co.uk>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B141221F8601; Wed, 2 May 2012 23:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level:
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JnybRZW3fik; Wed, 2 May 2012 23:59:32 -0700 (PDT)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF6621F85F8; Wed, 2 May 2012 23:59:32 -0700 (PDT)
Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.3]) by mail4.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1SPq02-0003n0-OA; Thu, 03 May 2012 07:58:51 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
In-Reply-To: <CA+cvDaYUt+T2mpk5ijSvR3onyoeYPbjUnyZhXhUC_3J45QJQmw@mail.gmail.com>
Date: Thu, 03 May 2012 07:59:28 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A05467E6-0C38-40E3-B0C0-2207F05A882C@niven-jenkins.co.uk>
References: <CA+9kkMB4nUayYO3q8ydj477jh9NM8oZyXAQ5k-NsRN=KHjb3cA@mail.gmail.com> <2DE7DDDA-6621-4E56-BD3D-1173833E672B@niven-jenkins.co.uk> <CA+9kkMApj1dPNn+0Uiz9iRPBhk3Px9kj-nP+Z+UGsjxoqY82eg@mail.gmail.com> <98BA299A-18E0-412C-A005-754F336E1620@niven-jenkins.co.uk> <CADOmCZXkF=Qc46x7+00KmB+y2q4Rm6xku2Q40YBQtsp4QeuqQQ@mail.gmail.com> <30166A91-3C02-48F7-8C3B-179DA770138C@niven-jenkins.co.uk> <4DC76AEC-2DCE-4DE4-B92C-C37F160DA7FF@niven-jenkins.co.uk> <CA+cvDaYUt+T2mpk5ijSvR3onyoeYPbjUnyZhXhUC_3J45QJQmw@mail.gmail.com>
To: Richard Alimi <rich@velvetsea.net>
X-Mailer: Apple Mail (2.1084)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Cc: Richard Alimi <ralimi@google.com>, draft-ietf-alto-protocol.all@tools.ietf.org, alto <alto@ietf.org>, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [alto] Review of draft-ietf-alto-protocol-11.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 May 2012 06:59:33 -0000

Rich,

On 3 May 2012, at 06:22, Richard Alimi wrote:

> On Wed, May 2, 2012 at 12:29 PM, Ben Niven-Jenkins
> <ben@niven-jenkins.co.uk> 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
>>> apps-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>> 
>> _______________________________________________
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto