Re: [Aggsrv] updated charter proposal

Cyrus Daboo <cyrus@daboo.name> Wed, 27 February 2013 16:10 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: aggsrv@ietfa.amsl.com
Delivered-To: aggsrv@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20D321F8611 for <aggsrv@ietfa.amsl.com>; Wed, 27 Feb 2013 08:10:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.536
X-Spam-Level:
X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNpCbh2dvanp for <aggsrv@ietfa.amsl.com>; Wed, 27 Feb 2013 08:10:20 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id DBF6F21F8545 for <aggsrv@ietf.org>; Wed, 27 Feb 2013 08:10:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 764963E2A5E3; Wed, 27 Feb 2013 11:10:19 -0500 (EST)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMJaexLKSoHM; Wed, 27 Feb 2013 11:10:18 -0500 (EST)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id CBC373E2A5D0; Wed, 27 Feb 2013 11:10:17 -0500 (EST)
Date: Wed, 27 Feb 2013 11:10:14 -0500
From: Cyrus Daboo <cyrus@daboo.name>
To: "Paul E. Jones" <paulej@packetizer.com>, 'Peter Saint-Andre' <stpeter@stpeter.im>, aggsrv@ietf.org
Message-ID: <B9DFC9C22213DCD410DB3586@caldav.corp.apple.com>
In-Reply-To: <01f701ce13ab$a9def660$fd9ce320$@packetizer.com>
References: <5127BC9B.8000203@stpeter.im> <01f701ce13ab$a9def660$fd9ce320$@packetizer.com>
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=2681
Subject: Re: [Aggsrv] updated charter proposal
X-BeenThere: aggsrv@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Aggregated Service Discovery \(aggsrv\)" <aggsrv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aggsrv>, <mailto:aggsrv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aggsrv>
List-Post: <mailto:aggsrv@ietf.org>
List-Help: <mailto:aggsrv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aggsrv>, <mailto:aggsrv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2013 16:10:20 -0000

Hi Paul,

--On February 25, 2013 at 5:58:44 PM -0500 "Paul E. Jones" 
<paulej@packetizer.com> wrote:

> I'm confused.  How is what is being described different than what
> WebFinger can do? From what I can tell, what is missing is just the
> definition of "rel" and "properties" values for WebFinger.  That would be
> a good focus for the group.
>
> Do we want to define another new protocol that is so similar?

Will you be in Orlando to provide input to the BoF?

It does look like webfinger could be a viable solution - and indeed I see 
you have an example in the webfinger spec of auto-configuration of an email 
client. Maybe it is sufficient for aggsrv to standardize the appropriate 
properties for services, and semantics of priority, grouping, and security 
requirements.

What I might do is try taking the examples in the spec I wrote and see what 
they would look like in terms of webfinger.

That said, I have some questions:

1) Security - it still seems to me that there is a fundamental difference 
in security "contexts" here. In particular, the aggsrv information must 
only be given out to the actual "owner" of the account. The webfinger spec 
does have a section on access control, aggsrv would need to have much 
stronger language. At the very least I think you should change Section 3.3 
of webfinger to include an example of an authenticated HTTP request and 
point out in the text that authentication is required.

2) If no rel= parameter is provided in the URI, is the webfinger server 
required to return all information for the target resource= value? It seems 
to me that aggsrv information should not be returned by "default" (i.e., 
when there is no rel=) but rather should only be returned by an explicit 
request for it (with a very specific rel=).

3) Links - one of the things we want to avoid is having aggsrv clients 
having to follow lots of links to get all the relevant data - that would 
pretty much eliminate one of the key performance enhancements we are 
looking to get with the new protocol over current best practice.

4) One of the simplest aspects of aggsrv is that it is trivial to setup a 
"static" document with service information and deploy that on the 
well-known URI. That significantly lowers the barrier to entry and makes 
the likelihood of deployment much greater. I am not sure that level of 
simplicity could be achieved with webfinger - at the very least it looks 
like the JRD response has to contain the "subject" member which echoes the 
resource= value. Whilst that could trivially be accomplished by, for 
example, string substitution in a PHP script it does imply additional 
overhead to deploy.

-- 
Cyrus Daboo