CURRENT MEETING REPORT
Reported by Sally Hambridge, Intel Corporation
Minutes of the Common Indexing Protocol Working
Group (FIND)
Patrik introduced Roland Hedberg as the new co-chair.
There was no discussion on the minutes of the meeting at the 34th
IETF in Dallas. Charter revision was postponed to the end of the
meeting, but Patrik went through the milestones:
We have a current draft: draft-ietf-find-cip-00.txt-The indexing protocol has been published from WHOIS++ work: RFC 1913.
The group missed on having the 3 papers for Client
Interface, Server Interface, and Server Engine.
The current paper (cip-00) has a few changes since
March 1995-there is a little more on tokenization. What we need
is a minimal set of requirements with the "cool features"
to be added later.
There was discussion on whether all servers in the
mesh had to speak all protocols to be able to direct a client
to all sorts of data. The CIP allows a client to use native code
to go to a server to respond in the same protocol about the location
of a service. The client can then go to that service. In order
that all servers do not have to speak all protocols, there will
have to be gateway servers. Clients may also have to advertise
what protocols they are able to accept. (This may be an optimization.)
There are problems with URL referrals in replication and caching.
We will need to devise a scheme which either limits indexing to
originals or has the ability to de-dup the data. We discussed
whether the mesh model was the correct one, and the decision that
it was-for scalability.
We discussed the Data Changed Template:
# DATA-CHANGED
Version-Number: 2.0
Modification-Date: 199603041625
DSI: 1.3.6.1.4.1.1375.1
Host-Name: pollee-hostname
Host-Port: 63
Best-Time-Next-Poll: 199603050100
Window-Size: 3600
Authentication-Type: Password
Authentication-Data: xxxxxxxx
# END
If we consider Server A to be the server with the
data and Server B to be the polling server, the Data-Changed Template
is what A sends to B when it has data to be updated. Main revisions
here include the DSI - or Data Set Identifier. This is present
in case the server with the data has several index sets it owns.
The DSI is the Enterprise Number registered with IANA. The polling
window gives the best time for the start of an update in GMT,
and the window size is the time in seconds of that polling window.
Note that although Server A gives the best time for polling, Server
B still makes the decision of when it polls. We were strongly
informed that passwords would not be sent in the clear, and we
had to work on the authentication mechanism. We had a long discussion
on the problems involved with Server A sending multiple DATA-CHANGED
notices between polling, and decided that the draft has to strongly
recommend against Real-Time updates. (That is, in not sending
a change notice for each change made in the data.)
There was a long discussion about assigning Reference
Numbers to DATA- CHANGED Notices as a way to reference individual
changes. Although a lot of the group thought there would be advantages
to referencing specific changes, the added complexity of this
was decided to be unwieldy. (Was it mandatory or optional, did
Server B have to return it if Server A sent it, did this kind
of incremental update really matter.) The group decided that if
a reference number was needed that the Modification-Date could
be used.
Version of the DATA-CHANGED TEMPLATE agreed on:
# DATA-CHANGED
Version-Number: 2.0
Modification-Date: 199603041625
DSI: 1.3.6.1.4.1.1375.1
Host-Name: pollee-hostname
Host-Port: 63
Best-Time-Next-Poll: 199603050100
Window-Size: 3600
# END
We then discussed the Poll Template. This template
is sent from Server B to Server A at the beginning of the polling
session:
# POLL
Version-Number: 2.0
Charset: UNICODE-1-1-UTF-8
Type-Of-Poll: CENTROID
Tokenization-Type: Tokens
DSI: 1.3.6.4.1.1375.1
DSI-Description: Bunyip
Host-Name: polling hostname
Host-Port: 63
Authentication-Type: Password
Authentication-Data: xxxxxxxx
# END
This template gives the type of Poll and the Attribute-Value
pairs associated with that poll. Note that the DSI and DSI description
are both present. We still need to do appropriate authentication
work, so the Authentication-Type and Authentication-Data Attribute-Values
pairs were removed. Since the Host-Name and Host-Port were part
of the authentication method, they were also removed. Some method
needs to be added back in! We discussed the implication of a Timestamp.
If there was no Timestamp, it would mean that Server A needed
to send Server B the entire index (for disaster recovery, for
example). A Timestamp would mean to send everything after that
time.
Final version:
# POLL
Version-Number: 2.0
Charset: UNICODE-1-1-UTF-8
Type-Of-Poll: CENTROID
Tokenization-Type: Tokens
DSI: 1.3.6.4.1.1375.1
DSI-Description: Bunyip
# END
We moved to the Centroid-Changes Template. This is
what Server A sends to Server B as the update.
# CENTROID-CHANGES
Version-Number: 2.0
Charset: UNICODE-1-1-UTF-8
Type: CENTROID
Tokenization-Type: Tokens
DSI: 1.3.6.1.4.1.1375.1
DSI-Description: Bunyip
URI: WHOIS://hostname/....
URI: LDAP://hostname/....
Authentication-Type: Password
Authentication-Data: xxxxxxxx
# BEGIN TEMPLATE
Template: USER
# BEGIN FIELD
Field: NAME
Data: Patrik
- FaI/ltstroI/m
- David
- Holmes
# END FIELD
# END TEMPLATE
# END CENTROID-CHANGES
The new information here includes the DSI information
which, even if clients don't understand it, it should be present.
URIs now give the information about the location of the data in
the DIT. We decided the Timestamp of the Centroid needed to be
added and that index changes to the Timestamp should be delta.
Once again, the Authentication Attribute-Value pairs were deleted
with the caveat of some other authentication mechanism to be added.
There was a question about how the indexing server knows whether
the data is to be added or deleted. We need experience with implementation
to tell tradeoffs in index size, number of false drops, update
frequency, etc. Deferred to the list was discussion of each client
knowing how to talk to each server - for lack of Real Time Cogent
Ability. Version which still needs work:
# CENTROID-CHANGES
Version-Number: 2.0
Charset: UNICODE-1-1-UTF-8
Type: CENTROID
Tokenization-Type: Tokens
Timestamp-of-Centroid: 199603030100
DSI: 1.3.6.1.4.1.1375.1
DSI-Description: Bunyip
URI: WHOIS://hostname/....
URI: LDAP://hostname/....
# BEGIN TEMPLATE
Template: USER
# BEGIN FIELD
Field: NAME
Data: Patrik
- FaI/ltstroI/m
- David
- Holmes
***** Add/Delete???? ******
# END FIELD
# END TEMPLATE
# END CENTROID-CHANGES
Questions from the mailing list
Are referrals returned as URIs? Yes
How are attribute names decided? When the Server
is creating a centroid it maps attribute names as well.
What Charset? Unicode-1-1-UTF-8.
Chris Weider said there had been an IAB workshop
on Charset and that he was presenting a preliminary report on
that workshop in the Open IAB meeting.
Patrik asked if there was interest in continuing work on the Common Indexing Protocol within the IETF. The group decided there was interest.