NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Chair(s):
Roland Hedberg <Roland.Hedberg@umdac.umu.se>
Patrik Faltstrom <paf@swip.net>
Applications Area Director(s):
Keith Moore <moore+iesg@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:
· An interface spec, where one says how you present a query and what the referrals you get back look like
· A server interface spec, where one says that the CIP will be able to include information presented in this format
· 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:
· Incremental updates of indices
· Support for the UTF-FSS encoding of UNICODE
· Guidelines for building an effective mesh of indexing servers
· Administrative protocols and procedures such as server registration
· 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:
· 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 with WHOIS++. |
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)
No Request For Comments
Minutes of the FIND Working Group
Chairs: Patrik Faltstrom <paf@swip.net>
Roland Hedberg - <Rolend.Hedberg@umdac.umu.edu>
Reported by: Sally Hambridge
Mailing List: find@bunyip.com
Archive: ftp://ftp.bunyip.com/pub/mailing-lists/find.archive/
I. Summary
The FIND working group reviewed all the documents in the queue and agreed to go to last call as soon as is feasible. There are still a few problems in dealing with index objects as Mime types and the group agreed after an examination of RFC 2048 that they would have to create a new cip tree to handle different types of cip index objects. After this is approved by the IESG, the documents will have to be updated, but we all thought the Washington DC meeting would be the last.
II. Minutes
Find has several drafts out:
draft-ietf-find-cip-arch-00.txt (architecture draft)
draft-ietf-find-cip-hierarchy-01.txt
draft-ietf-find-cip-mime-00
draft-ietf-find-cip-soif-01.txt
draft-ietf-find-cip-tagged-02.txt
draft-ietf-find-cip-trans-00.txt
draft-ietf-find-soif-registry-00.txt
The cip-arch, cip-mime, and cip-trans docs fulfill the core goals, and the soif and tagged drafts fulfill the goal of showing how cip would work on more than one index object.
There are still some problems:
1) Some index objects are in binary and some are text. The group asked if the mime type directory should be text or application. Text becomes problematic for especially soif objects, so we agreed it should stay application, but later decided the cip needed it s own mime tree.
2) Should the different index-objects have different mime types? The group decided that there should be a new family of mime types since according to RFC 2048 we cannot have different index objects as one mime type if they have different syntax. This will take IESG approval. There was a suggestion that really good data would include what mime-type it was. CIP objects would then have a faceted name - cip.indexobj and experimental cip objects would sport the x in front of the cip x-cip.indexobj.
3) There are a few problems with 2.3.4 and 2.4 in cip-mime-00 and the solution is to remove the references to attribute/value pairs.
4) Security between servers - Patrik suggested that since objects would be passed in mime that it made sense to use mime security rather than to re-invent the wheel.
5) Aggregation - Still a bit of an unsolved problem. There are two problems - one is that a person might want to have heterogeneous types be able to mesh, and the solution will be to add language to the draft (if it is missing) that this is dangerous and you do it at your peril. The second is that if you, as an index server, receive an object you do not understand you should pass it up with the original DSI. This language is in the draft and will stay stated as such.
III. Action Items
Patrik and Michael Mealling will sort out a draft defining the new cip tree. The new cip tree will follow the ietf-tree rules. All editors will then need to check their documents to make sure the mime verbiage matches the new cip tree.
All documents will then go to last call on the mailing list as soon as possible after that. Documents will then go to last call in the IETF community.
For new stuff - the ADs will decide whether to spin up new groups .
Interoperability for each index-object was deferred to a possible deployment working group.
None Received