Re: [alto] Info Resource Dirs, OPTIONS, 300 Multiple Choices and all that jazz ....

Ben Niven-Jenkins <ben@niven-jenkins.co.uk> Sat, 30 July 2011 18:22 UTC

Return-Path: <ben@niven-jenkins.co.uk>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EF721F8782 for <alto@ietfa.amsl.com>; Sat, 30 Jul 2011 11:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.554
X-Spam-Level:
X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPQeoE3A5vG4 for <alto@ietfa.amsl.com>; Sat, 30 Jul 2011 11:22:44 -0700 (PDT)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9048321F8781 for <alto@ietf.org>; Sat, 30 Jul 2011 11:22:44 -0700 (PDT)
Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.3]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1QnEBQ-0001IQ-9l; Sat, 30 Jul 2011 19:22:44 +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: <4E31CD25.2040308@pantheon.sk>
Date: Sat, 30 Jul 2011 19:22:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <69F33EB0-F002-4AB9-A754-872B74F8A753@niven-jenkins.co.uk>
References: <8B0A9FCBB9832F43971E38010638454F040D2C3929@SISPE7MB1.commscope.com> <CA57266A.6403%w.roome@alcatel-lucent.com> <8B0A9FCBB9832F43971E38010638454F040D2C392B@SISPE7MB1.commscope.com> <4E31CD25.2040308@pantheon.sk>
To: Robert Varga <robert.varga@pantheon.sk>
X-Mailer: Apple Mail (2.1084)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Cc: alto@ietf.org
Subject: Re: [alto] Info Resource Dirs, OPTIONS, 300 Multiple Choices and all that jazz ....
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/alto>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jul 2011 18:22:45 -0000

Robert,

On 28 Jul 2011, at 21:57, Robert Varga wrote:

> On 07/28/11 13:43, Thomson, Martin wrote:
>> On 2011-07-28 at 14:56:19, Bill Roome wrote:
>>> So the directory server DOES have an authoritative list of uris --
>> The IRD is not authoritative.  Sorry if you got an impression otherwise.  The directory is much like a DNS delegation - a hint from the parent domain that the child domain might be present at a particular place.
>> 
>> Keep in mind that the IRD might be on a different server to the individual resources.
> 
> Coming from HTTP, yes. Two questions arise:
> - who has the authoritative information? OPTIONS request seems to be the last instance, but it does not have to exist...

With HTTP the only thing that is truly authoritative for a given resource is the resource itself. That's just a fact of life when using HTTP.

> - could we not be a limit this a bit in exchange for greatly simplifying clients?
> 
> I really would like to see this simplified, as all this complexity does not seem to be founded on documented ALTO deployment use cases...

In general REST-ful design places some additional complexity on clients in order to reduce coupling between clients and servers and to provide server implementations with the flexibility to organise resources as they see fit.

As ALTO is using HTTP as a "transport" an ALTO server is within its rights to use any valid HTTP response as part of an ALTO response. I think what the draft is trying to do in some places is clarify some of the behaviour that is familiar to folks versed in HTTP but may not be immediately obvious to someone who isn't to try and avoid situations where an ALTO server returns a valid HTTP response but the ALTO client implementer/implementations reaction is "WTF did I get that response?"

Ben