Re: [apps-discuss] Aggregated service discovery

William Mills <wmills@yahoo-inc.com> Mon, 18 June 2012 20:56 UTC

Return-Path: <wmills@yahoo-inc.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 1C39821F85F3 for <apps-discuss@ietfa.amsl.com>; Mon, 18 Jun 2012 13:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.536
X-Spam-Level:
X-Spam-Status: No, score=-17.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
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 aFTI2RNC5Rxm for <apps-discuss@ietfa.amsl.com>; Mon, 18 Jun 2012 13:56:49 -0700 (PDT)
Received: from nm28-vm1.bullet.mail.ne1.yahoo.com (nm28-vm1.bullet.mail.ne1.yahoo.com [98.138.91.35]) by ietfa.amsl.com (Postfix) with SMTP id EBB7421F85FB for <apps-discuss@ietf.org>; Mon, 18 Jun 2012 13:56:48 -0700 (PDT)
Received: from [98.138.90.55] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jun 2012 20:56:45 -0000
Received: from [98.138.89.171] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jun 2012 20:56:45 -0000
Received: from [127.0.0.1] by omp1027.mail.ne1.yahoo.com with NNFMP; 18 Jun 2012 20:56:45 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 148424.8059.bm@omp1027.mail.ne1.yahoo.com
Received: (qmail 68287 invoked by uid 60001); 18 Jun 2012 20:56:44 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1340053004; bh=0rWXWYagcpX+8jwSK+ReqksEQ+YPBQXkrGrSHlL0Phc=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FMoB2GpuvwB+ckzjPMuSxuc4Dn8cmpPT7x5AMaE5dGoOY1bH2b16pVqJkYKPTRlqm+7RINm50+3hgb//es9nTofuK+FUuOkS9kHLbTowc2JuMrcf7mP7SjsI0gp1UIOTv1TzdJ6om9Sjyf9dXQH+oIwSnyTNzPoIGjTn0AvzPB4=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KGxJcvng2/7/iY/u5kZ8TRs9ngkZG+7fB/9zdkY3T8cFq9qSJx7PUI6Whm40TLuf8Nd7jyEiXdVu2iupzrCsJaH9x0KWpsZ4hCi7Wg8qnI5q5/cI8FUkiuyQzmtGH9Z3UZTrhMjJbj3wo7OfEupVUu/EdTAoSaWA+49jFDCJlHY=;
X-YMail-OSG: RzwVk5MVM1li99dnxDCMx3AgWtNPEg.6MI4ipSJAse21C3Y nQp2NHCWrAr4Rgg5LJEiWxIhosk.QPB3rFPqKixuVn7AO4eCsTUIBupeTuys gyOawf1.C5utqlAGcEUzeGNVYuplPra9MPAxFd09pdxiWUvi6I3yNQnDPn3x y5s7K4pKPh5m8ZjwZY1SPYoNOATLTGqzERtJXUi1epgk8KbuF5u4SgZ4jUOb R3tEYSDtZK0VTrJdxZLJun.B3kq7fLiVhebhd7HD5o9aOWWIpcA0pSNeV3Zg E4ctm.5Yx6Q.oo9pbZVpshWt1hnt1DotHPppugtBCodpQYu1afoPRDX51tKa KqEqAwm7j7cXeqXsuhUZU97NdhktYQTtPURdBQANLDTC3ti6HaK8pUsj1iNz KPqjRmNl4p2BBheAK8_Znl6JrY4YG1fwwTfcM6S1Ut.7Zn8k_oLUYVPF8.9R ZXXfgcrKW_x0Dbdpww4mO.6brgQ9FnrHO7TjdMZwmBlSfrNdxYCdfIGfntNz hDfjsOFeAx0P5lc3zqmAs2sGR0qJkCWf5YOI1CA01rKMVmfMnUMInEk8HWB_ KAOSn7Frj1a.0IvVujLUfkg8l2bHAP.W6sgK2MdFN4oAfA1bxwHXbarvpduy 7LEp3byzSZJCboSx6WW03_SWfOv4FYeSV_xERVDxjLLYACRQdiMWjEzFG2ow PPl5JgfCOxaWObpqM8PSzsL1LyVZHoG1KQSnhy6vnsCvx21ZsCvJorDtQzHo jivC2y6mE2C_T7d0DduQMdYbscN.079ChfX4HxuheVrX6HXD7YD.jyobPsef C1G2_31DWb_RR65FVPAhUGMHMBMFpl25D57HN26P_PRFbkNr1sm35JTPhUZH a4zL7S34N1E5ar9E-
Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Mon, 18 Jun 2012 13:56:44 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.120.356233
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> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> <1340046923.34140.YahooMailNeo@web31806.mail.mud.yahoo.com> <027001cd4d8f$48e260f0$daa722d0$@packetizer.com>
Message-ID: <1340053004.56116.YahooMailNeo@web31805.mail.mud.yahoo.com>
Date: Mon, 18 Jun 2012 13:56:44 -0700
From: William Mills <wmills@yahoo-inc.com>
To: "Paul E. Jones" <paulej@packetizer.com>, 'Peter Saint-Andre' <stpeter@stpeter.im>
In-Reply-To: <027001cd4d8f$48e260f0$daa722d0$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-551393103-286670863-1340053004=:56116"
Cc: "apps-discuss@ietf.org" <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
Reply-To: William Mills <wmills@yahoo-inc.com>
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 20:56:55 -0000

What data elements does a generic service description need?  


    name:  a service name form http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml
    host:  hostname

    port:  a port number

Is the name here sufficient to convey protocol and such things as SSL?  I think so, if we are using well known services.

    




>________________________________
> 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: Monday, June 18, 2012 1:16 PM
>Subject: RE: [apps-discuss] Aggregated service discovery
> 
>
>Bill,
> 
>Ah, I was confused.  I thought you were speaking of an IMAP link relation.  You did same URI scheme.
> 
>It is possible to have a link relation with no URI.  At least that is valid per the XRD spec.  The href is listed as optional:
>http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.link
> 
>In any case, one could return an IMAP URI or one could just return properties.  The choice is ours, but I do tend to think we would not want a URI scheme for POP3, IMAP, SMTP, etc.  It seems like overkill. 
> 
>This is why I preferred returning the mail configuration info using the “mailto” URI scheme.  This is an example where I would prefer it over “account” since “mailto” would refer to  a specific email address.  With that address, one could then discover the mail server configuration data as I showed it below.  I’d expect this to be populated by the email provider, not the user.
> 
>If we want to use the href field, then we could just use WebFinger to point to the email config document as I had initially proposed.  That was something like this:
> 
>{
>  "subject" : "mailto:paulej@packetizer.com",
>  "links" :
>  [
>    {
>      "rel" : "config-email",
>      "href" : "http://www.packetizer.com.com/config/email/?user=paulej"
>    }
>  ]
>}
> 
>So the client would first query the WebFinger server to get the above link relation (“config-email” or whatever) and then perform a second query to get the actual configuration parameters.  The document containing the configuration parameters would be in whatever format we want to define.
> 
>There are pros and cons with each approach.  I have no strong preference either way, but as I said, I’d love to see agreement on some universally agreed approach :)
> 
>Paul
> 
>From:William Mills [mailto:wmills@yahoo-inc.com] 
>Sent: Monday, June 18, 2012 3:15 PM
>To: Paul E. Jones; 'Peter Saint-Andre'
>Cc: 'Cyrus Daboo'; apps-discuss@ietf.org
>Subject: Re: [apps-discuss] Aggregated service discovery
> 
>Ah, I missed that nuance, that declared application data goes in "properties".
> 
>The "imap" scheme is listed in http://www.iana.org/assignments/uri-schemes.html and defined in http://www.rfc-editor.org/rfc/rfc5092.txt
> 
>I've been inquiring about the "related" link relation type, which seems semantically what we want at first glance.  It's not clear to me that you can define a link relation that does not have a uri?  That has only application data?  I don't think it's right to extend link relations to be an arbitrary data container, but requiring a URI scheme is going to be a lot of work for some things.  SMTP is the hard one right now, a hack for that might be a new relation and just put the postmaster mailto: link in the URI spot.  
> 
>I'm not inclined to try to encode arbitrary flags like login-required, I'd probably go as far as a well known service name and leave it there.
> 
>-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: Monday, June 18, 2012 11:22 AM
>>Subject: RE: [apps-discuss] Aggregated service discovery
>> 
>>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",
>>>        "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/
>>>>
>>>>
>>>>
>>>>
>>> 
>> 
>
>