Re: [apps-discuss] Aggregated service discovery

Mark Nottingham <> Thu, 24 May 2012 00:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E0BB11E8091 for <>; Wed, 23 May 2012 17:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.399
X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Fx5hBEA0Jya for <>; Wed, 23 May 2012 17:27:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BC17E11E808E for <>; Wed, 23 May 2012 17:27:21 -0700 (PDT)
Received: from (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id C28DC22E1F4; Wed, 23 May 2012 20:27:12 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Mark Nottingham <>
In-Reply-To: <FF3DD3C9968F397579BC846A@cyrus.local>
Date: Thu, 24 May 2012 10:27:09 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <64C6DF43A866F40437AF4CC3@cyrus.local> <> <FF3DD3C9968F397579BC846A@cyrus.local>
To: Cyrus Daboo <>
X-Mailer: Apple Mail (2.1278)
Subject: Re: [apps-discuss] Aggregated service discovery
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 May 2012 00:27:22 -0000

On 23/05/2012, at 10:55 PM, Cyrus Daboo wrote:

> Hi Mark,
> --On May 23, 2012 4:29:24 PM +1000 Mark Nottingham <> wrote:
>> If they're HTTP -
>> <>
> Of course we do want service discovery for non-HTTP protocols, LDAP, IMAP, Submission, POP3, XMPP etc. Now I could almost imagine having non-http resource URIs in the json-home document for these other protocols, but I think that would be over stepping the intent of json-home.

As long as the relationship is expressed as a well-defined link relation, I don't see a problem. Of course, some of the HTTP-specific bits are going to be irrelevant, but there isn't anything requiring their use (maybe I should call it "http-hint"?).

>> Not yet convinced that well-known is needed for this yet; it's
>> effectively substituting a hostname for a full URL.
> Not sure what you mean by that. Obviously it is important to have just one jumping off point for this.

1) What's the use case driving having ONE location for it? Some of the advice in .well-known is to lump things that share a use case into a single URL, but to avoid having "kitchen sink" well-knowns, because they become unwieldy. Is there a strong use case for someone discovering ALL of the various (and often totally unrelated) services a site offers in one request?

2) Even if it's so, the question I'm asking is why that ONE identifier is a hostname instead of a URL. Are there some hidden UI requirements at work here, perhaps?


Mark Nottingham