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.