IFX Mail Archive: Fwd: MAILCAP Charter take 4

Fwd: MAILCAP Charter take 4

Richard Shockey (rshockey@ix.netcom.com)
Wed, 24 Feb 1999 15:13:29 -0600

During todays IPP telecon there was some interest in the MAILCAP BOF that
is underway.

>Date: Fri, 12 Feb 1999 13:30:49 -0800 (PST)
>From: Ned Freed <Ned.Freed@innosoft.com>
>Subject: Charter take 4
>To: mailcap@cs.utk.edu
>List-Unsubscribe: <mailto:mailcap-request@cs.utk.edu?Subject=unsubscribe>
>
> Resource Capabilities Discovery Working Group
> (RESCAP)
>
>Chairs: Ned Freed and Jim Galvin
>
>Abstract:
>
>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
resource
>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.
At a
>minimum the service must be capable of returning mail recipient
capabilities as
>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
model
>and update protocol that can be used to set up and maintain the
information the
>resolution protocol accesses.
>
>The service resulting from the combination of these two protocols must
meet the
>following requirements:
>
>(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
> requirement.
>
>(3) Facilities to support inheritance within the attribute store will
> be essential, as the number of identifiers may be very large.
Specifically,
> 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.
>
>Goals:
>
> Mar 1999 Hold first meeting.
>
> May 1999 Submit Internet-Draft specifying service requirements and design
> goals.
>
> 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.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
Fax 314.918.9015
INTERNET Mail & IFAX : rshockey@ix.netcom.com
eFAX 815.333.1237
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<