Re: [core] draft-hartke-core-stateless

Jim Schaad <ietf@augustcellars.com> Tue, 11 September 2018 15:40 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C034131045; Tue, 11 Sep 2018 08:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dOPmKhb2d8j; Tue, 11 Sep 2018 08:40:02 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972FF130F46; Tue, 11 Sep 2018 08:40:02 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 11 Sep 2018 08:35:39 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Klaus Hartke' <klaus.hartke@ericsson.com>, 'Christian Amsüss' <christian@amsuess.com>, draft-hartke-core-stateless@ietf.org
CC: 'Core' <core@ietf.org>
References: <009901d4495b$194c4f30$4be4ed90$@augustcellars.com> <20180911131124.GA5521@hephaistos.amsuess.com> <6131e11057e84ec3882d487b32965856@ericsson.com>
In-Reply-To: <6131e11057e84ec3882d487b32965856@ericsson.com>
Date: Tue, 11 Sep 2018 08:39:34 -0700
Message-ID: <010201d449e5$a586f290$f094d7b0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGCaMHPcnJIPK10eKvsaWNjM2LnMwLfWkYSAbsrDlylaiVqkA==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/XOKiOfcL8VmAAi2Lui4zmQBu2hw>
Subject: Re: [core] draft-hartke-core-stateless
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Sep 2018 15:40:09 -0000


> -----Original Message-----
> From: Klaus Hartke <klaus.hartke@ericsson.com>
> Sent: Tuesday, September 11, 2018 6:31 AM
> To: Christian Amsüss <christian@amsuess.com>; draft-hartke-core-
> stateless@ietf.org
> Cc: Jim Schaad <ietf@augustcellars.com>; 'Core' <core@ietf.org>
> Subject: RE: [core] draft-hartke-core-stateless
> 
> Christian Amsüss wrote:
> > I also think that the option can be safe to forward -- as long as the
> > origin server replies with the "option part" of the token, the proxy
> > will return the full original request identity (token plus option part) back.
> 
> Right, proxies could simply forward the extended tokens in the requests and
> responses generated by clients and servers. But proxies also generate
> responses themselves, e.g., from cached responses or in case of errors (5.02,
> 5.04). We don't want clients to receive the extended token from another client
> or no extended token at all when a proxy does not support the option.
> 
> I can't think of any way to get sensible behavior without the proxies
> understanding what's going on.

If the option is part of the cache key for proxies which do not understand the option then you will not have that problem.

Jim

> 
> Klaus