INTERNET-DRAFT                               Charles H. Lindsey
Usenet Format Working Group                  University of Manchester
                                             July 2001

7.3.1. Single group

7.3.1.  Single group
   The "mvgroup" control message requests that the first specified group
   be moved to the second specified group. The message body MUST contain
   a "application/news-groupinfo" (7.1.2) containing machine- and
   human-readable information about the new group, and possibly other
   subparts as for a newgroup control message.

   When this message is received, and the new group does not already
   exist, it is 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.

   If the old group does not exist, the message is ignored unless the
   new group does not exist either, in which case the message SHOULD be
   treated as if it had been an equivalent "newgroup" message.

   If both groups exist, the groups MAY be "merged". If this is done, it
   MUST be done correctly, i.e. implementations MUST take care that the
   messages in the group being deleted are renumbered accordingly to
   avoid overwriting articles in one group with those of the other, and
   that crossposted articles do not appear twice. Otherwise, the old
   group is just removed.

        NOTE: Due to the severe difficulties of implementing this
        merging, those proposing to merge existing groups using this
        control message should be aware that it may not be implemented
        on many (if not most) sites, and should therefore be prepared
        for such disruption as may ensue.

   An indication that the old group was replaced by the new group MAY be
   retained by the serving agent so that continuity of service may be
   maintained, and clients made aware of the new arrangements.

        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,
        and could even enable users already subscribed to oldgroup to
        receive articles from newgroup instead.

   In all cases, the information conveyed in the "application/news-
   groupinfo" body part is applied to the new group.

   Until most serving agents conform to this standard, whenever a
   mvgroup control message for a single group is issued, a corresponding
   pair of rmgroup and newgroup control messages SHOULD be issued a few
   days later.

Diffs to previous draft

--- {draft-04}	Wed Jul 11 21:56:04 2001
+++ {draft-05}	Wed Jul 11 21:56:04 2001
@@ -5,10 +5,11 @@
    human-readable information about the new group, and possibly other
    subparts as for a newgroup control message.
 
-   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.
+   When this message is received, and the new group does not already
+   exist, it is 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.
 
    If the old group does not exist, the message is ignored unless the
    new group does not exist either, in which case the message SHOULD be