How to extend kadmin

[Greg Hudson]

Summary response:

* Nico, Ken, and (in previous off-list conversation) Tom have expressed
displeasure at an approach which requires more hand-editing of XDR code.
So the way we've extended kadmin for lockout support on the trunk (the
api 2->3 bump and conditionalization of xdr_kadm5_policy_ent_rec) is
controversial.

* However, Nico notes that the way we marshal krb5_principal is
problematic for using rpcgen.  I looked into this myself: we call
krb5_unparse_name on encode and krb5_parse_name on decode.  Does rpcgen
support app-defined encoding functions for particular fields?  If not, I
am doubtful that we will ever be in the position of being able to use
a .x file to define the kadmin protocol without starting over.

* Personally, I don't think hand-editing XDR code is a big deal, as long
as it wasn't my fault that we got into this position in the first place.
For better or for worse, rpcgen generates pretty readable and hackable
code.

* There've been some ideas for the future of kadmin that don't involve
ONC RPC, such as LDAP.  Lacking specific plans and resources allocated
to such a reboot, I have to assume that we'll be making evolutionary
changes to the current kadmin architecture for an indefinite period.

* I'm going to resist the temptation to get into a wide-ranging
discussion of network protocol architecture at this juncture.  Just
pretend I didn't say anthing about my personal like or dislike of
RPC-style network protocols.