HDTenEightyP/NetNews huggingface dataset:
From: deal@tempus.Kodak.Com (Stephen M. Deal)
Subject: Authentication of Clients in a C/S environment
Keywords: Kerberos, Trusted Hosts, Food for Thought
Reply-To: deal@Kodak.COM
Organization: Eastman Kodak Company
Distribution: na
Date: Fri, 20 Nov 92 03:23:45 GMT


One major implication of distributed processing (of which C/S is but one manifestation) is that of authentication.

Example: I have a Benefits database for a company of 100k employees. How can I enable each employee to review their benefits without giving each employee an account on the server machine?

How do you authorize a client? Can you even trust a client? Perhaps those clients executing on a node that has password protection (e.g. UNIX, VAX/VMS) can be trusted but what about single tasking nodes that run a Disk Operating System (a.k.a. DOS)?

Will a user on a untrustworthy client have to log in to every server to which they make a request? :-(

Kerberos (from MIT's Project Athena) provides a glimmer of hope but I have not seen any C/S vendor embrace this approach.

Has anyone given much thought to client authentication on PCs and Macs? Does anyone have any thoughts on how a server (DB  or otherwise) would handle such a mechanism?

  ======================================================================
  | Steve Deal	 	| Internet: deal@Kodak.COM		       |
  | Eastman Kodak Co.	| UUCP:     ...rutgers!rit!kodak!tempus!deal   |
  | Engr. Systems Div.	| Voice:    (716) 726 - 5396		       |
  | mailcode: 35108	| FAX:	    (716) 726 - 7406	               |
  | 901 Elmgrove Road	| 					       |
  | Rochester, NY	| 					       |
  | 	   14653-5108   |					       |
  ======================================================================
    Disclaimer:	"Everyone is entitled to an opinion, 
		 the above is mine and not that of my employer."
Xref: sparky comp.client-server:176 comp.unix.osf.misc:22 comp.os.ms-windows.programmer.win32:2044
From: jbaker@husc8.harvard.edu (James Baker)
Newsgroups: comp.client-server,comp.unix.osf.misc,comp.os.ms-windows.programmer.win32
Subject: dce rpc -- who supports it? and other thougthts
Keywords: NT RPC DCE OSF/1 calling protocol
Date: 19 Nov 92 05:56:57 GMT
Article-I.D.: husc8.JBAKER.92Nov18215657
Distribution: comp.client-server
Organization: Harvard Arts and Sciences Computer Services, Cambridge, MA


My main question is: who supports DCE RPC now?  And for the other
players, when?  So I know Window NT does -- I have played with it --
and I guess OSF/1 which DEC supports should.  But will IBM support it
for its mainframes and on what: VM/GCS?  Any wild ideas are appreciazted.

As for my experience with DCE RPC on Windows NT, it seems to be a
reasonable implementation of the RPC paradigm, as I understand it from
reading Power Programming and RPC and some other less useful books.
Not that I don't have gripes.  I would like to be able to control the
various queues with my own service discipline, or at least not without
altering the stub code.  An example would be to allow asynchronous
calls and other less generic calling protocols.  Of course, ONC RPC
has a rather simple way of supporting an asynchronous protocol  --
zero timeouts -- but could those fail on a machine with both client
and server on the same machine?  DCE RPC, on the other hand disallows
this trickery by making a zero timeout something else: a qualitative
minimum time that a response should take.  The attitude that DCE RPC
takes is either you are going to spin a thread off to call a long
running RPC routine or you are going to break it up into two and spin
to find when the results are ready.  I am sure it is indeed for the
best ;-).

In the article in Microsoft Systems Journal about the NT architecture,
Helen Custer (?) mentioned that the client-server support for local
(same machine, different address space) RPC is optimized by thread
pairing between the client/server.  Does MIDL/ACF support this with
the localrpc protocol, currently so well-documented ;-)?

BTW, am I right in thinking that OSF is some secret society?  I bike
by their place all the time in Cambridge -- and strangely I never hear
of them doing anything except in the pages of ComputerWorld and PC
Week and the Burton Group.  Nor is there a great abundance of postings
in comp.unix.osf.  Do I have to be on some mailing list?

Thanks.

-- Jim

jbaker@husc.harvard.edu (forwarded to ...)
jimb@kenan.com 
Newsgroups: comp.client-server
From: ksand@apple.com (Kent Sandvik )
Subject: Re: Need C++/SQL
Date: Sun, 22 Nov 1992 06:15:35 GMT
Distribution: na
Organization: Apple
Followup-To: comp.client-server,comp.databases,comp.lang.c++,comp.sys.mac.oop.macapp3,comp.sys.mac.programmer

In article <1emr1oINNas3@iskut.ucs.ubc.ca>, rawsthor@unixg.ubc.ca (Peter
Rawsthorne) wrote:
> My present approach is to create a class hierarchy separate 
> from the existing MacApp TObject library, called CDBMSObject.
> This seems to make sense given that SQL calls do not lend
> themselves to being inheritable.

This feels weird. Here I'm stating that try to avoid TObject 
base class use, and I'm a MacApp support engineer. Anyway,
the main reason is:
* You are locking to features in TObject that are hard to 
re-port to Bedrock, Interviews, Garnet, Alar, whatever new
frameworks out there

In other words cloning and other TObject specific features
will be hard to reimplement. Now, if you are unsure about
memory handling, use HandleObjects, or look at SLM that
provides memory pools and GetObjectByName style object
creation. 

Another design idea is to try to avoid any dependencies 
whatsoever and write class libraries that have a minimal
interface to the underlying OS. This is my motto nowadays.
If you do a nice design you might be able to port your SQL
classes to various other platforms. 

Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.
Newsgroups: comp.client-server
From: mchance@nyx.cs.du.edu (Michael Chance)
Subject: Re: Is Client-Server dead?
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Thu, 19 Nov 92 23:06:27 GMT


I think that folks are looking at client-server from different viewpoints
here.  The first from a small workgroup viewpoint (office/workgroup
server, local info-bases, small to medium size data & apps), which can
be adapted to "ad-hoc" programming styles and minimal configuration
support.

But that doesn't solve the corporate level viewpoint for a large
Fortune 500 company.  The execs in the corporate strategic planning
office need the data from the entire company, not just one department.
The raw compute power may be there in a 486 server, but it'll never
handle the I/O volume on the input side with any kind of response.
What about processing Citibanks credit card info each month?   Or any
Fortune 500 company-wide payroll or personnel systems?

The big iron will stay around as mega-data servers, the SPACRServes
will be the departmental servers, and the GUIs will be run off the
desktop.  Move the different parts to the right type of machines, with
multi-client-server configurations (as described in another posting).

And you'll still need IS to keep everything in sync (do you trust
every department to install the correct versions of the client
software on every machine ON SCHEDULE?) and talking to each other and
the world.

Michael A. Chance
--
Michael A. Chance          St. Louis, Missouri, USA    "At play in the fields
Work: mc3078@sw1sta.sbc.com                             of St. Vidicon"
Play: bq434@cleveland.freenet.edu
      mchance@nyx.cs.du.edu
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.client-server
Subject: Re: Authentication of Clients in a C/S environment
Date: 23 Nov 1992 01:06:22 GMT
Organization: Massachusetts Institute of Technology
Distribution: na
NNTP-Posting-Host: pit-manager.mit.edu
Keywords: Kerberos, Trusted Hosts, Food for Thought

(A preliminary note: Please, PLEASE follow the guidelines in
news.announce.newusers which state that postings to the Usenet should not
contain lines longer than 80 characters, and in fact recommend limiting line
length to 72 characters.)

In article <1992Nov20.032345.18307@kodak.kodak.com>, deal@tempus.Kodak.Com (Stephen M. Deal) writes:

|> How do you authorize a client? Can you even trust a client? Perhaps those
|> clients executing on a node that has password protection (e.g. UNIX, VAX/VMS)
|> can be trusted

The problem with assuming that "nodes that have password protection" are
trustable is that you are therefore assuming that those nodes have not had
their security breached in any way.  You are relying on node security in order
to guarantee your network security.  That is a bad idea.

The company for which I work (Aktis, Inc., a.k.a. Geer Zolot Associates) does
a lot of security analyses for sites with large networks.  Invariably, those
sites make assumptions about the security of individual machines on the
network when constructing their network security framework.  And invariably,
the security of individual machines on the network is compromisable and
therefore leads to compromises in network security as well.

Unless your physical network is completely secured, so that people cannot put
their own machines on it, your machines on the network are all physically
secure, so that people are not able to break into them using physical means,
and you have direct administration over all the machines on the network so
that you can guarantee that they do not have software security holes on all of
them, you cannot safely trust ANY machine on the network.

If you want network security, you need some sort of network security tool.
|> Kerberos (from MIT's Project Athena) provides a glimmer of hope but I have not
|> seen any C/S vendor embrace this approach.

This is changing.

First of all, the fact that OSF's DCE has embraced Kerberos implies that
vendors who wish to be DCE-compliant are going to have to start supporting
Kerberos.

Tivoli/WORKS, the OSF DME distributed management environment, allows (although
it does not require) the use of Kerberos for the authentication of
individuals' access to the Tivoli environment.

Several of the network RDMS vendors are currently investigating adding
Kerberos support to their products.

-- 
Jonathan Kamens                                         jik@MIT.Edu
MIT Information Systems/Athena              Moderator, news.answers
From: rmc@wang.com (rmc)
Newsgroups: comp.client-server
Subject: Re: Is Client-Server dead?
Date: 20 Nov 92 19:23:52 GMT
Organization: Wang Laboratories, Inc.

mpiet@is.morgan.com (Mark Pietrasanta) asks:

> It would seem that business is more suited to a peer-to-peer
> environment, although IS typically isn't.  How do we IS'ers
> maintain our role (or any role) as the business units start to
> welcome the new peer philosophy?  Especially if they embrace
> Microsoft's solutions, which will mean they can support and
> develop with minimal man-hours and without IS?

Expecting end users to produce answers-oriented analysis applications
to benefit themselves or their immediate work group is a reasonable
thing.  The IS department writing monthly sales role-up reports is
probably a thing of the past, and any IS department that tries to
fight over this type of application is likely being foolish.

Expecting end users, or even department specialists, to write
applications that respect cross department information requirements
and obscure legislated auditing requirements is probably foolish.
These considerations don't help with getting the "job at hand" done,
they only may reduce problems in the future.  And the future could
very well be outside of the current budgetary cycle.  I suspect that
the role of IS will be concentrated here;  coordinating the corporate
information schema, dealing with what the government insists you be
able to produce, and coordinating information exchanges with outside
agencies (either governmental or companies you do business with).  For
example, an insurance company would probably want an IS department
designing and building the applications for remote independent
insurance agents so a single application handled the full spectrum of
claims and new account business handled by the independent agents.
Having the claims department, the auto insurance department, the
medical insurance department etc. all come up with their own
applications is probably expensive for the big company, and more so
for the poor independent agent who then has to deal with 16 different
incompatible applications, probably some running on different
hardware.  (If you have 6 departments involved, at least one will
probably "standardize" on the Mac...)

R Mark Chilenskas
Chilenskas@Office.wang.com
From: mik@hpbbi4.BBN.HP.COM (#Michele Isernia)
Date: Fri, 20 Nov 1992 10:56:55 GMT
Subject: Re: dce rpc -- who supports it? and other thougthts
Organization: Hewlett-Packard GmbH
Newsgroups: comp.client-server

Hp does !

We (Apollo) "invented" the NCS RPC (the base for the DCE rpcs).

Mik
Newsgroups: comp.human-factors
From: alfa@b23a.b23a.ingr.com (Laura Walker)
Subject: Re: Click to Raise Windows vs. Point to Raise
Organization: Intergraph
Date: Mon, 23 Nov 1992 18:14:20 GMT

When operating in an application I want click-to-raise.
If just using windows I want point-to-raise.

Embellishment:
I'm using a page-layout program (FrameMaker or any) and have open 
multiple views of multiple documents, plus tear-off windows for certain
features that I access frequently.  It's extremely annoying to have windows
bouncing up active everytime I move my mouse button.  Page-layout (or CAD, etc)
are very mouse-y activities where click-to-raise is a necessity.

Whereas...if I'm just using windows to write scripts, or access e-mail
(or the usenet) my mouse is inactive. In this situation, I prefer that
X knows that when I move my mouse and point it on another window I really
mean it. 

I've tried both things both ways.  And I want it both ways.  Too bad!
(or perhaps you know of a way I can have it both ways?).

-----------------------------------------------------------------
|  /|| ||~| /|  |   | /|| |/[~|~|	laura@alfa.b23a.ingr.com
|_/ ||_|| \/ |  |_|_|/ ||_|\[_| \     
-----------------------------------------------------------------
Sr. Applications Engineer 		Voice:    205/730-8175
Federal & Industrial Publishing Systems	FAX:      205/730-9478
INTERGRAPH CORPORATION 		 	Mailstop: LR23a2       
One Madison Industrial Park 	 	Building 23A, Room 105H
Huntsville, Alabama, USA 35894 		--STANDARD DISCLAIMER--


>mattf@cac.washington.edu (Matthew Freedman) writes:
>> Before we change the system to match this defacto standard, the
>> point-to-raiseists would like to see hard evidence that click-to-raise
>> is really better. Does anybody have any? If not, unsubstantiated
>> personal opinion would be welcome too.
>> 

>ben@bailey.UUCP (Ben Bailey) writes:
>I wouldn't be too concerned about which is better, but would instead
>try to recognize a standard when one exists.  By doing it the way you
>are, one way or the other, you are forcing people to have to relearn
>a method, either when they come to your system from MS-Windows/Mac,
>or when they go to it (as they surely will).  The question then becomes
>how many additional people are you going to force to have to go through
>the relearning curve?

>> Please note that followups have been directed to comp.human-factors.
>> 
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> = Matthew M. Freedman                                                 =
>> = U. of Washington Information Systems       mattf@cac.washington.edu =
>> = 4545 15th Ave. NE; 4th Floor               (206) 543-5593           =
>> = Seattle, WA  98105                                                  =
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

>Ben
>--
>Ben Bailey                 ben@bailey.uucp -- bailey!ben@uunet.uu.net
>12210 Shady Forest Dr.     ben@bailey.tscs.com
>Riverview, Fl. 33569       -- The main thing is to keep the main
>813-677-5021                  thing the main thing.  Mainly.
From: FR5641A@auvm.american.edu (Fadi A. Rabie)
Newsgroups: comp.human-factors
Subject: should computers be the sole decision makers
Date: 15 Nov 92 19:48:04 GMT
Organization: The American University - University Computing Center

Organizations are depending on computer information to aid them in their
  decisions.   should these computers be the one who make  the decision
   instead of humans?
From: 00jhritter@leo.bsuvc.bsu.edu
Newsgroups: comp.human-factors
Subject: robots in our bodies
Date: 17 Nov 92 03:32:31 GMT
Organization: Ball State University, Muncie, In - Univ. Computing Svc's

I have been hearing a lot lately about the possibly that some day robots will
become so small that they could be injected into the blood stream to fight  
diseases or clean out clogged artieries.  Does any think this is possible?
Does any think this could lead to mind control?  How would this effect our
future?  Please reply, my grade depends on it!!
From: ahd@apollo.sunquest.com (Art Dyer)
Newsgroups: comp.human-factors
Subject: Re: Seperation of Church and Elevators
Date: 20 Nov 92 15:05:05 GMT
Organization: Sunquest Information Systems, Tucson

In article <palmer.722190827@news.larc.nasa.gov> palmer@icat.larc.nasa.gov
(Michael T. Palmer) writes:
>bassi@cs.unibo.it (Bruno Bassi) writes:
 >
 >>For this particular case, I think that a horizontal representation, with
 >>"left" and "right" arrows, would do much better.  [...]
 >>
 >>Any comments?
 >
 >Well, er, yes.  You may find it natural for text to grow rightward, but
 >people who read right-to-left (Hebrew, etc.) or bidirectionally (can't
 >remember this one) may not find it natural at all.  [...]
 >
 >I agree that there's got to be a better way, and I'm sure someone will
 >design something that makes us all feel pretty stupid for not thinking of
 >it before.  :-)
 >

OK, how about replacing the up and down arrows with plus and minus signs
to increase and decrease the value?

--
Art Dyer    ahd@apollo.sunquest.com    Voice:  (602) 570-2000
Newsgroups: comp.human-factors
From: gclapp@javelin.sim.es.com (Glenn Clapp)
Subject: Re: Dan Bricklin Demo II and Protoscreens
Organization: Evans & Sutherland Corp.
Date: Wed, 18 Nov 1992 00:41:45 GMT

In article <rolandi.721580869@andy> rolandi@hssc.scarolina.edu (Walter Rolandi) writes:
>
>Earlier I had posted a request for information from users of Dan
>Bricklin's Demo II and/or Protoscreens.  I'd like to find out what 
>users see as each system's particular strengths and weaknesses.  I
>expected to get a dozen or so responses, summerize them, and post
>the results.
>
>So far, nothing.  Are there no Demo II or Protoscreens users out there?
>What tools do HCI human factors folks use for interface prototyping
>these days?
>
>I'd appreciate any feedback I can get, either mailed to my Internet
>address or reposted to this group for a public discussion.  Thanks.
>

OK, OK!  I HAVE used Demo II, and it worked great.  I got my prototype
up and working satisfactorally in no time, and the customer was able
to get a good feel for the system as it would end up, and was able
to make useful suggestions.  Now, the BEST part.  I will sell my copy
of Demo II CHEAP.  Want it?

Glenn

-- 
=============================================================================
= Glenn Clapp                          |  gclapp@thunder.sim.es.com         =
= Evans and Sutherland Computer Corp.  |  My opinions are my own, but then  =
= Salt Lake City, Utah  (801) 582-5847 |  that's my opinion.                =
From: raveling@Unify.com (Paul Raveling)
Newsgroups: comp.human-factors
Subject: Re: The Problem With UNIX
Date: 17 Nov 92 20:54:10 GMT
Organization: Unify Corporation (Sacramento)

In article <1992Nov14.205538.26386@dragon.acadiau.ca>, rob@dragon.acadiau.ca (Rob Hutten) writes:
> qb7g6@fel.tno.nl (Maarten Landzaat) writes:
> 
> >"rm * .c" (when you really want "rm *.c")
> 
> >I think Unix (well, actually the shell is to blame) should always ask
> >for permission when the star is used with rm. 
> 
> Forced interactiveness can be a pain in the butt- I write a lot
> of shell scripts which call rm.  Some systems put an "alias rm rm -i"
> in the global login script, which is a pretty good idea.

	The variant that I've liked best was Tenex's scheme, which
	dates back just over 20 years.  Reasons:

	1.  Tenex's file system offered multiple versions of the same file.
	    A common technique was to work on a source file until
	    the change going in was REALLY debugged, producing perhaps
	    up to half a dozen versions, then use the DELVER utility
	    to chuck unwanted versions.  Common options for DELVER were
	    (1) Keep only newest version; (2) Keep 2 newest versions;
	    (3) Keep newest and oldest version.  DELVER also allowed
	    choosing versions to delete interactively.

	2.  The default for the DELETE command was to prompt for permission
	    to delete a file. The prompt would also supply a bit of extra
	    info -- "[Old File]" (rather than "[Old Version]" was a cue that
	    you were about to delete the only existing version of the file.

	3.  Deleted files could be undeleted.  You could deliberately
	    make deletions permanent at any time with an EXPUNGE command.
	    Tenex would do an automatic expunge for you when you logged off.


------------------
Paul Raveling
Raveling@Unify.com
From: mike@CIS.Prime.COM (Mike Causer)
Newsgroups: comp.human-factors
Subject: Re: Click to Raise Windows vs. Point to Rais
Date: 19 Nov 92 10:41:26 GMT
Reply-To: mike@CIS.Prime.COM
Organization: Computervision R&D Ltd

In article 2844@tau-ceti.isc-br.com, jimc@tau-ceti.isc-br.com (Jim Cathey) writes:
>  Also, bumping the mouse with your elbow by accident is not harmful
>  when the mouse works the ONE TRUE WAY. 

Where _do_ you keep your mouse?

Why force users one way or the other?  As a long-term SunView user
(forced to OpenWindows now), I prefer to have point-to-focus, but
"raising" as an explicit action.  Any "reasonable" window manager would
allow separate choices for these.  In particular, any WM that
automatically raises on receipt of input focus is a real pain to my
style of working, which is to have many overlapped windows some of
which have only the lowest few lines visible, but need input focus
occasionaly to do a quick action.  I suppose that the auto-raise is a
hangover from the glass-tty/MSdos era of one-job-at-a-time.

Mike Causer
Newsgroups: comp.human-factors
From: ematias@explorer.dgp (Edgar Matias)
Subject: Re: Seperation of Church and Elevators
Organization: CSRI, University of Toronto
Date: 22 Nov 92 18:59:52 GMT


>brian@dsm.fordham.edu (Brian Downing) writes:
>
>  I was thinking along similar lines with one minor modification. 
>  Because the simple '+' and '-' may easily be misinterpreted as 
>  arithmetic operators I would like to suggest the '++' and '--' 
>  increment and decrement operators from C.

This is completely ridiculous.  Since when is knowing C a requirement
for riding an elevator?!  I think up and down arrows work just fine.
Some navel-gazers out there might disagree with me, but I think if you
made this suggestion to a non-programmer, they'd think you were nuts.

Edgar
-- 
Edgar Matias
Input Research Group
University of Toronto
--
I speak for no one...
Newsgroups: comp.human-factors
From: jsue@ncsa.uiuc.edu (Jeffrey L. Sue)
Subject: Re: The Problem With Unix
Originator: jsue@troon.ncsa.uiuc.edu
Organization: The Dow Chemical Company
Distribution: comp.human-factors
Date: Mon, 16 Nov 1992 16:39:51 GMT

Personally I've found the best source of Unix commands to be the Outland
comic strip.  Specifically, Bill the Cat's vocabulary. ;^)


-- 
-----
Jeff Sue   
 - All opinions are mine -       (and you can't have any, nya nya nya)