W3C home > Mailing lists > Public > uri@w3.org > December 1999

Re: WG ACTION: Resource Capabilities Discovery (rescap)

From: James M Galvin <galvin@elistx.com>
Date: Fri, 10 Dec 1999 08:33:16 -0500
Message-ID: <9912100833.aa19439@one.eListX.com>
To: rescap@cs.utk.edu
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <19435.944832795.1@one.elistx.com>

I thought this would have been sent here also but I guess I was

------- =_aaaaaaaaaa0
Content-Type: message/rfc822

Return-Path: <@mail.acm.org:ietf-123-owner@loki.ietf.org>
Received: from mail.acm.org by one.eListX.com id aa29366; 7 Dec 99 17:27 EST
Received: from loki.ietf.org (loki.ietf.org [])
	by mail.acm.org (8.9.3/8.9.3) with ESMTP id RAA35892;
	Tue, 7 Dec 1999 17:27:11 -0500
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id QAA04648
	for ietf-123-outbound.09@ietf.org; Tue, 7 Dec 1999 16:05:07 -0500 (EST)
Received: from ietf.org (odin.ietf.org [])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id PAA04627
	for <all-ietf@loki.ietf.org>; Tue, 7 Dec 1999 15:59:08 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20498
	for <all-ietf>; Tue, 7 Dec 1999 15:59:07 -0500 (EST)
Message-Id: <199912072059.PAA20498@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce: ;
Subject: WG ACTION:  Resource Capabilities Discovery (rescap)
Date: Tue, 07 Dec 1999 15:59:06 -0500
Sender: scoya@cnri.reston.va.us

A new working group has been formed in the Applications Area of the
IETF.  For additional information, contact the Area Directors or the WG

Resource Capabilities Discovery (rescap)
 Current Status: Active Working Group
     James Galvin <galvin@elistx.com>
     Ned Freed <ned+ietf-43@innosoft.com>
 Applications Area Director(s): 
     Keith Moore  <moore@cs.utk.edu>
     Patrik Faltstrom  <paf@swip.net>
 Applications Area Advisor: 
     Patrik Faltstrom  <paf@swip.net>
 Mailing Lists: 
     General Discussion:rescap@cs.utk.edu
     To Subscribe:      rescap-request@cs.utk.edu
     Archive:           ftp://cs.utk.edu/pub/rescap
Description of Working Group:

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 primary purpose of this service is to distribute information about
resources or services to the global Internet; as such, it is not
intended for dissemination of private information.  However, the group
will also consider whether there is a need for the query protocol to
include authentication, and thus permit administrators to restrict the
capabilities that are returned according to a locally specified
security policy.

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

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.  This
protocol will obviously require strong authentication. The working
group will also consider whether privacy services are necessary for the
update protocol, and include such services in the protocol if it finds
that they are necessary.

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

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

    (d) An existing administrative model and maintenance protocol will
        be used if feasible. Possible candidates for this include ACAP
        and LDAPv3.

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.

This group will collaborate with the ENUM working group to determine
the degree to which it is appropriate for the two efforts to share
technology or protocols when solving their respective problems.
 Goals and Milestones: 
   Jan 00       Submit Internet-Draft specifying service requirements and 
                design goals.                                                  

   Mar 00       Submit Internet-Draft specifying resolution protocol.          

   Sep 00       Submit Internet-Draft specifying administrative/update protocol
                requirements and design goals.                                 

   Dec 00       Submit Internet-Draft specifying administration/update 

------- =_aaaaaaaaaa0--
Received on Friday, 10 December 1999 12:10:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:01 UTC