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

"Thomson, Martin" <Martin.Thomson@commscope.com> Thu, 28 July 2011 18:16 UTC

Return-Path: <Martin.Thomson@commscope.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 6F48E11E80F1 for <alto@ietfa.amsl.com>; Thu, 28 Jul 2011 11:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.578
X-Spam-Level:
X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599]
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 emrf5KZ41OXr for <alto@ietfa.amsl.com>; Thu, 28 Jul 2011 11:16:09 -0700 (PDT)
Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 8952A11E80F0 for <alto@ietf.org>; Thu, 28 Jul 2011 11:16:09 -0700 (PDT)
X-AuditID: 0a0404e9-b7cc4ae00000074e-e5-4e31a7713862
Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 6D.7E.01870.177A13E4; Thu, 28 Jul 2011 13:16:17 -0500 (CDT)
Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 28 Jul 2011 13:16:08 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 29 Jul 2011 02:16:05 +0800
From: "Thomson, Martin" <Martin.Thomson@commscope.com>
To: Bill Roome <w.roome@alcatel-lucent.com>, "alto@ietf.org" <alto@ietf.org>
Date: Fri, 29 Jul 2011 02:16:03 +0800
Thread-Topic: [alto] Info Resource Dirs, OPTIONS, 300 Multiple Choices and all that jazz ....
Thread-Index: AcxNUTQxj7akgrpuSWKRUW+t2YUMHAAADCCw
Message-ID: <8B0A9FCBB9832F43971E38010638454F040D2C3929@SISPE7MB1.commscope.com>
References: <8B0A9FCBB9832F43971E38010638454F040D2C3926@SISPE7MB1.commscope.com> <CA5718D4.63D2%w.roome@alcatel-lucent.com>
In-Reply-To: <CA5718D4.63D2%w.roome@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
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:16:10 -0000

On 2011-07-28 at 14:07:12, Bill Roome wrote:
> 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.

That sounds reasonable, and it does resolve the problem that you don't know what combinations of request and response content type are supported.  However, it doesn't reduce the complexity of the complete model.

However, if you have a statement that if a resource is indicated with multiple, then it must support all combinations of requests.

Given that, the affect on an implementation that doesn't want to deal with this can be minimized if you are careful.

> I'd also suggest that the resource directory MUST be authoritative (at 
> least within any Expires time). 

Sadly, that's not possible.  Even if the directory and the indicated resource are on the same server, there is no guarantee.

> Given that, is OPTIONS still necessary?

Sadly, yes.  However, you are always free to not request it.  Similarly, I expect that clients will have to survive if a resource doesn't support it.

--Martin