Re: [lemonade] some questions in draft-ietf-lemonade-notifications-03

[Mark Crispin <mrc at CAC.Washington.EDU>]

On Sun, 20 Aug 2006, Ned Freed wrote:
> Another problem IMO is that it is quite rare for those "existing 
> libraries and APIs" to actually exist on all platforms of interest. And 
> this is especially true here, where we're supposed to be dealing with an 
> even wider range of devices than is perhaps the norm.

Indeed.  It is singularly unhelpful to tell someone to use an API that is 
unobtainable on that person's platform.

In fact, I would go so far as to propose an IETF BCP that protocol 
specifications MUST NOT be defined to use any API unless the proponent 
commits to provide, and support, an implementation of that API free of 
charge for all platforms; and to post a security bond sufficient to fund 
such provision and support should the proponent become unable to fufill 
this responsibility.

If someone were to say "no problem", then I have a couple of TOPS-20 
systems that need provisioning... ;-)  Hey, it's got a C compiler. ;-)

> Quite true. And when the problem actually turns out to be in one of 
> those libraries (as it does all too often) gettting it fixed can be a 
> major undertaking. Indeed, the situation in regards to library 
> dependencies has gotten so bad in some quarters I often hope for the 
> issue to be in my own code, because at least that way I can find and fix 
> it.

True story:

The UW IMAP and POP3 servers were broken by the GSSAPI in krb5-1.5.  It 
keels over deep in the internals of GSSAPI with an assertion failure. 
It's their bug, they've fixed it in 1.5.1, and in all fairness they were 
fairly quick in saying "mea culpa" and getting a fix out.

Nonetheless...  It happened while I was on a one-month vacation.  I got 
egg on my face for something that was not my fault, and had nothing to do 
with.  Why didn't my "buggy" code properly initialize GSSAPI, etc. 
[Because there is no "initialize GSSAPI", that's why!  And by the way, 
that thing that wasn't initialized was creeping featurism in GSSAPI that 
is completely orthogonal to the purpose of GSSAPI and Kerberos!!]

I did what I could.  I put out a posting on the UW IMAP user list warning 
people about upgrading to krb5-1.5, suggesting that they wait until 
krb5-1.5.1, and providing the patch to krb-1.5 that fixes the problem. 
Above all else, (thankfully!) krb5-1.5 is new enough that most people do 
not run it and hopefully never will since 1.5.1 is coming.

Still, I expect some more incoming eggs before it blows over.

APIs can be a very good and useful thing.  I wrote (and use) the c-client 
API.  UW imapd uses c-client along with the GSSAPI and OpenSSL APIs. 
Pine adds two APIs (pico and pith) of its own, and uses some others (such 
as LDAP).

So I'm not anti-API.  However, I am VERY cautious when adding new APIs to 
the mix.  Even with your own APIs, you stand the risk of a cascading 
regression.  External APIs are a much greater risk.

I'm even more cautious when adding APIs to a protocol specification.  The 
SASL profile for Kerberos 5 is defined by GSSAPI.  This may be a good 
thing in some ways, but in other ways it's quite a problem.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade