Subject: Re: #1021 USEFOR Newsgroups header - resolution proposed

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 01 Jul 2005 17:00:33 +0200

--On torsdag, juni 30, 2005 18:26:15 +0000 Charles Lindsey 
<[email-masked]> wrote:

>
> In <[email-masked]> Harald Tveit
> Alvestrand <[email-masked]> writes:
>
>> OK, here's my "proposed text" again, incorporating feedback.
>
>> ---- restricting syntax; there are no changes to the ABNF -----
>
>> 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
>                                        ^
>                           created prior to this standard

Absolutely not. Sanity is not going to rule the world after this document 
comes out.

>> 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 insensiteve
>>    matching of newsgroup names.
>
>> ----- restricting use of specific characters ------------
>
>> Components beginning with underline ("_") are reserved for use by
>> future versions of this standard and MUST NOT be generated by
>> posting agents (whether in Newsgroups headers or in newgroup control
>> messages [USEPRO]). However, such names MUST be accepted by
>> relaying and serving agents.
>
> s/by posting agents//
>
> (I.e. MUST NOT be generated; period. And also removes any argument about
> what injecting agents do if they see one).
>
> s/by relaying and serving agents/all agents/

Makes no sense to me whatsoever. This may, however, be because the terms 
"generated" and "accepted" are not defined.

"accept" should be straightforward - if I send you a message, and you act 
on it according to normal procedures, you have accepted it.

"generate" may either mean "send" or mean "construct from component 
pieces". The text I proposed used it as "send", and put the onus on 
injecting agents for policing that they don't appear before there's a 
standadr for them.

> (Not so sure there, since it apparently restricts the right of injecting
> agents to reject them. OTOH, all mentions, esp. normative ones, of the
> various different kinds of agent are probaly best removed from USEFOR).

I would be happier if we had "user agent" and "server" as the only terms in 
the USEFOR description of the Netnews architecture, and put all the various 
agents into USEPRO. But if USEFOR is going to have *any* context to its 
description, I think it needs to have at least *some* terms defined.

> Also s/(Whether ...)//, since it does not actually add anything.
>
>> Components beginning with "+" and "-" are reserved for private
>> use and MUST NOT be generated by posting agents (whether in
>> Newsgroups headers or in newgroup control
>> messages [USEPRO]) without a private prior agreement to do so.
>> However, such names MUST be accepted by
>> relaying and serving agents.
>
> Same suggestions as above, for the same reasons. So I would suggest:
>
>    MUST NOT be generated without a private prior agreement with the
>    intended recipients (such as between a news-server and its clients).

Same comment about defining "generate".

>> ---- restricting component names ----
>
>> The following newsgroup names are reserved, and MUST NOT be used as
>> the name of a newsgroup:
>
>> Groups starting with the component "example"
>> The group "poster"
>
>> The following newsgroup names have been used for specific purposes in
>> various implementations and protocols, and MUST therefore not be used
>> for the names of normal newsgroups. They MAY be used for their specific
>> purpose, or by local agreement.
>
>> Groups starting with the component "junk"
>
> No, I think you can omit that one ("junk.foo is bizarre, but not harmful)
>
>> Groups starting with the component "to"
>> Groups containing the component "all"
>> Groups containing the component "ctl"
>
>   Groups starting with the component "control"
>
>> The group "control"
>
> But you can omit that, because it is already excluded because its first
> (& only) component is excluded.
>
>> The group "junk"
>> The group "to"
>
> And you can omit that, because it is already excluded as above.

Anything worth doing is worth overdoing :)
seriously, there have been people who have argued that a phrase like "A 
contains B" implies that there are more things in A than just B...

> OTOH, I am not sure your classification into two categories is the right
> one. Surely the distinction should be between the things which will cause
> things to break (poster, to, all, ctl) and the things which flout accepted
> conventions (example, junk, control, and even single-component names,
> though it now seems agreed not to mention these here).

"example" is strictly a standards-definer's privillege junket.
"junk" and "control" will (I think) cause things to break.

> Anyway, it is still necessary to give _reasons_ for all these exclusions,
> probably in a NOTE, because that is how you handled the reasons for
> all-digit groups, etc. Here are some texts that might be useful:
>
> ctl:
> because it formerly caused such articles to be interpreted as control
> messages
>
> all:
> because it is used as a wildcard in some implementations
>
> to:
> because of its special meaning to route certain control messages on a
> point-to-point basis [USEPRO]
>
> poster:
> because of its special meaning in the Followup-To header
>
> control:
> used by many serving agents for pseudo-newgroups to hold control
> messages
>
> junk:
> used by many serving agents to store invalid articles
>
> example:
> reserved for examples in this and other standards
>
>> NOTE: Some newsgroups violating these restrictions exist. It is not a
>> protocol violation to use these names to access those newsgroups.
>
>
> --
> 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: [email-masked]      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
>
>

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 1 Jul 2005 20:06:08 GMT

In <[email-masked]> "Charles Lindsey" <[email-masked]> writes:

>In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>(& only) component is excluded.

Thinking further about this, you could also word those cases as:

   Groups starting with (or consisting of) the component "to"

just for the removal of all doubt.

-- 
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: [email-masked]      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

---

From: "Ruud H.G. van Tol" <[email-masked]>
Date: Sat, 2 Jul 2005 08:30:46 +0200

Charles Lindsey:
> Charles Lindsey:
>> Harald Tveit Alvestrand:

>>> The group "control"
>>
>> But you can omit that, because it is already excluded because its
>> first (& only) component is excluded.
>

Groups starting with, or solely consisting of, one of these components:
"a", "b", "c".
(s/one/any/)

And for the others:
Groups containing any of these components: "d", "e", "f".

-- 
Affijn, Ruud

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 4 Jul 2005 13:42:48 GMT

>injecting agents for policing that they don't appear before there's a 

I guess it means "send", since it you construct a malformed article but
don't try to send it beyond your own machine, then who really cares?

And indeed, injecting agents have to do a lot of policing, but in
practical terms we can't expect them to catch _every_ conceivable error.

>"junk" and "control" will (I think) cause things to break.

Actually, nothing breaks, but it adds to the spread of FUD, which is
indeed unwelcome. So I could live with SHOULD NOT for those.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 4 Jul 2005 13:42:48 GMT