Fwd: MAILCAP Charter take 4

Fwd: MAILCAP Charter take 4

Richard Shockey rshockey at ix.netcom.com
Wed Feb 24 16:13:29 EST 1999


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 at innosoft.com>
>Subject: Charter take 4
>To: mailcap at cs.utk.edu
>List-Unsubscribe: <mailto:mailcap-request at 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 at ix.netcom.com
eFAX 815.333.1237  
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<



More information about the Ifx mailing list