From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Tue Aug 28 2001 - 04:04:39 CDT
In <GIpyLw.7pz@clw.cs.man.ac.uk> chl@clw.cs.man.ac.uk (Charles Lindsey) writes:
>In <200108241800.OAA15160@darkstar.prodigy.com> davidsen@prodigy.com (Bill Davidsen) writes:
>>curt@kcwc.com (Curt Welch) wrote:
>I didn't see this. Was it posted to this list, and can it be reposted (or
>will I find it in the archive)?
OK, I found it in the archive. Don't know why it didn't arrive the proper way.
>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.
OK, I can imagine the spec saying that the 'mvgroup' SHOULD do a
'newgroup' and SHOULD inhibit new posting to the oldgroup and MAY do
aliasing or moving articles across or whatever, but that it is the
responsibility of the hierarchy admin to issue the 'rmgroup' later on, at
whatever time he considers right (though 30 days might well be about right
in practical cases).
OTOH, many site still have 'rmgroup' set to manual (or to ignore) and
might still have it so even if they accepted 'newgroup' and 'mvgroup'.
>
>
>> 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.
Hmmm! I don't think I like the idea of automatically creating the group
when someone mis-spells it in a Newsgroups line (and such would not be
compliant with our draft, nor with son-of-1036). However, doing it your
way, I can see that you would not have to do anything at all when a
mvgroup arrived, but you are atypical of server implementors in general on
that score.
>
>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.
No, that doesn't really work in the real world, which is why it is so
rarely attempted. The least you need is to block posting to oldgroup ASAP,
and preferebly to divert articles to newgroup automatically as well.
>
>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....
There are central controlling authorities in many hierarchies (even for
the Big 8) which work quite well. I don't think abyone expects 'mvgroup'
to be much used in alt.* or free.*.
>
>> 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).
Yes, I think a lot of the benefit would come from just that.
>
>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.)
Indeed, but I don't think we can manage more than MAY (with strong hints
of 'should-in-lower-case') because it is a pain to implement in some
schemes (which is why we wanted to consult more actual implementors).
>
>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.
>
Yes, the draft would allow all those things.
>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.
>
Yes, bitching is the ultimate coercive tool on Usenet :-) .
>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.
I don't see that the abuse issues are any different than with 'newgroup'.
And pgpverify has removed most of those abuses, for sites that take the
trouble to check it.
>
>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.
I think we are already agreed that the 'mvgroup alt.* ...' bit needs to
go, whether we keep the rest of it or not. Not because it can be abused (a
newsadmin who automatically accepts _any_ control messages for alt.*
deserves all that he gets) but because it does not scale well - a server
might grind to a halt it it tried to move all those groups around.
>
>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....
It could be a useful tool for newsadmins to use to inform their own
clients of changes that affected only their own subnetwork (for example,
that a 'mvgroup' had happened, and that users had better subscribe to the
newgroup). But maybe we shall review it later on.
>
>The rest of what I said however remains valid however. :)
>
>Curt
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clw.cs.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5