From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Tue Sep 18 2001 - 16:28:02 CDT
Here, following the result of the Straw Poll, is my proposed text.
7.3. The 'mvgroup' Control Message
mvgroup-verb = "mvgroup"
mvgroup-arguments = CFWS newsgroup-name CFWS newsgroup-name
[ CFWS newgroup-flag ]
The "mvgroup" control message requests that the group specified by
the first (old-)newsgroup-name be moved to that specified by the
second (new-)newsgroup-name. Thus it is broadly equivalent to a
"newgroup" control message for the second group followed by a
"rmgroup" control message for the first group.
The second (new-)newsgroup-name MUST conform to all requirements
prescribed for the newsgroup-name of a "newgroup" control message
(7.1) and Ought, similarly, to conform to any established policies of
the hierarchy. The message body contains an "application/news-
groupinfo" part (7.1.2) containing machine- and human-readable
information about the new group, and possibly other subparts as for a
"newgroup" control message. The information conveyed in the
"application/news-groupinfo" body part, notably its newsgroups-line
(7.1.2), is applied to the new group.
When this message is received, the new group is created (if it does
not exist already) as for a "newgroup" control message, and MUST in
any case be made moderated if a newgroup-flag "moderated" is present.
At the same time, arrangements SHOULD be made to remove the old group
(as with a "rmgroup" control message), but only after a suitable
overlap period to allow the network to adjust to the new arrangement.
At the same time as a serving agent acts upon this message, all
injecting agents associated with that serving agent SHOULD inhibit
the posting of new articles to the old group (preferably with some
indication to the poster that the new group should have been used).
Relaying agents, however, MUST continue to propagate such articles
during the overlap period.
NOTE: It is to be expected that different serving agents will
act on this message at different points of time, users of the
old group will have to become accustomed to the new arrangement,
and followups to already established threads will likely
continue under the old group. Therefore, there needs to be an
overlap period during which articles may continue to be accepted
by relaying and serving agents in either group. This standard
does not specify any standard period of overlap (though it would
be expected to be expressed in days rather than in months). The
inhibition of injection of new articles to the old group may
seem draconian, but it is the surest way to prevent the
changeover from dragging on indefinitely.
[We could easily provide an extra parameter for the issuer of the
mvgroup message to suggest how many days the overlap should be. Does
anybody want to pursue that possibility?]
Since the "mvgroup" control message is newly introduced in this
standard and may not be widely implemented initially, it SHOULD be
followed shortly afterwards by a corresponding "newgroup" control
message; and again, after a reasonable overlap period, it MUST be
followed by a "rmgroup" control message for the old group.
In order to facilitate a smooth changeover, serving agents MAY
arrange to service requests for access to the old group by providing
access to the new group, which would then contain, or appear to
contain, all articles posted to either group (including, ideally, the
pre-changeover articles from the old one). Nevertheless, if this
feature is implemented, the articles themselves, as supplied to
reading agents, MUST NOT be altered in any way (and, in particular,
their Newsgroups headers MUST contain exactly those newsgroups
present when they were injected). On the other hand, the Xref header
MAY contain entries for either group (or even both).
NOTE: Some serving agents that use an "active" file permit an
entry of the form "oldgroup xxx yyy =newgroup", which enables
any articles arriving for oldgroup to be diverted to newgroup,
thus providing a simple implementation of this feature. However,
it is known that not all current serving agents will find
implementation so easy (especially in the short term) which is
why it is not mandated by this standard. Nevertheless, its
eventual implementation in all serving agents is to be
considered highly desirable.
On the other hand, it is recognised that this feature would
likely not be implementable if the new group was already in
existence with existing articles in it. This situation should
not normally arise except when there is already some confusion
as to which groups are, or are not, supposed to exist in that
hierarchy. Note that the "mvgroup" control message is not really
intended to be used for merging two existing groups.
7.3.1. Example
From: "example.all Administrator" <admin@example.invalid>
Newsgroups: example.admin.groups, example.admin.announce
Date: 30 Jul 1997 22:04 -0500 (EST)
Subject: cmsg mvgroup example.oldgroup example.newgroup moderated
Message-ID: <mvgroup-example.oldgroup-19970730@example.invalid>
Approved: admin@example.invalid
Control: mvgroup example.oldgroup example.newgroup moderated
Content-Type: multipart/mixed; boundary=nxt
--nxt
Content-Type: application/newgroupinfo
For your newsgroups file:
example.newgroup The new replacement group (Moderated)
--nxt
The moderated group example.oldgroup is replaced by
example.newgroup. Please update your configuration, and please
arrange to file articles arriving for example.oldgroup as if
they were in example.newgroup.
--nxt--
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