Subject: Fwd: 44th IETF: BOFs - RESCAP

From: James Rafferty <[email-masked]>
Date: Tue, 09 Mar 1999 16:54:12 -0500

Folks, 

As noted below, there will be a BOF next week on resource capabilities
(RESCAP).   

This is the new name for what we have previously called Mailcap.   

This work promises to produce mechanisms for querying of capabilities and 
capabilities reporting among other things and it could become an important
future part of the Internet fax infrastructure once it emerges.   

So, I encourage people in the fax community to attend the meeting and
participate in the work to follow.   

Regards, 

James

>To: IETF-Announce: ;
>cc: [email-masked]
>Subject: 44th IETF: BOFs - RESCAP, REMBOOT
>Date: Tue, 09 Mar 1999 06:54:02 -0500
>From: Steve Coya <[email-masked]>
>
>
>Resource Capabilities Discovery BOF (rescap)
>
>Monday, March 15 at 1530-1730
>=============================
>
>Chairs: James M Galvin <[email-masked]>
>        Ned Freed <[email-masked]>
>
>DESCRIPTION:
>
>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.

>    (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.
>
>AGENDA:
>
>Charter review/bashing (20 mins)
>Query protocol requirements (30 mins)
>Administrative/update protocol requirements (30 mins)
>Use of existing protocols for administration/update (10 mins)
>
>==========================================================
*------------------------------------------------*
James Rafferty			
President, Human Communications LLC	
12 Kevin Drive			
Danbury, CT  06811-2901		
USA					
Voice/Fax:  +1-203-746-4367
Email/Internet Fax:  [email-masked]
	 [email-masked]
     [email-masked]

HC Web Site:  http://www.humancomm.com  
*---------------------------------------------------