[17179] in Kerberos_V5_Development
Re: String attributes feature (project review)
daemon@ATHENA.MIT.EDU (Simo Sorce)
Tue Sep 20 11:43:47 2011
From: Simo Sorce <simo@redhat.com>
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <CAK3OfOi9=6EtvWSsMJYABQ7iitXQJOLu1zfDp8_kkF61qchLkg@mail.gmail.com>
Date: Tue, 20 Sep 2011 11:43:35 -0400
Message-ID: <1316533415.2684.529.camel@willson.li.ssimo.org>
Mime-Version: 1.0
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Tue, 2011-09-20 at 10:31 -0500, Nico Williams wrote:> On Tue, Sep 20, 2011 at 10:17 AM, Simo Sorce <simo@redhat.com> wrote:> > On Tue, 2011-09-20 at 09:28 -0500, Nico Williams wrote:> >> 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 ?> > These sorts of keys don't need to be internationalized.> > Internationalizing lookup keys means handling normalization. That> seems way too heavyweight for the purpose of this extension.
Given you are talking about having a vendor prefix/suffix I would liketo be able to use a company name in its original form.
If my company name is Järvi Oy, I'd like to be able to to have'järvi_otp_name' as the name of the option instead of distorting thename.
> >> b) the key namespace needs more guidance/definition (e.g.,> >> feature@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...> > I don't care what it looks like, as long as we have a naming> convention that helps prevent collisions.> > If you want the keys to sort nicely, though, you should want a vendor> *suffix* :)
I think it is more important to group options by vendor, which is asimple alphabetical ordering if you use a prefix.But whatever ...
> >> c) should any type information be included for the data part?> >> > type is "string" so far ?> > Sure, but the string's form is given by the kind of data being stored> in it. A type indicator would be completely superfluous, I agree, but> it might help users (think of a URL to documentation of the given> key's value format).
Sounds like just too much. In general the value is a simple string, inthose cases where it is not you have to document yourself to understandwhat it is anyways.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
