Re: [apps-discuss] Aggregated service discovery

"Paul E. Jones" <paulej@packetizer.com> Mon, 18 June 2012 18:23 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 5660921F84F0 for <apps-discuss@ietfa.amsl.com>; Mon, 18 Jun 2012 11:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 4ZjejUQTcfwA for <apps-discuss@ietfa.amsl.com>; Mon, 18 Jun 2012 11:22:59 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7263921F84E7 for <apps-discuss@ietf.org>; Mon, 18 Jun 2012 11:22:59 -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 q5IIMuHF002805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Jun 2012 14:22:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340043777; bh=s5lei3NN3dmXwFzTPAcnbniOfQ8PSLRY43B+Z/vSa8I=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=FF0MAhXE4LbEp70aSGhcFQIifVaoAWtbecmACHRL6CIxLyn4h/bAf1sEsjYEeXC1Z nf4U2aSunjr11UQCaHOUeXsm8+lT2fKprDxQohSrL0d+U7G52D5LV7SiLc2LEhvPaQ lVbFN83ysWxIh1hLRGhXdZh6gpCqsN7le1M/4cVw=
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> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com>
In-Reply-To: <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com>
Date: Mon, 18 Jun 2012 14:22:59 -0400
Message-ID: <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0229_01CD4D5D.DD3DE210"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQNYFRdarpUA3Z9l4mSBSKHTly568wGsYWTHAiB/MPYCgTB6NAGRuS9TAZsphI0CgPvwiQHAzgIyAdRbPCqTbklo8A==
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 18:23:01 -0000

Bill,

 

In the referenced draft below, I assume the “grant-types” and “token-types” should be contained inside a “properties”?  That is, I think you want this:

 

{

  "subject" : "acct:carol@example.com",

  "links" :

  [

    {

      "rel" : "oauth2-athorize",

      "href" : "http://login.example.com/oauth2/authorize"

    },

    {

      "rel" : "oauth2-token",

      "href" : "https://login.example.com/oauth2/token",

     "properties" :

      {

       "grant-types" : "code password",

        "token-types" : "bearer"

      }

    }

  ]

}

 

For auto-provisioning of email clients (which I understand was your goal), we can either define one link relation that points to a separate configuration document of some sort, or we define multiple link relations.  My previous example showed the single link relation and the email below shows use of multiple.  Both have pros and cons, but I tend to favor using multiple link relations, since this allows one to introduce new stuff without changing the one mail configuration file.  Also, it reduces the number of queries a mail client has to make to get config information.

 

You indicate that IMAP already has a defined URI.  Where is that defined?  I could not find it in the IANA link relations registry, so I assume it’s really a URI defined in a spec somewhere.  In any case, we could use URIs for these things (rather than defining single token link relation values and registering them).  I have no preference, but I would like an agreed approach to provisioning.  I hate configuring all the stuff manually on email clients. :-)

 

Paul

 

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

 

Paul, 

 

Thanks for the reply on this.  I do already have a separate doc for registering the OAuth specific relations, http://tools.ietf.org/id/draft-wmills-oauth-lrdd-01.html

 

I don't think I like the thought of having to register a new link type for every service, but that might be the right way.  IMAP already has a URI defined for example so if we use a more general link relation then the URI scheme details the type.  The tradeoff is whether you can look for a specific link-type or if you have to scan list elements for the URI type you need.

 

-bill

 

 


  _____  


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

 

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 <http://smtp.packetizer.com/> ",

        "port" : "587",

        "login-required" : "yes",

        "transport" : "starttls"

      }

    },

    {

      "rel" : "imap-server",

      "properties" :

      {

        "host" : "imap.packetizer.com <http://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/