W3C home > Mailing lists > Public > ietf-tls@w3.org > April to June 1996

Re: Openness, change control, future protocol revisions

From: Dennis Glatting <dennisg@plaintalk.bellevue.wa.us>
Date: Fri, 10 May 96 07:47:05 -0700
Message-Id: <199605101447.HAA02048@imo.plaintalk.bellevue.wa.us>
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.

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.

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

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

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.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:58 UTC