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.