String attributes feature (project review)

[Simo Sorce]

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).
Something like:

mit_otp_name = value
rh_otp_name = value
rsa_otp_name = value
etc...

> 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.

-- 
Simo Sorce * Red Hat, Inc * New York