Re: [alto] Info Resource Dirs, OPTIONS, 300 Multiple Choices and all that jazz ....
Richard Alimi <rich@velvetsea.net> Thu, 28 July 2011 18:25 UTC
Return-Path: <richard.alimi@gmail.com>
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 1A8C922800E for <alto@ietfa.amsl.com>; Thu, 28 Jul 2011 11:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.956
X-Spam-Level:
X-Spam-Status: No, score=-2.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 Sm4umf7+MpPt for <alto@ietfa.amsl.com>; Thu, 28 Jul 2011 11:25:44 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7417D22800D for <alto@ietf.org>; Thu, 28 Jul 2011 11:25:44 -0700 (PDT)
Received: by iye7 with SMTP id 7so3786023iye.31 for <alto@ietf.org>; Thu, 28 Jul 2011 11:25:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=0oF9pQXYvWnGvnL4ksDjY1w9Y0dLHnYdE9nMO9PlSmE=; b=t9tyhxh65V2b9Z1rbV5J+GabICoaJcBbpsQHeusKLQLnWvKEpCYZPP9yFMVxUuTlT0 eYNdVfgMX2NAlrpE6g8HL94a/oVDB266Is6pG4lL3Llmpby9q6Rj/frI9LYH7gK2hskE CR4K4HhtudVSw85nRryuh02zEPTis7G9Irdek=
Received: by 10.231.119.216 with SMTP id a24mr254294ibr.58.1311877543128; Thu, 28 Jul 2011 11:25:43 -0700 (PDT)
MIME-Version: 1.0
Sender: richard.alimi@gmail.com
Received: by 10.231.114.156 with HTTP; Thu, 28 Jul 2011 11:25:23 -0700 (PDT)
In-Reply-To: <CA5718D4.63D2%w.roome@alcatel-lucent.com>
References: <8B0A9FCBB9832F43971E38010638454F040D2C3926@SISPE7MB1.commscope.com> <CA5718D4.63D2%w.roome@alcatel-lucent.com>
From: Richard Alimi <rich@velvetsea.net>
Date: Thu, 28 Jul 2011 11:25:23 -0700
X-Google-Sender-Auth: tBG_ZAeXKV71eXAeeBJV9ByT2_8
Message-ID: <CA+cvDabOXedt2QV3CEWXx_X5yxgFJj6pqvqa4vqqakALDvOuwg@mail.gmail.com>
To: Bill Roome <w.roome@alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "alto@ietf.org" <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: Thu, 28 Jul 2011 18:25:45 -0000
On Thu, Jul 28, 2011 at 11:07 AM, Bill Roome <w.roome@alcatel-lucent.com> wrote: > I understand; I sometimes have that affect on people! > > And yes, allowing a directory to identify other directories is > sub-optimal. But it's useful when the entity providing the resource > directory knows there's another server, but does not have the > authoritative answer for exactly what services that server provides. > Hence, "Sorry client, but ya better get the real information from this > guy." > > Actually, here's my proposal in more detail. Each entry in the resource > directory would have one -- AND ONLY ONE! -- media type, and 0 or 1 accept > types. That's sufficient to define the service that entry provides and the > method it expects. > > This does NOT mean that a URI is limited to one service, though, because a > uri can appear in several entries. For example, the following means that > "map-service" responds to a GET and returns the full map, or to a POST and > returns a filtered map: > > }, { > "uri" : "http://foobar/map-service", > "media-types" : [ "application/alto-networkmap+json" ] > }, { > "uri" : "http://foobar/map-service", > "media-types" : [ "application/alto-networkmap+json" ] > "accepts" : [ "application/alto-networkmapfilter+json" ] > }, { One quick note. We already say that this one must indeed be split out: If an entry has an empty list for "accepts", then the corresponding URI MUST support GET requests. If an entry has a non-empty list for "accepts", then the corresponding URI MUST support POST requests. If an ALTO Server wishes to support both GET and POST on a single URI, it MUST specify two entries in the Information Resource Directory. Your point does apply in the general case though (e.g., networkmap and costmap at the same URI). Rich > > I'd also suggest that the resource directory MUST be authoritative (at > least within any Expires time). If the server cannot provide an > authoritative description of the detailed services, then it should have > give the uri of a directory server that can. > > > Given that, is OPTIONS still necessary? > > - Bill Room > > > > On 07/28/2011 13:19, "Thomson, Martin" <Martin.Thomson@commscope.com> > wrote: > >>On 2011-07-28 at 12:33:10, Bill Roome wrote: >>> I would appreciate it if you could explain how my proposal increases >>> the coupling between the client and the server. >> >>I apologise, your proposal did not increase coupling. 'twas the >>expression of philosophy that caused the allergic reaction. >> >>Thinking on it more, the technical proposal - that a directory can >>identify other directories - is perfectly fine. It's suboptimal, given >>that the first directory could just as easily include the second, but >>it's perfectly sound. >> >>There's a problem with resources that don't support GET, which is one of >>the cases where you get 300 responses and where you need OPTIONS >>requests. But the general guidance there is to avoid the creation of >>resources that don't do GET. >> >>--Martin >> >> > > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto >
- [alto] Info Resource Dirs, OPTIONS, 300 Multiple … Bill Roome
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Thomson, Martin
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Bill Roome
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Robert Varga
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Thomson, Martin
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Thomson, Martin
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Bill Roome
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Thomson, Martin
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Richard Alimi
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Bill Roome
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Thomson, Martin
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Robert Varga
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Richard Alimi
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Richard Alimi
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Richard Alimi
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Richard Alimi
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Richard Alimi
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Ben Niven-Jenkins
- Re: [alto] Info Resource Dirs, OPTIONS, 300 Multi… Thomson, Martin