Questions About How to Properly Name Newsgroups
Martin X. Moleski, SJ
in drafting one part of a document that explains "how to
create a new newsgroup in the Big-8."
Here is the old prescription of how to construct a valid
group name:
"Naming Requirements.
"A group name is made up of name components separated by '.' (period or
dot). Each component must consist solely of lowercase ASCII letters,
digits, '+' (plus), or '-' (dash), must contain at least one letter
(a-z), and must be no more than twenty characters long."
Several questions have arisen about the naming tradition.
1. Is there already a document which also explains how to fit
a group's name within the hierarchy? Any advice for newbies
on how to name their group in such a way that its purpose
will be clear?
2. Where did the "no more than twenty characters" limit
come from; is there historical precedent for it, or did
we make it up? Should we continue to use this guideline
or has it become meaningless? I've heard that some
alt groups have components that are in the 30-character
range.
3. Are there documents describing the proper purpose of
the hierarchies? Various theories have been proposed
in another thread, I think. If this is not settled,
then what kind of position SHOULD we take from now
on about the purposes of the hierarchies?
4. Is the requirement to "contain at least one letter"
still a concern? I've been told that "alt.2600"
exists and operates without any difficulty.
I'm sure there may be other "naming" issues that I haven't
thought of.
Thanks for any help you can give us.
Marty
Mark Goodge
to keyboard and typed:
>
>2. Where did the "no more than twenty characters" limit
>come from; is there historical precedent for it, or did
>we make it up? Should we continue to use this guideline
>or has it become meaningless? I've heard that some
>alt groups have components that are in the 30-character
>range.
It used to be a restriction imposed by by certain server software
packages. I'm not aware of any these days which would still have a
problem with it.
>4. Is the requirement to "contain at least one letter"
>still a concern? I've been told that "alt.2600"
>exists and operates without any difficulty.
As above. Some servers used to barf on it. I'm not sure if any still
do.
Mark
--
Visit: http://www.FridayFun.net - jokes, lyrics and ringtones
Listen: http://www.goodge.co.uk/files/dweeb.mp3 - you'll love it!
Martin X. Moleski, SJ
of an older document:
<ftp://ftp.isc.org/pub/usenet/CONFIG/README>
Here is the critical section, which answers some of my
questions:
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".
Those criteria are based on rules written by Henry Spencer for the
Son-of-1036 draft standard and included in the current USEFOR draft. At
this time, only pure ASCII newsgroup names are accepted. Unicode
newsgroup names will be considered should they ever be standardized.
There is an additional criteria that is also taken from the current
USEFOR draft, but which is still a matter of some debate -- the limit on
the length of a component. The de facto limit was 14 octets for over a
decade and a half. It is currently proposed that this be lifted to a
"soft" limit of 30 octets (in other words, this limit is recommended but
not required). This limit is currently enforced. 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.
Peter J Ross
> Some of us in the working group would like to ask for help
> in drafting one part of a document that explains "how to
> create a new newsgroup in the Big-8."
>
> Here is the old prescription of how to construct a valid
> group name:
>
> "Naming Requirements.
>
> "A group name is made up of name components separated by '.' (period or
> dot). Each component must consist solely of lowercase ASCII letters,
> digits, '+' (plus), or '-' (dash), must contain at least one letter
> (a-z), and must be no more than twenty characters long."
>
>
> Several questions have arisen about the naming tradition.
>
> 1. Is there already a document which also explains how to fit
> a group's name within the hierarchy? Any advice for newbies
> on how to name their group in such a way that its purpose
> will be clear?
>
> 2. Where did the "no more than twenty characters" limit
> come from; is there historical precedent for it, or did
> we make it up?
14 used to be the limit; see RFC 1036.
Um... you guys *have* read the RFCs, haven't you?
> Should we continue to use this guideline
> or has it become meaningless? I've heard that some
> alt groups have components that are in the 30-character
> range.
Were such groups approved by the alt.configgers? Are they propagated
everywhere?
> 3. Are there documents describing the proper purpose of
> the hierarchies? Various theories have been proposed
> in another thread, I think. If this is not settled,
> then what kind of position SHOULD we take from now
> on about the purposes of the hierarchies?
>
> 4. Is the requirement to "contain at least one letter"
> still a concern? I've been told that "alt.2600"
> exists and operates without any difficulty.
It's anomalous, and it's a crappy group anyway, in signal/noise terms,
perhaps because it's not well propagated.
> I'm sure there may be other "naming" issues that I haven't
> thought of.
>
> Thanks for any help you can give us.
You ought to preserve backwards-compatibility, whatever else you do to
the namespace.
Read RFC 1036.
Read Son-of-1036.
Read the latest USEFOR drafts.
The leader of the USEFOR folks posts in news.groups.
Sheesh!
PJR :-)
--
_ _(o)_(o)_ _ FSM: http://www.venganza.org/
._\`:_ F S M _:' \_, PJR: http://www.insurgent.org/~pjr/
/ (`---'\ `-. AUK: http://www.netcabal.com/auk/
,-` _) (_, F_P God's Own Newsreader: http://www.slrn.org/
Adam H. Kerman
>Some of us in the working group would like to ask for help
>in drafting one part of a document that explains "how to
>create a new newsgroup in the Big-8."
>Here is the old prescription of how to construct a valid
>group name:
I'l repeat what I said to Joe earlier: Incorporate the naming guidelines
by reference. Don't make proponents refer to two different documents in an
attempt to figure out which one is current.
Also, incorporate Russ's "Group Creation Criteria" by reference, which I
see that you found.
Brian Mailman
(snip)
Now we *know* you have BarB tied up and gagged in the basement.
B/
Joe Bernstein
Adam H. Kerman <a...@chinet.com> wrote:
> At 5:05pm -0500, 03/15/06, Martin X. Moleski, SJ <mol...@canisius.edu>
> wrote:
> >Some of us in the working group would like to ask for help
> >in drafting one part of a document that explains "how to
> >create a new newsgroup in the Big-8."
> I'l repeat what I said to Joe earlier: Incorporate the naming guidelines
> by reference. Don't make proponents refer to two different documents in an
> attempt to figure out which one is current.
You're losing me. Doesn't "incorporate by reference" mean precisely
that the proponent ends up looking at two different documents?
The context here. In the discussion of banning stuff I have, as
I suggested I would, moved that the bans incorporate the Guidelines
text on naming, in the following ways:
1. In a list of Things We Don't Do (for some value of Don't, under
discussion), include:
a. Actions affecting groups outside the Big 8.
b. Groups that violate the naming requirements.
2. In a section of the same document following that list, include
the naming requirements.
It has been suggested that instead we should have a Guide To Naming
that would incorporate the naming requirements, so then we'd have
1. but not 2. This makes proponents refer to two different
documents, but incorporates the naming guidelines by reference.
So, um, I'm confused.
Joe Bernstein
--
Joe Bernstein, writer j...@sfbooks.com
<http://www.panix.com/~josephb/> "She suited my mood, Sarah Mondleigh
did - it was like having a kitten in the room, like a vote for unreason."
<Glass Mountain>, Cynthia Voigt
Peter J Ross
<mol...@canisius.edu> wrote in news.groups:
> There is an additional criteria that is also taken from the current
> USEFOR draft, but which is still a matter of some debate -- the limit on
> the length of a component. The de facto limit was 14 octets for over a
> decade and a half.
It's in Son of RFC 1036.
"A newsgroup name consists of one or more components, which may be
plain components or (except for the first) encoded words. A plain
component MUST contain at least one letter, MUST begin with a letter
or digit, and MUST not be longer than 14 characters."
> It is currently proposed that this be lifted to a
> "soft" limit of 30 octets (in other words, this limit is recommended but
> not required). This limit is currently enforced. 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.
I'm amazed to learn that The New Cabal didn't already know about this
kind of stuff. READ THE FREAKIN' RFCs ALREADY!
Peter J Ross
wrote in news.groups:
> On Wed, 15 Mar 2006 17:05:40 -0500, Martin X. Moleski, SJ
> <mol...@canisius.edu> wrote in news.groups:
>
>> Some of us in the working group would like to ask for help
>> in drafting one part of a document that explains "how to
>> create a new newsgroup in the Big-8."
>>
>> Here is the old prescription of how to construct a valid
>> group name:
>>
>> "Naming Requirements.
>>
>> "A group name is made up of name components separated by '.' (period or
>> dot). Each component must consist solely of lowercase ASCII letters,
>> digits, '+' (plus), or '-' (dash), must contain at least one letter
>> (a-z), and must be no more than twenty characters long."
>>
>>
>> Several questions have arisen about the naming tradition.
>>
>> 1. Is there already a document which also explains how to fit
>> a group's name within the hierarchy? Any advice for newbies
>> on how to name their group in such a way that its purpose
>> will be clear?
>>
>> 2. Where did the "no more than twenty characters" limit
>> come from; is there historical precedent for it, or did
>> we make it up?
>
> 14 used to be the limit; see RFC 1036.
Sorry: I meant Son-Of, and thought I'd typed it.
But the point is that if you want to change the naming requirements,
you need to create a new RFC (since Son-Of is generally treated as if
it were a real RFC), not ask for opinions in news.groups.
CNews is still available for download, so any changes you make will
have to be compatible with CNews.
And don't tell me that no commercial provider uses CNews; your
responsibility is to Usenet, including hobbyists who may prefer to use
CNews, not to commercial providers.
Rob Kelk
<snip>
>4. Is the requirement to "contain at least one letter"
>still a concern? I've been told that "alt.2600"
>exists and operates without any difficulty.
I believe that there are still some news servers that store messages in
files with numeric names, in directories arranged by hierarchy. Thus,
in the group foo.bar, messages would be saved with the names
spool/foo/bar/1, spool/foo/bar/2, spool/foo/bar/3, and so on. If there
was a newsgroup foo.bar.500, there's a very good chance that Something
Bad would happen on those servers once the 500th message for foo.bar
showed up - the subgroup and the message would both be called
spool/foo/bar/500 and there'd be a conflict. And if that wasn't a
problem, the entire subgroup might be deleted when it came time to
expire that 500th message, depending on how poorly the server software
was coded.
I don't know how many servers work this way, but I don't *know* that the
number is zero. If it were up to me, I'd leave this requirement in.
I believe alt.2600 gets by because every server has expired 2600
messages in "alt" (no subhierachy sections in the name) long ago, thanks
to spammers...
<snip>
--
Rob Kelk
Personal address (ROT-13): eboxryx -ng- tznvy -qbg- pbz
Any opinions here are mine, not ONAG's.
ott.* newsgroup charters: <http://onag.pinetree.org>
Martin X. Moleski, SJ
<slrne1ha3...@nntp.alcatroll.com>:
> ... I'm amazed to learn that The New Cabal didn't already know about this
>kind of stuff. READ THE FREAKIN' RFCs ALREADY!
Will do. Any Day Now. :o(
Marty
Martin X. Moleski, SJ
in <121h9is...@news.supernews.com>:
>Now we *know* you have BarB tied up and gagged in the basement.
:-O
Martin X. Moleski, SJ
<Pine.LNX.4.63.0603151747330.21107@qbbshf>:
>I'l repeat what I said to Joe earlier: Incorporate the naming guidelines
>by reference. Don't make proponents refer to two different documents in an
>attempt to figure out which one is current.
>Also, incorporate Russ's "Group Creation Criteria" by reference, which I
>see that you found.
Here's another, older (1995-1999) document:
<http://www.faqs.org/faqs/usenet/creating-newsgroups/naming/part1/>
Apart from the 14-character limit, it's got good stuff about how
to name groups.
Marty
Adam H. Kerman
>Adam H. Kerman <a...@chinet.com> wrote:
>>At 5:05pm -0500, 03/15/06, Martin X. Moleski, SJ <mol...@canisius.edu>
>>wrote:
>>>Some of us in the working group would like to ask for help
>>>in drafting one part of a document that explains "how to
>>>create a new newsgroup in the Big-8."
>>I'l repeat what I said to Joe earlier: Incorporate the naming guidelines
>>by reference. Don't make proponents refer to two different documents in an
>>attempt to figure out which one is current.
>You're losing me. Doesn't "incorporate by reference" mean precisely
>that the proponent ends up looking at two different documents?
No. It means he would look in the Naming Guideline for the guidelines on
naming a newsgroup, and not in any other document. Whatever document you
are preparing for proponents to read, _The Nifty Guide to Proposing a
Newsgroup in the Big 8_, should refer the reader to the Naming Guidelines
and not restate the provisions.
>The context here. In the discussion of banning stuff I have, as
>I suggested I would, moved that the bans incorporate the Guidelines
>text on naming, in the following ways:
>1. In a list of Things We Don't Do (for some value of Don't, under
> discussion), include:
> a. Actions affecting groups outside the Big 8.
> b. Groups that violate the naming requirements.
>2. In a section of the same document following that list, include
> the naming requirements.
>It has been suggested that instead we should have a Guide To Naming
>that would incorporate the naming requirements, so then we'd have
>1. but not 2. This makes proponents refer to two different
>documents, but incorporates the naming guidelines by reference.
>So, um, I'm confused.
The Naming Guidelines should be maintained as a separate document and that
the document you are preparing should incorporate it by reference.
I don't want a proponent to read whatever is going into #2 and also have
to read the Naming Guidelines, and then try to figure out which provisions
are current.
Is the committee tinkering with the Naming Guidelines at this time? Can
you drop us a hint as to what you all think is wrong with them?
Joe Bernstein
Martin X. Moleski, SJ <mol...@canisius.edu> wrote:
> Some of us in the working group would like to ask for help
> in drafting one part of a document that explains "how to
> create a new newsgroup in the Big-8."
I thought the issue was a document devoted exclusively to names.
> Several questions have arisen about the naming tradition.
>
> 1. Is there already a document which also explains how to fit
> a group's name within the hierarchy? Any advice for newbies
> on how to name their group in such a way that its purpose
> will be clear?
As I wrote on the list, there is, but it is general rather than
specific. I think we should *avoid* being specific, for reasons I
gave on the list; Jim Riley has recently posted here an analysis of
memes about *.religion.* that's an example of those reasons.
The document in question is available, I suspect, many places
online. Here's an example dug up from Google (well, the last
example they show):
|From: David.W.Wri...@bnr.co.uk
|Subject: Guidelines on Usenet Newsgroup Names
|Date: 1999/12/28
|Message-ID: <FnG10...@tac.nyc.ny.us>
|X-Deja-AN: 565600088
|Expires: Fri, 28 Jan 2000 09:00:11 GMT
|Approved: netannou...@deshaw.com (Mark Moraes)
|Supersedes: <FMMECD....@tac.nyc.ny.us>
|Followup-To: news.newusers.questions
|Reply-To: netannou...@deshaw.com (Mark Moraes)
|Newsgroups: news.announce.newusers,news.groups,news.admin.misc,alt.config,alt.answers,news.answers
|
|Original-author: David.W.Wri...@bnr.co.uk
|Archive-name: usenet/creating-newsgroups/naming/part1
|Last-change: 13 Jun 1995 by netannou...@deshaw.com (Mark Moraes)
|Changes-posted-to: news.misc
|
| Guidelines on Usenet Newsgroup Names
|
| "To-day we have naming of parts."
|
|This document is intended to be a primer for use by those involved in
|creating new Usenet news groups, namely in the "comp", "humanities",
|"misc", "news", "rec", "sci", "soc" and "talk" hierarchies. The same
|principles may be used with other hierarchies, but those are beyond the
|scope of this document.
|
|Usenet news group names are structured, hierarchic, taxonomic but not
|definitive. They are intended to help users find what they want and news
|administrators manage their systems, to the benefit of their users.
|By understanding each of these concepts, you can understand how to
|select suitable names for new news groups.
|
|Structured
|
| News group names are structured into parts separated by dots, for
| example "rec.pets.dogs". Each part may be up to 14 characters
| long, and should consist only of letters, digits, "+" and "-",
| with at least one letter.
At least "up to 14" needs updating.
|Hierarchic
|
| Names fall into clear hierarchies - for example all computer-related
| groups are in comp. Each may be sub-divided into second, third, and
| lower level hierarchies, such as sci.physics and comp.sys.sun, by
| adding more parts to the basic name. The first part is the most
| general (sci or comp), the second more specific, and so on. The
| last part completes the actual group name. As each part implies a
| further level, words at the same level are included into one part
| using a hyphen - e.g. misc.invest.real-estate rather than
| misc.invest.estate.real, which would imply that a real was a type
| of estate!
OK, the first sentence is misleading (there are computer-related groups
in other hierarchies), so if revision is contemplated that's something
to attack. "for example computer-related groups are normally in comp."?
|Taxonomic
|
| Taxonomy is the science of the classifying things - for example
| species in biology, or books in a library. Group names classify
| subjects into areas and hierarchies. Getting these right is not
| easy, for you have to fit in with those already there, and also
| allow for likely future growth.
|
|Not definitive
|
| News group names are inclusive rather than definitive. That is to
| say, a group name defines an area in which a message may be posted
| if there is no other group with a better name fit. The name does
| not define exact limits to the group, eliminating subjects that do
| not exactly match the definition.
|
|Helping users
| The group name is often the only clue the user has about the group
| without reading a selection of articles from the group. There are
| currently over 1300 Usenet news groups, and well over 10,000 groups
| including all the other news hierarchies from alt to zer. It is
| not possible for users to read every group to find out which are of
| interest to them. Similarly, even a very popular group will only
| be read by 1% of all Usenet users. So the name has to make sense to
| the 99% who are not reading the group. It should be clear enough
| to avoid users posting "what is this?" articles, and to ensure that
| those who *would* like to know more about the subject do recognise
| the group's purpose and start to read it and join in. Also, bear in
| mind that Usenet is global, that users come from many different
| cultures, and that for many, English is not their first language.
The numbers need updating, and the cases where "Usenet" means "the Big 8"
need distinguishing from the cases where "Usenet" means "netnews".
(Here, 1300 is obviously the Big 8; I'm not sure which 1% is. Below,
transport limitations are obviously netnews.)
| This leads to some strong guidelines about choosing names:
|
| - Group similar subjects together, in the same hierarchy if
| possible, so that people looking for a related subject will have a
| good idea where to find it. It is often better to put a new group
| with others in an approximately right "place" than to insist on
| getting the name precise at the expense of putting the group in
| some obscure area that many potential users will not look at.
|
| - Create general groups before creating very specific ones.
|
| - Dnt Abrv8. Do not abbreviate or use obscure names. Your
| abbreviation may well be recognised by someone else as meaning
| something entirely different, especially if English is a second
| language to them. At the moment, Usenet transport limitations
| restrict the length of any component to 14 characters. This may
| sometimes force abbreviation, in this case, create as meaningful
| an abbreviation as possible within 14 characters.
These final two sentences need updating.
| - Use English words in group names. The articles in a group should
| use whatever language is appropriate for that group, but group names
| should use English as that is the one language that can be
| understood by almost all Usenet users.
If by "Usenet" he meant anything other than "the Big 8", even in 1995
that was dubious - heck, even in 19*8*5; today it's clearly not true.
But for the Big 8, it's still reasonable.
|Helping news administrators
| No site now has the disk space to carry 10,000 news groups and keep
| all their articles for weeks. So news administrators have to be
| selective in which groups they carry and how long they keep the
| articles of each group (expiry times). Yet with so many groups,
| they cannot manage each one separately. So they make use of
| the hierarchic property, and control news in hierarchies. For
| example, one may keep comp articles longer than rec, another may
| decide not to take any comp.sys.ibm.* groups as none of their users
| reads them. This is the other reason hierarchies are so important,
| and why a new group should always be fitted into an existing
| hierarchy if at all possible. Some new group proposers think it
| does not matter if their group does not fit in to this scheme,
| assuming that news administrators who don't want it can select it
| out individually: this is a mistaken view. Every group that a site
| gets that its users do not read, makes less disk space and so
| shorter expiry times for the groups they *do* want.
The first sentence is, how to say, no longer true. Change to
"Most sites don't have the disk space ..."
|What's next?
| Think about these guidelines before naming your new news group.
|
| Remember that name mistakes made in the past when Usenet was much
| smaller, or now in uncontrolled parts of the net like alt, are no
| reason to make more mistakes now. On the contrary, now is the time
| to correct some of those past mistakes.
|
| And if you still need advice, ask group-adv...@uunet.uu.net.
Replace the e-mail address.
Really, these are just basic principles. I don't understand why this
document was allowed to vanish in the first place, but I also don't
see any purpose in re-inventing the wheel. And I'm almost certain
a committee is an inferior way to write.
> 3. Are there documents describing the proper purpose of
> the hierarchies?
The Lists of Active Newsgroups contained descriptions of the
hierarchies. These descriptions may or may not be reliable,
but here's the set from shortly after the Great Renaming:
! "comp" Topics of interest to both computer professionals and
! hobbyists, including topics in computer science, software
! source, and information on hardware and software systems.
!
! "sci" Discussions intended as technical in nature and relating
! to the established sciences.
!
! "misc" Groups addressing themes not easily classified under any of the
! other headings or which incorporate themes from multiple
! categories.
!
! "soc" Groups primarily addressing social issues and socializing.
!
! "talk" Groups largely debate-oriented and tending to feature long
! discussions without resolution and without appreciable amounts
! of generally useful information.
!
! "news" Groups concerned with the news network and software themselves.
!
! "rec" Groups oriented towards hobbies and recreational activities.
And here's the last one, which comes from after the creation of
humanities.* (heck, possibly from after the last group created *in*
humanities.*).
!!"comp" Topics of interest to both computer professionals and
!! hobbyists, including topics in computer science, software
!! source, and information on hardware and software systems.
!!
!!"humanities"
!! Professional and amateur topics in the arts & humanities.
!!
!!"misc" Groups addressing themes not easily classified under any of the
!! other headings or which incorporate themes from multiple
!! categories.
!!
!!"news" Groups concerned with the news network and software themselves.
!!
!!"rec" Groups oriented towards the arts, hobbies and recreational
!! activities.
!!
!!"sci" Discussions marked by special and usually practical knowledge,
!! relating to research in or application of the established
!! sciences.
!!
!!"soc" Groups primarily addressing social issues and socializing.
!!
!!"talk" Groups largely debate-oriented and tending to feature long
!! discussions without resolution and without appreciable amounts
!! of generally useful information.
> Various theories have been proposed
> in another thread, I think.
Well, here are mine. I have two:
comp.* is about computers
humanities.* is about the humanities and arts
misc.* is about real life
news.* is about Usenet
rec.* is about recreation
rec.arts.* is about the arts
sci.* is about the sciences and other technical subjects
soc.* is about social groups and societies
talk.* is about endless talk
That's the topical (and inferior) one. The other is the one I think
Jim Riley probably agrees with, and the one the Great Renaming was
essentially about:
news.* is groups you (as a news-admin) must take.
comp.* is groups you almost certainly want.
sci.* is groups you probably want.
(humanities.* belongs at this level too.)
misc.* is groups there's a good chance you want.
rec.* is groups you might want.
soc.* is groups you probably don't want.
talk.* is groups only an idiot would want.
This is, shall we say, somewhat out of date. On the other hand, the
topical one, like all topical ones, is more than somewhat wrong.
Note David Wright's principle above: It's better to put a group
near other groups with similar topics, than to Get It Right. Hence,
for example, there are a dozen groups in soc.history.* because
Henry Churchyard back in 1990 or so made the wrong decision about
what hierarchy to put it in. (To be fair, at that time there was
no obvious right decision; and the profoundly botched renaming of
sci.classics into humanities.classics pretty much destroyed any
interest there might have been in a more massive renaming.)
> If this is not settled,
> then what kind of position SHOULD we take from now
> on about the purposes of the hierarchies?
An agnostic one. We SHOULD follow David Wright's advice, and
accept that we have not been authorised to conduct Great Renaming II.
> I'm sure there may be other "naming" issues that I haven't
> thought of.
Well, I can supply *loads* of news.groups folklore about names -
for example, I used to be a second-rate expert in namespace
terminals (things like ".moderated" or ".marketplace"). I'm
sure there are many others who can do the same sort of thing.
But I really *don't* want us to go down the uk.* path of, for
example, chartering sub-hierarchies. It's too late for the Big 8
to do anything of the sort without a second Great Renaming. Just
randomly, for example, is rec.arts.* divided by form (rec.arts.books.*,
rec.arts.comics.*, rec.arts.tv.*) or by genre (rec.arts.sf.*,
rec.arts.horror.*, rec.arts.flamenco) ?
So what I *want* us to do is simply update and resume the posting
of David Wright's Guidelines, and leave the folklore to news.groups
where it belongs.
Joe Bernstein
Peter J Ross <p...@kookbusters.org> wrote:
> CNews is still available for download, so any changes you make will
> have to be compatible with CNews.
>
> And don't tell me that no commercial provider uses CNews; your
> responsibility is to Usenet, including hobbyists who may prefer to use
> CNews, not to commercial providers.
Um, I make A News available for download at my website. But I'm damned
if I think we're responsible for maintaining compatibility with A News.
More seriously, as I understand it, the reasons for not using the
namespace terminal "general" relate to behaviour of many versions
of B News. Most of the pro-*.misc arguments were also fairly
strongly linked to B News.
Rumour has it that B News is still running somewhere, though the
last time news.software.b was polled nobody said they were doing
it themselves.
But the ban on .general has been revoked for years, as have the
last vestiges of the pro-*.misc policies.
So. My personal view on this is pretty simple. I think we should
just incorporate the text from the old guidelines into whatever we
produce, because until I moved precisely that on the mailing list,
not one person in all these months had said anything against that
bit of the system. (And even when I did push it on the mailing list,
comment dwelt on my improper way of doing so, not on the actual
material, until, well, today, a week later.)
I think we should also revive David Wright's document, because
it's a Good Thing to do.
But if, against my preference, the board *does* tinker with the
rules, there's room for it to do so.
Martin X. Moleski, SJ
<slrne1han...@nntp.alcatroll.com>:
>But the point is that if you want to change the naming requirements,
>you need to create a new RFC (since Son-Of is generally treated as if
>it were a real RFC), not ask for opinions in news.groups.
Russ is honoring 80-char names with components up to 30 chars.
I doubt we'll roll that decision back.
Marty
Martin X. Moleski, SJ
<4418ab76...@news.individual.net>:
>>4. Is the requirement to "contain at least one letter"
>>still a concern? I've been told that "alt.2600"
>>exists and operates without any difficulty.
>I believe that there are still some news servers that store messages in
>files with numeric names, in directories arranged by hierarchy. Thus,
>in the group foo.bar, messages would be saved with the names
>spool/foo/bar/1, spool/foo/bar/2, spool/foo/bar/3, and so on. If there
>was a newsgroup foo.bar.500, there's a very good chance that Something
>Bad would happen on those servers once the 500th message for foo.bar
>showed up - the subgroup and the message would both be called
>spool/foo/bar/500 and there'd be a conflict. And if that wasn't a
>problem, the entire subgroup might be deleted when it came time to
>expire that 500th message, depending on how poorly the server software
>was coded.
>I don't know how many servers work this way, but I don't *know* that the
>number is zero. If it were up to me, I'd leave this requirement in.
>I believe alt.2600 gets by because every server has expired 2600
>messages in "alt" (no subhierachy sections in the name) long ago, thanks
>to spammers...
If that were the rationale, then the rule could possibly be amended
to read that only the final component must not be all-digits.
Marty
Martin X. Moleski, SJ
<Pine.LNX.4.63.0603151829480.21654@qbbshf>:
>Is the committee tinkering with the Naming Guidelines at this time? Can
>you drop us a hint as to what you all think is wrong with them?
There are discrepancies in documents & FAQs (14, 20, 30; whether
all-digits are acceptable in a component or not).
We would like to write our own FAQs to help proponents
craft valid proposals.
Marty
Peter J Ross
<j...@sfbooks.com> wrote in news.groups:
> In article <slrne1han...@nntp.alcatroll.com>,
> Peter J Ross <p...@kookbusters.org> wrote:
>
>> CNews is still available for download, so any changes you make will
>> have to be compatible with CNews.
>>
>> And don't tell me that no commercial provider uses CNews; your
>> responsibility is to Usenet, including hobbyists who may prefer to use
>> CNews, not to commercial providers.
>
> Um, I make A News available for download at my website. But I'm damned
> if I think we're responsible for maintaining compatibility with A News.
CNews is available in Debian. ANews and BNews aren't. Unlike A and B,
C might conceivably be used somewhere in the future.
> More seriously, as I understand it, the reasons for not using the
> namespace terminal "general" relate to behaviour of many versions
> of B News. Most of the pro-*.misc arguments were also fairly
> strongly linked to B News.
I think the prohibition was against "general", not "*.general", but it
isn't in RFC 1036 anyway.
Changing the traditional 14-octet limit might affect servers that are
configured to reject such newsgroups, even if they could be
reconfigured to accept them. I really think that departures from the
RFC limits ought to be thought about very carefully, and that some
discussion with the USEFOR team might be useful.
> Rumour has it that B News is still running somewhere, though the
> last time news.software.b was polled nobody said they were doing
> it themselves.
>
> But the ban on .general has been revoked for years, as have the
> last vestiges of the pro-*.misc policies.
>
> So. My personal view on this is pretty simple. I think we should
> just incorporate the text from the old guidelines into whatever we
> produce, because until I moved precisely that on the mailing list,
> not one person in all these months had said anything against that
> bit of the system. (And even when I did push it on the mailing list,
> comment dwelt on my improper way of doing so, not on the actual
> material, until, well, today, a week later.)
>
> I think we should also revive David Wright's document, because
> it's a Good Thing to do.
>
> But if, against my preference, the board *does* tinker with the
> rules, there's room for it to do so.
Whatever you do, being aware of the RFCs might not hurt.
The RFCs cited in the "see also" section of that excellent document
known as "man 5 tin" are 977, 1036, 1524, 2045, 2046, 2047, 2048, 2822
and 2980, which will probably be enough to be going along with, though
822 might also still have some relevance, since it's the one cited in
1036. Doesn't anybody read this stuff?
Peter J Ross
<mol...@canisius.edu> wrote in news.groups:
> On Thu, 16 Mar 2006 00:01:10 +0000, Peter J Ross <p...@kookbusters.org> wrote in
> <slrne1han...@nntp.alcatroll.com>:
>
>>But the point is that if you want to change the naming requirements,
>>you need to create a new RFC (since Son-Of is generally treated as if
>>it were a real RFC), not ask for opinions in news.groups.
>
> Russ is honoring 80-char names with components up to 30 chars.
Russ isn't in charge of USEFOR; Charles Lindsey is. And Son-of-1036
has more authority than the USEFOR draft. The reason I keep plugging
this point is that I think the RFCs are more important than the
current practice of commercial providers - or even hobbyist providers
like me. If a generally accepted convention hasn't been obsoleted,
don't stop observing it. RFC 1036 and Son-Of haven't yet been
obsoleted.
> I doubt we'll roll that decision back.
As a matter of interest, does anybody know what's the longest
component in a current Big-8 group name?
Brian Palmer
> No. It means he would look in the Naming Guideline for the guidelines on
> naming a newsgroup, and not in any other document. Whatever document you
> are preparing for proponents to read, _The Nifty Guide to Proposing a
> Newsgroup in the Big 8_, should refer the reader to the Naming Guidelines
> and not restate the provisions.
All in one resources are very useful to proponents; clearly
distinguished sections are easy enough to read on their own. (Chapter
1: Choosing a name. Chapter 2: Writing an RFC Chapter 3: Checklist )
Much easier to grasp than loosely related documents written with no
knowledge of each other.
And, at least as importantly, when one of them is updated, all the
others can be updated at once -- having local control of the
guidelines would give the Board freedom to change some provisions
("due to widespread administrator disapproval of the Norman invasion
of Great Britain, every new newsgroup must include one component that
does not have a French root"), or rewrite for clarification ("oops, we
mean 'one component does not have a French root, according to
http://urbandictionary.com'").
As for whether one document or another is out of date: whatever the
Board is maintaining, that has to be the rules the Board is going by
and the guidelines that they point to. If this were going to be
yet-another-third-party-thing, your points made about the proponents
not knowing which is to be relied on would be spot on; but this
would be from a governing party.
--
I'm awfully glad I'm a Beta, because I don't work so hard.
Joe Bernstein
Peter J Ross <p...@kookbusters.org> wrote:
> On Thu, 16 Mar 2006 00:52:54 +0000 (UTC), Joe Bernstein
> <j...@sfbooks.com> wrote in news.groups:
> > More seriously, as I understand it, the reasons for not using the
> > namespace terminal "general" relate to behaviour of many versions
> > of B News. Most of the pro-*.misc arguments were also fairly
> > strongly linked to B News.
> I think the prohibition was against "general", not "*.general", but it
> isn't in RFC 1036 anyway.
I wasn't arguing against "Obey the RFCs", I was arguing against "Be
terrified of breaking software." There's a difference. (Below, I
*do* argue against this particular version of "Obey the RFCs",
since you bring it up; but my last post wasn't about that.)
The prohibition was against *.general. The deal was that certain
versions of B News (I forget which) were designed such that all
followups to articles posted to a newsgroup named X.general would
have to go to a newsgroup named X.followup. It was one of the
many failed attempts to impose discipline on net.general.
I think but am not sure that soc.sexuality.general was the first
group that passed that broke that ban; I forget whether there were
earlier groups that were allowed to go to CFV, but failed.
> Changing the traditional 14-octet limit might affect servers that are
> configured to reject such newsgroups, even if they could be
> reconfigured to accept them. I really think that departures from the
> RFC limits ought to be thought about very carefully, and that some
> discussion with the USEFOR team might be useful.
>
> Whatever you do, being aware of the RFCs might not hurt.
You know, I've read 1036 and I believe I've read Son of, though I'm
not sure.
But I'm a little boggled. If violating the RFCs in this regard is
so awful, *why didn't anyone complain when tale started allowing it?*
I mean, yes, I acknowledge that there's an intrinsic Badness to
"breaks the RFC". I'm not among those who think this means one
should *never* violate RFCs, but I can respect those who do. But
where were you guys at the time?
The 20-character limit has been there for *years*. I haven't
checked whether there are existing Big 8 groups that violate
the 14-character limit - I'm assuming someone out there can
write a PERL script that can do this faster than me eyeballing
the list - but I believe there are.
(OK, the rest of this post actually assumes there are so I went and
found one. comp.software.extreme-programming. It would be nice to
know how many more there are. Anyway, I now *know* this was on
tale's watch, because I spent part of the day listing the RFDs
and CFVs 2002-2005 and this wasn't one of them.)
Are you suggesting that we should rmgroup these groups now because
after they've been around for years, someone has noticed that
their names violate an RFC that's universally acknowledged as
outdated?
Or are you just saying we have to obey the RFC going forward?
If so, I've got to ask why. Anyone still running software that
has problems with 15-character names *has already stopped
trusting the Big 8*. They've *had* to. So why should we refuse
to newgroup a future group so as to cater to these folks, if
they exist, whom we unintentionally hurt years back, and who are
no longer listening to us? The only way we'll get them back is
to do those rmgroups...
Jonathan Kamens
>(OK, the rest of this post actually assumes there are so I went and
>found one. comp.software.extreme-programming. It would be nice to
>know how many more there are.
comp.software.extreme-programming is the only one, as far as I can
tell.
Adam H. Kerman
>On Wed, 15 Mar 2006 17:50:20 -0600, "Adam H. Kerman" <a...@chinet.com> wrote:
>>I'l repeat what I said to Joe earlier: Incorporate the naming guidelines
>>by reference. Don't make proponents refer to two different documents in an
>>attempt to figure out which one is current.
>>Also, incorporate Russ's "Group Creation Criteria" by reference, which I
>>see that you found.
>Here's another, older (1995-1999) document:
><http://www.faqs.org/faqs/usenet/creating-newsgroups/naming/part1/>
>Apart from the 14-character limit, it's got good stuff about how
>to name groups.
That's what I was referring to when I mentioned the Naming Guidelines.
That looks like the latest revision.
Adam H. Kerman
>On Wed, 15 Mar 2006 18:39:32 -0600, "Adam H. Kerman" <a...@chinet.com> wrote:
>>Is the committee tinkering with the Naming Guidelines at this time? Can
>>you drop us a hint as to what you all think is wrong with them?
>There are discrepancies in documents & FAQs (14, 20, 30; whether
>all-digits are acceptable in a component or not).
>We would like to write our own FAQs to help proponents
>craft valid proposals.
Then amend the Naming Guidelines by removing the length limit of the name
part and digits in the name part, leaving that for Russ's document.
I guess you need a summary document that refers to the Naming Guidelines
and Russ's document. In that one you would mention the 20-character limit,
I suppose and all-digit name parts, but only if someone remembers to
update it on occassion.
I don't think you should summarize the Naming Guidelines themselves as
naming is rather complicated (except in the case of of split).
Instead, encourage proponents to ask for help in getting it right.
Adam H. Kerman
>All in one resources are very useful to proponents; clearly
>distinguished sections are easy enough to read on their own. (Chapter
>1: Choosing a name. Chapter 2: Writing an RFC Chapter 3: Checklist )
>Much easier to grasp than loosely related documents written with no
>knowledge of each other.
Hyperlinks work nicely for this purpose.
But if a single document is too long, it'll put off proponents who need to
read it.
>And, at least as importantly, when one of them is updated, all the
>others can be updated at once -- having local control of the
>guidelines would give the Board freedom to change some provisions
I was hoping to avoid having multiple organic documents covering the same
subject matter that no one keeps in synch.
>As for whether one document or another is out of date: whatever the
>Board is maintaining, that has to be the rules the Board is going by
>and the guidelines that they point to. If this were going to be
>yet-another-third-party-thing, your points made about the proponents
>not knowing which is to be relied on would be spot on; but this
>would be from a governing party.
Hm? I thought the guidelines were as official as anything else was at the
time of authorship. In any event, I sort of preferred it as an independent
document that could give general guidance Usenet-wide.
Russ Allbery
> It's in Son of RFC 1036.
> "A newsgroup name consists of one or more components, which may be
> plain components or (except for the first) encoded words. A plain
> component MUST contain at least one letter, MUST begin with a letter
> or digit, and MUST not be longer than 14 characters."
Be very careful about reading Son of 1036. It has some useful information
in it, and it also has quite a bit that was never implemented and is no
longer useful.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Russ Allbery
> Russ isn't in charge of USEFOR; Charles Lindsey is.
Charles Lindsey is the editor of USEPRO, not USEFOR, and is not the chair
of the working group. He's not "in charge" in any meaningful sense of the
term.
> And Son-of-1036 has more authority than the USEFOR draft.
They are both inaccurate in different ways, but USEFOR is at this point a
significantly better guide than Son-of. (USEPRO is another matter.)
> The reason I keep plugging this point is that I think the RFCs are more
> important than the current practice of commercial providers - or even
> hobbyist providers like me.
Usenet article format has no current RFC that should be considered a
standard. All of the available ones have serious problems in various
respects.
NNTP is in better shape; we have three documents that are IESG-approved
and are currently sitting in the RFC Editor's queue.
> If a generally accepted convention hasn't been obsoleted, don't stop
> observing it. RFC 1036 and Son-Of haven't yet been obsoleted.
Please note that RFC 1036 is not a standard in the IETF sense. It is an
informational RFC. As such, it doesn't go through the standards process
in the same way that a standards-track RFC would.
Robert Singers
said [snip]
> I'm sure there may be other "naming" issues that I haven't
> thought of.
How about promoting the convention of capitalizing only the first word
and any proper nouns in titles. People basically don't understand the
rules for capitalizing words in titles and invariably get it wrong. Not
to mention the Internet is a whole is contributing to crazy
capitalization in sentences.
Some times less is more.
--
rob 'pet peeve' singers
pull finger to reply
Foemina Erit Ruina Tua
Charles Lindsey
>Several questions have arisen about the naming tradition.
>1. Is there already a document which also explains how to fit
>a group's name within the hierarchy? Any advice for newbies
>on how to name their group in such a way that its purpose
>will be clear?
David Wright's FAQ, which has already been mentioned in this thread. Also
a similar uk.* document on www.usenet.org.uk.
>2. Where did the "no more than twenty characters" limit
>come from; is there historical precedent for it, or did
>we make it up? Should we continue to use this guideline
>or has it become meaningless? I've heard that some
>alt groups have components that are in the 30-character
>range.
It was originally 14, in the days when that was the limit for Unix
filenames. No current *-nix system requires that anymore. Tale aritrarily
upped it to 20 some years ago (uk.* likewise). The USEFOR draft actually
makes it 30.
>3. Are there documents describing the proper purpose of
>the hierarchies? Various theories have been proposed
>in another thread, I think. If this is not settled,
>then what kind of position SHOULD we take from now
>on about the purposes of the hierarchies?
See the David Wright FAQ. Any hierarchy (incl. big-8) is free to establish
more precise guidelines as it sees fit (e.g. in uk.* we have written
"hierarchy charters" for its main sub-hierarchies).
>4. Is the requirement to "contain at least one letter"
>still a concern? I've been told that "alt.2600"
>exists and operates without any difficulty.
It works as it stands, but if ever anybody tried to create subgroups of
the form "alt.2600.*", then the majority of existing servers on Usenet
would promptly fall over.
The best guide as to what is technically acceptable is to be found in the
current USEFOR draft.
Note that _some_ length limit is needed both for components and overall
names. The overall length is in fact constrained by the "Newsgroups line"
which accompanies each newsgroup (see the NNTP draft), and which has to
fit into 72 characters according to some arcane rules known as "Tale's
rules". USEFOR maintains those rules, mainly because we foresee that when
we get around to internationalized newsgroup names things are going to get
even more complicated, so it is best not to make changes in that area just
yet.
--
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: c...@clerew.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
Jonathan Kamens
>It works as it stands, but if ever anybody tried to create subgroups of
>the form "alt.2600.*", then the majority of existing servers on Usenet
>would promptly fall over.
I'm not sure why you say that. What do you think would go
wrong? I just tried it with INN and it caused absolutely no
problems at all, as far as I could tell.
At least with INN, the worst that happens if a newsgroup name
has a component that's only a number is that if hierarchical
article storage is being used, and there's a newsgroup ending
at the same point in the tree, a single article will get lost
when INND reaches that number in article counting in the
latter group and tries to save an article.
In other words, if both alt.this.group and alt.this.group.500
are groups, then when INND tries to save article number 500
in alt.this.group, it'll fail and the article will be lost.
The next article to be saved will get the number 501 and the
problem is gone forever.
With a minor code change, INND could detect this particular
failure (i.e., trying to save a file on top of a directory)
and increment the article number while saving, thus
completely eliminating the problem.
Martin X. Moleski, SJ
in <Iw87B...@clerew.man.ac.uk>:
>>1. Is there already a document which also explains how to fit
>>a group's name within the hierarchy? Any advice for newbies
>>on how to name their group in such a way that its purpose
>>will be clear?
>David Wright's FAQ, which has already been mentioned in this thread. Also
>a similar uk.* document on www.usenet.org.uk.
Thanks.
>>2. Where did the "no more than twenty characters" limit
>>come from; is there historical precedent for it, or did
>>we make it up? Should we continue to use this guideline
>>or has it become meaningless? I've heard that some
>>alt groups have components that are in the 30-character
>>range.
>It was originally 14, in the days when that was the limit for Unix
>filenames. No current *-nix system requires that anymore. Tale aritrarily
>upped it to 20 some years ago (uk.* likewise). The USEFOR draft actually
>makes it 30.
OK.
I'm getting a little woozy here.
If I remember what Russ said, the USEFOR draft
is very likely to become the standard? In
his document on Usenet names (2004), he was
accepting 80-char total and 30-char components.
> ... It works as it stands, but if ever anybody tried to create subgroups of
>the form "alt.2600.*", then the majority of existing servers on Usenet
>would promptly fall over.
Heh heh. It's becoming clearer and clearer that "alt.2600" is
a pattern that should not be followed.
>The best guide as to what is technically acceptable is to be found in the
>current USEFOR draft.
Well, that opens a whole can of worms.
<http://www.ietf.org/internet-drafts/draft-ietf-usefor-useage-01.txt>
seems to be the latest, but it says it expired in September 2005.
================= Excerpt #1:
3.1.1.5. Newsgroups
There are restrictions on the length of components of <newsgroup-
name>s, and on the <newsgroup-name>s themselves, as described more
fully in 7.2. Posting and injecting agents MAY attempt to enforce
them but, because of the possibility that hierarchy policies or
future standards may relax them, it SHOULD be possible for posters to
override such checks, and software MUST be so written that they can
be disabled altogether.
================= Excerpt #2:
7.2. Naming of Newsgroups
Because group control messages can only be issued on the authority of
the responsible agency, it follows that the agency has complete
control of the names of the newsgroups to be considered as valid
members of that (sub-)hierarchy. Consequently, it needs to establish
policies for the format of the <newsgroup-name>s it intends to
permit; these policies can be both technical and aesthetic.
[USEFOR] provides by default the following technical restrictions
upon which hierarchy administrators can then build, and which SHOULD
in any case be applied in hierarchies not subject to such management.
[Well, it doesn't provide them yet, but it needs to.]
NOTE: These restrictions are intended to reflect existing
practice and are intended both to avoid certain technical
difficulties and to avoid unnecessary confusion. They may well
change over time in the light of future experience.
1. Uppercase letters are forbidden.
NOTE: Traditionally, <newsgroup-name>s have been written in
lowercase. However, posting agents SHOULD NOT convert uppercase
characters to the corresponding lowercase forms except under the
explicit instructions of the poster.
2. A <component> is forbidden to consist entirely of digits.
NOTE: This requirement was in [RFC 1036] but nevertheless
several such groups have appeared in practice and implementors
should be prepared for them. A common implementation technique
uses each <component> as the name of a directory and uses
numeric filenames for each article within a group. Such an
implementation needs to be careful when this could cause a clash
(e.g. between article 123 of group xxx.yyy and the directory for
group xxx.yyy.123). Once the latter group exists, the
subsequent creation of the former would be precluded for all
time.
3. A <component> is limited to 30 <component-char>s and a
<newsgroup-name> to 66 <component-char>s (counting also the '.'s
separating the <component>s).
NOTE: Whilst there is no longer any technical reason to limit
the length of a <component> (formerly, it was limited to 14
octets) nor of a <newsgroup-name>, it should be noted that these
names are also used in the <newsgroups-line> where another
overall policy limit applies (7.1) and, moreover, excessively
long names can be exceedingly inconvenient in practical use. The
66 limit on <newsgroup-name>s ensures that a Followup-To Header
with such a name will still fit within 79 characters overall.
In the event that some future extension to [USEFOR] allows
internationalized <newsgroup-name>s including non-ASCII characters,
there will be further technical issues to be taken into account,
including:
4. What non-ASCII punctuations and other symbols are to be allowed.
5. What normalizations need to be observed to overcome multiple ways
of constructing glyphs with identical or similar appearance.
6. Restrictions on mixing alphabets within one <component> of a name
(so as to avoid confusion between, for example, Latin A and Greek
Alpha, and similar confusions between some Latin and Cyrillic
letters - though retaining the restriction on uppercase letters
will mitigate these problems somewhat).
Aesthetic reasons for policy limitations are likely to include
insistence upon a clear hierarchical structure (the tree of names
needs to be neither too broad nor too deep), that the <component>s of
<newsgroup-name>s are meaningful in the context of the language(s)
expected to be used, that frivolous names are avoided, and that
abbreviations are likely to be recognized by the intended readership.
[David Wright has a FAQ on hierarchical naming which might give us some
help.]
================= Excerpt #3:
7.1 ... The current convention
is to limit its length so that the <newsgroup-name>, the HTAB(s)
(interpreted as 8-character tabs that takes one at least to column
24) and the <newsgroup-description> (excluding any <moderation-flag>)
fit into 79 characters. This document does not seek to enforce any
such rule, but any decision to extend it should be made as a specific
decision for the hierarchy. Reading agents SHOULD therefore enable a
<newsgroups-line> of any length to be displayed, e.g. by wrapping it
as required.
=================== End Excerpts
>Note that _some_ length limit is needed both for components and overall
>names. The overall length is in fact constrained by the "Newsgroups line"
>which accompanies each newsgroup (see the NNTP draft), and which has to
>fit into 72 characters according to some arcane rules known as "Tale's
>rules". USEFOR maintains those rules, mainly because we foresee that when
>we get around to internationalized newsgroup names things are going to get
>even more complicated, so it is best not to make changes in that area just
>yet.
OK. Bottom line: 66-octets total & 30-octets for a component.
Marty
Adam H. Kerman
>Martin X. Moleski, SJ <mol...@canisius.edu> writes:
>>2. Where did the "no more than twenty characters" limit come from; is
>>there historical precedent for it, or did we make it up? Should we
>>continue to use this guideline or has it become meaningless? I've heard
>>that some alt groups have components that are in the 30-character range.
>It was originally 14, in the days when that was the limit for Unix
>filenames. No current *-nix system requires that anymore. Tale aritrarily
>upped it to 20 some years ago (uk.* likewise). The USEFOR draft actually
>makes it 30.
Which is similarly arbitary, right?
>Note that _some_ length limit is needed both for components and overall
>names. The overall length is in fact constrained by the "Newsgroups line"
>which accompanies each newsgroup (see the NNTP draft), and which has to
>fit into 72 characters according to some arcane rules known as "Tale's
>rules". USEFOR maintains those rules, mainly because we foresee that when
>we get around to internationalized newsgroup names things are going to
>get even more complicated, so it is best not to make changes in that area
>just yet.
Does that not have to do with the 80-character width of terminals, a long-
standing convention, and the common 8-space tab stop? 80 minus 8 is 72.
The point is to allow a user grepping the newsgroups file to be able to
successfully display the name and description on one line.
I assume tale reasoned that preserving space for a description of such a
long group name is irrelevant, as it will already contain every possible
key word.
It seems like something that should be retained.
Adam H. Kerman
>If I remember what Russ said, the USEFOR draft
>is very likely to become the standard?
I assume Russ doesn't expect to be immortal and made no such prediction.
My prediction is great-great-grandson of will be the standard, if Usenet
is still around.
Martin X. Moleski, SJ
<Pine.LNX.4.63.0603161515390.17367@qbbshf>:
>Does that not have to do with the 80-character width of terminals, a long-
>standing convention, and the common 8-space tab stop? 80 minus 8 is 72.
That sounds right.
>The point is to allow a user grepping the newsgroups file to be able to
>successfully display the name and description on one line.
Also persuasive.
But I missed how we get down from 72 to 66, which is what the
USEFOR document recommends.
[Not that it matters. I can handle arbitrariness. I got used
to that a long time ago.]
>I assume tale reasoned that preserving space for a description of such a
>long group name is irrelevant, as it will already contain every possible
>key word.
Makes sense.
Marty
Rob Kelk
(Jonathan Kamens) wrote:
<snip>
>At least with INN, the worst that happens if a newsgroup name
>has a component that's only a number is that if hierarchical
>article storage is being used, and there's a newsgroup ending
>at the same point in the tree, a single article will get lost
>when INND reaches that number in article counting in the
>latter group and tries to save an article.
>
>In other words, if both alt.this.group and alt.this.group.500
>are groups, then when INND tries to save article number 500
>in alt.this.group, it'll fail and the article will be lost.
>The next article to be saved will get the number 501 and the
>problem is gone forever.
What happens when it comes time to expire alt.this.group.[499-501] ?
Does the entire alt.this.group.500 disappear?
(I mentioned this in <news:4418ab76...@news.individual.net>.)
<snip>
--
Rob Kelk
Personal address (ROT-13): eboxryx -ng- tznvy -qbg- pbz
Any opinions here are mine, not ONAG's.
ott.* newsgroup charters: <http://onag.pinetree.org>
Russ Allbery
> At least with INN, the worst that happens if a newsgroup name
> has a component that's only a number is that if hierarchical
> article storage is being used, and there's a newsgroup ending
> at the same point in the tree, a single article will get lost
> when INND reaches that number in article counting in the
> latter group and tries to save an article.
INN will throttle rather than lose the article. But other than that, what
you say is correct.
> With a minor code change, INND could detect this particular
> failure (i.e., trying to save a file on top of a directory)
> and increment the article number while saving, thus
> completely eliminating the problem.
Yup.
Russ Allbery
> What happens when it comes time to expire alt.this.group.[499-501] ?
> Does the entire alt.this.group.500 disappear?
INN never expires article ranges, only specific articles.
Russ Allbery
> If I remember what Russ said, the USEFOR draft is very likely to become
> the standard?
If anything becomes the standard, it's likely to be something reasonably
like the current USEFOR draft. The premise is, however, questionable.
Rob Kelk
wrote:
>Rob Kelk <rob...@deadspam.com> writes:
>
>> What happens when it comes time to expire alt.this.group.[499-501] ?
>> Does the entire alt.this.group.500 disappear?
>
>INN never expires article ranges, only specific articles.
Good to know.
Henrietta K Thomas
<r...@stanford.edu> wrote:
>Peter J Ross <p...@kookbusters.org> writes:
>
>> Russ isn't in charge of USEFOR; Charles Lindsey is.
>
>Charles Lindsey is the editor of USEPRO, not USEFOR, and is not the chair
>of the working group. He's not "in charge" in any meaningful sense of the
>term.
But, IIRC, Charles /was/ the 'chair' of the USEFOR group when the final
draft was submitted to IETF, and appears to have been largely
responsible for its content.
<...>
>> If a generally accepted convention hasn't been obsoleted, don't stop
>> observing it. RFC 1036 and Son-Of haven't yet been obsoleted.
>
>Please note that RFC 1036 is not a standard in the IETF sense. It is an
>informational RFC. As such, it doesn't go through the standards process
>in the same way that a standards-track RFC would.
Yes, but it appears to be all we have to go by until the USEFOR draft is
approved as a standard, and I'm thinking that /something/ is better than
nothing at all.
YMMV
Martin X. Moleski, SJ
name, this seems to me to be consistent with the USEFOR
draft and something that we could use as a guideline:
1. A group name is made up of name components separated by '.' (period or dot).
2. Each component must consist solely of lowercase ASCII letters (a-z), digits
(0-9), '+' (plus), or '-' (dash).
3. Each component must contain at least one letter (a-z).
4. No component should be more than thirty characters in length.
5. The group name as a whole should not exceed 66 characters in length.
Marty
Adam H. Kerman
>OK, in terms of outlining the rules for writing a good
>name, this seems to me to be consistent with the USEFOR
>draft and something that we could use as a guideline:
I continue to object to this. Refer people to Russ's document, or quote
the relevant portion of Russ's document. Please don't write another.
It's going to be pretty rare that a "good name" includes a 30-character
component. If it does, it'll be difficult to keep it from exceeding 66
characters. I don't see what good this does suggesting to a proponent that
it's a logical way to name a proposed group.
>1. A group name is made up of name components separated by '.' (period or dot).
>2. Each component must consist solely of lowercase ASCII letters (a-z), digits
>(0-9), '+' (plus), or '-' (dash).
Out of interest, are there any special implications of various News
servers having trouble filing articles if the top-level hierarchy were all
digits beyond a later name part?
Adam H. Kerman
>Given some of the silliness the USEFOR group is producing, nothing at
>all may well wind up better.
What are your main objections?
Martin X. Moleski, SJ
<Pine.LNX.4.63.0603171023280.13967@qbbshf>:
>I continue to object to this.
Objection noted.
>Refer people to Russ's document, or quote
>the relevant portion of Russ's document. Please don't write another.
I don't think wading through Russ's document to
find the relevant section is helpful to people
trying to negotiate the system for the first time.
When we get things going, we'll probably keep a wiki
as the foundation for the FAQs that we write ourselves.
It won't be hard to have as many links as you would like
to recommend in the footnotes.
>It's going to be pretty rare that a "good name" includes a 30-character
>component. If it does, it'll be difficult to keep it from exceeding 66
>characters. I don't see what good this does suggesting to a proponent that
>it's a logical way to name a proposed group.
Who knows? Maybe it will never be an issue.
All I'm trying to do is to find the facts, such
as they are, and prepare the ground for a good
decision about how to describe accurately what can
and cannot be done in the Big-8.
>Out of interest, are there any special implications of various News
>servers having trouble filing articles if the top-level hierarchy were all
>digits beyond a later name part?
I can't understand the question, let alone answer it.
The top-level hierarchy is something like rec.*, news.*, talk.*,
isn't it?
If the top-level hierarchy isn't one of those, it isn't
in the Big-8, and I don't care what digits there may
be beyond a later name part.
OK, you've got me thinking of a further refinement:
1. A group name is made up of name components separated by '.' (period or dot).
2. Name components:
2.1 The first component in the name of a Big-8 newsgroup will be one
of the following:
comp.
humanities.
misc.
news.
rec.
sci.
soc.
talk.
2.2 Each subsequent component must consist solely of
lowercase ASCII letters (a-z),
digits (0-9),
'+' (plus), or
'-' (dash).
2.3 Each component must contain at least one letter (a-z).
2.4 No component may be more than thirty characters long.
3. The group name as a whole should not exceed 66 characters.
--
http://NewsGuy.com/overview.htm 30Gb $9.95 Carry Forward and On Demand Bandwidth
Adam H. Kerman
>On Fri, 17 Mar 2006 10:32:31 -0600, "Adam H. Kerman" <a...@chinet.com> wrote:
>>Refer people to Russ's document, or quote
>>the relevant portion of Russ's document. Please don't write another.
>I don't think wading through Russ's document to
>find the relevant section is helpful to people
>trying to negotiate the system for the first time.
Then quote the relevant portion.
Adam H. Kerman
> "Martin X. Moleski, SJ" <mol...@canisius.edu> wrote:
>> 2.1 The first component in the name of a Big-8 newsgroup will be one
>> of the following:
>> comp.
>> humanities.
>> misc.
>> news.
>> rec.
>> sci.
>> soc.
>> talk.
>It was my impression that AK wants a single document for all of Usenet. He
>doesn't want a separate document that applies only to the Big-8.
I was asking the committee to avoid duplicating the Naming Guidelines and
Russ's README in a document that will require a proponent to compare one
to another to learn what the provisions are. Martin wants to write a
document for Big 8 proponents.
As I'm not one of the Ocean's 11, my wishes are irrelevant.
Martin X. Moleski, SJ
<blGSf.20898$nB6....@news-wrt-01.rdc-nyc.rr.com>:
>> 2.1 The first component in the name of a Big-8 newsgroup will be one
>> of the following:
>>
>> comp.
>> humanities.
>> misc.
>> news.
>> rec.
>> sci.
>> soc.
>> talk.
>It was my impression that AK wants a single document for all of Usenet.
No single document for all of Usenet exists at this time.
>He
>doesn't want a separate document that applies only to the Big-8.
Understood. Noted. Deposited in the archives. AK only wants
things that we write to point to the "official sources." He
doesn't want us to have a separate document for our customers.
He wants one source that is updated by The Powers that Be, while
our documents only have links to it.
I understand his position. I respectfully disagree with it after
going out and reading some of the extant documents.
Marty
Peter J Ross
wrote in news.groups:
> Peter J Ross <p...@kookbusters.org> writes:
>
>> Russ isn't in charge of USEFOR; Charles Lindsey is.
>
> Charles Lindsey is the editor of USEPRO, not USEFOR, and is not the chair
> of the working group. He's not "in charge" in any meaningful sense of the
> term.
OK. Would you accept "Russ isn't in charge of USEFOR (or USEPRO);
somebody else is"? The point was that an appeal to your current
practice isn't an appeal to authority in this case.
>> And Son-of-1036 has more authority than the USEFOR draft.
>
> They are both inaccurate in different ways, but USEFOR is at this point a
> significantly better guide than Son-of. (USEPRO is another matter.)
But parts of Son-of have been tested by time. No other interpretation
or revision has been tested much in practice, has it?
>> The reason I keep plugging this point is that I think the RFCs are more
>> important than the current practice of commercial providers - or even
>> hobbyist providers like me.
>
> Usenet article format has no current RFC that should be considered a
> standard. All of the available ones have serious problems in various
> respects.
I didn't describe RTC 1036 as a *standard* in the "IETF Standard"
sense. Of course, parts of it have to be re-interpreted in practice;
what worked in BNews might not work in later implementations. It's a
"standard" only in the sense that departing from some of its most
straightforward recommendations might cause problems.
Anyway, I've drawn attention to the issue, which is all I wanted to
do. If the members of the committee who were unaware of the relevant
documents are aware of them now, my work is done.
PJR :-)
--
_ _(o)_(o)_ _ FSM: http://www.venganza.org/
._\`:_ F S M _:' \_, PJR: http://www.insurgent.org/~pjr/
/ (`---'\ `-. AUK: http://www.netcabal.com/auk/
,-` _) (_, F_P God's Own Newsreader: http://www.slrn.org/
Peter J Ross
<sta...@shell.peak.org> wrote in news.groups:
> In article <slrne1hhf...@nntp.alcatroll.com>,
> Peter J Ross <p...@kookbusters.org> wrote:
>>Russ isn't in charge of USEFOR; Charles Lindsey is.
>
> Upon planet Earth, Harald Tveit Alvestrand is the current chairman of the
> IETF-USEFOR working group. Charles is only an editor of one of the drafts.
I stand corrected.
>>And Son-of-1036 has more authority than the USEFOR draft.
>
> If by "more", you mean "none", then you are correct.
>
>>RFC 1036 and Son-Of haven't yet been
>>obsoleted.
>
> It's hard to "obsolete" a "standard" that isn't a standard.
OK. I'll newgroup control.$#?&ИЧ.general.ctl and see what happens. ;-)
Martin X. Moleski, SJ
<slrne1mm7...@nntp.alcatroll.com>:
> ... I've drawn attention to the issue, which is all I wanted to
>do. If the members of the committee who were unaware of the relevant
>documents are aware of them now, my work is done.
As some of the feminists are said to have said, "Raised consciousness
is not a blessing."
Watch your back as you ride off into the sunset, Shane. :-P
Russ Allbery
I realize that you want to make this as simple as possible, but there is a
reason for all of the rules that are in the document on ftp.isc.org,
including the way that they're phrased. For example, the above allows
name components beginning with + or -, which have never been allowed and
which are probably going to be reserved for implementation use in a future
standard (if we get any).
You also really do have to not use "all" and "ctl" as components or you
will break real software currently in use.
If you want technical limitations on group names, I recommend using the
list taken from that document:
- 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".
except that I'd probably rule out _ for the Big Eight. (It's used in
alt.* but it's never been used in the Big Eight; the Big Eight has always
used - instead.)
Yes, the uppercase letter note duplicates the first rule, but it's such a
common error that it's worth repeating. You can omit the last three
rules, of course, for the Big Eight.
Russ Allbery
> Russ Allbery <r...@stanford.edu> wrote in news.groups:
>> Peter J Ross <p...@kookbusters.org> writes:
>>> Russ isn't in charge of USEFOR; Charles Lindsey is.
>> Charles Lindsey is the editor of USEPRO, not USEFOR, and is not the
>> chair of the working group. He's not "in charge" in any meaningful
>> sense of the term.
> OK. Would you accept "Russ isn't in charge of USEFOR (or USEPRO);
> somebody else is"? The point was that an appeal to your current practice
> isn't an appeal to authority in this case.
The ftp.isc.org rules that I took over from David Lawrence are about as
authoritative as you're going to get right now. They are certainly more
authoritative than either USEFOR or RFC 1036 in that, unlike either of
those documents, they actually affect reality in some small ways.
Thankfully, at this point, I believe USEFOR has essentially copied them,
although that may be confusingly split between USEFOR and USEPRO (I
haven't checked).
>> They are both inaccurate in different ways, but USEFOR is at this point
>> a significantly better guide than Son-of. (USEPRO is another matter.)
> But parts of Son-of have been tested by time.
There are very few parts of Son-of that are both different than RFC 1036
and have been tested by time. Son-of was a draft document for a new
revision of the Usenet protocol that was never implemented. Bits and
pieces of it have made it into software; other bits (such as the
Newsgroups encoding rules) have been abandoned completely. You have to
know quite a bit about Usenet to distinguish, which makes Son-of an
extremely risky document to rely on.
> No other interpretation or revision has been tested much in practice,
> has it?
Again, there is currently no authoritative standard for Usenet. Again,
USEFOR is at this point a significantly better guide than Son-of. I don't
know how to say this more clearly.
Nicholas Fitzpatrick
>name, this seems to me to be consistent with the USEFOR
>draft and something that we could use as a guideline:
>
Ugh, please no. There are some of us who type in the group names from
trn.
Not that there has been groups I read created within the last decade ...
Nick
Martin X. Moleski, SJ
<87slpgo...@windlord.stanford.edu>:
>I realize that you want to make this ... simple ...
And accurate.
So here's the revised version:
1. A group name is made up of name components separated by '.' (period or dot).
2. Rules governing the formationof name components:
2.1 The first component in the name of a Big-8 newsgroup will be one
of the following:
comp.
humanities.
misc.
news.
rec.
sci.
soc.
talk.
2.2 A component must not contain characters other than [a-z0-9+-].
FN: The underscore character ("_") is allowed in components
by Usenet but is traditionally not used in the Big-8.
2.3 A component must contain at least one non-digit.
2.4 A component must not contain uppercase letters.
2.5 A component must begin with a letter or digit.
2.6 Sequences 'all' and 'ctl' must not be used as components.
2.7 No component may be more than thirty (30) characters long.
3. The group name as a whole should not exceed sixty-six (66) characters.
============ End Draft. Begin Argument. ========================
* 2.7 and 3 are "disputed questions.
From <ftp://ftp.isc.org/pub/usenet/CONFIG/README> (2004):
Those criteria are based on rules written by Henry Spencer for the
Son-of-1036 draft standard and included in the current USEFOR draft.
... There is an additional criteria that is also taken from the current
USEFOR draft, but which is still a matter of some debate -- the limit on
the length of a component. The de facto limit was 14 octets for over a
decade and a half. It is currently proposed that this be lifted to a
"soft" limit of 30 octets (in other words, this limit is recommended but
not required). This limit is currently enforced. 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.
Except that "the current USEFOR draft" (March, 2005; self-expired
as of September, 2005) says in section 7.2:
3. A <component> is limited to 30 <component-char>s and a
<newsgroup-name> to 66 <component-char>s (counting also the '.'s
separating the <component>s).
<http://www.ietf.org/internet-drafts/draft-ietf-usefor-useage-01.txt>
There is an additional criteria that is also taken from the current
USEFOR draft, but which is still a matter of some debate -- the limit on
the length of a component. The de facto limit was 14 octets for over a
decade and a half. It is currently proposed that this be lifted to a
"soft" limit of 30 octets (in other words, this limit is recommended but
not required). This limit is currently enforced. 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.
Bottom line: I chose 66 characters for my draft because it fits
within a limit of 72 and 80 characters.
Where is that nice man who said I should read the friendly manual?
Russ Allbery
> Except that "the current USEFOR draft" (March, 2005; self-expired
> as of September, 2005) says in section 7.2:
Er, what USEFOR draft are you looking at? The current USEFOR draft was
published this month and is not expired. It places no limit on the length
of components.
If you're looking at the landfield.com site, please note that this is no
longer where the working group documents are stored.
Here is the complete relevant section from the current draft:
3.1.5. Newsgroups
The Newsgroups header field specifies the newsgroup(s) to which the
article is posted.
newsgroups = "Newsgroups:" SP newsgroup-list CRLF
newsgroup-list = *WSP newsgroup-name
*( [FWS] "," [FWS] newsgroup-name ) *WSP
newsgroup-name = component *( "." component )
component = 1*component-char
component-char = ALPHA / DIGIT / "+" / "-" / "_"
Folding the Newsgroups header field over several lines has been shown
to harm propagation significantly. Folded Newsgroups header fields
SHOULD NOT be generated, but MUST be accepted.
A newsgroup component SHOULD NOT consist of digits only, and SHOULD
NOT contain uppercase letters. Such components MAY be used only to
refer to existing groups that do not conform to this naming scheme.
NOTE: All-digit components conflict with one widely used storage
scheme for articles. Mixed case groups cause confusion between
systems with case sensitive matching and systems with case
insensitive matching of <newsgroup-name>s.
<component>s beginning with underline ("_") are reserved for use by
future versions of this standard and MUST NOT be generated by user
agents (whether in Newsgroups header fields or in newgroup control
messages [I-D.ietf-usefor-usepro]). However, such names MUST be
accepted by news servers.
<component>s beginning with "+" and "-" are reserved for private use
and MUST NOT be generated by user agents (whether in Newsgroups
header fields or in newgroup control messages [I-D.ietf-usefor-
usepro]) without a private prior agreement to do so. However, such
names MUST be accepted by news servers.
The following <newsgroup-name>s are reserved, and MUST NOT be used as
the name of a newsgroup:
o Groups whose first (or only) component is "example"
o The group "poster"
The following <newsgroup-name>s have been used for specific purposes
in various implementations and protocols, and therefore MUST NOT be
used for the names of normal newsgroups. They MAY be used for their
specific purpose, or by local agreement.
o Groups whose first (or only) component is "to"
o Groups whose first (or only) component is "control"
o Groups which contain (or consist only of) the component "all"
o Groups which contain (or consist only of) the component "ctl"
o The group "junk"
NOTE: "example.*" is reserved for examples in this and other
standards; "poster" has a special meaning in the Followup-To
header field; "to.*" is reserved for certain point-to-point
communications in conjunction with the "ihave" control message
[I-D.ietf-usefor-usepro]; "control.*" and "junk" have special
meanings in some news-servers; "all" is used as a wildcard in some
implementations; and "ctl" was formerly used to indicate a
<control-command> within the Subject header field.
Martin X. Moleski, SJ
wrote in <441b7d98$1...@news.sentex.net>:
>>4. No component should be more than thirty characters in length.
>Ugh, please no. There are some of us who type in the group names from
>trn.
You'll have to talk to someone above my pay grade.
I'm just repeating what I learned from reading the
friendly manuals.
Russ Allbery
>> I'm just repeating what I learned from reading the
>> friendly manuals.
> According to Russ, you've been reading the wrong manual.
No, the 30 came straight from the manual I'd recommend.
USEFOR's lack of component length limitation is part of a general policy
to avoid arbitrary limits inside the *protocol specification*. That
doesn't mean that implementations on top of the specification should
similarly place no limits for other reasons.
On one hand, I think there's a lot to be said for having no concrete
limits on component length and instead leaving the naming process up to
the discussion. Either the name will be obviously worth using a long
component for or it won't. I've seen very few cases where this was at all
ambiguous.
On the other hand, I do need to impose some sort of upper limit on both
group name length and on component size for the ftp.isc.org list just for
general sanity's sake, and I think the current 30/80 limits are reasonable
upper limits. Beyond that, I have a hard time imagining a useful
newsgroup name that couldn't somehow be abbreviated.
Russ Allbery
> My only point is that certain elements of the process should be left to
> the folks who have spent years learning what they are doing. The BM
> Board should be spending all of their time and effort on the elements
> within their expertise, leaving the technical items to the true
> technical wizards. IOW, the BM Board is wasting time on elements beyond
> their knowledge. Nothing good will come of this.
I'm enjoying posting technical trivia. I expect other people may be
enjoying learning. I don't really see a problem here. No one's being
paid by the hour, after all. :)
Adam H. Kerman
>sa...@nyc.rr.com wrote:
>>> 2.1 The first component in the name of a Big-8 newsgroup will be one
>>> of the following:
>>>
>>> comp.
>>> humanities.
>>> misc.
>>> news.
>>> rec.
>>> sci.
>>> soc.
>>> talk.
>>It was my impression that AK wants a single document for all of Usenet.
>No single document for all of Usenet exists at this time.
>>He doesn't want a separate document that applies only to the Big-8.
>Understood. Noted. Deposited in the archives. AK only wants
>things that we write to point to the "official sources."
Guys, I've always been "ahk" on Unix.
Martin, you guys are the officials, so the documents in question will be
your responsibility to revise. I want there to be only one organic
document on any one subject. It makes a lot of sense that the Naming
Guidelines are a separate document, as naming is a rather complicated
topic.
>He doesn't want us to have a separate document for our customers.
Customers? Thought skirv was having you guys go all corporate.
>He wants one source that is updated by The Powers that Be, while
>our documents only have links to it.
Again, that's you guys.
Mark Kramer
>as of September, 2005) says in section 7.2:
The current USEFOR draft section 7.2 is REFERENCES to other documents.
If the entrire Body Of Eleven is as out of date with respect to
something as simple as this as you are, then how can we hope for
anything useful as your work-product?
Get thee to the IETF website and look at the real "current USEFOR
draft". Then look up "USEPRO", and then "USAGE". Better idea, step
aside and allow a replacement that actually knows what is going on.
At least one of you Eleven ought to be up to date with how USENET is
going to operate technically if you are going to waste a lot of time
trying to rewrite the protocol.
Nicholas Fitzpatrick
Russ Allbery <r...@stanford.edu> wrote:
>
>On the other hand, I do need to impose some sort of upper limit on both
>group name length and on component size for the ftp.isc.org list just for
>general sanity's sake, and I think the current 30/80 limits are reasonable
>upper limits. Beyond that, I have a hard time imagining a useful
>newsgroup name that couldn't somehow be abbreviated.
A total length of 80 would be pretty painful! But I can see your
points about not putting in restrictions.
Great idea Russ, they should put you in charge of building this camel!
Nick
Henrietta K Thomas
sta...@shell.peak.org (John Stanley) wrote:
>In article <9tvk12t9fesths4mo...@4ax.com>,
>Henrietta K Thomas <h...@xnet.com> wrote:
>>But, IIRC, Charles /was/ the 'chair' of the USEFOR group when the final
>>draft was submitted to IETF, and appears to have been largely
>>responsible for its content.
>
>What 'final draft' would that have been, the one just submitted or the one
>prior to that, or the one prior to that, or the one for USEPRO, or the
>one for USEAGE?
Never heard of USEPRO or USEAGE til now. I'm talking about USEFOR Draft
No. 7, which I thought was submitted to IETF several years ago. But
I've just come from Kent Landfield's site [1], and I get the impression
they're starting all over again. There is, indeed, a USEFOR group still
going, and Charles is listed as an editor. Looks like I have a lot of
catching up to do.
[1] http://www.landfield.com/usefor/
>Charles is an editor. He is not the chair. Sometimes it looks that way,
>but he is not in charge.
>
>>Yes, but it appears to be all we have to go by until the USEFOR draft is
>>approved as a standard, and I'm thinking that /something/ is better than
>>nothing at all.
>
>Given some of the silliness the USEFOR group is producing, nothing at
>all may well wind up better.
Martin X. Moleski, SJ
<m2rn129em1hmunla0...@4ax.com>:
> ... There is, indeed, a USEFOR group still
>going, and Charles is listed as an editor. Looks like I have a lot of
>catching up to do.
>[1] http://www.landfield.com/usefor/
A quick glance shows nothing later than 2004.
Charles' latest draft (self-staledated last September)
is at a different site:
<http://www.ietf.org/internet-drafts/draft-ietf-usefor-useage-01.txt>
Martin X. Moleski, SJ
<Pine.LNX.4.63.0603172352360.915@qbbshf>:
>Guys, I've always been "ahk" on Unix.
OK. I go by "mx" or "mxm" in various circles.
>Martin, you guys are the officials, so the documents in question will be
>your responsibility to revise.
"The documents in question" are of two different types:
1. For all of Usenet: something we are subject to and not
in control of. I didn't know things were so unsettled
out there until I started trying to RTFM.
2. For the Big-8: yes, we have a responsibility to
provide helpful documents for those whom we serve.
>I want there to be only one organic
>document on any one subject. It makes a lot of sense that the Naming
>Guidelines are a separate document, as naming is a rather complicated
>topic.
It sure can be. I've learned a lot this week.
Naive users probably will match the patterns they've
already seen 90% of the time and won't need to
bother about the rules at all. I would like to have
them ready for when the harder cases arise.
>>He wants one source that is updated by The Powers that Be, while
>>our documents only have links to it.
>Again, that's you guys.
We're subsidiary powers--waaaay subsidiary. There are the
standards people (IETF) and there are news adminisrators.
We've got to work within the boundaries they set for us.
Martin X. Moleski, SJ
<878xr8o...@windlord.stanford.edu>:
>Martin X Moleski, SJ <mol...@canisius.edu> writes:
>
>> Except that "the current USEFOR draft" (March, 2005; self-expired
>> as of September, 2005) says in section 7.2:
>
>Er, what USEFOR draft are you looking at?
<http://www.ietf.org/internet-drafts/draft-ietf-usefor-useage-01.txt>
>The current USEFOR draft was
>published this month and is not expired.
OK. I see it now:
<http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-07.txt>
>It places no limit on the length
>of components.
OK, I'll drop this line from my draft:
"2.7 No component may be more than thirty characters long."
The current USEFOR draft says nothing about the overall length
of the name. The earlier version said 66 chars.
Your 2004 README says:
"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."
<ftp://ftp.isc.org/pub/usenet/CONFIG/README>
What's the status of this precept?
Martin X. Moleski, SJ
wrote in <dvg96d$8ea$1...@pcls4.std.com>:
>The current USEFOR draft section 7.2 is REFERENCES to other documents.
Thanks for the information.
>If the entrire Body Of Eleven is as out of date with respect to
>something as simple as this as you are, then how can we hope for
>anything useful as your work-product?
"Ab un' disc' omnis" is a fallacy.
>Get thee to the IETF website and look at the real "current USEFOR
>draft".
BTDT & brought back the URL to help others find it:
<http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-07.txt>
By the way, if you know the maintainer of this page, you
might suggest that he or she change the status of the USEFOR-USEAGE 01
draft from "active" to "expired":
<https://datatracker.ietf.org/public/idindex.cgi?command=show_wg_id&id=1368>
That might help people to sort out which is the "active" draft.
> Then look up "USEPRO", and then "USAGE".
USEPRO is OK.
But when you say "USAGE", you must mean this document:
<http://www.ietf.org/internet-drafts/draft-ietf-usefor-useage-01.txt>.
See--it's got the word "useage" [spelled correctly] in it and it's
listed first on the page. But that's the document that is
self-expired and that Russ told me--just today--is irrelevant.
> ... if you are going to waste a lot of time
>trying to rewrite the protocol.
I'm not trying to rewrite the protocol. I'm trying to
write a draft for the Big-8 that will comply with it. And
when and if the standards change, I'm pretty sure that
the Big-8 Management Board will try to act in compliance
with the new standards.
Martin X. Moleski, SJ
<121n1rd...@corp.supernews.com>:
> "Martin X. Moleski, SJ" <mol...@canisius.edu> wrote:
>
>> I'm just repeating what I learned from reading the
>> friendly manuals.
>
>According to Russ, you've been reading the wrong manual.
Here is I-Ds List Working Group, Usenet Article Standard Update (usefor)
<https://datatracker.ietf.org/public/idindex.cgi?command=show_wg_id&id=1368>
Here are the first three documents in its table of contents:
draft-ietf-usefor-useage-01 2005-03-16 Active ID Exists
draft-ietf-usefor-usefor-07 2006-03-06 Active ID Exists
draft-ietf-usefor-usepro-05 2006-01-06 Active ID Exists
I've been quoting the first article, which (oddly enough) is marked
as ACTIVE. The name of the article is "USEFOR-USEAGE." It was one
of the articles mentioned by people as part of TFM. It is also,
as Russ has demonstrated, no longer accurate and no longer ACTIVE.
I guess I should have broken my vows and used ESP rather than RTFM.
Martin X. Moleski, SJ
<87ek10m...@windlord.stanford.edu>:
>No, the 30 came straight from the manual I'd recommend.
That's why I put it in my drafts.
>On one hand, I think there's a lot to be said for having no concrete
>limits on component length and instead leaving the naming process up to
>the discussion. Either the name will be obviously worth using a long
>component for or it won't. I've seen very few cases where this was at all
>ambiguous.
OK, that's an argument for not specifying it.
>On the other hand, I do need to impose some sort of upper limit on both
>group name length and on component size for the ftp.isc.org list just for
>general sanity's sake, and I think the current 30/80 limits are reasonable
>upper limits. Beyond that, I have a hard time imagining a useful
>newsgroup name that couldn't somehow be abbreviated.
USEFOR-USEAGE (expired 2005) said 30/66.
Your readme (2004) said 30/72.
USEFOR-USEFOR (2006) doesn't say anything.
Now it's 30/80.
All I want to do is write something that is reasonably accurate
and in COMPLIANCE with Usenet standards.
I suppose a reasonable statement would be:
3. As a general rule, the group name as a whole should not exceed 72 characters.
Martin X. Moleski, SJ
<BgMSf.19914$4%1.3...@news-wrt-01.rdc-nyc.rr.com>:
>The BM Board should be focused
>on creating a process, not rewriting the technical manuals.
Part of the process is kicking out proposals that violate
Usenet naming standards. No point in voting on an RFD
that is technically unsound.
Part of the process of kicking out proposals is having
a document that shows what the Usenet naming standards
are.
Part of the process of developing a document that shows
what the Usenet naming standards are is finding an
authoritative source for the Usenet naming standards
to which we may all defer in case of disagreements.
IOW, I am solely focused on "creating a process," not on
"rewriting the technical manuals."
Geoff Berrow
contained the following:
>> IOW, I am solely focused on "creating a process," not on
>> "rewriting the technical manuals."
>
>Russ has quoted text from the already existing documents that's just fine
>*as it is*. There is no need for a new document.
That's just what I was thinking. Why not simply refer to existing
documentation?
--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the (uk.*) commitee's, mine.
Tim Skirvin
>I hope your new system includes friendly regulars who will help new
>Proponents instead of flame them. "RTFM!" isn't always as simple as it
>sounds.
We certainly hope so. One thing that all current proposals and
systems includes is the equivalent of the old Group Mentors; when we have
something more concrete on the table, then we'll post about it in more
detail.
- Tim Skirvin (sk...@killfile.org)
Chair, Big-8 Management Board
--
http://www.big-8.org/ Big-8 Management Board
http://www.killfile.org/~tskirvin/ Skirv's Homepage <FISH>< <*>
Martin X. Moleski, SJ
<b%USf.19921$4%1.1...@news-wrt-01.rdc-nyc.rr.com>:
>> IOW, I am solely focused on "creating a process," not on
>> "rewriting the technical manuals."
>Russ has quoted text from the already existing documents that's just fine
>*as it is*. There is no need for a new document.
I understand your point of view.
You agree with ahk that:
1. A naming document exists.
2. All we need is a pointer to that document.
Although I understand the argument you are making and
recognize that it one way that people might proceede,
I have looked at every document that has been recommended
to me and do not find in any of them the composite rules
that guide the Big-8. Hence I am continuing to advocate
the draft below for use in the Big-8 newsgroup creation
process.
I may be outvoted when the time comes to make a decision. Right
now, I'm just trying to clarify what it takes to COMPLY with
Usenet standards.
I understand that this does not correspond to what you think
is a worthwhile use of my time and energy.
Marty
1. A group name is made up of name components separated by '.' (period or dot).
2. Rules governing the formation of name components:
2.1 The first component in the name of a Big-8 newsgroup will be one
of the following:
comp.
humanities.
misc.
news.
rec.
sci.
soc.
talk.
2.2 A component must not contain characters other than [a-z0-9+-].
That is to say, the characters allowed are:
-- lowercase letters (a to z)
-- digits (0 to 9)
-- the plus sign: +
-- the minus sign: -
FN: The underscore character ("_") is allowed in components
by Usenet but is traditionally not used in the Big-8.
Components beginning with the underscore character
are reserved for future development in Usenet.
2.3 A component must contain at least one non-digit.
In other words, "rec.autos.makers.ford.500" is invalid
because the component "500" is made up only of digits.
2.4 A component must not contain uppercase letters.
2.5 A component must begin with a letter or digit.
2.6 Sequences 'all' and 'ctl' must not be used as components.
2.7 As a general rule, shorter components are preferred to longer
components.
3. The group name as a whole should not exceed [66/72/80] characters.
REFERENCES
----------
I-Ds List Working Group, Usenet Article Standard Update (usefor):
<https://datatracker.ietf.org/public/idindex.cgi?command=show_wg_id&id=1368>
USEFOR: <http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-07.txt>
Allbery: <ftp://ftp.isc.org/pub/usenet/CONFIG/README>
Martin X. Moleski, SJ
<nYUSf.19920$4%1.1...@news-wrt-01.rdc-nyc.rr.com>:
>I hope your new system includes friendly regulars who will help new
>Proponents instead of flame them.
All unfriendly regulars will be expelled from news.groups just
as soon as someone points to TFM that's got the definition
of "unfriendly" and contains procedures to expel them from
an unmoderated group. :o)
> "RTFM!" isn't always as simple as it sounds.
That's why I'd like to write our own document instead of providing
a set of pointers like this:
I-Ds List Working Group, Usenet Article Standard Update (usefor):
<https://datatracker.ietf.org/public/idindex.cgi?command=show_wg_id&id=1368>
USEFOR-USEAGE: <marked as "active" but not really "active" any more>
<http://www.ietf.org/internet-drafts/draft-ietf-usefor-useage-01.txt>
USEFOR-USEFOR:
<http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-07.txt>
USEFOR-USEPRO:
<http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-05.txt>
Allbery: <ftp://ftp.isc.org/pub/usenet/CONFIG/README>
Martin X. Moleski, SJ
<sl8o12t6nfmq6bnt0...@4ax.com>:
> ... Why not simply refer to existing
>documentation?
Please give me the link to "existing documentation"
that is simple and accurate.
I'd be happy to include the link in anything I draft.
Thanks.
Marty
Martin X. Moleski, SJ
<J9WSf.20601$X.9...@news-wrt-01.rdc-nyc.rr.com>:
>How many of these new documents is the new Board creating? You are talking
>about naming, Joe is talking about auto-rejections ...
These two are related.
Having an incorrect name was one proposed reason for
rejecting proposals out of hand.
Then someone said, "Well, we should help people to
understand how to correct their improper proposals
by explaining the naming rules for them."
And I said, "That's a great question to pose in news.groups.
There are lots of friendly people there who would be happy
to help us develop a simple and accurate statement of
the naming rules."
> there's a thread about
>the FAQ ...
Yes--started by the FAQ maintainers.
Are you suggesting that we not should not answer questions posed in
news.groups? Granted, that was tale's method.
>How many different manuals will Proponents need to read and
>learn?
I don't know yet. Looks like if ahk and his ilk have
their way, it could be three (USEFOR, USEPRO, USEAGE).
>Do you remember "workbooks" from school? Reading section (rules aka
>standards), instructions, and then blank work space for the student to use?
>If you intend to spend so much time and effort on this, a Tutorial
>Workbook type thing (which includes all the separate projects Board members
>are pursuing) might prove more valuable in the long run.
Perhaps.
Marty
Geoff Berrow
Moleski, SJ contained the following:
>
>> ... Why not simply refer to existing
>>documentation?
>
>Please give me the link to "existing documentation"
>that is simple and accurate.
>
>I'd be happy to include the link in anything I draft.
The point is, you don't need to do it /now/. I don't know if you've
noticed but we seem to be missing a group creation system here and that
should be your priority. You simply need to state that groups shall be
named in accordance with the latest USEFOR draft and move on. Once we
are back up and running again you can assign the task of tidying up
these details to a subcommittee.
You will run out of time if you try to attend to every last detail.
Martin X. Moleski, SJ
<vkfo129qpdsq0j9p0...@4ax.com>:
>The point is, you don't need to do it /now/. I don't know if you've
>noticed but we seem to be missing a group creation system here and that
>should be your priority.
As I understand it, this is PART of the "group creation system."
>You simply need to state that groups shall be
>named in accordance with the latest USEFOR draft and move on.
I think I've found and read the latest USEFOR draft--several
times now. I don't find it adequate for what I understand
our purposes to be.
>Once we
>are back up and running again you can assign the task of tidying up
>these details to a subcommittee.
Ah. I see. I shouldn't have any informed views of my own until
the subcommittee makes a decision. Why didn't I think of that?
>You will run out of time if you try to attend to every last detail.
I understand that you think this is a trivial detail, not
worth my time and attention.
I respectfully disagree.
Marty
Russ Allbery
> Your 2004 README says:
> "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."
> <ftp://ftp.isc.org/pub/usenet/CONFIG/README>
> What's the status of this precept?
That's what is still being enforced by the software that maintains the
ftp.isc.org newsgroup list.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Russ Allbery
> Your readme (2004) said 30/72.
No, it doesn't. Here's the relevant paragraph:
There is an additional criteria that is also taken from the current
USEFOR draft, but which is still a matter of some debate -- the limit on
the length of a component. The de facto limit was 14 octets for over a
decade and a half. It is currently proposed that this be lifted to a
"soft" limit of 30 octets (in other words, this limit is recommended but
not required). This limit is currently enforced. 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.
It discusses 72 but actually says 80 (with a rationale).
Russ Allbery
> Here are the first three documents in its table of contents:
> draft-ietf-usefor-useage-01 2005-03-16 Active ID Exists
> draft-ietf-usefor-usefor-07 2006-03-06 Active ID Exists
> draft-ietf-usefor-usepro-05 2006-01-06 Active ID Exists
The differences between these drafts gets into USEFOR working group
politics that probably aren't worth arguing about here. The short version
is that only USEFOR is currently being actively worked on by the group as
a whole. Charles has, from time to time, released new working versions of
the other documents in preparation for when the group as a whole is ready
to start working on them, but numerous controversial and unsettled issues
have been deferred until the usefor draft is considered essentially
finished.
Jeffrey M. Vinocur
>
> 2.1 The first component in the name of a Big-8 newsgroup will be one
> of the following:
>
> comp.
> humanities.
> misc.
> news.
> rec.
> sci.
> soc.
> talk.
Nitpicking here, but if components are separated by dots, then
the dot is not part of the component...and therefore should not
appear in the list above.
--
Jeffrey M. Vinocur
je...@litech.org
Martin X. Moleski, SJ
<121okn9...@corp.supernews.com>:
> "Martin X. Moleski, SJ" <mol...@canisius.edu> wrote:
>> Are you suggesting that we not should not answer questions posed in
>> news.groups? Granted, that was tale's method.
>Where did that come from?
You seemed to be unhappy with the fact that we were
discussing the FAQ. I was pointing out that I did
not carelessly take the initiative to squander my
time on the question but answered what I consider
legitimate, even helpful, questions from Graham
and bard.
>I have
>explicitly stated that the BM Board needs an official spokesman rather than
>11 rogues posting opinions.
Your suggestion is noted and archived. Thanks
for the advice.
>If you ever publish official documents, anyone
>can refer posters to those documents.
Yes. That's true.
The question, however, was what to do with the FAQ
in the interim. I suggested that it might be edited
to indicate the facts, such as they are, about what
is happening now.
Marty