That's a good summary - but there are two questions (I think):

i) Do we want to add an x-client-id (or similar) parameter to the known
extraData parameters (ditto for x-server-id) so that there is a
consistent way of doing this

ii) I think that the presence of an x-client-id should not be an
invitation to the server to return any extra fields it likes (on the
basis that it knows by other means that the client knows how to handle
such fields but didn't explicitly ask for such fields, so probably isn't
expecting such fields) with the possible exception of an x-server-id
field. Note that this doesn't rule out Peter using a
x-client-functionality-class (or whatnot) for this sort of purpose.

Matthew

> -----Original Message-----
> From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]] 
> On Behalf Of Dr Robert Sanderson
> Sent: 07 April 2005 12:50
> To: [log in to unmask]
> Subject: Re: Server Identification in the Explain Record
> 
> To summarise, so that I'm sure I understand the discussion:
> 
> * Servers should allow clients to request extra fields individually
> * Servers should allow clients to request packages of extra fields
> * Servers should explain the extra fields/packages available
> * Servers should not return extra fields without being asked
> * Clients may request extra fields at any time
> * Client identification is an extra field
> * Server identification is:
>      1.  In the explain record
>      2.  An extra field in any response
> 
> If so, then that's good, because that's the status quo :)
> 
> Rob
> 
>        ,'/:.          Dr Robert Sanderson ([log in to unmask])
>      ,'-/::::.        http://www.o-r-g.org/~azaroth/
>    ,'--/::(@)::.      Dept. of Computer Science, Room 805
> ,'---/::::::::::.    University of Liverpool
> ____/:::::::::::::.  L5R Shop: http://www.cardsnotwords.com/ 
> I L L U M I N A T I
>