LISTSERV mailing list manager LISTSERV 16.0

Help for ZNG Archives


ZNG Archives

ZNG Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

ZNG Home

ZNG Home

ZNG  April 2005

ZNG April 2005

Subject:

Re: Server Identification in the Explain Record

From:

Peter Noerr <[log in to unmask]>

Reply-To:

Z39.50 Next-Generation Initiative

Date:

Wed, 6 Apr 2005 12:59:25 -0600

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (118 lines)

> -----Original Message-----
> From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]]On Behalf Of
> Matthew J. Dovey
> Sent: Wednesday, April 06, 2005 3:52 AM
> To: [log in to unmask]
> Subject: Re: Server Identification in the Explain Record
>
>
> > it does make sense for the server to
> > set up a specific method of communicating with a specific
> > client - if there are enough of them, and there is some gain
> > to one or both sides. This may be in reduced overhead for
> > particular clients because they don't need everything (a full
> > html user screen for returned results for example is a
> > serious waste of resources for a MSE/SE communication, when
> > an XML structure will be of more use to both sides)
>
> The example is not a good one since SRU/W would never return a html user
> screen.

It was a deliberately out of scope response in the larger context of the
above excerpt to show that the MSEs have to deal with SRU/W servers in a
more mixed context

> However the principle that the server can send additional
> information/do additional processing for a particular client is already
> catered for in the request ExtraData mechanisms
> (http://www.loc.gov/z3950/agency/zing/srw/extra-data.html). However,
> rather than the server doing such things in a non-deterministic way
> based on recognising the client, the otherInfo mechanism allows the
> client to explicitly request the server to return additional
> information/do additional processing) and also allows the server to
> indicate to the client whether it recognised and acted upon the request,
> or simply ignored it. Having the client explicitly request such things
> has the advantages that any client can in principle take advantage of
> the additional functionality (rather than client with a particular
> vendor/version signature - which would lead to clients sending false
> information in order to get at the information, just as I often have to
> get Opera to impersonate IE6 to get websites to work), and also makes
> the server behaviour more deterministic which is a general principle in
> SOA and for interoperability in general.

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. It can send all the otherInfo requests it
likes - if the server will not recognise them they will not be acted on.
Hopefully the client will get diagnostic or extraData messages pointing out
the error of its ways.

To my mind this is a major component of a SOA and SLAs - a particular class
of client is entitled to a particular set or level of services. Being able
to offer different services to different classes of (paying) users is a very
common business model.

The security issue is definitely there. Saying you are who you are not has
been with us for quite a while, so why should computing be immune. However
service level based on client class is not going to make things less secure
than a 'one size fits all' server which will answer any request as long as
you know the request. Currently MSE identification gets the MSE virtually
nothing so 'faking it' is not really a problem. In fact it has the effect
that it is likely to get a real user a set of results which are less
comprehensible (certainly not as pretty) so there is a dis-incentive for
actual people to pretend to be software. Remember also that there is a whole
layer of authentication/authorization going on as well so this is not any
sort of backdoor.

>
> > it is
> > useful in the event that a particular implementation sends
> > back less then complete information - there is a 'fall back'
> > position available. (I know that, for example, not sending a
> > schema URI with the record is non compliant for SRU/W, but
> > there will be some programmer out there eventually who
> > decides it is a waste of time. As a community the size of
> > stick we can wave at them is limited. If they have valuable
> > data users will want to access it however 'compliant'
> > they actually are.)
>
> I don't think we should encourage people to be lazy in their
> implementation of the protocol. That would lead to the sort of
> indeterminate behaviour which makes z39.50 so difficult to debug. In
> this case you may think you have a fully working client but it turns out
> that your client is full of bugs but the server is being too forgiving
> and it is only until your high profile customer tries it on a different
> server that the bugs come to light.
>
> It is also the case that there are a number of firewalls emerging which
> are WebService (both SOAP and REST) aware and will check incoming and
> outgoing messages very strictly for conformance. So whilst your server
> may be forgiving the lazy/buggy client may still not be able to
> communicate with you (or may mysteriously break overnight and be a
> diagnostic nightmare because someone has improved the security of your
> network with such a beast - an avoidable nightmare if everyone has stuck
> to strict adherence of the specification).
>

I agree entirely that we wish to ensure that "compliant" systems are
compliant. Z39.50 is a good example of nastiness. My point is only that the
real world is nasty and we will get partially compliant "compliant" systems
which will have to be dealt with. I suspect the firewalls, et al will not be
a factor as those organisations which are technically savvy enough and good
citizens enough to institute those measures are not the ones who will
produce lazy/buggy software. And if they are considered on the server side,
then is keeping potential customers away in the name of upholding standards
a good ROI?


Peter

Dr Peter Noerr
Chief Technical Officer
Museglobal, Inc.

[log in to unmask]
www.museglobal.com

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

July 2017
October 2016
July 2016
August 2014
February 2014
December 2013
November 2013
October 2013
February 2013
January 2013
October 2012
August 2012
April 2012
January 2012
October 2011
May 2011
April 2011
November 2010
October 2010
September 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
October 2009
September 2009
August 2009
July 2009
May 2009
April 2009
March 2009
February 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager