🚀 go-pugleaf

I was very surprised to find out in the past week or so that the bit
groups are leaking out to Unix land and that the Unix folks are unhappy
about various things about them.  There is an NNTP managers discussion
list (nntp-managers@ucbarpa.Berkeley.EDU) where they discuss stuff.
To join it, send email to nntp-managers-request@ucbarpa.berkeley.edu.
This is a person, so you just write and ask to be added to the list.

What follows are much edited (by me - to save space and your time
reading) excerpts from their discussions over the past few months.
The last item listed was written to this list by Bill Verity of PSU
and very much reflects my position on all of this.

What do you think?  We need to talk among ourselves and with them about this.

=========

Here's the contents of all the mail I saved on the controversy.  Basically
it boils down to this:

1. both psuvm and ucbarpa gate bit.all onto into USENET.

2. At some site(s) downstream, they get gated back into mailing lists.

3. At some further point along the line, they come back in again, and there
   they overwrite each other repeatedly because they have the same message
   ID's, etc., etc.

4. The net result (excuse the pun) is that things are left in an uncertain
   state, there are multiple copies of the same article, duplicates end up
   on the list, etc.  Things then get really ugly...

What Eric and other folks want to do is for you and he to agree on a plan of
action so this behavior is stopped.  I suspect that will require some minor
modifications on both sides.  I stand ready to help, if I can.

My personal feeling is that a change has to be made, but that it has to be
made ``in situ'' (obviously lots of folks have come to rely on NETNEWS), and
that some sort of name rewriting should be done to map the names correctly.

===========

 It is time for me to throw down the gauntlet - I'd like you all to
 stop distributing the bit.* newsgroups. Here's why:

 1. they have bad names - we went through considerable pains years ago
 to set up a reasonable hierarchical name space. The names they're
 choosing are very poor by comparison. It is long past the time that the
 LISTSERV based mailing lists should have been integrated into the
 standard 7 top level name space, with mail/news gateways.

 2. there should not be a bit.* for the same reasons that there should
 not be a .bitnet top level domain name. USENET is a topic oriented,
 information network that spans many transports. It should not have
 transport specific names for its topics except as the topics in
 question related to the maintenance of that transport system (i.e. I
 have no objection to an "inet.operations" that is about operational
 problems of the Internet, I just don't want anything *else* to be
 inet.*).

 3. Many of the LISTSERV groups duplicate Internet mailing lists and
 USENET newsgroups, and therefore have messages with the same
 message-IDs transiting them as their USENET counterparts. This will
 lead to problems in distributing the USENET newsgroups, because you'll
 have <1234@foo.bar> in bit.listserv.barf, and comp.barf. Only one of
 them will get that message - and it will depend on which one arrives
 first. Very Bad Stuff, Folks.

 I have been looking for a BITNET site with UNIX systems and netnews,
 and some reasonable expectation of stability who can set up the
 software to gateway the LISTSERV stuff with netnews and make it work
 long term. Any volunteers? Once we find that person/site, the final
 question is one of name choices for each LISTSERV group.

===========

 A related issue is BITNET headers.  The last time I looked (a couple
 months ago) at groups being gatewayed into bit.all there were far too
 many
         From: WHOEVER@FOOVM

 to interoperate comfortably with email.  Perhaps this has
 improved--I don't know.  In any event, if you do find someone willing
 to gateway LISTSERV into the traditional USENET hierachy, which I think
 is a Good Idea by the way, I'd like to see that gateway do some (gasp)
 header munging.

===========

 I suspect the problems Erik is pointing out occured because bit.all
 started out to solve one problem and grew, and perhaps because the
 gateway people are not old USENET hands.

 >  It is time for me to throw down the gauntlet - I'd like you all to
 >  stop distributing the bit.* newsgroups. Here's why:

 We should -*<NOT>*- stop distributing the bit.all newsgroups while the
 problems are being fixed.  Users are benefiting from what we have now,
 and we shouldn't arbitarily cut them off.  If we want to ask further
 sites to carefully consider not joining the bit distribution until the
 problems are resolved, that's ok.

 >  1. they have bad names - we went through considerable pains years
 >  ago to set up a reasonable hierarchical name space. The names
 >  they're choosing are very poor by comparison. It is long past the
 >  time that the LISTSERV based mailing lists should have been
 >  integrated into the standard 7 top level name space, with mail/news
 >  gateways.

 The names chosen are the same as the list name on BITNET.  This means
 8 characters or less.  This does result in losing names relative to
 USENET practice.

 It's my understanding that bit.listserv.all (all of bit.all except
 bit.general (the hierarchies' news.admin)) was originally set up to
 let BITNET system administrators have the better user interfaces of
 netnews readers to more efficiently handle their daily list
 consumption.  This is the reason they were gotten into BU (and to save
 me some time, the IBM staff wanted me to gate more and more LISTSERV
 lists into our local mailing list newsgroup tree).

 Re-naming these groups away from their listserv names is a dis-service
 to the BITNET part of our readership (but read on).  It also spreads
 them over the namespace, so it be harder for an IBMer to find them
 all.

 It's also possible that some LISTSERV lists will not want to be in the
 USENET mainstream hierarchies.  For example, info-nets@think.com is
 gated to LISTSERV INFONETS@BITNIC, and info-nets did not wish to join
 the USENET mainstream when the inet distribution was set up.

 There should defintely remain a bit distribution used as inet is now.
 (Hmm, will spaf issue 4 checkgroup messages?)

 >  2. there should not be a bit.* for the same reasons that there
 >  should not be a .bitnet top level domain name. USENET is a topic
 >  oriented, information network that spans many transports. It should
 >  not have transport specific names for its topics except as the
 >  topics in question related to the maintenance of that transport
 >  system (i.e. I have no objection to an "inet.operations" that is
 >  about operational problems of the Internet, I just don't want
 >  anything *else* to be inet.*).

 bit.all is less a transport name, than a community of people on IBM systems
 often talking about IBM system issues (though they are lists that are
 of general interest).

 I'm not convinced that totally closing down bit.all is a good idea.
 The IBMers are going to be living with LISTSERV and the constrained
 environment it lives in for a long time yet.  At the least there
 should be a cutover period of many months.  Also, many of the LISTSERV
 lists are not of interest to most of USENET being concerned with
 technical details of IBM systems (much like the vmsnet, unix-pc and
 u3b alternative hierarchies).

 >  3. Many of the LISTSERV groups duplicate Internet mailing lists and
 >  USENET newsgroups, and therefore have messages with the same
 >  message-IDs transiting them as their USENET counterparts. This will
 >  lead to problems in distributing the USENET newsgroups, because
 >  you'll have <1234@foo.bar> in bit.listserv.barf, and comp.barf.
 >  Only one of them will get that message - and it will depend on
 >  which one arrives first. Very Bad Stuff, Folks.

 Agreed, duplicate gateways into different newsgroups is the one thing
 about the present situation that is Evil! {-!  And it's the first
 thing we should get fixed.

 A solution is to have the gateway site cross post in a single article
 to both a bit.listserv group and a better named newsgroup in the
 USENET mainstream hierarchies.  The extra inodes, bytes and processing
 time are not a large issue compared to user dis-convienence.  Later
 on, as desired, some/many of the bit.listserv.all newsgroups can be
 deleted and the mainstream newsgroup used.

 Another solution is to leave things as they are, except to cross post
 where the USENET mainstream and bit.listserv.all both want the group.

 Suggestions:

 * Give PSUVM.BITNET a chance to offer to fix this problem, before we
 hunt for a new gateway.

 * Erik should move the BITNET lists gated at ucbvax to which ever
 BITNET site takes this duty on.

 * There are quite a few bit.listserv.all groups that have USENET
 newsgroup and/or internet mailing list equivalents, but are not gated.
 The gateway site could offer to join them, when all sides are willing.
 BITNET does have a LISTSERV for announcing new LISTSERVs making this
 easier to do as an on-going activity.

 * The gateway site should definitley get the address in headers right.
 At least: FOO%SITE.BITNET@cunyvm.cuny.edu .

===========

 Let me take the devils advocate position for a moment ...

 The stand you are taking is like:

 > The stuff you've spent n years developing and tuning
 > for the needs and limitations of your environment
 > are totally worthless.  You should throw away all of
 > that hard work and user training and join us in this
 > bright wonderful new world of Usenet.

 Yes it would be nice if they did things like we did.  In the same vein,
 It would be nice if the UUCP world would stop worrying their silly
 heads over routing issues and just do it "right".  Same problem,
 there's a difference in how a couple of communities are doing things
 and they're trying to do their things in concert.  But they have lots
 of inertia behind doing things in some particular way -- changing the
 usage pattern of hundreds of thousands of users is very hard to do.

 We won't get BITNET to embrace Usenet software and techniques of
 communication if we're looking down our collective noses on their
 previous efforts.

 Let me suggest a more middle road position which might require
 more work than somebody's willing to put in

   Let them have a bit.all hierarchy.  For one thing "we"
   cannot stop them from having one.  For another thing it
   would allow those sites, who are leery of throwing hundreds
   of megs of disk storage at some strange thing those silly
   Unix people run, to join Usenet at a lower cost.

   Investigate which of the current bit.listserv things are
   actually redistributions of existing Usenet things.  Gateway
   those properly.  Also you will come across some with the
   same topic base as existing Usenet things -- gateway these
   as well.  One I know of is "AMIGA-L" which could stand
   to become an appendage of comp.sys.amiga.

   Can the gatewaying be done in/out of multiple groups?  This
   was an idea I had during alt.sca -> rec.org.sca which might've
   appeased Matt.  I see a (possibly) solvable problem right
   off.  Articles originating on Usenet will, with current software,
   be in one or the other group -- how to get the article into
   both the other half of the newsgroup and also get it to
   the mailing list. ----er---- if I could wish for a new software
   feature right now it'd be "paired" newsgroups ...

 Paired newsgroup: This would be a way to have an arriving article which
 is in one newsgroup to be automagically cross-posted into another newsgroup.
 There'd be a file, call it "pairs", like so

   comp.sys.amiga bit.listserv.amiga-l
   news.bitnet    bit.general
   ...       ...

 This would allow each site to extract out certain subsets of the newsgroup
 space into another hierarchy which would have meaning local to particular
site.
 And if there were a way of coordinating the pairings then bit.all could
 be bit.all and *also* in the "mainstream".

 Sorry .. I got off on a tangent ...

 Basically I feel you're taking a slightly extreme stance and might want
 to tone it down a bit.  I understand and agree with where you're coming
 from but politically it might be better to do otherwise ..

===========

 Perhaps I missing something, but why do we care if we move the name of
 the BITNET-gatewayed usenet groups away from their LISTSERV names?  If
 someone is in the IBM world, they'll have to use the LISTSERV names,
 without any questions.

 If an IBM person has managed to get access to a real system (I don't
 consider a system which is based on the emulation of punched cards real,
 but let's not start that flame war....) which happens to have Netnews,
 why not introduce him/her to the entire gamut of newsgroups --- among
 which are the BITNET gatewayed groups.

 I guess my main puzzlement is why the arguments which people are
 advancing in favor of a bit.all not apply towards having an inet.all.
 I haven't noticed any problems with having the inet groups distributed
 amongst the mainline hierarchies.  Why should bit.all be any different?

===========

 Point a: Distributions were hacked in after the fact and don't work
 that well in practice.  As a concept, it's hard to understand.  It
 doesn't help that the Distribution: field of many messages are
 downright "broken."

 Point b: The listserv name <-> newsgroup name translation should not
 involve any lookup tables; otherwise, you'll turn away people wanting
 to convert from BITNET e-mail to news reading.

 Both point "a" or point "b" imply that bit.* should be in its own
 chunk of the hierarchy, like gnu.* or vmsnet.*. In my opinion, the
 name should reflect, in some sense, the "administrative domain" the
 groups are affiliated with; anything else leads to chaos.

===========

 OK, some clarifications:

 1. I do not wish to stop BITNET from having a bit.* heirarchy and
 having it contain anything that they want.

 2. I *do* wish to stop the propagation of bit.* OUTSIDE of BITNET,
 unless it meets some constraints; primarily these constraints are to
 prevent interoperability problems.

 3. I recognize that there is much of value being discussed in the
 LISTSERV forums, even if the packaging leaves something to be desired.
 It is my end goal to see these discussions at least in properly named
 inet groups, and preferably in standard USENET groups, available to
 any interested party.

 4. Since NNTP-Managers is about a protocol used (among other things)
 for moving news over the Internet, I presumed that my audience was
 administrators of Internet USENET sites; these arguments, except as
 further propagated by you all to other interested parties, are not
 reaching BITNET-only USENET sites (I know that there are some dual
 membership sites), so I wasn't exhorting BITNET sites to "throw away
 years of work" on my say so.


 What the BITNET people should realize, however, is that to the extent
 that they import Internet mailing lists into LISTSERV forums that then
 become bit.* newsgroups, they will not be able to properly receive the
 USENET/inet equivalent newsgroups, because of Message-ID conflicts.
 When the bit.* newsgroups are exported outside BITNET, this problem
 spreads. I have been seeing many of my netnews neighbors begin carrying
 bit.* and I'm trying to nip this problem in the bud.

 Netnews is a powerful, ennabling technology. I hope that the BITNET
 people make good use of it. If they run a netnews distribution network
 in isolation, they can do whatever they want with it. Just like running
 your own private IP network that isn't connected to the Internet.

 However, when they want to exchange with the rest of us, we *must*
 agree on the newsgroup names (particularly those gatewayed to other
 distribution systems, like Internet mailing lists), in advance.
 Otherwise, we end up with a mess, and the system as a whole stops
 working.

===========

 If the Bitnet sites expect their users to now use newsreader
 interfaces to read the bit groups, then they can have them learn a new
 naming scheme at the same time.  If Bitnet II can go TCP, then surely
 the users can learn a new naming scheme.

===========

 There are several reasons why moving groups from bit.listserv.* in the
 mainstream 7 is a bad idea:

    * A goodly number of the bit.all newsgroups are not of
 interest to most of USENET and shouldn't get world distribution.
    * Users are use to the bit.all and LISTSERV namespaces.  This
 wasn't the case when inet was set up.  There was a clean slate, and no
 one lost their mailing list access, they were just seduced over to the
 inet newsgroups.
    (Note, I'm always leery of arguments from administrators about
 things that make their lives easier and users lives harder, though
 that isn't the case here, yet).
    * USENET news is read under CMS (and maybe other IBM O/S's).

 I've seen little comment about having the gateway crosspost to both
 bit.all and the mainstream 7, for those groups that are appropriate.
 Seems the best solution to me.

===========

 ...  What do we get to do to enforce our ideas of
 "what is right"?  Simply put, the same as any other administrator.  By
 a concerted statement by the NNTP-managers that bit.* newsgroups will
 not be distributed, under such names, but, for the Internet/Usenet
 community, will be available under other names, we solve the problem.
 This does not limit what BITnet sites choose to call their groups, the
 only important thing is that the gateway software functions properly.
 Should there be griping and complaining, we have a ready answer:  the
 Message-Id problem.  While this is the least of the problems caused by
 the current situation, it is an undeniable result of the current chaos.

 As for the more general proliferation of top-level namespaces, I am
 heartened to see that, with the exception of bit.*, they all seem to
 fit the original idea of the "big 7".  They all are topic-related, not
 trasport-related.  Unmvax has alt, bionet, biz, ddn, gnu, pubnet, u3b,
 unix-pc, and usrgroup (defunct).  And then bit.* messes things up.
 These are all hierarchies to discuss issues of a particular nature,
 not just forums classified by transport apparatus of origin.  Alt is a
 possible exception; regard it as groups not supported by a sufficient
 number of people to warrant transfer as a "standard group".  The other
 hierarchies are similar as well.  There isn't really any problem with
 proliferation.  Except for bit.*, there is a real reason behind the
 separation of each of these.  Limited interest (alt, bionet, u3b,
 unix-pc, usrgroup), legal questions (biz, alt), and centralized
 control (gnu, bionet) are all common reasons for such separate
 hierarchies.  But such reasons are naturally related to the subject
 matter.  I don't see a reason to discourage that sort of thing when
 necessary.  But creating top-level hierarchies (*) which don't fit
 into the scheme is, simply put, a big mistake, pointing us back to the
 days of net.* and mod.*.

 (*) For purposes of this discussion, we should regard bit.* as a new
 top-level hierarchy.  They *are* new to the Internet/Usenet world, and
 that is the question.  We can leave Bitnet to do what it will; there
 is no need for us to force the issue on them; I am simply suggesting
 that we *do* try to keep the Internet/Usenet world clean and simple.

===========

 >    * A goodly number of the bit.all newsgroups are not of
 > interest to most of USENET and shouldn't get world distribution.

 This is based on the presumption that top level hierarchies are also
 distributions; which is exactly what I would argue against.

 >    * Users are use to the bit.all and LISTSERV namespaces.  This
 > wasn't the case when inet was set up.  There was a clean slate, and no
 > one lost their mailing list access, they were just seduced over to the
 > inet newsgroups.

 Ever hear of the great renaming?  Better that the names should have
 started out where they are now, but they didn't.

===========

 Regarding the bit.* groups, I have a few questions that I hope someone
 can answer.

 - Do these already exist somewhere as USENET groups?  Is it a full set
   of the LISTSERV groups, or only a subset?

 - How many groups are we talking about?  Tens or hundreds?

 - I agree that it would be better to integrate them into the regular
   USENET hierarchy, and set up bidirectional feeds if the BITNET people
   agree to this.  Some of the LISTSERV groups probably already overlap
   with existing USENET groups.  Has anyone looked to see how many
   could be fed into an existing group, and how many would be new groups?

===========

 >  If that's the case for most (or all) of you, I would suggest to gateway
 >  all those groups into one single USENET group (e.g. misc.listserv), or
 >  perhaps a VERY FEW subgroups thereof where really necessary.

 AcK!  One single USENET group for all of the bit.listserv groups would
 be very bad.  The wide range of topics and the traffic they carry
 would be completely unreasonable for one group.  Much like making
 "general" the only group, world distribution.

===========

 Not sure what I can add to this discussion.

 1. The bit.all groups were created to help the few IBM sites that run
    NETNEWS cut down on some of their spool traffic.

 2. Many of us would rather read these lists from a server than from our
    own mailbox.

 3. I'm surprised other sites are even seeing this traffic.  I thought
    newsgroups were only exchanged with consenting machines.  I guess many
    will accept ALL newsgroups.  Our implementation will only keep first
    level groups that we have previously defined although any lower level
    group will be kept automatically.

 4. What alternatives are being suggested here.  There are over 1000 of
    these mailing lists and various sites are porting their favorite ones
    into their local systems.

 5. We have a number of other local prefixes (staff., psu.) that aren't
    being broadcast beyond their appropriate boundaries.  Don't know why
    the BIT. should behave any differently.   Staff stays on PSUVM and
    PSU gets sent to other UNIX and VMS machines on campus that run the
    "real" usenet software.