Proposal for debugging API in 1.3.2

[Sam Hartman]

Today, Jeff, Alexis and I had an extended Zephyr discussion about the
debugging API.  Ken and Jeff's current proposal is not a proposal for
a debugging API but rather a proposal for a user status messages API.

It's unclear to me whether user status messages are a desirable
feature of a library like the Kerberos library.  Also, it is clear to
me there is a significant difference in the debugging approach KFM is
currently taking and the approach Jeff is suggesting for KFW.  The
option of asserting that one of these approaches is correct is
unappealing to me because I can see that having a unified vision in
debugging is important and I don't understand the issue well enough to
make an informed decision.  I believe I can learn to understand the
issue, but not in the 1.3.2 timeframe.

There are also significant disadvantages to making a stopgap decision
now with the goal of fixing it later.  In general, people never find
the time to fix such decisions later.  So we should only move forward
on this issue if we believe the results will be acceptable at least as
a starting point for a long-term solution.

I do not believe we can resolve the general disagreement raised today
for 1.3.2.  However I believe there may be a way to move forward.  I
propose the following API.  If we accept this API, we should do so
believing that it will be acceptable even if we never make major
changes to it.

A function krb5int_message, taking a facility, format string and
variable arguments.  This function will be defined as a static inline
function that will either call a platform-specific function or do
nothing.  We will define one facility code, corresponding to the user
status messages Jeff wants to add now.

We may define macros for giving krb5int_message a shorter name.  These
macros will not take arguments.

This proposal addresses my concerns with Ken and Jeff's proposal:

1) It required multiple macros for each of the possible numbers of
   arguments you might need.

2) It did not seem like it would expand into a debugging API because
   it was missing facility codes.  However it seemed like people might
   start using it as a debugging API rather than revise the API and
   change the existing messages.  Alternatively we might end up both
   with a user status API and a debugging API in the same product.
   That seems unacceptably confusing.

3) Alexis and I are generally concerned about the use of macros in the
   proposal.