From: Clive D.W. Feather (clive@demon.net)
Date: Tue Aug 28 2001 - 06:11:34 CDT
Curt Welch said:
>> 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).
It's little more than an "at" job.
> 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.
Removing the old group immediately has problems. It doesn't say "might do
it some time in the future", it says "might delay it by some time".
> 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.
The message has two actions, with a delay between them. That's better and
more robust that relying on two separate messages.
> 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.
Why ? Why are you unwilling to make the old group clearly *be* an old
group, even if you object to the delayed remove ?
> 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.
Most hierarchies have security measures in place for these control
messages. Nobody is suggesting that they wouldn't apply equally here.
> 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).
Sheesh. In other words, you're one of the causes of the misspelled groups
that go flying around the place.
If people didn't do that, then messages with spelling errors in the header
wouldn't propogate very far. Posters would soon figure out that the message
isn't going to the group desired, and would adjust the name accordingly.
With this autocreate bogosity, other people find themselves thinking that
the group is legitimate. That means it hangs around for longer.
> And it automatically
> removes groups when the articles have expired and the group
> has seen no new traffic for an extended period of time.
Even moderated groups ?
So a low-traffic group will keep appearing and disappearing, and during the
off time your users won't know it's there ? Instead they'll just create new
groups with names not quite the same as the one they mis-remembered ?
Yet you're unhappy to block the "old" group in a move, so that it can die
away more quickly ?
> 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.
Experience shows this is not ideal. A specific "don't use the old group any
more" process would help, rather than relying on people to "get the word".
> 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.
news != Usenet
And Tale looks rather like a central authority to me. As does the UK
Committee, and Dave Williams for demon.*, and ....
> You actually think that supporting "mvgroup alt.* hipcrime.*"
> is a good thing?
I think we've just about decided to remove the hierarchy rename bit. And
anyone crazy enough to run unauthorised group creation on autopilot is,
well, crazy.
> Merging articles? Like that's going to happen. Good laugh.
If it were practical, there would be obvious benefits. Which is a reason to
talk to server authors.
> 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.
Hmm. Interesting point. But, there again, newgroups get authenticated
elsewise, so there shouldn't be a spam problem.
-- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8371 1138 Internet Expert | Home: <clive@davros.org> | Fax: +44 20 8371 1037 Demon Internet | WWW: http://www.davros.org | DFax: +44 20 8371 4037 Thus plc | | Mobile: +44 7973 377646