Re: [apps-discuss] Aggregated service discovery

"Paul E. Jones" <paulej@packetizer.com> Thu, 24 May 2012 16:19 UTC

Return-Path: <paulej@packetizer.com>
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 BB55A21F8566 for <apps-discuss@ietfa.amsl.com>; Thu, 24 May 2012 09:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 EDLHopuGRwND for <apps-discuss@ietfa.amsl.com>; Thu, 24 May 2012 09:19:11 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B2BFB21F8562 for <apps-discuss@ietf.org>; Thu, 24 May 2012 09:19:11 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q4OGJ2mT018518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 May 2012 12:19:03 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1337876343; bh=GpmnBS2R5Esxmrh+m25cFlJ9c6+iDLpU9abQNGxD+uA=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=lL1uBYvBashrzAI++fBRPG3RjoXRdhnwA/kpulG3MYh/XuZ1d6jKHecyyM5M7CCxV a8QzGAC0myiov0T2mK0XVVowLm0MVZrODytImycy5jkbNh+ELK8ZbqIpEAJBCNtWKn 4SSh1MytUjo3AfpbS1/RjaCS5PIymM4Ngpt0fUg4=
From: "Paul E. Jones" <paulej@packetizer.com>
To: 'Cyrus Daboo' <cyrus@daboo.name>, apps-discuss@ietf.org
References: <64C6DF43A866F40437AF4CC3@cyrus.local>
In-Reply-To: <64C6DF43A866F40437AF4CC3@cyrus.local>
Date: Thu, 24 May 2012 12:19:10 -0400
Message-ID: <059c01cd39c8$f3d027c0$db707740$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQNYFRdarpUA3Z9l4mSBSKHTly5685PDVqvg
Content-Language: en-us
Subject: Re: [apps-discuss] Aggregated service discovery
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: Thu, 24 May 2012 16:19:12 -0000

Cyrus,

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?resource=mailto:paulej@packetizer.com

Returning...

{
  "subject" : "mailto:paulej@packetizer.com",
  "links" :
  [
    {
      "rel" : "config-email",
      "href" : "http://www.packetizer.com.com/config/email/?user=paulej"
    }
  ]
}

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" : "cluster23.imap.packetizer.com",
    "smtp-submission" : "smtp.packetizer.com"
  }

(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.

Paul

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
> On Behalf Of Cyrus Daboo
> Sent: Tuesday, May 22, 2012 11:00 AM
> To: apps-discuss@ietf.org
> Subject: [apps-discuss] Aggregated service discovery
> 
> Hi folks,
> Today many protocols define their own "service discovery" protocols (e.g.,
> <http://tools.ietf.org/html/rfc6186>,
> <https://datatracker.ietf.org/doc/draft-daboo-srv-caldav/>,
> <http://tools.ietf.org/html/rfc6125>).
> 
> >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@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss