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
- Re: Transport requirements for DNS-like protocols John C Klensin
- RE: Transport requirements for DNS-like protocols John C Klensin
- Re: Transport requirements for DNS-like protocols Dave Crocker
- Re: Transport requirements for DNS-like protocols Michael Mealling
- Re: Transport requirements for DNS-like protocols Eric Brunner-Williams in Portland Maine
- Re: Transport requirements for DNS-like protocols Dave Crocker
- RE: Transport requirements for DNS-like protocols Patrik Fältström
- Re: Transport requirements for DNS-like protocols Rob Austein
- Re: Transport requirements for DNS-like protocols Eric Brunner-Williams in Portland Maine
- RE: Transport requirements for DNS-like protocols John C Klensin
- RE: Transport requirements for DNS-like protocols Nicolas Popp
- Re: Transport requirements for DNS-like protocols Patrik Fältström
- Re: Transport requirements for DNS-like protocols John C Klensin
- Re: Transport requirements for DNS-like protocols Patrik Fältström
- Re: Transport requirements for DNS-like protocols Eric Brunner-Williams in Portland Maine
- Re: Transport requirements for DNS-like protocols John C Klensin
- Re: Transport requirements for DNS-like protocols Eric Brunner-Williams in Portland Maine
- Re: Transport requirements for DNS-like protocols Michael Mealling
- Re: Transport requirements for DNS-like protocols Patrik Fältström
- Re: Transport requirements for DNS-like protocols Michael Mealling
- Re: Transport requirements for DNS-like protocols John C Klensin
- Re: Transport requirements for DNS-like protocols Michael Mealling
- Re: Transport requirements for DNS-like protocols John C Klensin
- Re: Transport requirements for DNS-like protocols Michael Mealling
- Re: Transport requirements for DNS-like protocols Patrik Fältström
- Transport requirements for DNS-like protocols Rob Austein
- RE: Transport requirements for DNS-like protocols Patrik Fältström
- RE: Transport requirements for DNS-like protocols John C Klensin
- RE: Transport requirements for DNS-like protocols Patrik Fältström