Re: Rep (2) : simple information lookup services

Tim Howes <tim@terminator.rs.itd.umich.edu> Tue, 20 July 1993 14:46 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04648; 20 Jul 93 10:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04644; 20 Jul 93 10:46 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa08901; 20 Jul 93 10:46 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.03996-0@haig.cs.ucl.ac.uk>; Tue, 20 Jul 1993 15:37:15 +0100
Received: from terminator.rs.itd.umich.edu by bells.cs.ucl.ac.uk with Internet SMTP id <g.12403-0@bells.cs.ucl.ac.uk>; Tue, 20 Jul 1993 15:37:05 +0100
Received: from vertigo.rs.itd.umich.edu by terminator.rs.itd.umich.edu (5.67/2.2) with SMTP id AA15524; Tue, 20 Jul 93 10:36:52 -0400
Message-Id: <9307201436.AA15524@terminator.rs.itd.umich.edu>
To: Ascan Woermann (Tel +33 93-65-34-65) <Woermann@osi.e3x.fr>
Cc: Non Receipt Notification Requested <osi-ds@cs.ucl.ac.uk>
Subject: Re: Rep (2) : simple information lookup services
In-Reply-To: Your message of "Mon, 19 Jul 93 22:36:23 BST." <7431177535170woer*/S=Woermann/OU=OSI/O=E3X/PRMD=E3X/ADMD=atlas/C=FR/@MHS>
Date: Tue, 20 Jul 93 10:36:52 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tim Howes <tim@terminator.rs.itd.umich.edu>

> From:    Ascan Woermann <Woermann@OSI.e3x.fr> (Tel +33 93-65-34-65)
> To:      osi-ds@cs.ucl.ac.uk (Non Receipt Notification Requested)

> > 	Question = question-id,
> > 		   target name (in UFN format),
> > 		   attribute types sought.
> > 
> > 	Response = question-id (for linkage),
> > 		   result:
> > 			precise name,
> > 			attribute values.
> > 		   or error:
> > 			solved name parts,
> > 			problem explanations.
> > 
> > Indeed, we can even add some form of navigation control, also some
> > "precise/loose" match property. But the generic idea is that this could be
> > kept simple and short...
> 
> The UFN server in ISODE uses a similar protocol to the one you propose.
> Whilst I agree about the simple and short, it would be difficult to offer 
> the variety of services I had in mind with an entirely UFN oriented protocol.

Simpler is better, but Ascan is right in that we need to be able to
specify criteria more general than even a fuzzy name.  Perhaps replacing
the "target name (in UFN format)" in Christian's proposal with a more
general "target criteria (in some yet-to-be-specified format)" would do
the trick.

As for the problem of returning multiple entries, why not follow the
LDAP approach of returning 0 or more results followed by an error
(or success) indication.                                  -- Tim