Re: [apps-discuss] Aggregated service discovery

William Mills <> Wed, 13 June 2012 22:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0396D21F8595 for <>; Wed, 13 Jun 2012 15:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.474
X-Spam-Status: No, score=-17.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xZ3xDwNY07Pf for <>; Wed, 13 Jun 2012 15:17:23 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 71D1E21F8522 for <>; Wed, 13 Jun 2012 15:17:23 -0700 (PDT)
Received: from [] by with NNFMP; 13 Jun 2012 22:17:20 -0000
Received: from [] by with NNFMP; 13 Jun 2012 22:17:20 -0000
Received: from [] by with NNFMP; 13 Jun 2012 22:17:20 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 53447 invoked by uid 60001); 13 Jun 2012 22:17:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ginc1024; t=1339625840; bh=r+ga6vt6V+5YiuhLl+jkKfVTYIzYJxHdlEbajQRjCFU=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=fgHev3Arwniam2KUlvqWMx4gBuh4jOZAnQg6UJFbpiEUoMo0fxoxYAV20/2QyKqzEuCupwhX3ZF4jKZzEWimOl7tnF735gJop7sl7iYvBkCo20ViFmr9bLaYC7gm7QDmKeyUp8Xb3fzjbmb8L74gMccYoIo+R62znr/pEVAGEFs=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024;; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=cOP63KhDeFzixUe1hvXslQAJLE91dXr0nfHhE6rnDnkljL3Wfq997dvdHziWCFqT2yG/IiGpnmXHJVWnM1t1mOybhaFeF1YoTGLnJeCKwurIGLmFWIeqL0ytDMFQ3ShXJ04GtljrSmM470PIoGOQVOUM6N7255tocXTjBSr5Iaw=;
X-YMail-OSG: TVivSAEVM1k7qE1FI.vtMMpf0mTrsWsvWiY0d0yG0GmbyMJ pElQlev2zDjqGIGUeb2h8fD2EobRJAxJfRz4l6Fw0qIb2Ew4riKEGtsDlMis 1JsRJBZTAB0lBidZZxo4M1bJeGNBkqrSwyx3v6UgBpY2Ifhx6dCqLx0ImjJ8 gyWaoRSmVwrpeSZBdXNW.lylsX.St7k3NODktJYeCra41E2Ga02FIE4EO.ol yObexzQPcHVix2W6cn0GY7vlCIfnbb4xUWfOUuqIrNlXP8dAj9Ohz9LJkeMC inQ_pOilc_McyEdF.l1I_SybmVvfmxFm2c3O2bWwfcvCUgKZfYgbu_dP.Msd 5FmtEVIQzvrk_3VT6N6uCm6S80TGTYlafQwg7c0TLQxrOHl8wPScgf4SLEJb uX8E7ZlHHnnxg.mQilWdmuQI2zqigQf4oymt3D1FSlG463ziJP2CYryj1mCD uXV5HCBJpat9.8SG3xEUlAxVhMJhFLxrDk6l7iT03cY4zejZZX0W5TTH_hEF Q.uVOW5v2Cj8PMpcWIFDpcq3r2FGGiF.lNpwNoDOqxtdS493BMuWFwtQJQbt WRkQTTeAyfQ3GIAlIS7OVOv8fzjo79UYqe207_cGzcwiN4xcze0pSlC.dFTg fCmvoXGYXhU6W5esAFa4-
Received: from [] by via HTTP; Wed, 13 Jun 2012 15:17:19 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/
References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$>
Message-ID: <>
Date: Wed, 13 Jun 2012 15:17:19 -0700
From: William Mills <>
To: "Paul E. Jones" <>, 'Cyrus Daboo' <>, "" <>
In-Reply-To: <059c01cd39c8$f3d027c0$db707740$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1238014912-370352827-1339625839=:48148"
Subject: Re: [apps-discuss] Aggregated service discovery
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills <>
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Jun 2012 22:17:25 -0000

I was just thinking about this topic and found the thread in the archive.  I'm interested specifically in the use case of a client discovering IMAP and SMTP services along with OAuth endpoints.

XMPP, IMAP and POP all have URI schemes defined, though SMTP does not.  With things that already have a dedicated scheme for a service type would it make sense to use the "related" link type already defined?  Then the client looks for "related" links of the scheme they want to discover.

The "related" link type was registered as part of "Atom", but it seems to fit.

We still have to deal with SMTP for what I want.  DNS SRV records certainly also work, but I like a one-stop-shop.


> From: Paul E. Jones <>
>To: 'Cyrus Daboo' <>; 
>Sent: Thursday, May 24, 2012 9:19 AM
>Subject: Re: [apps-discuss] Aggregated service discovery
>I apologize for not replying sooner.
>I do believe WebFinger could be used to locate these services.  I wasn't
>aware of RFC 6186 (and rushed right out to add it to my domain), but
>WebFinger could be used to provide an even better level of granularity.  It
>exists now, so I'm not sure if one would want to migrate to WebFinger, but
>if it did I can imagine something like this:
>GET /.well-known/host-meta?
>  "subject" : "",
>  "links" :
>  [
>    {
>      "rel" : "config-email",
>      "href" : ""
>    }
>  ]
>The above document would include a link relation that refers to mail server
>configuration.  Querying the /config/email/ URI might return a JSON document
>like this:
>  {
>    "imaps" : "",
>    "smtp-submission" : ""
>  }
>(Note: this is a trivial example, whereas we'd probably need to indicate use
>of SSL, TLS, login requirements, etc.)
>It would accomplish something similar to SRV records, but provide a finer
>level of granularity to allow domain owners to assign users to different
>machines and specific configurations.
>> -----Original Message-----
>> From: []
>> On Behalf Of Cyrus Daboo
>> Sent: Tuesday, May 22, 2012 11:00 AM
>> To:
>> Subject: [apps-discuss] Aggregated service discovery
>> Hi folks,
>> Today many protocols define their own "service discovery" protocols (e.g.,
>> <>,
>> <>,
>> <>).
>> >From a client perspective, these each work fine individually. But more
>> often than not, a client device actually wants to be able to discover all
>> services a "service provider" has available or provisioned for the user.
>> i.e., a user expects email, calendar, contacts, IM, directory etc to be
>> setup in one step by the client, rather than having to go and setup each
>> service separately. Whilst a client can present a single UI for such an
>> "aggregated service discovery" it still has to go use separate discovery
>> protocols for each service. This is expensive - lots of separate DNS
>> lookups, etc.
>> Several proprietary systems offer and "aggregated service discovery"
>> protocol - in its simplest form a GET on a well known URI that returns an
>> XML document listing available services and other useful configuration
>> information.
>> It is time we had such a protocol for the IETF standard suite of
>> protocols.
>> In particular implementors involved in the Calendaring and Scheduling
>> Consortium are very keen to see a good solution to this problem. So I am
>> starting a discussion on this here to solicit some ideas about how best to
>> approach this, with a view to writing a draft.
>> The obvious, and simplest approach, is the HTTP GET on a .well-known URI
>> returning an XML or JSON document with a standard "schema".
>> Another possibility is to leverage the webfinger work. I'd like to hear
>> from webfinger experts as to whether a use case like this would be a
>> reasonable solution. Some concerns I have are the security "scope".
>> Obviously service discovery is something that a user does for themselves
>> and their service information should be private, which seems somewhat
>> contrary to the primary user case for webfinger whether other users are
>> looking up the information.
>> Security, simplicity and efficiency are the key goals for this protocol.
>> Comments, ideas?
>> --
>> Cyrus Daboo
>> _______________________________________________
>> apps-discuss mailing list
>apps-discuss mailing list