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
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Our website uses cookies on your device to give you the best user experience. By using our website, you agree to the placement of these cookies. To learn more, read our privacy policy. Read Privacy Policy