Re: Openness, change control, future protocol revisions

Date: Thu, 9 May 1996 23:05:04 -0700
From: Christopher Allen <ChristopherA@consensus.com>

> At 10:45 PM  -0700 5/9/96, Bennet Yee wrote:
> >Myself, I'd prefer to see this WG (or a subsequent
> >one) specify some minimal core API (for Unix, Windows, and MacOS), so
> >that we wouldn't run into these problems in the future, or at least
> >run into them once for everybody rather than multiply in various
> >different ways for various vendors / freeware implementations.
>
> I'm uncomfortable with this. Hasn't IETF's experience
> with defining API's (as opposed to protocols) been poor?
> Someone else want to comment on their specific
> experience of trying to define APIs through an IETF
> standards process?
>

I'll bite. :)

The CAT WG developed and maintains the Generic Security
Service API (GSS-API). I have written more than one
implementation of the GSS-API and I participate in the
CAT WG. (Oh, BTW, I don't speak for my employer. :)) The
GSS-API can be considered a success, a failure, or
mediocre, depending on your point of view.

A GOOD POINT
By far the GSS-API's (IMO) best point is that it is a
standard. As a standard, it is a valuable check mark on a
MIS manager's budget approval list.

A BAD POINT
Once a standard, customers hold you to the standard, even
when it is broken.

A MEDIOCRE POINT
The applicability of the GSS-API is limited. In simple
client/server applications the GSS-API is useful
because it is a simple API (20 functions); however, in
complex client/server environments it is not useful
because it is a simple API -- it doesn't account for
multi-threading.

Certainly we can argue forever in the day the points of an
IETF sponsored API. We can do the same for a protocol too.
I'm not convinced there is a difference between an API
standard and a protocol standard. The market is looking
for both.


-dpg

Received on Friday, 10 May 1996 10:47:24 UTC