NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 26-Nov-97
Chair(s):
Roland Hedberg <Roland.Hedberg@umdac.umu.se>
Patrik Faltstrom <paf@swip.net>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Applications Area Advisor:
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Mailing Lists:
General Discussion:find@bunyip.com
To Subscribe: majordomo@bunyip.com
In Body: in body: subscribe find
Archive: ftp://ftp.bunyip.com/pub/mailing-lists/find
Description of Working Group:
On the Internet, several more or less localized directory services have evolved over the last couple of years. Also 2 global directory services have been deployed, X.500 and Whois++. To be able to find something or someone, one needs to know what service to use, and what server to query.
One step towards the solution of this problem is to define one and only one common indexing protocol which all directory services can use when passing indexing information. When a user queries one server it should be possible for that user to get a referral to another server and even another service, if the two servers have exchanged index information.
For this to work, one common protocol must be developed. The idea is to expand on the Centroid ideas used by Whois++, to allow it to be used for other services than Whois++. At the very least, a localized service should be able to be polled by an indexing server using the Common Indexing Protocol (CIP). To be specific, three specifications are to be presented:
o An interface spec, where one says how you present a query and what the referrals you get back look like
o A server interface spec, where one says that the CIP will be able to include information presented in this format
o An engine spec, which specifies that this is how one support the functionality using Centroids a la Whois++.
The task for this working group is to create the Common Indexing Protocol so it is (1) usable for other distributed directory services such as X.500, (2) allows the use of non-distributed directory services such as CCSO in the distributed directory service, and (3) addresses needs such as replication to make the protocol itself more stable.
Just because the Common Indexing Protocol is already in use by Whois++, but not published, the first task of this group is to publish version 1 of the Common Indexing Protocol as is. After that, the protocol must be extended according to the specification below. This will result in version 2 of the protocol.
Other topics to be addressed potentially include:
o Incremental updates of indices
o Support for the UTF-FSS encoding of UNICODE
o Guidelines for building an effective mesh of indexing servers
o Administrative protocols and procedures such as server registration
o Security between directory services
The working group will work in very close cooperation with the working groups ASID and IDS in the IETF.
The working group will use the following Internet-Drafts as input:
o Architecture of the Whois++ Index Service, Chris Weider <draft-ietf-wnils-whois-03.txt o How to interact with a Whois++ mesh, Patrik Faltstrom <draft-ietf-wnils-whois-mesh-01.txt
Goals and Milestones:
Dec 95 |
|
Hold first meeting at Dallas IETF. |
Dec 95 |
|
Submit first version of the Common Indexing Protocol to the IESG for publication as an RFC. |
Dec 95 |
|
Submit paper on Whois++ navigation to the IESG for publication as an RFC. |
Feb 96 |
|
Produce first set of Internet-Draft on the client interface, server interface, and engine. |
Mar 96 |
|
Submit Internet-Draft describing usage of the Common Indexing Protocol with LDAP/X.500. |
Mar 96 |
|
Submit Internet-Draft describing usage of the Common Indexing Protocol withWHOIS++. |
Jun 96 |
|
Submit the Internet-Drafts on the client interface, server interface, and engine to the IESG for consideration as Proposed Standards. |
Jul 96 |
|
Submit Internet-Draft on usage of CIP and Whois++ to IESG for consideration as an Informational RFC. |
Jul 96 |
|
Submit Internet-Draft on usage of CIP with LDAP/X.500 to IESG for consideration as an Informational RFC. |
Aug 96 |
|
Generate document summarizing first round on LDAP/X.500 and Whois++ interoperability tests, and submit to IESG for consideration as an Informational RFC. |
Internet-Drafts:
· A Tagged Index Object for use in the Common Indexing Protocol
· A CIP-based Centroid Exchange for LDAP
· CIP Index Object Format for SOIF Objects
· Hierarchical Extensions to the Common Indexing Protocol
· Registration Procedures for SOIF Template Types
· CIP Transport Protocols
· MIME Object Definitions for the Common Indexing Protocol (CIP)
· The Architecture of the Common Indexing Protocol (CIP)
· LDAPv2 client Vs the Index Mesh
No Request For Comments
Minutes of the Common Indexing Protocol (FIND) Working Group
Chair: Patrik Faltstrom
Minutes: Sally Hambridge
The FIND working group met for the last time. There are a number of documents on the table and Working Group last call is on right now. Send any comments by 12/19/97. The documents are:
draft-ietf-cip-arch-01.txt
draft-ietf-cip-mime-01.txt
draft-ietf-cip-trans-05.txt
draft-ietf-cip-ldapv2-00.txt
draft-ietf-cip-soif-02.txt
draft-ietf-cip-soif-registry-00.txt
draft-ietf-cip-tagged-04.txt
Most of them have changed by one revision number to reflect the decision not to add a new mime type for index objects, but to add a new branch to the tree for them. This is because adding a new mime type would be opening a Pandora's box of other groups creating mime types for every new object that might appear, and we didn't want to do that.
The document draft-ietf-cip-hierarchy-01.txt was also to be updated, as it does not yet follow the structure as an index-object should according to the new MIME spec. The authors were going to submit an updated document the following two weeks after the IETF. Patrik pointed out that because this is only yet another example of an index-object-type, the wg should not wait with closure for this last document if it slips away in time. With the publication of these drafts as RFCs the working group will conclude.
None Received