Re: choosing principal names

On 10/5/2011 3:00 PM, Nico Williams wrote:
>   Each application should document
> its principal naming requirements.
And so kick the can into the laps of the users: for each application 
they might now or in the future use:  to learn this whole obscure world, 
and how their proposed applications make use of it.  This innocuous 
sentence of yours if full stop, makes it the end user's job to decide 
whether the documentation applications provide does or does enshrine 
naming policies that might or might not collide with current and 
unspecified future applications that might or might not use gssapi or 
other middleware a few layers and two daemons down from where they live. 
    And if there are collisions, do the applications provide ways to 
mangle default config files beyond all recognition and so be obliged to 
maintain them forever, learning sasl_auth rewrite rule formats and other 
utterly avoidable minutiae or only if 'untainted on this os' ?

If they do not, can the other application have config file tweaks to 
make it possible to not collide with the stuffy one that just locks you 
into the default krb5.conf and that's that (gssd with it's solitary -d 
switch on freebsd... unless I'm willing to put into into a shell and use 
KRB5 environment variables to violate the gssd doc on freebsd and NOT 
use the default krb5.conf----  lotsa fun...)

Kindly reconsider.  Just name space guidance that will if followed 
disabiguate people from non-people, services from instances, clients 
from servers and manage the grey area of 'root real user'.

Please read the above charitably, I don't mean to be argumentative.  The 
policy you suggest of documentation is of course good -- but if not 
coupled with no guidance from the entity that defines 'principal' as to 
name format.  Lack of name space guidance raises the education, time and 
investment barriers obstructing widespread deployment and reduces the 
possibility of managing applications separately.

Thanks for reading

Harry