- From: Dennis Glatting <dennisg@plaintalk.bellevue.wa.us>
- Date: Fri, 10 May 96 07:47:05 -0700
- To: Christopher Allen <ChristopherA@consensus.com>
- Cc: ietf-tls@w3.org
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