                         GROUP CREATION POLICIES
                        Last modified: 2018-02-19

  (This document was originally written by David Lawrence, but has since
  been updated and is currently maintained by Russ Allbery.  For all
  matters concerning this archive, please contact usenet-config@isc.org.)

  This document describes the policies by which the active and newsgroups
  files in this directory <ftp://ftp.isc.org/pub/usenet/CONFIG/> are
  maintained.  It describes first the addition and removal of groups in
  hierarchies that are covered, and then discusses what happens when we
  become aware of a new hierarchy via a newgroup control message.

  This archive updates hourly, and due to delays in propagation, it can
  take somewhat longer for control messages to be acted on.  If the
  control message was posted from a well-connected site, allow about two
  hours for its effects to be reflected in the active and newsgroups
  files.

  The intention is for the active and newsgroups files here to be complete
  for all publicly available hierarchies.  To that end, we appreciate when
  discrepancies with other authoritative lists are pointed out.  Please
  send mail to usenet-config@isc.org if you have such a discrepancy to
  point out.

  For a friendlier view of the information in this directory, including
  relevant log messages and recent changes, see:

    <http://usenet.trigofacile.com/hierarchies/>

  Given the volume of Usenet control messages and the number of
  hierarchies publicly available, some intentional, some not, it is
  unlikely that we'll be able to keep up with all new public hierarchies
  without help.  If you know of or are involved with a public newsgroup
  hierarchy that is not listed in control.ctl in this directory, please
  send a note to usenet-config@isc.org containing the details.  You may
  also want to look at:

    <https://www.eyrie.org/~eagle/faqs/usenet-hier.html>

  This message refers to "newgroup" and "rmgroup" control messages, which
  are special types of Usenet articles that add and remove groups,
  respectively.  Usage of this terminology implicitly includes
  "checkgroups", another type of special Usenet article that compares an
  entire list of groups with those carried by a server.  It also includes
  maintenance that we do in response to messages received not via the
  normal Usenet control messages, such as from a web site or through
  email.

  This document is expected to remain fairly static.  The canonical list
  of hierarchies for which information is currently known can be found in
  the file control.ctl in this same directory.  For documentation on its
  format, see the control.ctl(5) man page that comes with INN.  A copy is
  available on the web at:

    <https://www.eyrie.org/~eagle/software/inn/docs/control.ctl.html>

HIERARCHY MAINTENANCE

  Where a central authority nominally exists for a hierarchy, I honor the
  newgroups and rmgroups issued by that authority.  For example, the group
  additions and removals done by Ed Hew for biz.*, or UK Control for uk.*,
  or Marco d'Itri for linux.*, are honored here as definitive.  You can
  see which email addresses are honored by looking at the control.ctl file
  in this directory, fully known as:

    <ftp://ftp.isc.org/pub/usenet/CONFIG/control.ctl>

  Where no nominal authority exists for a hierarchy, the list of groups
  carried in that hierarchy were generally taken from whatever the
  generally agreed-upon set was, and are currently static.  (alt.* and
  free.* are exceptions; see below.)  We are willing but reluctant to
  change the list of groups on a manual basis if those changes are
  similarly generally agreed-upon by the users of that hierarchy.
  However, it is far better, if a hierarchy without a current authority
  needs changes, for someone to step up and volunteer to be that authority
  and issue real control messages for the hierarchy.

  The "alt" and "free" hierarchies are special cases.  In each hierarchy,
  all properly formatted newgroups (see below) are automatically executed,
  and all rmgroups are ignored.  No manual changes will be made in either
  hierarchy except under very special circumstances, and will require
  substantial justification.  Similarly, the moderation status and
  description of the newsgroup will be set to whatever was present in the
  last control message for that group.

  All newsgroup names consist of components, which are the elements of
  the name between the dots.  For example, "news.announce.newgroups" has
  three components, "news", "announce" and "newgroups.  No groups will be
  added that do not conform to the following standard for Usenet groups:

  - a component must not contain characters other than [a-z0-9+_-]
  - a component must contain at least one non-digit
  - a component must not contain uppercase letters
  - a component must begin with a letter or digit
  - sequences 'all' and 'ctl' must not be used as components
  - the name must have at least two components
  - the first component must begin with a letter
  - the first component must not be "control", "to", or "example".
  - the entire newsgroup name must be no longer than 80 characters

  Those criteria are based on the rules in RFC 5536.  At this time, only
  pure ASCII newsgroup names are accepted.  Unicode newsgroup names will
  be considered should they ever be standardized.  Entire newsgroup
  names are limited to 80 characters, rather than the soft limit of 72
  characters proposed by the standard, because two existing non-joke
  groups have names longer than 72 characters.

  In addition, to be automatically processed, control messages must be
  properly formatted Usenet messages containing an Approved header and a
  syntactically valid Control header.  "checkgroups" control messages must
  be no more than 256KB in size, and "newgroup" and "rmgroup" messages
  must be no more than 64KB in size.  "newgroup" control messages must
  contain a valid newsgroup description for the created newsgroup, which
  means there must be a line in the body reading, exactly:

      For your newsgroups file:

  with no leading whitespace, followed on the next line by a valid
  description line for the newsgroup (see THE NEWSGROUPS FILE for a
  discussion of the format of this line).  This description must not
  contain any control characters (octets between 0x00 and 0x1F).

  The newsgroup descriptions in the newsgroups file are taken from the
  most recent control message for that group, whether a valid "newgroup"
  or "checkgroups" message.

  While this archive does not place limitations on the Supersedes header,
  be aware that many control message processors refuse to accept control
  messages that have a Supersedes header due to widespread abuse.
  Supersedes serve little purpose in control messages, and senders are
  best served by not using them.

NEW HIERARCHIES

  If you are the maintainer for a hierarchy that is not already present in
  the control.ctl file in this directory, we strongly recommend reading
  the Usenet Hierarchies FAQ at:

    <https://www.eyrie.org/~eagle/faqs/usenet-hier.html>

  which contains information about how to have your hierarchy added to
  these newsgroup lists as well as how to make it easier for other sites
  to add your hierarchy.

  Briefly, please mail usenet-config@isc.org a valid control.ctl entry for
  your hierarchy, and if it already has existing newsgroups, please also
  send a pointer to the hierarchy web site with a list of newsgroups in
  checkgroups format or include that list in the mail message.  We also
  strongly recommend sending PGP-signed control messages for all changes
  to the newsgroup list, and sending PGP-signed checkgroups messages
  monthly for the entire hierarchy.  If you are using PGP to sign your
  control messages, you also need to send us the public key or a pointer
  to where it can be found.

  There are several legacy hierarchies that allow control messages from
  anyone in a certain region, and two (alt.* and free.*) that allow
  control messages from anyone.  Given rampant abuse of this capability,
  new hierarchies that allow anyone to send control messages will not be
  added without extremely compelling justification.  If the intention is
  to create a hierarchy in which anyone in a particular region or with a
  particular affiliation can create a group, we strongly recommend still
  using a central control message sender with PGP-signed control messages
  (possibly automated) and providing some way for people with the
  appropriate affiliation to request that it add a new group.  Otherwise,
  the hierarchy is likely to fill with junk groups that will never be
  used.

THE NEWSGROUPS FILE

  The newsgroups file is maintained by using the "For your newsgroups
  file:" lines from the individual newgroups that make each group, or by
  the entire list provided in a checkgroups message.

  As far as the format of the newsgroups file is concerned, there's a
  preferred format for each line.  Unfortunately, we do not have the time
  to fix up the lines that are being automatically included from newgroup
  messages.  This information is provided so that control message senders
  can craft better control messages.

  Here's what should be included for each line:

    group.name<tabs>description[ (Moderated)]

  There should be at least one hard tab (assume 8 column tab stops)
  between the group name and the description.  If the group name is at
  least 16 characters, follow it with one tab.  If the group name is at
  least 8 characters, follow it with two tabs.  In the unlikely event the
  group name is less than 8 characters, follow it with three tabs.

  The total line length should be at most 79 columns for good display in
  the traditional terminal width.  The description should start with a
  capital and not be more than 55 characters (79 - 24) long.  If the group
  name is 24 characters or more, the description should be correspondingly
  shorter so that the group name, a tab to the next 8-character tab stop,
  and the group description still fits in 79 columns.  For example, if
  the group name is 32 characters long, a tab to the next tab stop means
  the description will start at column 41 and should be no longer than 39
  characters (79 - 40).

  If the group is moderated, it should have " (Moderated)" at the very end
  of the description, not counted as part of the length of the
  description.  This text must be exactly that, with no variations, as it
  is used by news software to find moderated groups.

  Traditionally, all newsgroup descriptions ended with a period, but this
  isn't necessary and steals away one character that is occasionally
  useful for forming a better description.

  Some over-long descriptions could be made to easily fit the length by
  dropping "puff" phrases like "Discussion of" which don't meaningfully
  contribute to the description.  Others are usually pretty easy to get to
  no more than column eighty, except when the group names start getting
  really long.  Hopefully then the group name itself contains quite a bit
  of description.

  In some cases, a longer description really will be necessary, and the
  software maintaining this newsgroups file will not reject longer
  descriptions.  They may, however, be less readable and less useful for
  some Usenet users.

  Be very careful that your news client or other software that you use to
  post the control message does not wrap the description line.  If it
  does, any text that's wrapped will be ignored by most servers and will
  not be included in the description.

  There is, at present, no good mechanism for managing the character set
  of the newsgroup descriptions.  Many non-English hierarchies include
  newsgroup descriptions in their native languages, since this is more
  useful for their users, and those are included verbatim in this
  newsgroups file.  This unfortunately means that different lines of the
  file will require different character set settings to read properly, and
  those character sets are not documented in the file.  Hopefully some
  future standard will provide a way to address this; in the meantime,
  using UTF-8 for non-ASCII characters is recommended.

LOGGING

  Each action taken on the active group list, and each processed Usenet
  control message, is logged in the log files at:

    <ftp://ftp.isc.org/pub/usenet/CONFIG/LOGS/>

  The log files are by year and month when the control message was
  processed, and each log entry is time stamped.  All times are in UTC.
  Lines beginning with ACTION represent a change in the active and
  newsgroups files, and lines beginning with a message ID in angle
  brackets describe the disposition of a control message.

  The ACTION lines are:

    ACTION: newgroup            New newsgroup added.
    ACTION: changegroup         Moderation status of newsgroup changed.
    ACTION: changedesc          Description of newsgroup changed.
    ACTION: rmgroup             Newsgroup removed.

  Other lines can help if you're attempting to determine what happened to
  a particular control message.  If it was not archived, it will be
  mentioned in the logs with some error message (assuming it reached us at
  all).  If there is a log message stating that it has been processed,
  that means that it was received, was valid, and was recognized by a rule
  in control.ctl, but resulted in no change to the active and newsgroups
  files.  Control messages that have no error message but also have no log
  entry indicating they were processed did not match any rule in
  control.ctl.

  Archived messages are added to the control message archive at:

    <ftp://ftp.isc.org/pub/usenet/control/>

  See:

    <ftp://ftp.isc.org/pub/usenet/control/README>

  for more details on the archive policy.

COPYRIGHT AND LICENSE

  Copyright 2003-2004, 2006-2008, 2010, 2013
      Russ Allbery <eagle@eyrie.org>

  Copying and distribution of this file, with or without modification, are
  permitted in any medium without royalty provided the copyright notice
  and this notice are preserved.  This file is offered as-is, without any
  warranty.

  SPDX-License-Identifier: FSFAP
