Re: [Aggsrv] updated charter proposal

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

Return-Path: <paulej@packetizer.com>
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 7C14221E80FE for <aggsrv@ietfa.amsl.com>; Mon, 25 Feb 2013 14:58:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.462
X-Spam-Level:
X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599]
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 X1oUtZ5qBhal for <aggsrv@ietfa.amsl.com>; Mon, 25 Feb 2013 14:58:47 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 170D621E8134 for <aggsrv@ietf.org>; Mon, 25 Feb 2013 14:58:44 -0800 (PST)
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 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; d=packetizer.com; 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" <paulej@packetizer.com>
To: "'Peter Saint-Andre'" <stpeter@stpeter.im>, <aggsrv@ietf.org>
References: <5127BC9B.8000203@stpeter.im>
In-Reply-To: <5127BC9B.8000203@stpeter.im>
Date: Mon, 25 Feb 2013 17:58:44 -0500
Message-ID: <01f701ce13ab$a9def660$fd9ce320$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQDwSaYLA9DbEJOVMCQUxjyWUnEXJppGwRsA
Content-Language: en-us
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: 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?

Paul

> -----Original Message-----
> From: aggsrv-bounces@ietf.org [mailto:aggsrv-bounces@ietf.org] On Behalf
> Of Peter Saint-Andre
> Sent: Friday, February 22, 2013 1:45 PM
> To: aggsrv@ietf.org
> Subject: [Aggsrv] updated charter proposal
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> http://trac.tools.ietf.org/wg/appsawg/trac/wiki/AggSrv 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
> https://stpeter.im/
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJRJ7ybAAoJEOoGpJErxa2pFMEQAJz0m+1dstov0tIwi7Qg1U7U
> mmUj5dRyNkRveyxjkEj6Ck6H396FziR023w1Qd3IpIn1WdM6Zol1CzMl59cbM8Cw
> yM33s5J2Bka4DwAfhFzXkTIG1DucwLBKjkIsiwglArqHfssEMo8vrPW3g0YZ00++
> lDVgIFJtnUfLdPq9eys1JpwH/htilXetcaglfjEFaabtCuHDCMu2PdZQ7CwhKuSP
> unnNHqELJSd1NHjZOXBuJhbq+pTJYl1MnMXbYbOHgTM96tCW9NwMA0S2R9WfZpyL
> bWwtbmsgy4vJ7Nv5BQt/BMnxei5ZsuRQAHb6G5vd9IuZVEdmgIFbRAeN4AKqasaw
> CZwLbTC387798BunfEBbPwptdilXx+lIpN+XbIRrBwt+XhEQFE1h2gVuk5woyO+Y
> 1kZlAYDVSjaIjieEabsoE/cYsvD2ItdhW7DoyarTpI/IBc9xniQHXPjrzWo4SVSb
> XFh53ouqAt3rTMLObbaTrwa2Vmg297Ksbj74Sl8kIKELsx/cfMZahn5VdLff/kAx
> ieurfO5A0VydYBWfu56xE8YBQN/Zzgljib3wIGmeHDE1cvm+BMlUkggmVVTUOR1B
> 3fIqA2mDauePvjGGXIfOAjnlAI2HYWES4Hduaddo2Gb5tADNUrdiiVxUbvZAMyod
> qmXi4JpGFcL0CLj0Ko5q
> =T6NV
> -----END PGP SIGNATURE-----
> _______________________________________________
> aggsrv mailing list
> aggsrv@ietf.org
> https://www.ietf.org/mailman/listinfo/aggsrv