>Date: Fri, 12 Feb 1999 13:30:49 -0800 (PST)
>From: Ned Freed <Ned.Freed@innosoft.com>
>Subject: Charter take 4
> Resource Capabilities Discovery Working Group
>Chairs: Ned Freed and Jim Galvin
>A variety of resource identifiers have been widely deployed on the Internet as
>a means of identifying various resources, services, and destinations. However,
>a means of attaching a set of attributes or characteristics to a given
>identifier and subsequently assessing those attributes or characteristics has
>not been specified and deployed.
>A particularly important resolution service of this general type is one which,
>when given a mail address identifying a particular mail recipient, will return
>a series of attributes describing the capabilities of that recipient. This
>differs from a directory service in that no searching or other advanced query
>operations are involved.
>The first task of this working group will be to define a general resolution
>protocol that will translate resource identifiers to a list of attributes.
>minimum the service must be capable of returning mail recipient
>described above, but ideally the service should also handle more general
>capability and characteristics discovery.
>The second task of this working group will be to define an administrative
>and update protocol that can be used to set up and maintain the
>resolution protocol accesses.
>The service resulting from the combination of these two protocols must
>(0) The resolution protocol must be highly scalable, as the intent is to
> deploy it very widely.
>(1) Resolution protocol and server overhead must be very low, as some
> applications will make very heavy use of it.
>(2) Identifiers input to the resolution service must be formatted as
> Uniform Resource Identifiers (URIs) containing one or more DNS domains.
> Note that mail addresses can be presented as mailto: URIs to meet this
>(3) Facilities to support inheritance within the attribute store will
> be essential, as the number of identifiers may be very large.
> mechanisms must be provided by which administrators can set default
> values for members of their administrative domains.
>(4) Existing protocols will be profiled for use as part of this service
> whenever possible rather than developing new protocols. In particular:
> (a) The DNS must be used as the first step in the resolution service,
> This is because all the URIs under consideration here contain a DNS
> domain and the DNS is already properly delegated.
> (b) Existing DNS record types such as SRV and NAPTR will be used if
> feasible, to ease deployment.
> (c) A lightweight resolution protocol may be defined by this working group
> if no existing protocol proves to be suitable.
> (d) An existing administrative model and maintenance protocol will be
> used if feasible. Possible candidates for this include ACAP and
> LDAPv3. The protocol and security model by which a user can update
> his or her own attributes must be covered.
>The means to register and extend the set of attributes must be specified.
>However, specification of actual attributes needed by various applications of
>this service is outside of the scope of this working group.
> Mar 1999 Hold first meeting.
> May 1999 Submit Internet-Draft specifying service requirements and design
> Jun 1999 Submit Internet-Draft specifying resolution protocol.
> Jul 1999 Submit Internet-Draft specifying administrative/update protocol
> requirements and design goals.
> Aug 1999 Submit Internet-Draft specifying administration/update protocol.
> Dec 1999 Submit resolution and administration/update protocols to area
> directors for IETF last call.
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
INTERNET Mail & IFAX : email@example.com