From: Brad Templeton (email@example.com)
Date: Tue Sep 02 1997 - 16:51:36 CDT
Well, I've been saying for some time that one of the biggest causes of
trouble and noise on USENET (particularly news.groups) is that groups
are a tree hierarchy of short, sometimes cryptic components. The short
part causes people to argue endlessly about names, because the name can't
be descriptive, and the tree part makes it worse because it really should
be a DAG, and there is no particular reason a group shouldn't be able
to appear in more than one hierarchy.
But when I've pushed for that, there seems to be pressure from the people
who love arguing over group names against this. And indeed, it does involve
some significant software changes.
The format group doesn't really have much to say about this. Group names
in the Newsgroups header would continue to be short symbolic names. But
suggesting that there be better descriptive names, and that they appear
in DAG based menus instead of the current hierarchies is valid, but it's
not sure where to say it.
However, there are some things in the spec that talk about "hierarchies"
and they would need some sort of recognition that a group can appear
in more than one hierarchy. (Links in filesystems are valuable and
similar value in negotiation and hierarchy based policy control can be
found with newsgroups having more than one name.)
If a group has more than one name, should it:
a) Have a "master" name for policy issues (ie. who has permission to
do things like 3rd-party cancels, subgroup etc.)
b) Allow things if any of the names matches a policy rule
c) Allow things only if all the names match? (unlikely)
For example if sci.aquaria is the same group as rec.aquaria, then indeed
a feed of rec or sci should get it. And a person able to do cancels
in "rec" should be able to cancel there, as should one in "sci".
Subgroups are more complex.