> -----Original Message-----
> From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]]On Behalf Of
> Matthew J. Dovey
> Sent: Wednesday, April 06, 2005 1:16 PM
> To: [log in to unmask]
> Subject: Re: Server Identification in the Explain Record
>
>
> > I believe responding in a manner which is determined by (some form of)
> > identification of the client is just as deterministic as
> > responding to a
> > particular request from the client. In fact it may be a more strict
> > determinism as the client will only receive what its
> > identification by the
> > server allows it to be sent.
>
> 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. 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.

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. Then each server is independent and
complete in its own services. 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. Just
another way of handling what I believe will be the case for commercial
content operations - multiple service levels from a particular organisation.
>
> The other approach is that the client explicitly asks for all the
> additional services it knows how to handle and then the server returns
> all of those additional services (but no more) which it know how to
> return (this is comparable to the options negotiation in the z39.50
> init). This is why a server should not return an extraData element
> unless there is a corresponding extraData element in the request.
>
Really the only difference between what we are describing is the granularity
of the overall service offered. I'm suggesting they will come in packages,
Matthew is suggesting they will be individual services, supplied on demand
(at least that is my interpretation of what he is saying?). Surprise,
surprise they are not mutually exclusive - restaurants often have both prix
fixe meals and al a carte selections on their menu.

> Matthew
>
>
Peter