From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Tue May 01 2001 - 15:41:29 CDT
In <yl7l01epyk.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes:
>Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
>> Russ Allbery <rra@stanford.edu> writes:
>>> Or copying. Copying is marginally easier, but still quite possibly not
>>> straightforward depending on what your article store looks like. The
>>> fundamental implementation problem with mvgroup is that it breaks an
>>> abstraction inherent in some obvious ways of implementing article
>>> storage for the existing protocol.
>> No, is is irrelevant whether the moving is done by copying or tinkering
>> with pointers or any other way. My point is that our draft does not
>> require it to be done at all. So the question does not arise.
> When this message is received, the new group SHOULD be created (and
> MUST be moderated if a newgroup-flag "moderated" is present) and all
> existing articles SHOULD be copied or moved to the new group; then
> the old, now empty group SHOULD be removed.
OK, we are talking at cross purposes. Let us start over.
The text above actually changed earlier in this thread. It is now clear
that it refers only to the case where the new group does not yet exist.
It is in the case where the new group already exists (i.e. you are using
mvgroup to merge two existing groups) that copying of one group into the
other would be extremely nasty, which is why it is only a MAY (with a
strong hint that it is not likely to happen at all). We might even forbid
that case entirely, except that would seem to preclude booster mvgroup
messages, which may be needed from time to time.
So my references to "copying" were to that MAY-only case. The easier case,
where the whole of the old group needs to be transferred to the (initially
empty) new group I referred to as "moving" since I presumed that in most
implementations one would be altering pointers or directories or aliases
rather than actually copying bytes from one place to another. I cannot see
how doing that would compete with Rocket Science in most situations. And
using the "=" feature of the Active file would likely do a lot of the
work.
>>> It's a good idea, don't get me wrong. I'm entirely in favor of it
>>> being in our document. But it's not existing practice and it is a new
>>> requirement.
OK, so we just need to look at the details to see if we have said the
right thing.
>> Eh? Surely it is existing practice. If not, what is the existing
>> practice? What do you currently put in the Newgroups line of a control
>> message?
>Anything you please. People *should* post them to the relevant group, but
>it's quite common not to; a lot of the alt.* folks are under the
>impression that they can't post it to the new group (since that group
>doesn't exist yet) and therefore post all their control messages to
>alt.config. Some hierarchies post all the control messages to a
>designated control group rather than to the affected group, for whatever
>reason.
I have not heard of a hierarchy that does that. And for sure Tale has been
doing what we now recommend for yonks, and I think Tale could reasonably
be described as an "existing practitioner" :-) .
>The language in our draft seems to me at least to, if not require, then
>strongly suggest that servers reject control messages at least at
>injection that aren't posted to the affected group. I think that's
>actually a good idea. But it's a change. (One that I'd call
>"straightforward," for what it's worth.)
That would not be my interpretation, and I don't think it should be
required. If a valid (and preferably PGP-signed) control message manages
to find its way to your site (in spite of having an unsuitable Newgroups
header), then I think you should accept it (assuming you subscribe to that
hierarchy in the first place).
I think you have just convinced ne that the MUST in that paragraph (3rd
para of section 7) should be a SHOULD. Do others agree?
-- 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