chip@vector.UUCP (Chip Rosenthal) (07/24/88)
On Monday, August 1, comp.dcom.telecom will return unless there are
flames of outrage against my plan.
Starting on this date, I will begin to forward digests from the TELECOM
mailing list into comp.dcom.telecom. Actual submissions should continue
to go to the mailing list coordinator at address "telecom@xx.lcs.mit.edu".
I will assume that messages received by telecom@vector.UUCP should go to
the mailing list coordinator, unless they specify USENET distribution
only. (USENET adminitrivia may be sent to telecom-request@vector.UUCP.)
Unfortunately, I have not been able to reach the TELECOM coordinator about
this. I will try once again. I hope s/he will be pleased about regaining
the USENET telcom readers without having to hassle with gatewaying.
Again, if anybody has any problems or concerns about this, please drop
me a line. As a final note, vector is fairly well connected to the
Southeast US through killer and rpp386. I would be interested in setting
up a UUCP connection with a backbone site elsewhere in the country to
help with comp.dcom.telecom propogation.
--
Chip Rosenthal /// chip@vector.UUCP /// Dallas Semiconductor /// 214-450-0400
{uunet!warble,sun!texsun!rpp386,killer}!vector!chip
I won't sing for politicians. Ain't singing for Spuds. This note's for you.mcb@tis.llnl.gov (Michael C. Berch) (07/26/88)
In article <440@vector.UUCP> chip@vector.UUCP (Chip Rosenthal) writes: > On Monday, August 1, comp.dcom.telecom will return unless there are > flames of outrage against my plan. > > Starting on this date, I will begin to forward digests from the TELECOM > mailing list into comp.dcom.telecom. Actual submissions should continue > to go to the mailing list coordinator at address "telecom@xx.lcs.mit.edu". > I will assume that messages received by telecom@vector.UUCP should go to > the mailing list coordinator, unless they specify USENET distribution > only. (USENET adminitrivia may be sent to telecom-request@vector.UUCP.) > > Unfortunately, I have not been able to reach the TELECOM coordinator about > this. I will try once again. I hope s/he will be pleased about regaining > the USENET telcom readers without having to hassle with gatewaying. Arrrgh! Please don't gateway TELECOM in digested form. Digests are not amenable to newsreading software (yes, you can deal with them with readnews or rn, but it ain't fun). If TELECOM is to be gatewayed, it should be done as *individual messages*, meaning it needs to be done at or near the source of the ARPA-side mailing list, i.e., on an Internet/Usenet gateway site that can handle the individual messages. You need to coordinate this closely with the TELECOM list coordinator. I think everyone appreciates your volunteering to provide the service, but it is worth taking the time to make sure it gets done effectively and efficiently. Michael C. Berch News/mail admin, TIS.LLNL.GOV systems mcb@tis.llnl.gov / uunet!tis.llnl.gov!mcb / ames!lll-tis!mcb
bob@acornrc.UUCP (Bob Weissman) (07/26/88)
In article <22336@tis.llnl.gov>, mcb@tis.llnl.gov (Michael C. Berch) writes: > Digests are > not amenable to newsreading software (yes, you can deal with them with > readnews or rn, but it ain't fun). If TELECOM is to be gatewayed, it > should be done as *individual messages* I beg to differ. I find the 'm' command of vnews perfectly acceptible for dealing with digests. Your comment is like saying television shows should not be broadcast in color because you have a black and white television set. -- Bob Weissman Internet: bob@acornrc.uucp UUCP: ...!{ ames | decwrl | oliveb | pyramid }!acornrc!bob Arpanet: bob%acornrc.uucp@ames.arc.nasa.gov
mcb@tis.llnl.gov (Michael C. Berch) (07/27/88)
In article <977@acornrc.UUCP> bob@acornrc.UUCP (Bob Weissman) writes: > In article <22336@tis.llnl.gov>, mcb@tis.llnl.gov (Michael C. Berch) writes: > > Digests are > > not amenable to newsreading software (yes, you can deal with them with > > readnews or rn, but it ain't fun). If TELECOM is to be gatewayed, it > > should be done as *individual messages* > > I beg to differ. I find the 'm' command of vnews perfectly acceptible for > dealing with digests. > > Your comment is like saying television shows should not be broadcast in > color because you have a black and white television set. That is not a very good analogy. I haven't used vnews in a few years, since I find rn to be much more powerful (and I think much of the community would agree). All that vnews' "m" permitted, as I recall, was the ability to treat a digest like a collection of messages *for reading purposes only* (you can go to the next sub-message, etc.). But with vnews can you: (1) SAVE individual digest messages, (2) REPLY to the author of individual digest messages, (3) FOLLOWUP to an individual digest message, ALL OF THESE in a completely compatible way with other, non-digest-type Usenet articles, with all the headers correct??? And with the message-ID of the responded-to article cited correctly??? Another problem with digests is that since headers become part of the body of the message, digestifiers remove "verbose" header information that may be useful in identifying the origin of the message, assisting with a reply to the author, keeping a thread together, etc. So even if a newsreader was theoretically perfect in all of these tasks, the raw material may not be there anymore. Vnews "m" may satisfy you, but I would prefer to be able to use the full power of a tool like rn on ALL Usenet messages I read, including things gatewayed from Internet mailing lists. Gnews and other newsreaders from the gnu/lisp/emacs community may solve some of these problems but when the raw material's gone, there's no way to recover. Characterizing digests as "color TV" and rn as a "black-and-white TV" newsreader is a pretty silly analogy. Digests LOSE information that newsreading tools can make use of. It might be more accurate to say that I am objecting to people broadcasting in black-and-white when the population already has color TVs, and color broadcasting systems are available for free. (Enough of that metaphor, I think.) Michael C. Berch mcb@tis.llnl.gov / uunet!tis.llnl.gov!mcb / ames!lll-tis!mcb