The aim of the document is to discourage foolish people from advocating the use of friendly name addresses in the @cam domain. I guess a lot of the pressure for this could be relieved by supporting friendly name addresses @admin, so we're deliberately emphasizing that the current policy is not against friendly name addresses and in fact actively supports them, for example in the way the managed mail domain interface works.
I avoided a discussion of large departmental domains to keep the document short. It's a bit of a can of worms. There are questions of what categories of people you give email addresses to and what effect that has on the rate you chew through the namespace. In particular, if (like Chemistry) you exclude students, Engineering is less than a third the size of the UAS.
I expect admin will find out that they are large enough that they have significant problems with name clashes. In the past the CS would have tried to lead them away from that kind of trouble, but nowadays it's probably better to avoid seeming too obstructive.
One area in which the instigators of this make-work do not seem interested is to improve the way we use domain names. For example, if we allow large departments to have divisional subdomains (like Physics) then friendly name addresses become more feasible - though of course it has the downside of exposing more organizational complexity.
So yes, that's the kind of nuance and hedging I wanted to avoid in favour of simplified and direct language, so that non-technical senior managers can get a better idea of the considerations behind the status quo, and hopefully they'll think about more than just the surface appearance of email addresses.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2009-06-03 15:20 (UTC)The aim of the document is to discourage foolish people from advocating the use of friendly name addresses in the @cam domain. I guess a lot of the pressure for this could be relieved by supporting friendly name addresses @admin, so we're deliberately emphasizing that the current policy is not against friendly name addresses and in fact actively supports them, for example in the way the managed mail domain interface works.
I avoided a discussion of large departmental domains to keep the document short. It's a bit of a can of worms. There are questions of what categories of people you give email addresses to and what effect that has on the rate you chew through the namespace. In particular, if (like Chemistry) you exclude students, Engineering is less than a third the size of the UAS.
I expect admin will find out that they are large enough that they have significant problems with name clashes. In the past the CS would have tried to lead them away from that kind of trouble, but nowadays it's probably better to avoid seeming too obstructive.
One area in which the instigators of this make-work do not seem interested is to improve the way we use domain names. For example, if we allow large departments to have divisional subdomains (like Physics) then friendly name addresses become more feasible - though of course it has the downside of exposing more organizational complexity.
So yes, that's the kind of nuance and hedging I wanted to avoid in favour of simplified and direct language, so that non-technical senior managers can get a better idea of the considerations behind the status quo, and hopefully they'll think about more than just the surface appearance of email addresses.