From: Curt Welch (curt@kcwc.com)
Date: Thu Aug 23 2001 - 13:16:22 CDT
I'm not subscribed to the list, so if anyone want me to
see follow-ups to this message, be sure to cc me (curt@kcwc.com).
I run NewsReader.Com and wrote the news server which is used
by the serivce, so I'm writting this just to let all of you
know my point of view on this mvgroup issue.
> 2. The actual rmgroup part SHOULD be deferred for a
> reasonable period (between 1 to 30 days, though I would
> not want to specify precise figures) to allow articles
> in transit and from injectors not yet upgraded to continue
> to arrive.
This is just bogus. First, from the implementation point
of view, it's a bitch to implement a delay like that (not
hard, just a bitch because there's nothing else in the
server that needs a delay like that). Second, from the
usage point of view, the effect of the command should be
well defined. Either it does something or it doesn't do
something. This "might do it some time in the future" type
of definition just stries me as wrong.
Whenever you send a control message you understand that not
all servers will honor it. And some might wait for a sysadmin
to act on it so their might be a delay. But to define the
effect of the message as "SHOULD delay" is just the wrong
place to start. If you need a dealy, then that should really
be done by the person sending the control messages. Let
them figure out when it's time to send a rmgroup if a
delay is really needed.
> 3. Perhaps local posting to oldgroup to be stopped
> immediately ('n' in active file in some implementations).
> That might be at the MAY/Ought/NOTE level.
> 4. Perhaps retention of articles after the (deferred)
> rmgroup until they expire ('x' in active file). That is
> certainly NOTE level I think, though it is common current
> practice.
> 5. New articles arriving for oldgroup (and even existing
> articles in oldgroup) MAY be placed in (or transferred
> to) newgroup ('=newgroup' in active file).
> 6. In a NOTE, explanation that the MAY is because existing
> systems are unlikely to offer this feature (at least for
> some time), but with some encouragement to move towards
> that goal (perhaps even threaten MAY->SHOULD in a future
> standard). Also a warning that such merging may never be
> possible if both groups exist already and both contain
> articles.
> 7. In a NOTE, warning that the effect of 5 could be that
> the newsgroups listed in the Xref header might include
> oldgroup or newgroup or both.
> Item #5 is the problem. In the present draft, that MAY
> is a SHOULD, but INN would have some difficulty in
> adapting the '=newgroup' flag in its active file to do
> the job because of its somewhat bizarre internal stroage
> structure (to be fixed someday, perhaps). OTOH, I did an
> experimental implementation using CNews without undue
> difficulty (but CNews is hardly a major player nowadays).
>From an implementation point of view, none of the above ideas
would really be hard for me.
But, I can tell you for sure that no matter what goes in
the draft or the standard, my server will never treat a
mvgroup as anything other than a "newgroup" alias. Though
I could see that posting the mvgroups to the old group as
well as to control.mvgroup just as form of notification
to the readers of the old group might be a good idea.
However, I will NEVER remove a group, block posting to a
group, or cause articles to be posted elewhere, simply
because I received a control message asking me to do that.
The abuse potential is way too high. My server creates
groups automatically for all new groups (not just newgroup
control messages, but anytime it sees an article posted to
a group which doesn't yet exist). And it automatically
removes groups when the articles have expired and the group
has seen no new traffic for an extended period of time.
This makes group administration an (almost) zero-maintenance
item for me and I don't intend to change that.
If you want to rename a group, just create the new group
and get everytone to switch to the new group. Once everyone
has switched, send out the rmgroup.
I think the idea of a mvgroup control message on usenet is
mostly bogus. It's a good idea for a distributed discussion
system which has a central authority controling it, but
since there is no central authority on Usenet, then it can't
really work. So for Usenet, I think it's mostly a waste of
time. But....
> The argument for including 'mvgroup' in the present draft,
> even with that "MAY" in it, is that it will at least give
> notice that 'mvgroup' is definitely going to happen,
> which will encourage hierarchy admins to start using it.
> The argument against is that it would be better left as
> an "experimental protocol" until we see whether it catches
> on or not.
I don't really have a problem with mvgroup going into the
draft. If nothing else, it does give the hierarchy admins
a clear way of transmitting intent to all the news admins.
i.e., we are renaming a group. This is something that happens,
and it's never an easy job, so giving the heirachy admins
another way to get the word out can't be a bad thing (as long
as you don't open up yet another abuse hole).
The meaning of the control message however should be
simple and clear. Is should mean, "rename the group NOW".
It's understood that all news servers and news admins
will end up doing what they feel is "right" with these
messages, and what they feel they "can" do based on their
design, but the draft should read...
1) The new group SHOULD be created.
2) All articles arriving from peers which list the old
group SHOULD be filed under the new group instead of the
old group (this will be reflected in the Xref:, but the
Newsgroups: line of course should not be changed.)
3) Any local users trying to POST to the old group
SHOULD have the POST rejected with a message indicating
the reason and the name of the new group.
What happens to the old group isn't imporant as long as the
above 3 things happens. So I think the draft should mostly
just ignore the issue. Either the old group can be removed
(with or without a dealy) or it can remain on the server.
What happens to the old articles likewise isn't important.
Either they can all just vanish (not the best option, but
OK), or they can remain available in the old group, or they
can be moved to the new group (or get there simply because
the old group was simply renamed internally), etc. etc.
The combination of #3 above (reject post), and #2
(cross-file articles from other peers), will cause problems
for the posters. If they try to follow-up to one of those
cross-filed artices, their post will be rejected. But I
think that's the way it should would. It will encourage
the users to force everyone to switch instead of allowing
the old group to live on for years.
If only a small handful of servers rename the group,
the users on those servers will keep bitching until
everyone has stopped posting to the old group.
In summary...
First, mvgroup is questionable for Usenet because of the
abuse issues. But it's not worthless because it does help
communicate the intent even if most servers will have it
disabled. I wouldn't waste my time adding it to a standard,
but I don't mind if ends up as part of the standard.
Second, I for one, will probably ignore it because of the
abuse issues, and because group renames already work fine
on my server and require no attention on my part.
Third, if you do add it to the standard, just make it simple
and obvious and don't over specify what the server should
do with it. The above 3 SHOULD's I think is all that is
needed to clearly describe the "correct" way for a server
to implement the control message. If any server decides
not to do it that way, it's no big deal. The intent of the
message is clear no matter what the server does with it.
Ugh. I wrote all the above without reading the draft. But
I just scanned it before I hit send. You guys are funny. :)
You actually think that supporting "mvgroup alt.* hipcrime.*"
is a good thing? What Usenet do you live in anyway?
Merging articles? Like that's going to happen. Good laugh.
The initial message (application/news-tranmission) stuff is
likewise a stupid thing to do. It totally breaks all the
current spam filters and feed file logic. You guys are spending
a lot of time solving non-problems in my mind. Good luck
with all your hard work....
The rest of what I said however remains valid however. :)
Curt