Re: [Aggsrv] updated charter proposal

"Paul E. Jones" <> Mon, 25 February 2013 22:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C14221E80FE for <>; Mon, 25 Feb 2013 14:58:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.462
X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X1oUtZ5qBhal for <>; Mon, 25 Feb 2013 14:58:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 170D621E8134 for <>; Mon, 25 Feb 2013 14:58:44 -0800 (PST)
Received: from sydney ( []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id r1PMwe3o011696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Feb 2013 17:58:41 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=dublin; t=1361833121; bh=F8a5a9ZYxU8t1UFiH0ViauTKAd3Lna+GN9KYOMaV5FE=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=I2WVTmRiZyl/0ptmvova5pFq/h/0UZbNgG/f/fRk/+Aav0SnNW0NbiJyFwoiVgnAV kGL/L2ZwrqP1/RcpmMSt36eGoyS1lp4sxDae4q1bNSbAOTVJVY7CLW8+jwE5Z0NAxa 4ChXVPweVi+6xO1UVxirYQ4hFtEbJWqWjRYBzkA0=
From: "Paul E. Jones" <>
To: 'Peter Saint-Andre' <>,
References: <>
In-Reply-To: <>
Date: Mon, 25 Feb 2013 17:58:44 -0500
Message-ID: <01f701ce13ab$a9def660$fd9ce320$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Subject: Re: [Aggsrv] updated charter proposal
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Aggregated Service Discovery \(aggsrv\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Feb 2013 22:58:48 -0000

Peter, et al,

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?


> -----Original Message-----
> From: [] On Behalf
> Of Peter Saint-Andre
> Sent: Friday, February 22, 2013 1:45 PM
> To:
> Subject: [Aggsrv] updated charter proposal
> Hash: SHA1
> The proponents have sent me an updated charter for the aggsrv initiative.
> The text can be found below, and I've also updated
> accordingly.
> ###
> Aggregated Service Discovery Working Group
> Problem Statement:
> Service providers and enterprises commonly offer a variety of
> application services delivered over multiple protocols.  A user will
> often consume these services from several endpoints, requiring service
> discovery or manual configuration for each service at each endpoint.
> Some of these services leverage existing standards-based discovery, such
> as DNS, DHCP, or UDDI, while others may rely on some form of proprietary
> discovery.  Still others may not support any form of discovery,
> requiring the manual entry of service access information.
> As the quantity and variety of these services grow, it becomes
> increasingly onerous for administrators to manage the disparate
> discovery mechanisms, and burdensome on users to provide configuration
> where discovery is not supported.
> It is useful to first consider whether the issues described here might
> be addressable through the direct use or extension of existing discovery
> protocols.  DHCP [1], for example, is widely deployed and supports
> extension for the discovery of new types of services.  Many DHCP
> extensions already exist for the discovery of such services as DNS, NTP,
> NIS, LDAP, and others.  The DHCP protocol, however, is limited by a
> dependence on local network broadcast, lack of support for structured
> data, and an extension mechanism not intended for unregistered
> customization.  This, coupled with a relative dearth of application-
> level APIs supporting DHCP service-specific extensions, makes DHCP an
> unlikely solution for the issues we face here.
> Another option would be to leverage DNS through DNS-SD [2].  The DNS-SD
> extension is expressly designed to support Internet-scale service
> discovery using standard DNS queries and existing record types.
> However, it remains a significant limitation that the discovered data is
> global and cannot be made a function of information provided in the
> request.  For example, an enterprise with several IMAP servers, each
> servicing the same email domain but hosting different subsets of
> employees, could not employ DNS-SD for email service discovery using
> that one domain.  It is also important to consider that we wish to
> establish a solution that is broadly and uniformly usable across a wide
> array of platforms and environments.  It is an unfortunate fact that
> browser-based clients often lack the necessary APIs and trust necessary
> to make explicit DNS queries for particular types of records.
> In terms of new ideas, similar discovery standardization efforts already
> under way include WebFinger [3], which is intended to address
> generalized discovery for any type of URI identifiable resource, and
> Simple Web Discovery [4], which is more specifically related to the
> discovery of services.  The former provides an interesting framework
> within which aggregated service discovery could operate, however by
> itself there is insufficient guidance and structure to address the
> specific needs of service discovery use cases.  Simple Web Discovery, on
> the other hand, while expressly intended for the discovery of services,
> tends to focus specifically on service location and is not well suited
> for aggregate discovery of dissimilar service types.
> Objectives:
> The Aggregated Service Discovery working group will standardize an
> extensible protocol supporting the discovery of multiple services with a
> single operation and with limited initial information (e.g. a well-known
> URL, or email address).  A central objective shall be the establishment
> of a protocol and message format which may be readily adopted by a wide
> variety of endpoints, minimizes client startup time by reducing network
> roundtrips, and takes into consideration the various technical
> challenges faced by clients in the wild, including security, firewalls,
> same-origin policies and limited platform APIs.
> Equally important, the working group will focus on ease of deployment,
> and support for both standard and non-standard services types.  The
> barriers to adoption should be made as low as possible without
> compromising the security and integrity of the discovery process.
> In the interest of meeting the above objectives, this working group will
> develop a core message format based on JSON, and protocol based on HTTP
> and REST (using [5] as the starting point).  Initially, the group will
> focus on a draft defining an extensible aggregated discovery document
> structure, and operations for discovery document retrieval.
> The group will not necessarily define new formats and protocols, and
> will consider existing technologies where possible.
> Potential follow up work may include an additional draft for defining a
> complimentary protocol for local area network service discovery.
> This draft would define a means by which aggregated discovery documents
> may be obtained by clients in a fully automated manner, possibly based
> on mDNS or DHCP.  However, the group would need to recharter in order to
> add such a draft to its deliverables.
> Milestones:
> Jun 2013 - Accept protocol and format document as Working Group item Oct
> 2013 - Start Working Group Last Call on protocol and format document Dec
> 2013 - Submit protocol and format document to IESG
> References:
> [1] RFC 2131 - DHCP
> [2] RFC 6763 - DNS-SD
> [3] draft-ietf-appsawg-webfinger
> [4] draft-jones-simple-web-discovery
> [5] draft-daboo-aggregated-service-discovery
> ###
> Peter
> - --
> Peter Saint-Andre
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird -
> iQIcBAEBAgAGBQJRJ7ybAAoJEOoGpJErxa2pFMEQAJz0m+1dstov0tIwi7Qg1U7U
> mmUj5dRyNkRveyxjkEj6Ck6H396FziR023w1Qd3IpIn1WdM6Zol1CzMl59cbM8Cw
> yM33s5J2Bka4DwAfhFzXkTIG1DucwLBKjkIsiwglArqHfssEMo8vrPW3g0YZ00++
> lDVgIFJtnUfLdPq9eys1JpwH/htilXetcaglfjEFaabtCuHDCMu2PdZQ7CwhKuSP
> bWwtbmsgy4vJ7Nv5BQt/BMnxei5ZsuRQAHb6G5vd9IuZVEdmgIFbRAeN4AKqasaw
> CZwLbTC387798BunfEBbPwptdilXx+lIpN+XbIRrBwt+XhEQFE1h2gVuk5woyO+Y
> 1kZlAYDVSjaIjieEabsoE/cYsvD2ItdhW7DoyarTpI/IBc9xniQHXPjrzWo4SVSb
> XFh53ouqAt3rTMLObbaTrwa2Vmg297Ksbj74Sl8kIKELsx/cfMZahn5VdLff/kAx
> ieurfO5A0VydYBWfu56xE8YBQN/Zzgljib3wIGmeHDE1cvm+BMlUkggmVVTUOR1B
> 3fIqA2mDauePvjGGXIfOAjnlAI2HYWES4Hduaddo2Gb5tADNUrdiiVxUbvZAMyod
> qmXi4JpGFcL0CLj0Ko5q
> =T6NV
> _______________________________________________
> aggsrv mailing list