IPP> FYI: Fwd: First try at a charter for MAILCAP

IPP> FYI: Fwd: First try at a charter for MAILCAP

Richard Shockey rshockey at ix.netcom.com
Wed Jan 27 12:59:54 EST 1999


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  
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<



More information about the Ipp mailing list