The attached message may be of interest to members of this WG looking at
different forms of capabilities discovery and exchange.
#########################
>X-Sender: JRafferty at 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 at imc.org>
>From: James Rafferty <jrafferty at 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 at imc.org>List-Archive: <http://www.imc.org/ietf-fax/mail-archive/>
>List-Unsubscribe: <mailto:ietf-fax-request at 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 at cs.utk.edu>; to subscribe, send to <Mailcap-request at 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 at INNOSOFT.COM>
>>Subject: First try at a charter for MAILCAP
>>To: mailcap at cs.utk.edu>>List-Unsubscribe:
><<mailto:mailcap-request at cs.utk.edu%3FSubject=unsubscribe>mailto:mailcap-req
>uest at 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 at worldnet.att.net>J_Rafferty_HC at compuserve.com>jrafferty at 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 at ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<