Re: [Aggsrv] updated charter proposal

["Paul E. Jones" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Peter Saint-Andre
> Sent: Friday, February 22, 2013 1:45 PM
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aggsrv