RE: Transport requirements for DNS-like protocols

Patrik Fältström <paf@cisco.com> Mon, 01 July 2002 11:34 UTC

Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYK00704ITRTN@eListX.com> (original mail from paf@cisco.com); Mon, 01 Jul 2002 07:34:39 -0400 (EDT)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYK00701ITRTL@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Mon, 01 Jul 2002 07:34:39 -0400 (EDT)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYK00701ITQTK@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Mon, 01 Jul 2002 07:34:38 -0400 (EDT)
Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GYK0063TITQCE@eListX.com> for ietf-irnss@lists.elistx.com; Mon, 01 Jul 2002 07:34:38 -0400 (EDT)
Received: from xbe-ams-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g61BWrY6020974; Mon, 01 Jul 2002 13:32:54 +0200 (MET DST)
Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 01 Jul 2002 13:32:58 +0200
Received: from dhcp-64-103-48-81.cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 01 Jul 2002 13:32:57 +0200
Date: Mon, 01 Jul 2002 08:52:38 +0200
From: Patrik Fältström <paf@cisco.com>
Subject: RE: Transport requirements for DNS-like protocols
In-reply-to: <2626548.1025471624@KLENSIN-TP>
To: John C Klensin <klensin@jck.com>, Nicolas Popp <nico@realnames.com>, 'Michael Mealling' <michael@neonym.net>
Cc: Rob Austein <sra@hactrn.net>, ietf-irnss@lists.elistx.com
Message-id: <27312065.1025513558@localhost>
MIME-version: 1.0
X-Mailer: Mulberry/2.2.0 (Mac OS X)
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Content-disposition: inline
References: <17823168.1025345475@localhost> <2626548.1025471624@KLENSIN-TP>
List-Owner: <mailto:ietf-irnss-help@lists.elistx.com>
List-Post: <mailto:ietf-irnss@lists.elistx.com>
List-Subscribe: <http://lists.elistx.com/ob/adm.pl>, <mailto:ietf-irnss-request@lists.elistx.com?body=subscribe>
List-Unsubscribe: <http://lists.elistx.com/ob/adm.pl>, <mailto:ietf-irnss-request@lists.elistx.com?body=unsubscribe>
List-Archive: <http://lists.elistx.com/archives/ietf-irnss/>
List-Help: <http://lists.elistx.com/elists/admin.shtml>, <mailto:ietf-irnss-request@lists.elistx.com?body=help>
List-Id: <ietf-irnss.lists.elistx.com>
X-OriginalArrivalTime: 01 Jul 2002 11:32:58.0102 (UTC) FILETIME=[0CA42160:01C220F3]

--On 2002-06-30 21.14 -0400 John C Klensin <klensin@jck.com> wrote:

> Sonex/ soundex matches are fuzzy matching, but they are not
> fuzzy search; I think that fuzzy search is going to be needed
> here.

True.

I think the reason why I am arguing so strongly for client-side
calculations is just because too many people doing services forget we have
a CPU in the client aswell as the server side. Just look at the "paged
result sets" in IMAP and LDAP which I still for my life don't understand
how people can deploy. It will cost soo much. "We need it because we have
so limited amount of memory and CPU in the client." is what I have heard.
So, instead of having the client do a search+fetch from the server, the
client also want to pass enough information to get the items sorted
correctly (whatever that can be) + the server is to keep a state for the
client, like a cached view.

This imply not only that we need semantics and syntax which enables the
client to pass sorting algorithm input to the server, but also that the
server need to keep state. One for each client. What is the timeout? What
happens if new records are added or removed to the view the client looks at?

_Extremely_ complicated.

So, of course one need cooperation between client and server, where the
various calculations are made where it "makes sense". My point is that
"makes sense" is not always the server. Much more seldom than what people
in general(!) think.

    paf