ghudson at MIT.EDU
Fri Sep 4 17:30:21 EDT 2009
On Fri, 2009-09-04 at 14:56 -0400, Nicolas Williams wrote:
> MIT has already added non-standard GSS-API extensions. So has Sun. So
> has Heimdal. We're working towards having an IANA registry for GSS-API
> extensions. That should be good enough.
I should clarify my position:
* I am fine with adding unstandardized GSSAPI extensions which have a
well-defined purpose. (Thus, gss_acquire/add_cred_impersonate_name is
okay because that's how we do S4U.)
* I am fine with adding standardized GSSAPI extensions which we don't
have an identified need for, if resources are available to do so. For
example, I don't know if we have a current use for gss_store_cred, but I
wouldn't think to raise any objection on principle if someone wanted to
implement it in our tree.
* I see no benefit in adding unstandardized APIs for no particular
reason, nor do I see any benefit in standardizing
* When I said "code that isn't tested doesn't work," I meant that code
without an identifiable need is likely to bitrot or simply be non-useful
in the first place, even if it's covered by a regression test suite.
> I don't care that much. But this is the sort of thing where actual
> experience helps. So I'd rather it ship, preferably with a warning
> that it's subject to change/removal/... (That's what we did with
> gss_store_cred(), for example.)
I would much rather apply the YAGNI principle, since it is easier to add
interfaces than remove or change them.
More information about the krbdev