Re: Request for advice

Mark Nottingham <mnot@mnot.net> Thu, 11 February 2016 00:33 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: wellknown-uri-review@ietfa.amsl.com
Delivered-To: wellknown-uri-review@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93541A8724 for <wellknown-uri-review@ietfa.amsl.com>; Wed, 10 Feb 2016 16:33:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 xoAFqD9J2qxB for <wellknown-uri-review@ietfa.amsl.com>; Wed, 10 Feb 2016 16:33:26 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D53D1A8722 for <wellknown-uri-review@ietf.org>; Wed, 10 Feb 2016 16:33:26 -0800 (PST)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 538C822E25F; Wed, 10 Feb 2016 19:33:23 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: Request for advice
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <56BB29B4.8090106@desy.de>
Date: Thu, 11 Feb 2016 11:33:21 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D9CE563-5FF8-4C6A-BF54-C928CCCC60E2@mnot.net>
References: <56BB29B4.8090106@desy.de>
To: Paul Millar <paul.millar@desy.de>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/wellknown-uri-review/KRnR1r3Pvo4houbU3hO5wm-Qwzw>
Cc: wellknown-uri-review@ietf.org
X-BeenThere: wellknown-uri-review@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Well-Known URI review list <wellknown-uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wellknown-uri-review>, <mailto:wellknown-uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wellknown-uri-review/>
List-Post: <mailto:wellknown-uri-review@ietf.org>
List-Help: <mailto:wellknown-uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wellknown-uri-review>, <mailto:wellknown-uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Feb 2016 00:33:28 -0000

Hi Paul,

> On 10 Feb 2016, at 11:14 pm, Paul Millar <paul.millar@desy.de> wrote:
> 
> Hi,
> 
> I am working within a small team devising a new HTTP-based protocol.  We hope to use a /.well-known URI and register this protocol with IANA.
> 
> The protocol involves the client issuing a POST request to the server and receiving some information back; i.e., this is not a lookup (GET or HEAD) request.
> 
> As I see it, there are two options:
> 
> a.	client issues POST requests directly to a well-known
> 	endpoint; e.g., /.well-known/<foo>
> 
> b.	client issues GET request to /.well-known/<foo-discovery>
> 	endpoint.  The response describes the location of <foo>.
> 	The client makes POST request to that URI.
> 
> Option a. has some advantages in terms of latency and reduced complexity; however, it seems from RFC 5785 that the latter option is more in line with the intended use of /.well-known.  Option b. is also the approach taken by most other registrants (e.g., OpenID-Configuration)
> 
> Would both approach be acceptable, or should we focus on option b. ?

(b) gives people who deploy more flexibility, in that they can direct clients to a different server, etc. This is especially helpful when you're expecting a POST, because if you want to redirect them, they'll have to retransmit the request body (unless both sides support expect/continue, which has proven problematic over the years).

It's true that this way requires an extra request, but the response can be cached. 

One question -- are you using a .well-known to enable someone to find out something about the host, or is it just a convenience? 

I.e., is it acceptable for your service to take a full URL as an input instead of a hostname? 

Cheers,


--
Mark Nottingham   https://www.mnot.net/