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

Christian Amsüss <> Tue, 11 September 2018 13:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 984271294D0; Tue, 11 Sep 2018 06:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n0cTrsCcjRxv; Tue, 11 Sep 2018 06:11:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4809B12785F; Tue, 11 Sep 2018 06:11:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 3B473417B1; Tue, 11 Sep 2018 15:11:27 +0200 (CEST)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by (Postfix) with ESMTP id 2B8E336; Tue, 11 Sep 2018 15:11:26 +0200 (CEST)
Received: from ( [IPv6:2a02:b18:c13b:8010::71b]) by (Postfix) with ESMTPSA id C389443; Tue, 11 Sep 2018 15:11:25 +0200 (CEST)
Received: (nullmailer pid 13568 invoked by uid 1000); Tue, 11 Sep 2018 13:11:25 -0000
Date: Tue, 11 Sep 2018 15:11:25 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <>
Cc: Jim Schaad <>, 'Core' <>
Message-ID: <>
References: <009901d4495b$194c4f30$4be4ed90$>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99"
Content-Disposition: inline
In-Reply-To: <009901d4495b$194c4f30$4be4ed90$>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [core] draft-hartke-core-stateless
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Sep 2018 13:11:35 -0000

Hello Klaus,

On Mon, Sep 10, 2018 at 04:07:48PM -0700, Jim Schaad wrote:
> Section 3.1 - I am not sure that I agree that the option should be unsafe to
> forward.  As long as a client and a server agree to deal with the option
> then it does not matter what any intermediate proxies might do.  Changing
> this modifies 3.2.2 as well

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)

Either way, one could add that a proxy is free to take responsibility of
the Extended-Token itself, make a note to insert it into the response,
and forward the request without any Extended-Token, relieving the origin
server of the responsibility to deal with the critical option. (I figure
that any non-constrained proxy would want to do that, as it limits the
way a Extended-Token request can fail).

Best regards

I shouldn't have written all those tank programs.
  -- Kevin Flynn