Re: [webfinger] Automated Service Configuration now uses webfinger

Gonzalo Salgueiro <gsalguei@cisco.com> Tue, 09 July 2013 16:34 UTC

Return-Path: <gsalguei@cisco.com>
X-Original-To: webfinger@ietfa.amsl.com
Delivered-To: webfinger@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4768221F9E94 for <webfinger@ietfa.amsl.com>; Tue, 9 Jul 2013 09:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.339
X-Spam-Level:
X-Spam-Status: No, score=-10.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 Pr2FmzA3NGg8 for <webfinger@ietfa.amsl.com>; Tue, 9 Jul 2013 09:33:58 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 4963C21F9DB4 for <webfinger@ietf.org>; Tue, 9 Jul 2013 09:33:57 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r69GXuwK006011 for <webfinger@ietf.org>; Tue, 9 Jul 2013 12:33:56 -0400 (EDT)
Received: from dhcp-64-102-154-205.cisco.com (dhcp-64-102-154-205.cisco.com [64.102.154.205]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r69GXt8u015054; Tue, 9 Jul 2013 12:33:55 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Gonzalo Salgueiro <gsalguei@cisco.com>
In-Reply-To: <C76BB7412D784BB9C44707C0@caldav.corp.apple.com>
Date: Tue, 09 Jul 2013 12:33:55 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D1FAD6F5-1C6B-44DA-B5E3-54DEC7818043@cisco.com>
References: <F23E5FFF11431C634EC5CA18@caldav.corp.apple.com> <036001ce7c5c$38d87b70$aa897250$@packetizer.com> <C76BB7412D784BB9C44707C0@caldav.corp.apple.com>
To: Cyrus Daboo <cyrus@daboo.name>
X-Mailer: Apple Mail (2.1508)
Cc: Paul Jones <paulej@packetizer.com>, webfinger@ietf.org
Subject: Re: [webfinger] Automated Service Configuration now uses webfinger
X-BeenThere: webfinger@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the Webfinger protocol proposal in the Applications Area <webfinger.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webfinger>, <mailto:webfinger-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/webfinger>
List-Post: <mailto:webfinger@ietf.org>
List-Help: <mailto:webfinger-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webfinger>, <mailto:webfinger-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2013 16:34:03 -0000

On Jul 9, 2013, at 9:54 AM, Cyrus Daboo <cyrus@daboo.name> wrote:

> Hi Paul,
> 
> --On July 9, 2013 at 12:24:35 AM -0400 "Paul E. Jones" <paulej@packetizer.com> wrote:
> 
>> I believe for all examples we've considered with WF so far, there was no
>> need for the client to perform any manipulation on the URI for the
>> specific link relation.  The examples in this document are the first to
>> do that.  Is there a reason?  Can I persuade you to put the user-specific
>> URL right into the WebFinger response?
> 
> Yes, that seems like a better approach.

Agreed.
> 
> One question that has come up is whether webfinger should be the only HTTP service config document discovery mechanism. One suggestion has been to have a separate .well-known resource for direct access to the document. My feeling is that at this point I think we should stick solely with webfinger - partly to help promote use of webfinger itself, but also because there might be a whole bunch of other useful information that webfinger could provide. e.g. the service config client might also want to get the user's vCard in addition to service information and that could be accomplished in a single webfinger lookup. I will try adding an example to the spec to illustrate that.

An example would help. In this case, Webfinger's flexibility to discover info of any kind is a big advantage and should be highlighted. Our experiences with Webfinger dictate that simplicity is key to widespread adoption, so IMO restricting to just Webfinger as a discovery framework seems more implementation-friendly.  

Thanks for the updates to the doc.  It is looking much better.

--G

> 
> -- 
> Cyrus Daboo
> 
> _______________________________________________
> webfinger mailing list
> webfinger@ietf.org
> https://www.ietf.org/mailman/listinfo/webfinger
>