Editor's note: These minutes have not been edited.
Minutes of the Find Working Group
37th IETF, San Jose, December 11, 1996
Chairs: Patrik Faltstrom, Roland Hedberg
Patrik opened the meeting with a set of Wormholes which he
suggested we avoid: the Common Indexing Protocol (CIP) works
between servers. There will be a separate protocol for clients
which we will not discuss today. We will discuss what goes on
between servers and we might discuss what goes in an index object
and what goes in the protocol.
Patrik suggested that we need to divide the current CIP draft
into an architecture document and a protocol document. The
discussion on access protocol is deferred to the list.
The group worked on CIPv3 open issues. CIP moves MIME messages
back and forth. The payload section is still undefined. Open
questions include: What is a Data Set Identifier (DSI)? There is
a difference between globally unique IDs which aggregate for
indexing and those which are used to break referral loops. We
have a solution for aggregation but not for referrals.
HERE THERE BE DRAGONS: A virtual dataset could reside on more than 1
server. The Base-URI of a server is in a referral, but it is not
clear what this is for a virtual dataset. When 2 disparate
datasets are aggregated they become 1 thing. Referrals must
bounce through any server which has aggregated them. This is
easier to understand when the servers all speak the same
protocol(s). There needs to be a method of pruning. Jeff needs
to lay out these rules in the document. Since it is easier to do
for homogeneous networks, the group decided to address these first
and try to make sure none of the rules for homogeneous networks
would bomb heterogeneous networks later. There need to be rules
for two processes: referrals and resolution. For aggregation -
if you do not aggregate you can have skip level referrals. If
you're part of aggregation you must be part of the referral.
This increases processing and response time. Trade offs of
these 2 must be made clear in the draft. The decision on the
trade off will probably be application or domain driven.
Mime: Instead of creating new mime types, the group has elected
to use application/cip-request. Jeff would like the body null
and to pack the parameters. This entire discussion was deferred
to the list. There was a question asked about whether the spec
should be more persuasive about using mime to format the payload?
The answer was that we have no idea of what mime will cost.
There may be appropriate uses, so the draft should have examples
of when to use it.
Version: this was retained for backwards compatibility. This
seems to be a problem on TCP transport and a Whois++ issue and
should be moved somewhere else. There was a suggestion to look
at the SNXP Mime Object transport at
http://www.fv.com. This
issue was also deferred to the list.
Policy for indexing objects: This is what to do when an indexing
server gets an index object it doesn't understand. This can
happen during an index-push. If a server accepts the object it
may re-export the object intact without storing - especially if
it didn't understand the payload. If it rejects it, it should
return an error code.
Three more issues were deferred to the list: Mesh Management,
which really needs help; the abstract definition of matching
semantics also needs help and HTTP URLs. Should 2 different URLs
be used for aggregation?
CIP and LDAP Draft (draft-ietf-find-cip-ldap-00.txt)
The draft defines the ldap schema for index information kept by
the server and defines the ldap index object. The ldap schema
allows mesh management and allows ldap to query the index.
Futures will include defining the incremental index mechanism and
to discuss the implications of aggregation and filtering. (These
will be different depending on payload.) Suggestions are welcome
to the list.
CIP and WWW
Indexing the web makes for interesting scaling problems. Do we
think we're willing to write index objects for each application
or should we use a core SOIF? The Query Referral group from MIT
found the context of the index objects more interesting than the
rules for passing them around. Negotiation seems to be the key
issue - This is my index object, can you handle it? These rules
should be as strict as the MIME registry rules. This may cut out
proprietary indexing schemes because the public mesh can't deal
with it. We should also distinguish between indexing "the web"
and indexing "html documents on the web."
Integrating Hierarchical data:
This is an attempt to fit hierarchical data into the index.
Hierarchical attributes do not compress well. There are lots of
unique tokens. This tweak allowed that compression by having
schema information which told which attributes were hierarchical,
and also had integrity checks.
RWhois v. 2.0 is out soon. It will use CIP to index information
from other NICs.
Patrik wants anyone working on CIP to communicate with him so he
can manage progress.
Our Charter needed revision since we had clarified that indexing
objects were different from the transport protocol. Patrik
updates the charter with new milestone:
Dec 95 1st CIP as an RFC
Dec 95 Whois++ navigation as an RFC
Feb 97 three papers (client interface, server interface and engine) as
I-D
Mar 97 CIP and Whois++ I-D
Mar 97 CIP and LDAP I-D
Jun 97 three papers (client interface, server interface and engine) as
RFCs
Jul 97 CIP and Whois++ as RFC
Jul 97 CIP and LDAP as RFC
Aug 97 Interoperability between LDAP/X.500 and Whois++ as RFC
Patrik ended the discussion by reminding us we needed clear
distinctions between routing and fulfillment.
