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