Re: [apps-discuss] Looking at Webfinger

Mark Nottingham <mnot@mnot.net> Wed, 04 July 2012 22:37 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C539C11E807F for <apps-discuss@ietfa.amsl.com>; Wed, 4 Jul 2012 15:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.302
X-Spam-Level:
X-Spam-Status: No, score=-105.302 tagged_above=-999 required=5 tests=[AWL=-2.703, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VA7pStqFAqa for <apps-discuss@ietfa.amsl.com>; Wed, 4 Jul 2012 15:37:00 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9243111E8073 for <apps-discuss@ietf.org>; Wed, 4 Jul 2012 15:36:58 -0700 (PDT)
Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2F53422E257; Wed, 4 Jul 2012 18:37:02 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="iso-8859-1"
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAJu8rwUeAKEtAS-g6X3xJqyu-Xy6yQnfdeNj3mGC__D3zijwzA@mail.gmail.com>
Date: Thu, 05 Jul 2012 08:36:59 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>
References: <F80C8C9C-7AB8-4B7E-BFD2-4D69499D21A1@mnot.net> <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <CABP7RbfNXx8HtsRBcVf=AVaDTyg=xQYHWAyCkHWx1n+JBQ8=Zw@mail.gmail.com> <CAMm+Lwg20rfr=P66=vZadL8Ga5KDXmfizZE5v6dXiZMTvZKY=Q@mail.gmail.com> <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com> <CAMm+LwgM57++oqE-5meECxE0S=kU2kVHJLumyDSBciJ13QvuoA@mail.gmail.com> <CABP7RbctkibSKr6r_Ay34z4Wr67tU6qG5G5gLCZovGx_hWYHYQ@mail.gmail.com> <DF4591C5-A5AE-4D2A-BB3A-FF4DAFBBD98A@ve7jtb.com> <CABP7RbefS9Sy2m0GsiSx2VZopf78DhqU1fjfsDn5z926Q_--GA@mail.gmail.com> <CAJu8rwUeAKEtAS-g6X3xJqyu-Xy6yQnfdeNj3mGC__D3zijwzA@mail.gmail.com>
To: John Panzer <jpanzer@google.com>
X-Mailer: Apple Mail (2.1278)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jul 2012 22:37:02 -0000

On 05/07/2012, at 8:16 AM, John Panzer wrote:

> Just as a historical note.  The envisioned usage of host-meta was originally to avoid a specification which mandated a particular dynamic URL API at a particular /.well-known endpoint (because it may not be feasible to do that across all organizations and deployments).  The host-meta document itself would be highly cacheable and so wouldn't incur an additional network trip in the common case.
> 
> Having a 3xx redirect is a reasonable alternative that allows a similar escape hatch via something like mod_rewrite, albeit at the cost of needing an additional network trip each time.  Since a deployment can always avoid the 3xx redirect with additional dynamic plumbing behind the well-known endpoint, I don't think that's a horrible thing.
> 
> An application-level redirect would be almost equivalent to an HTTP redirect, but then there are two ways to do the same thing.  If _only_ an application-level redirect is allowed, then you have to have at least a minimal dynamic service at the well-known endpoint (no more mod_rewrite).  But the whole reason for this is to avoid the requirement for a dynamic service behind well-known...

"dynamic" and "static" are properties of the implementation, not the interface. HTTP doesn't require that any particular URL be "dynamic"; anything can, with the right metadata, be cached (and indeed, I've cached many, many things with the wrong metadata, because of silly site operators and their ideas about "dynamic").

Now, if people want to target a particular implementation that makes it easier to serve a particular style of URL without writing code, fine, but let's not confuse things.

E.g., a URL like

http://example.com/.well-known/user/bob

is easy to serve in pretty much any way you like with Apache.

I'm also going to push back on the "it may not be feasible to do that across all organizations and deployments" motivation. This is a race to the bottom. The trick is to make it accessible enough to get sufficient traction to pull everyone along, without pandering to *everyone*'s requirements.

Regards,

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