Due to a recent change of email address, the ZNG server has been
rejecting my postings, so I am re-sending the three that I send since
this problem arose.  This is the first of the three messages, with the
other two to follow soon.  Apologies that they come so late,
especially if the discussion has moved on since then.

--

Date: Thu Apr  7 10:52:51 +0100 2005
From: Mike Taylor <[log in to unmask]>
To: [log in to unmask]

> Date: Wed, 6 Apr 2005 13:39:44 -0600
> From: Peter Noerr <[log in to unmask]>
>
> > Quite the opposite - the client had no idea what to expect back as
> > it is entirely up to what the server thinks such a client may want
> > back. The client may get back some information it has no idea how
> > to handle, and not get back something the server could have sent
> > back and the client could make use of.
>
> In principle it could be the case. However in commercial practice
> the information content and services supported are defined (often by
> contract - a non-normative document!) for the class of client and it
> is up to the client to interpret.

I have to side with Matthew on this one.  It is much, much better to
have client explicitly requesting the particular features they want
rather than having servers take a guess as what combination of
features might be best.  It is fine for a server to decline to provide
a particular requested feature, and this is what we would expect to
happen if a client requests a feature that its operator has not paid
for.  No problem here, just a nice, simple, explicit dialogue where no
guesswork is required and everything is easy to follow and hence to
debug.

> Of course the Explain for this class of client (along with schema
> and profiles) should define the service and content so everything
> work smoothly. But I'm not holding my breath.

There is no Explain for clients (although now that you mention it,
it's an interesting idea).  Only servers can currently be Explained.

> Of course the same effect can be achieved by having a number of
> virtual servers each supporting a different class of service which
> may be, for example, sitting behind different ports.

In such a scenario, it would still be the case that the server are
forbidden to supply additional information to the client unless the
client requests it.  See
        http://www.loc.gov/z3950/agency/zing/srw/extra-data.html

> By going to the particular port the client is asking for that set of
> services, which may include all sorts of extraInformation
> capabilities for those clients who can gain admission.

No.

 _/|_    ___________________________________________________________________
/o ) \/  Mike Taylor  <[log in to unmask]>  http://www.miketaylor.org.uk
)_v__/\  "If you can't make it good, make it look good" -- attributed to
         Bill Gates.

--
Listen to free demos of soundtrack music for film, TV and radio
        http://www.pipedreaming.org.uk/soundtrack/