Re: [apps-discuss] Aggregated service discovery

Andrew McMillan <> Thu, 24 May 2012 05:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85AE421F85FD for <>; Wed, 23 May 2012 22:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bZ41E5V37VhP for <>; Wed, 23 May 2012 22:04:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6BC5B21F85A7 for <>; Wed, 23 May 2012 22:03:59 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20BA820507 for <>; Thu, 24 May 2012 16:54:38 +1200 (NZST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id hnRZB+fd+IqH for <>; Thu, 24 May 2012 16:54:32 +1200 (NZST)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id A783F20506 for <>; Thu, 24 May 2012 16:54:32 +1200 (NZST)
Message-ID: <>
From: Andrew McMillan <>
Date: Thu, 24 May 2012 16:54:31 +1200
In-Reply-To: <>
References: <64C6DF43A866F40437AF4CC3@cyrus.local> <> <FF3DD3C9968F397579BC846A@cyrus.local> <>
Organization: Morphoss Ltd
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-I3Fqbf9rZbt3Nz+0Eok+"
X-Mailer: Evolution 3.2.2-1+b1
Mime-Version: 1.0
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 05:04:01 -0000

On Thu, 2012-05-24 at 10:27 +1000, Mark Nottingham wrote:
> 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?

Here's some real background, that I hope exposes some of the value that
this could offer...

I started working in a new company on the 2nd of May.  On arrival they
issued me with a username and a password that applied to the following

* CalDAV
* CardDAV
* Wiki
* Continuous Integration Testing system
* Problem tracking system
* Wireless LAN

and quite possibly a few more that I have yet to discover.  This is only
a relatively small company of about 150 staff, so I think it's pretty
stellar that they've managed to get all of these things singing and
dancing to the same username and password.

What they have not done, and what they *cannot* do, is to leave me to it
at that point, and I (or my software) will be able to figure everything
out for itself.

What I (and Cyrus and others from CalConnect) would like to see would be
a unification of the process of discovering these things.

Currently IANA maintains a registry of well-known ports, more recently
this has been extended to include SRV details, and there is also a
registry of .well-known URLs.  What is missing is a registry of any
parameters which apply to a service.

For example, to configure my SMTP service, I needed to know that it was
using port 465, that SSL was required, and that plain text
authentication was used in the SSL channel.  I have other mail servers I
connnect to on port 8487, with TLS, and although these variations on the
protocol are quite well-understood by the server and the client software
they tend to require a lot of poking and prodding from the client to
discover what is the right answer.  And without any ability to control
what is the preferred answer.

Having configured my SMTP service I then had to configure my IMAP,
CardDAV and CalDAV all in the one program.  Obviously that's a pretty
bad UI in that particular program, but it's far from unique.

I would like to see the sourcing of this information become the kind of
service that the operating system can offer to programs.  So that I can
configure the absolute minimum necessary information about my employer
(perhaps a domain name, a username and some authentication details) and
then as I configure (e.g.) my new XMPP application it offers me a list
of the ones it knows about by querying this central source "which
accounts have an associated XMPP service?".  When I select the account I
need enter nothing more, because the people who knew enough to set it up
in the first place have provided all of the relevant information as
client configuration parameters for that service, and my device has
discovered them.

If we are ever going to unify these kinds of things into a single place
in the operating system then having standards for a registry and a
framework for such service parameters will be what makes it possible.

Microsoft currently have an autodiscovery document which some people are
also using to provide information for non-Microsoft services in
non-standard ways.  I believe that Apple also have some internal
standards for retrieving centralised service parameters.

Neither of these approaches is a standard, and from what I have seen of
them they are somewhat built of duct tape and necessity and are not
appropriate for use other than to inform us of some of the parameters
that will be needed for some of the services.

In this sense I think that json-home would be an acceptable transport
for such information, but I would be uncomfortable (to say the least)
with trying to impose a pre-defined structure that would suit the
definition of all current and future services.  For this reason I think
that a per service registration of parameter names (perhaps with some
lightweight definition of associated data structures) would be the best

> 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?

The UI would be that I have three 'facts' and I would like to use these
to configure my $SERVICE.  I'd like to be able to supply the same three
facts for any service and hope that my software was able to hide further
complexity from me, ideally supplying them only once, and authorizing
each client on first use.

I believe those facts should be:

* A domain name
* A username
* Some authentication token(s)

Of course the domain name could be a URL, but in providing a standard
simplification a domain name offers the advantage that it is shorter
than a URL, and if we then define a set of standard transformations to
that domain name (such as an SRV lookup to discover protocols, hosts and
ports, and appending some standard path) we can save my mother a lot of
laborious and error-prone data entry on her smartphone.

					Andrew McMillan.

------------------------------------------------------------------------                     Porirua, New Zealand
Twitter: _karora                                  Phone: +64(272)DEBIAN
        Life is knowing how far to go without crossing the line.