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

Bill Roome <w.roome@alcatel-lucent.com> Thu, 28 July 2011 18:07 UTC

Return-Path: <w.roome@alcatel-lucent.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 9945E11E80D7 for <alto@ietfa.amsl.com>; Thu, 28 Jul 2011 11:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 moV1WKZ3thzh for <alto@ietfa.amsl.com>; Thu, 28 Jul 2011 11:07:18 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id ADEE111E807B for <alto@ietf.org>; Thu, 28 Jul 2011 11:07:18 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p6SI7DLG008417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2011 13:07:14 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6SI7DK1021880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Jul 2011 13:07:13 -0500
Received: from [135.104.34.106] (wdr-i7mbp.research.bell-labs.com [135.104.34.106]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p6SI7BaP009270; Thu, 28 Jul 2011 13:07:12 -0500 (CDT)
User-Agent: Microsoft-MacOutlook/14.12.0.110505
Date: Thu, 28 Jul 2011 14:07:12 -0400
From: Bill Roome <w.roome@alcatel-lucent.com>
To: "Thomson, Martin" <Martin.Thomson@commscope.com>, "alto@ietf.org" <alto@ietf.org>
Message-ID: <CA5718D4.63D2%w.roome@alcatel-lucent.com>
Thread-Topic: [alto] Info Resource Dirs, OPTIONS, 300 Multiple Choices and all that jazz ....
In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D2C3926@SISPE7MB1.commscope.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
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:07:19 -0000

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" ]
  }, {

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
>
>