[1332] in Kerberos_V5_Development
kadm5 api, krb5_tl_data, type number assignment
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Tue Jun 18 15:35:41 1996
Date: Tue, 18 Jun 1996 15:35:29 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: krbdev@MIT.EDU
Chris previous expressed concern that the kadm5 api is dealing
directly with the krb5_tl_data instead of, say, a renamed
kadm5_tl_data. It will clearly be useful for kadm5 clients to be able
to manipulate a principal's tl_data for various reasons. A couple
possibilities:
1. Create a new kadm5_tl_data type and a new suite of functions
parallel to krb5_tl_* to manipulate it, and have the kadm5 api export
only that type, handling conversions between it and krb5_tl_data's
internally (as it does with all other krb5_db_entry fields).
2. The fact that we'd have to create a completely parallel data
structure and suite of functions just to avoid using something from
libkdb elsewhere in krb5 indicates that perhaps the first set
shouldn't be in libkdb in the first place. Thus, option 2 is to
remove the krb5_tl_data routines from libkbd, put them somewhere more
general (libkrb5, libkrb5util, whatever), and have kadm5 use
krb5_tl_data directly.
3. Admit to ourselves that what the kadm5 is really doing is
exporting a low-level feature of libkdb directly to callers and,
therefore, not get too upset with the fact that it is also exposing
the underlying data structure to do it rather than inventing a
duplicate that would serve no additional purpose. Option 3 is
therefore do nothing, leave it the way it is. The big disadvantage
here is that it means kadm5 rpc clients (programs that do not run on
the kdc) have to link against libkdb to get the krb5_tl_data routines.
Given these three, I'd say the mental attitude of 3 and the action of
2 are the correct choice.
On a separate but related topic, Marc has made the following
suggestion for the name space of krb5_tl_data tl_data_type values:
0 <= x < 256 reserved for internal use MIT
256 <= x < 32768 should only be used if registered with MIT
32768 <= x < 65536 application-defined
Comments? If we reach agreement, I'll add it to the kadm5 functional
spec.
Barry
