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

Bill Roome <w.roome@alcatel-lucent.com> Thu, 28 July 2011 14:35 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 42BE821F8B29 for <alto@ietfa.amsl.com>; Thu, 28 Jul 2011 07:35:28 -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 ZC3+q76KFigq for <alto@ietfa.amsl.com>; Thu, 28 Jul 2011 07:35:27 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6AB21F8BF8 for <alto@ietf.org>; Thu, 28 Jul 2011 07:35:26 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p6SEZP2x005490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <alto@ietf.org>; Thu, 28 Jul 2011 09:35:26 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6SEZPWU022462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <alto@ietf.org>; Thu, 28 Jul 2011 09:35:25 -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 p6SEZNTQ028249 for <alto@ietf.org>; Thu, 28 Jul 2011 09:35:24 -0500 (CDT)
User-Agent: Microsoft-MacOutlook/14.12.0.110505
Date: Thu, 28 Jul 2011 10:35:24 -0400
From: Bill Roome <w.roome@alcatel-lucent.com>
To: alto@ietf.org
Message-ID: <CA56EBEC.6368%w.roome@alcatel-lucent.com>
Thread-Topic: Info Resource Dirs, OPTIONS, 300 Multiple Choices and all that jazz ....
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Subject: [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 14:35:28 -0000

Section 7.6.2, Encoding of Information Resource Directory:

   "Each entry MUST indicate a URI that either directly provides the
   indicated Information Resource, or responds to a HTTP OPTIONS request
   which provides an Information Resource Directory with entries of
   additional Information Resources.

   "If an ALTO Client makes a GET or POST request to a URI that does not
   directly provide an indicated Information Resource, the ALTO Server
   MUST either reply with an HTTP 300 status code ("Multiple Choices")
   and an Information Resource Directory in the HTTP response¹s entity
   body, or indicate an appropriate HTTP status code. Note that in
   general, it is preferred that ALTO Clients use HTTP OPTIONS requests
   to discover additional Information Resources."

Here's my philosophy about protocol designs: client-server protocols
should be designed to simplify the client. If that pushes work onto the
server, tough! The goal is to simplify the client.

So what's the problem with those paragraphs? Consider the first. That says
the server has two distinct choices. How can a client discover WHICH
choice the server made? "Try it and find out."

Please! That's an insult to client implementors. That's a clear case of
designing to simplify the server, at the expense of the client.

Furthermore, this means a client must use three techniques to get the
information from a info directory:
  * A GET request to the primary directory URI,
  * An OPTIONS request to a multiple-type URI, or
  * A "300 Multiple Choices" error response to a GET or POST.

   
So what's my suggestion?  Drop those two paragraphs completely. Instead,
allow the information resource directory to contain an entry for ANOTHER
resource directory, with additional services. The media-type would be
application/alto-directory+json, of course. Eg,

    }, {
       "uri" : "http://custom.alto.example.con/extra-dictionary",
       "media-types" : [ "application/alto-directory+json" ]
    }, {

   
Then if a client wants to explore those services, it can do a GET on that
URI.

And for those who think the original specification is necessary -- the
OPTIONS and 300 response and all that -- now that we've had a bake-off,
how many servers actually implemented those options? How many clients
supported them?

	- Bill Roome