From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Fri Aug 24 2001 - 10:08:00 CDT
On Thu, 23 Aug 2001 10:10:44 +1200
Chris Pugmire <chrisp@netwinsite.com> said...
>
> At 09:12 AM 8/23/01 +1200, you wrote:
> >The IETF Usenet Format working group (grandson of 1036) has been
> >considering a 'mvgroup' control message. ...
[snipped]
> Hmm, Thanks for asking :-)
OK, I hope you don't mind my copying your reply to the Working Group.
Reply-To the WG as before.
>
> In our system moving existing items to a new group requires rewriting
> the headers in order that the items reflect the group they appear in
> (and so that follow ups from news clients go to the new group not the
> old one etc). As such it's a very expensive operation, and prone to
> cause problems (for example doing this to a large binary group could
> cause disk shortage problems. and someone abusing it with thousands of
> groups could cripple every server they managed to get it actioned on)
>
No, the idea was that the Newsgroups header would NOT be rewritten
(you are free to write what you like within Xref, of course). As Henry
Spencer said recently, "rewriting headers is Evil". Our whole draft is
based on the maxim that everyone on Usenet sees the identical article
(except for a limited number of 'variant' headers such as Path and
Xref).
But is there actually any problem from the Server's POV of having an
article with a Newsgroups header that does not include the group under
which it is stored? I would have thought the problems (if any) would
have arisen only in the News Readers. In my CNews test, all that happend
to existing articles was a Unix 'mv' to the new directory (new articles
being diverted there automatically).
As to News Readers, one of the problems is that followups will likely go
to oldgroup (unless the News Reader is unbelievably smart), but there
is not much to be done about this. In the aftermath of a 'mvgroup'
there are bound to be lots of articles still arriving for oldgroup:
some that were in transit before the changeover, some from systems that
have not (or will not) upgraded, and some that are followups (even from
upgraded systems, though such systems will hopefully post new articles
correctly).
On servers that have implemented that MAY option, all these 'misposted'
articles will automatically be diverted to the newgroup. On other
servers, users will have to remain subscribed to both groups for some
while. Some degree of confusion is bound to follow any 'mvgroup', and
the pundits and the netcops on the group itself will have to work it
out. But the argument is that the confusion would be far worse under the
present newgroup/rmgroup scheme, and the confusion should in any case
decrease as more servers get around to implementing that "MAY".
> So I think that option 5) regarding existing items should be a 'MAY'
> (and infact option 5 needs to be split into two halves so this can be
> clear)
Currently, they are both suggested as MAY, but the distinction might
be made (my summary was not meant to be the actual text that would be
written into the draft).
>
> Option 5 regarding new items being redirected to the new group if from
> other systems, this seems reasonable.
>
> I think the standard should say that local posts must be blocked
> and the user given an error (please post to group x.y.z instead) as
> otherwise the user will not find out what is going wrong and may post
> repeatedly in an attempt to get the posts to appear.
Yes. That is a fairly ruthless way of overcoming the followup problem,
but would likely have the desired effect fairly rapidly. Unfortunately,
such a ruling would fall foul of the rule that says only one of the
Newsgroups posted to needs to exist locally, but at least it would cope
with all not-crossposted followups.
>
> However, what happens if someone messes up and does this between two
> valid news groups, how is the damage un-done ? Does there need to be
> a command to remove this redirection without deleting the original
> group?
Doing a 'mvgroup' between two existing groups (perhaps as an attempt
to merge them, but more likely the result of some cockup) probably
means that a server needs to keep both groups around, and just cannot
implement the MAY bit. The draft might well deprecate the practice (the
present draft contains dire warnings regarding this case). That will
not prevent the cockups, of course :-( .
>
> Note that sucking servers will not get these control messages, and so
> will never know that the group name has changed in this way (unless
> this information is encoded in a standard way inside the list active
> response or from the 'group' response), however the user will be
> informed if local posts are blocked properly so it will basically
> work.
A sucking server that aims to keep a decent newsspool ought to suck
the control.* groups. That is what my home setup does (except for
control.cancel).
>
> One final thought, the whole newgroup/rmgroup system is not very
> reliable in my opinion, I've always felt that if someone wanted to
> change how this system works then a central web site with a reliable
> trusted list of groups would be much simpler to implement than the
> current pgp/control message system. Maybe this has already been
> discussed to death if so I apologize for mentioning it, but I would
> certainly favour a change in that direction if you are going to mess
> with this part of usenet.
TINC
>
> I'm not really keen on adding such new commands, but we can and will
> implement it if it is in the new standard.
Good!
>
> I hope some of the above thoughts are useful, if not please ignore them :-)
>
> ChrisP.
Thanks for your comments.
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