Re: [apps-discuss] Aggregated service discovery

"Paul E. Jones" <paulej@packetizer.com> Mon, 18 June 2012 01:48 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 EF7A721F85C0 for <apps-discuss@ietfa.amsl.com>; Sun, 17 Jun 2012 18:48:18 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 wNo-hNPtkUgc for <apps-discuss@ietfa.amsl.com>; Sun, 17 Jun 2012 18:48:16 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0770821F85C5 for <apps-discuss@ietf.org>; Sun, 17 Jun 2012 18:48:15 -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 q5I1m5ri006329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Jun 2012 21:48:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1339984088; bh=pOcQPEVLpH7syymC4lZYWCDE6xSpWltRFIc2UT1X4DQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=e90AqNjzlxI7gRMwH8KP/7O8xCP4v7PKp6ckmmSVMekCrh+KhOOCOn2sD5YxMLcxQ eLPyocuNLHxXNcyFgaJH5sbUP8+SKcUYqnkVzXCEpWt+Zc+fmG9xBxQa2RfuCMIDOI 3iV9ptCfqZOX6TP5iYyFlvq/kwp0ydD5aHGopLeE=
From: "Paul E. Jones" <paulej@packetizer.com>
To: 'William Mills' <wmills@yahoo-inc.com>, 'Peter Saint-Andre' <stpeter@stpeter.im>
References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com>
In-Reply-To: <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com>
Date: Sun, 17 Jun 2012 21:48:07 -0400
Message-ID: <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0125_01CD4CD2.E3366B50"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQNYFRdarpUA3Z9l4mSBSKHTly568wGsYWTHAiB/MPYCgTB6NAGRuS9TAZsphI0CgPvwiZOJzEiA
Content-Language: en-us
Cc: apps-discuss@ietf.org
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: Mon, 18 Jun 2012 01:48:19 -0000

Bill,

 

My apologies for the belated reply.  I've been busy this week and got rather
behind on email.

 

I do not personally like using SRV records, either.  SRV records could work
for smaller domains, but I'm not sure that they're the best solution for
larger domains.  Personally, I would prefer putting users on specific
servers or server clusters and SRV records will not differentiate users. 

 

To use WebFinger to find one's IMAP, SMTP, or POP server, we could do as I
suggested in my email.  Now the question is what does one query?  Since
these three services are email, I'd suggest we query
"mailto:paulej@packetizer.com".  We could use another URI scheme (e.g.,
"acct:"), but mailto seems most appropriate given that you're seeking info
about mail services.

 

I provided an example earlier that would simply point to a config file with
server information.  We could do this directly via WebFinger like this:

 

GET /.well-known/host-meta?resource=mailto:paulej@packetizer.com

 

This query would then return something like this:

 

{

  "subject" : "mailto:paulej@packetizer.com",

  "links" :

  [

    {

      "rel" : "smtp-server",

      "properties" :

      {

        "host" : "smtp.packetizer.com",

        "port" : "587",

        "login-required" : "yes",

        "transport" : "starttls"

      }

    },

    {

      "rel" : "imap-server",

      "properties" :

      {

        "host" : "imap.packetizer.com",

        "port" : "993",

        "transport" : "ssl"

      }

    }

  ]

}

 

We would need to standardize the link relation values (smtp-server and
imap-server).  We would also need to document what the various properties
would be.  If you would like to create such a configuration document based
on WebFinger, I'd be happy to help out.  In any case, you can see that
WebFinger would serve quite nicely for conveying configuration information
given a user's email ID.

 

I'm not sure exactly what you would need for OAuth endpoints, but I would
suggest you make that a separate document since it is not mail related.  (At
least I assume it's not.  Even if it were, the mail server information and
OAuth information are still different animals.)

 

Paul

 

From: William Mills [mailto:wmills@yahoo-inc.com] 
Sent: Wednesday, June 13, 2012 7:32 PM
To: Peter Saint-Andre
Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org
Subject: Re: [apps-discuss] Aggregated service discovery

 

In my use case it's a service/server.

 

Not a terribly happy answer to say "DNS SRV records won't work for you, and
there is no other solution.".  By the same token I could ask "Why do we need
Webfinger and host meta at all if we have DNS SRV records?".

 

If XMPP uses SRV records for discovery, that's fine.  IMAP and outbound SMTP
services both lack a defined discovery method other than the ubiquitous
"service documentation".  Is there a compelling reason to pick DNS over WF
for this?  From the app developer point of view I don't want to have N ways
to discover M services.

 

-bill

 

 


  _____  


From: Peter Saint-Andre <stpeter@stpeter.im>
To: William Mills <wmills@yahoo-inc.com> 
Cc: Paul E. Jones <paulej@packetizer.com>; 'Cyrus Daboo' <cyrus@daboo.name>;
"apps-discuss@ietf.org" <apps-discuss@ietf.org> 
Sent: Wednesday, June 13, 2012 3:57 PM
Subject: Re: [apps-discuss] Aggregated service discovery


On 6/13/12 4:54 PM, William Mills wrote:
> As I said, I'm interested specifically in IMAP, SMTP and OAuth endpoints. 

What exactly is an "endpoint"? A client? An account? A server?

> As a data point, DNS SRV records are not controllable in many hosted
> domain models.

At the last XMPP Summit a few months ago, we learned that DNS SRV
records are unavailable in whole countries (e.g., Japan). That doesn't
mean we should define a replacement for DNS over HTTP. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/