Subject: #1178 USEFOR 3.1.5++: Whitespace in headers with newsgroup names

From: Harald Alvestrand <[email-masked]>
Date: Mon, 17 Apr 2006 12:14:03 +0200

This ticket has a confused history, but the issue seems clear:

Whitespace, including folding whitespace, in lists of newsgroups 
(Newsgroups:, Distribution:, Followup-to:) is a newly introduced feature 
of this specification, and doesn't work as intended on all news servers.

The current text in 3.1.5 is:

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.

The claim (by Frank, Feb 20) is that:

> The issue is WSP in all of
> Newsgroups, FollowupsTo, and Distribution:
>
> Newsgroups: one, two, three
>
> That doesn't work as expected on many servers, the blank after
> the comma (any FWS).  USEPRO offers a note about this issue to
> be moved to USEFOR.  For FollowupsTo and Disribution it's the
> same issue, they only need a pointer to SHOULD NOT (or whatever
> it is) for Newsgroups.
The note is from section 3.2 of USEPRO, "Transitional arrangements":

* Because of its importance to all serving agents, the whitespace and 
folding in Newsgroups header fields newly permitted by [USEFOR] SHOULD 
NOT be generated (though it MUST be accepted); this restriction may well 
be removed in a future version of this standard.

I suggest the following resolution for USEFOR:

In section 3.1.5:

Not all servers support <FWS> in the list of newsgroups. In particular, 
folding the Newsgroups header field over several lines has been shown to 
harm propagation significantly. <FWS> in the <newsgroup-list> SHOULD NOT 
be generated, but MUST be accepted.

In section 3.2.3 (followup-to):

As in the Newsgroups: header field, <FWS> in the <newsgroup-list> SHOULD 
NOT be generated, but MUST be accepted.

In section 3.2.7 (distribution):

<FWS> in the <dist-list> SHOULD NOT be generated, but MUST be accepted.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 18 Apr 2006 16:53:56 GMT

>be generated, but MUST be accepted.

s/has been shown to/will currently/

I would still like a sentence to the efffect that some future standard may
lift the restriction (just to encourage implementors to take the MUST
accept seriously). Lack of folding of newsgroups is currently a
confounded nuisance, which is why insisting on its being accepted was one
of the first decisions taken by this WG.

-- 
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: Harald Alvestrand <[email-masked]>
Date: Tue, 18 Apr 2006 22:55:57 +0200

> of the first decisions taken by this WG.
I will not countenance forward-looking statements in this document 
unless there's clear WG consensus for them.

The MOST probable outcome of this effort is IMHO that this is the last 
Netnews standard ever issued - because the decline in the importance of 
Netnews is rapid enough that nobody will care what the standard says in 
another few years.

If I'm wrong, and Netnews continues to be important, the standard can be 
reissued. But don't make promises we're unlikely to keep.

---

From: Richard Clayton <[email-masked]>
Date: Wed, 19 Apr 2006 11:29:36 +0100

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>confounded nuisance, 

It's the main thing -- at the edges -- preventing idiots from posting to
500 newsgroups at once...

... "cleanfeed" style restrictions on cross-posting do of course exist
but are far from universally applied.

So I'm happy to leave it without the indication that a future standard
might change things, because (a) I don't think it will and (b) it's true
anyway, and it would be a really dumb implementer who failed to realise
that's what the MUST was intended to mean.

>which is why insisting on its being accepted was one

I shall be constructive, and not comment on that last bit :)

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 19 Apr 2006 14:07:41 GMT

>unless there's clear WG consensus for them.

A sentence to that effect has been in all our previous 'article' drafts,
and thereafter in all our USEPRO drafts.

This issue (#1178) started with a suggestion to more that sentence from
USEPRO into USEFOR (since it was clealy a USEFOR matter). However,
subsequent discussion seems to have concentrated on other related wording
and that particular part of the proposal was never really commented upon -
one way or the other. Sure, if the WG does not want to say that, then it
need not be said, but the WG does not seem to, have expressed an opinion
thus far.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 20 Apr 2006 07:54:53 +0200

> need not be said, but the WG does not seem to, have expressed an opinion
Anyone else want to defend notes claiming future relaxations?

The word "future" occurs four times in usefor-07:

- justification for reserving _ in newsgroup name components
- note that Approved can't be verified, but a future version may add 
digital signatures
- note that the Lines: field may be removed in a future version
- A wish that PGPVERIFY will be standardized "in the near future"

I don't see a reason to add a fifth one; the 8 occurences in usepro will 
no doubt  be critically examined when the WG's attention turns fully to 
that document.

                      Harald

                             Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 21 Apr 2006 13:25:52 GMT

>- A wish that PGPVERIFY will be standardized "in the near future"

Yes, it is agreed that the present PGPVERIFY has some technical problems,
and our charter explicitly mentions it as a thing needing attention. In
fact, we did some work on replacing it a few years back, but then decided
that it was a step too far for our present drafts, so we decided to leave
it for a future 'security' extension. There are several other security
issues which need to be looked at, so I still believe we need to work on
that security extension, but not until our present drafts are well out of
the way.