#########################
>X-Sender: JRafferty@postoffice.worldnet.att.net
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
>Date: Wed, 27 Jan 1999 11:38:14 -0500
>To: Ietf-Fax <ietf-fax@imc.org>
>From: James Rafferty <jrafferty@worldnet.att.net>
>Subject: Fwd: First try at a charter for MAILCAP
>X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id
>IAA20782
>Sender: owner-ietf-fax@imc.org
>List-Archive: <http://www.imc.org/ietf-fax/mail-archive/>
>List-Unsubscribe: <mailto:ietf-fax-request@imc.org?body=unsubscribe>
>
>Folks,
>
>The "mailcap" charter discussions have started.
>
>This work is likely to be of interest to the Fax WG, since it is targeted
>toward providing a mechanism for accessing capabilities lists for a URL, such
>as a Mailto: address.
>
>A copy of the first charter draft is attached.
>
>I encourage interested members from the Fax WG to sign up for the mailcap
>mailing list and join in the fun. This work is likely to spawn some parallel
>activities in our WG, to match up the emerging protocol work with our fax
>schema needs going forward.
>
>The Mailing list is
><Mailcap@cs.utk.edu>; to subscribe, send to <Mailcap-request@cs.utk.edu>
>with SUBSCRIBE in the body.).
>
>Regards,
>
>James
>
>
>
>
>>Date: Mon, 25 Jan 1999 00:35:24 -0800 (PST)
>>From: Ned Freed <Ned.Freed@INNOSOFT.COM>
>>Subject: First try at a charter for MAILCAP
>>To: mailcap@cs.utk.edu
>>List-Unsubscribe:
><<mailto:mailcap-request@cs.utk.edu%3FSubject=unsubscribe>mailto:mailcap-req
>uest@cs.utk.edu?Subject=unsubscribe>
>>
>> Messaging Capabilities Discovery Working Group
>> (MAILCAP)
>>
>>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
>>identifier 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 goal of this working group is to define a general resolution service that
>>will translate resource identifiers to lists attributes. At a minimum the
>>service must be capable of addressing the mail capabilities problem described
>>above, but ideally the service should also handle more general capability and
>>characteristics discovery.
>>
>>Any service developed by this working group must fulfill the following
>>requirements:
>>
>>(0) It must be highly scalable, as the intent is to deploy it very widely.
>>
>>(1) Protocol and server overhead must be very low, as some applications of
>> such a service will make very heavy use of it.
>>
>>(2) Identifiers input to this service must be formatted as Uniform Resource
>> Identifiers (URIs). 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.
>>
>>(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 this service, at least
>> for any URI which contains a DNS domain. This is because the DNS
>> is already properly delegated.
>> (b) Existing DNS record types such as SRV and NAPTR will be
>> used when feasible, to ease deployment.
>> (c) A lightweight query 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
>> specified if at all possible. 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.
>>
>>(5) Specification of the attributes needed by applications of this service is
>> outside of the scope of this working group. Note, however, that some
>> discussion of the sorts of attributes such a service needs to be
>> able to store may be appropriate. In particular, the means to extend
>> the set of attributes must be specifies.
>>
>>Goals:
>>
>> Mar 99 Hold first meeting
>>
>> xxx yy Submit Internet-Draft specifying service requirements and design
>> goals
>>
>> xxx yy Submit Internet-Draft specifying service
>>
>*------------------------------------------------*
>James Rafferty
>President, Human Communications LLC
>12 Kevin Drive
>Danbury, CT 06811-2901
>USA
>Voice/Fax: +1-203-746-4367
>Email/Internet Fax: JRafferty@worldnet.att.net
> J_Rafferty_HC@compuserve.com
> jrafferty@humancomm.com
>
>HC Web Site: http://www.humancomm.com
>*---------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<