String attributes feature (project review)
simo at redhat.com
Tue Sep 20 11:17:46 EDT 2011
On Tue, 2011-09-20 at 09:28 -0500, Nico Williams wrote:
> I believe that building an extension data keyed by text feature over
> TL data is a great idea.
> I'm less sure about the idea that the data must be text as well, but
> it's certainly most expedient. The alternative would be to make
> kadmin pluggable, but that'd also mean distributing plugins to the
> kadmin clients...
> A few comments:
> a) the key should be all US-ASCII;
What's the point of limiting it to US-ASCII when UTF-8 is a standard and
allows proper internationalization ?
> b) the key namespace needs more guidance/definition (e.g.,
> feature at domainname, a la SSHv2);
I would say that a vendor prefix makes for a better name space (and let
displaying code to more easily order alphabetically and get all vendor
related keys together with ease).
mit_otp_name = value
rh_otp_name = value
rsa_otp_name = value
> c) should any type information be included for the data part?
type is "string" so far ?
> d) how should binary data be encoded for storage as text data? There
> are many options, but it'd be nice if there was a single common
> recommendation (e.g., base64) and utility functions for it.
Yes, I agree we should recommend base64 in case someone needs to store
arbitrary data that is not valid utf-8
Simo Sorce * Red Hat, Inc * New York
More information about the krbdev