Subject: #1314 Resolution - Newsgroups and reserved characters

From: Harald Alvestrand <[email-masked]>
Date: Mon, 21 Aug 2006 05:00:37 -0700

Wordsmithed resolution (going almost all the SHOULD way):

Proposed new text:

A newsgroup component SHOULD NOT consist of digits only, and SHOULD
NOT contain uppercase letters. Such components MAY be used to
refer to existing groups that do not conform to this naming scheme,
but SHOULD NOT be used otherwise.

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 SHOULD NOT be generated by user
agents (whether in header fields or in newgroup control
messages [I-D.ietf-usefor-usepro]). However, such names MUST be
accepted by news servers, if permitted by site policy.

<component>s beginning with "+" and "-" are reserved for private use
and SHOULD NOT be generated by user agents (whether in
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, if permitted by site policy.

---

From: Seth Breidbart <[email-masked]>
Date: Mon, 21 Aug 2006 13:38:31 -0400 (EDT)

> However, such names MUST be accepted by news servers, if permitted
> by site policy.

I really dislike the "MUST ... if" construction; it seems to violate
the meaning (at least spirit) of "MUST".  I'd prefer something like
"MUST NOT be rejected for this reason alone".  That still permits
rejection for any other reason, so it should retain the desired
meaning.

There is a potential difference in meaning in the case of "site policy
is to reject components beginning with _".  I think we want to say not
to have such a policy, in which case my wording would be better.  (If
we don't say not to have such a policy, the entire sentence is
meaningless.)

Seth

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Mon, 21 Aug 2006 14:19:22 -0400

Harald Alvestrand wrote:
 > However, such names MUST be

I aagree with Seth.

To me, that "MUST accept, if permitted by site policy" actually means "MAY 
reject for [rare] site-specific reasons."

Can it be written using "MAY reject" in both places?

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 21 Aug 2006 23:25:53 +0200

> rejection for any other reason, so it should retain the desired
What I'd like the words to mean is that if you ship a product that can't 
be configured to accept newsgroup names starting with "_" or "+", the 
customer can point to the RFC and say "this product is deficent".

But if a site is configured to not accept any such group name, that's a 
legitimate configuration choice.

I'm sure there are servers configured to reject all groups with "binary" 
in their names, too.....

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 22 Aug 2006 09:23:08 +0200

Harald Alvestrand wrote:

>>> However such names MUST be accepted by news servers, if
>>> permitted by site policy.
[...]
>> "MUST NOT be rejected for this reason alone".

Third proposal in another article:
| MAY be rejected.

> What I'd like the words to mean is that if you ship a product
> that can't be configured to accept newsgroup names starting
> with "_" or "+", the customer can point to the RFC and say
> "this product is deficent".

Makes sense, maybe say "such names MUST be supported by news
servers and user agents." (period, same idea as you've used it
elsewhere, don't talk about "site policy" if it's unnecessary).

> But if a site is configured to not accept any such group
> name, that's a legitimate configuration choice.

Yes, about as interesting as not accepting names containing a
Z (or later for Unicode various scripts).  We could be more
specific why "_" is reserved:  s/future versions/future I18N/

Frank

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 23 Aug 2006 04:47:06 -0700

> specific why "_" is reserved:  s/future versions/future I18N/
We don't have a documented consensus on what it's going to be used for. 
So better not say.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 23 Aug 2006 11:31:38 GMT

>accepted by news servers, if permitted by site policy.

No, I don't think site policy is relevant here. The original intent was
that the future extension should be able to presume that these "funny"
articles would propagate normally through existing servers (at least until
they hit a server which knew what they meant and what to do with them).

>names MUST be accepted by news servers, if permitted by site policy.

but in that case you need to s/MUST/MAY/ (or maybe s/MUST/SHOULD/).

Or you could follow Harald's argument that they MUST be accepted (or
servers MUST be capable of accepting them). But then you need to
understand what "accept" means, and IMO "accept" includes "read and
recognize, and then drop on the floor".

-- 
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: Frank Ellermann <[email-masked]>
Date: Thu, 24 Aug 2006 10:21:57 +0200

Harald Alvestrand wrote:

>> We could be more specific why "_" is reserved:  s/future
>> versions/future I18N/

> We don't have a documented consensus on what it's going to

Yes, but I assumed that there once was some kind of consensus
why it's reserved - if a hypothetical USEFORbis finds another
solution (like the 2047-constructs in s-o-1036) they could then
"unreserve" the underline.  Otherwise they (= USEFORbis folks)
might not know that they are supposed to use or "unreserve" it.
 
> So better not say.

<shrug />  So let them read the old USEFOR archive.  With other
Chairs I'd be paranoid about the curious lack of I18N in this
draft.  When the UTF-8 header fields were killed four years ago
in a WGLC the various *prep RFCs didn't exist.

Frank

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 24 Aug 2006 02:09:45 -0700

> in a WGLC the various *prep RFCs didn't exist.
this WG was chartered to fix that.....

> At the present time an urgent need has been identified to formalize and
> document many of the current and proposed extensions to the Usenet
> Article format. Many extensions are only vaguely documented and have
> competing and overlapping alternatives.
>
> In particular the following areas need urgent attention:
>
> - Standards for the signing of articles (sign-control and PGP-MOOSE)
> - Authentication of cancels.
> - Use of non-ASCII character sets in article headers and bodies
> - Standardization of article bodies and the use of MIME in articles.
> - Standardization and extension of 3rd party control messages affecting
>   articles (NOCEM)
> - General revision of various limits (eg article size) listed in
>   previous standards.
>
> and many other aspects of the standards need reviewing.
>
I guess we need a new charter even though it's out-of-sequence with our 
other out-of-date milestones...

                     Harald

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 24 Aug 2006 16:56:01 +0200

Harald Alvestrand wrote:

> I guess we need a new charter

If there's something better than "No Request For Comments"
at the end of that page, approved and waiting for missing
normative references will do.

For some of the open questions in the old charter it can
be good if mail solutions like DKIM or EAI test the water
before NetNews.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 25 Aug 2006 10:24:57 GMT

>might not know that they are supposed to use or "unreserve" it.

No, there was no specific extension in view. There were just three
characters (+-_) that were syntactically harmless, but by well-established
convention _never_ appeared at the start of a newsgroup-component. We
wished to preseve the convention, so took the opportunity of reserving
those characters for special uses.

I have at times suggested odd things that '+' and '-' might be used by
particular servers by private arrangement with their own clients. If you
want a suggestion for '_', then we might want some day for each newsgroup
to be accompanied by a meta-group containing meta-information about the
main group (NOCEMs for articles in the main group, perhaps). So if the
main group was example.foo, then the meta-group would be _example.foo.
>> So better not say.

Agreed to that. It is just a loophole which costs nothing, but might be
useful someday.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 25 Aug 2006 14:06:00 +0200

Charles Lindsey wrote:
 
> there was no specific extension in view. There were just
> three characters (+-_) that were syntactically harmless, but
> by well-established convention _never_ appeared at the start

Okay, maybe "'_' for I18N" is a product of my imagination, and
the future USEFORbis could find better uses for it.

> we might want some day for each newsgroup to be accompanied
> by a meta-group containing meta-information about the main
> group

For meta-data see also draft-dfncis-netnews-admin-sys-07.txt -
trapped in the RFC editor queue for four years.  

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 25 Aug 2006 10:29:41 GMT

>other out-of-date milestones...

When we have got our present committments out of the way, then it would be
in order to sit down and see what other unfinished business we need to
attend to, and a charter revision would then be in order.

The things that spring to mind are I18N (but the EAI group seems to be
laying a good groundwork for that) and various security-related matters.
But that is all for the future.