Subject: #1032 USEFOR changes from 1036

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 21 Jul 2005 16:11:44 +0200

I've gotten some off-list comments on the text I cribbed from USEPRO.
Currently, we may suggest this text:

o The [RFC 2822] conventions for parenthesis-enclosed <comment>s
in headers are supported.
 o Whitespace is permitted in Newsgroups headers
 o The syntax of the Path header has been reworked to add multiple
forms of information
 o MIME is recognized as an integral part of Netnews.
 o There is a new Injection-Date header to facilitate
the rejection of stale articles.
 o There are several new optional headers defined, notably
 Archive, Injection-Info, and User-Agent, leading to increased
 functionality.
 o There are numerous other small changes, clarifications and
 enhancements

Is this an acceptable text for "changes from 1036"?

                      Harald

---

From: Henry Spencer <[email-masked]>
Date: Thu, 21 Jul 2005 11:49:15 -0400 (EDT)

> the rejection of stale articles.

Perhaps better as:

 o There is a new Injection-Date header to make the
rejection of stale articles more precise and minimize
spurious rejections.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 21 Jul 2005 18:01:28 +0200

Harald Tveit Alvestrand wrote:
 
> o The [RFC 2822] conventions for parenthesis-enclosed
>   <comment>s in headers are supported.

| o The [RFC 2822] conventions for parenthesis-enclosed
|   <comment>s are supported in new header fields and all
|   header fields also used for mail (excl. Message-ID).

> o There are numerous other small changes, clarifications
>   and enhancements

The introduction of a potentially arbitrary <id-right> is
a new concept.  1036 also didn't have the "unique forever".
More stuff mentioned in s-o-1036 that I didn't check:

+ multiple moderators in the Approved header
+ generalization of the Xref rules
+ cancellation authorization based on From, not Sender

We're about to deprecate "Lines:".  We also modified the
"Subject:" (no more SHOULD "Re: ", old "cmsg" removed)

                           Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 22 Jul 2005 16:39:30 GMT

>I've gotten some off-list comments on the text I cribbed from USEPRO.

Eh? There has been no prior mention on this list of your "cribbed text". I
see now that it is based on USEPRO-03, but there is a more up-to-date
version, reflecting recent changes, in USEPRO-04. Here it is in full:

     o The [RFC 2822] conventions for parenthesis-enclosed <comment>s in
       header fields are supported in all newly defined header fields
       and in header fields inherited from [RFC 2822].  They are,
       however, still disallowed for performance and/or compatibility
       reasons in the Message-ID, Newsgroups, Path, Followup-To,
       Control, Supersedes, Distribution, Xref and Lines header fields.
     o Whitespace is permitted in Newsgroups header fields, permitting
       folding of such header fields. Indeed, all header fields can now
       be folded.
     o An enhanced syntax for the Path header field enables the
       injection point of and the route taken by an article to be
       determined with certainty.
     o MIME is recognized as an integral part of Netnews.
     o There is a new Control message 'mvgroup' to facilitate moving a
       group to a different place (name) in a hierarchy.
     o There is a new mandatory Injection-Date header field to
       facilitate the rejection of stale articles.
     o There are new optional header fields defined, Archive,
       Injection-Info and User-Agent, leading to increased
       functionality.
     o Certain header fields and Control messages (F-3.3 and Appendix
       A.3) have been made obsolete.
     o Distributions are expected to be checked at the receiving end, as
       well as the sending end, of a relaying link.
     o There are numerous other small changes, clarifications and
       enhancements.

Clearly, if this is to be moved to USEFOR, the points about the 'mvgroup'
control message, Distributions and obsolete control messages would remain
in USEPRO. I am slightly surprised that you have removed any mention of
obsolete header fields.

Apart from that, it is merely a question of how much to say about each
matter. I see that others have asked for a little more, and have
identified some possible omissions. There is clearly room for some
mix'n'matching of the various suggestions.

> o There are numerous other small changes, clarifications and

It also needs to be decided where to put the "Transitional Arangements"
currently sitting in USEPRO-04.

-- 
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 Tveit Alvestrand <[email-masked]>
Date: Sat, 23 Jul 2005 13:22:45 +0200

--On fredag, juli 22, 2005 16:39:30 +0000 Charles Lindsey 
<[email-masked]> wrote:

>
> In <[email-masked]> Harald Tveit
> Alvestrand <[email-masked]> writes:
>
> version, reflecting recent changes, in USEPRO-04.

You're right.... the message I sent out on June 9 didn't have the text I 
suggested cribbing; I thought it had.

I've asked Ken to keep track of the "currently suggested text" for this 
section.

> Here it is in full:

Need to be careful here.. we recommend not folding, which is why I toned it 
down.

>        determined with certainty.

With respect, that's simply wrong.
Even with the new syntax, there are half a dozen ways in which a false 
injection point can be put into a Path header (old-syntax path, compromised 
server and fooled server being 3 of them).

>        group to a different place (name) in a hierarchy.

USEPRO.

>        facilitate the rejection of stale articles.

It's not mandatory....

>        A.3) have been made obsolete.

Control messages go to USEPRO, but header fields go to USEFOR.
I think we should name them.

>        well as the sending end, of a relaying link.

USEPRO.

> currently sitting in USEPRO-04.

I think all of it, except the "don't fold" stuff, goes to USEPRO, and the 
"don't fold" stuff is already in the main body of USEFOR. Do we need to 
repeat it here?

>
> --
> 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: Sat, 23 Jul 2005 14:00:05 +0200

Harald Tveit Alvestrand wrote:

>> Indeed, all header fields can now be folded.

> Need to be careful here.. we recommend not folding,
> which is why I toned it down.

The Message-ID: header field cannot be folded, it has
only two of these misleading [FWS] in the ABNF.  Dito
Supersedes (misleading [FWS] instead of *WSP), and the
deprecated Lines:

I've tested it only for the Message-ID:    Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 25 Jul 2005 11:15:49 GMT

>Need to be careful here.. we recommend not folding, which is why I toned it 

Sure. That was in my "Transitional Arrangements", but if those are to
remain in USEPRO, some "toning down" is in order here. Also, As Frank has
pointed out, you can't fold a Message-Id, though that is only because
there is not convenient folding point inside it.

>server and fooled server being 3 of them).

Actually no. Even if the Bad Guy preloads the Path with a long string,
including a "POSTED", his injection agent will immediately insert a second
POSTED (and two POSTEDs are an immediate cause for suspicion, although
there are a (very) few legitimate uses for them). And the injection agent
will also provide a new Injection-Info.

Therefore, unless an injecting agent goes rogue, or the Bad Guy manages to
hack his way into it, things are much, much safer that they are at present

>It's not mandatory....

I have already asked for a ticket to look at that.

>I think all of it, except the "don't fold" stuff, goes to USEPRO,...

OK, I can do that.

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 27 Jul 2005 12:23:13 -0400

> in headers are supported.

s/headers/structured header fields/

>  o Whitespace is permitted in Newsgroups headers

s/headers/header fields/

>  o The syntax of the Path header has been reworked to add multiple

s/header/header field/

>  o MIME is recognized as an integral part of Netnews.

Probably warrants some mention of I18N w.r.t. MIME RFC 2047 as
amended by 2231 and errata as I18N provisions mandated by BCP 18.

> the rejection of stale articles.

s/header/header field/

>  Archive, Injection-Info, and User-Agent, leading to increased

s/headers/header fields/
On a related note, it's not clear that we should be worrying about
new functionality in this document at this point (well past multiply-
extended deadline for producing a draft for publication); e.g. there
is still apparently no consensus on Injection-Info.

>  o There are numerous other small changes, clarifications and

These should probably be documented.  Simply saying "there are numerous
other [...] changes" is little better than saying "figure it out for
yourself".
 
> Is this an acceptable text for "changes from 1036"?

There are additional substantive changes not mentioned.  E.g. lack of
rationale for using the IMF (RFCs 850, 1036 section 2)[1], separation
into format and protocol documents, change of (intended) status from
Informational to Standards Track, necessary IPR and content changes
brought about by process and format revisions.  Probably many others,
some of which we need to implement but have not yet implemented (e.g.
registration templates and IANA considerations for header field
registrations).

The document as currently written moves further from compatibility
with the Internet Message Format than 1036; ideally that should be
changed, but failing that the decreased compatibility should be
noted in detail.

------------
1. While the primary consideration mentioned in 850/1036 remains
   important, developments since the mid-1980s affirm the wisdom
   of the choice and argue for improved compatibility:
   a. there now exist combined-use UAs (Netscape Navigator, Mozilla
      Suite, Mozilla Thunderbird, Microsoft Outlook Express, Pine,
      etc.); these have been enabled by the choice of the IMF and
      have benefitted Usenet enormously (the mentioned UAs are responsible
      for a substantial proportion of postings) 
   b. there now exist protocols for conveying messages which include
      all messaging applications (e.g. IMAP), said protocols being used
      by and with the combined-use UAs mentioned above
   c. much of the rational for differences was based on the limitations
      of 1970s-80s vintage hardware -- processor speed is several orders
      of magnitude greater now, as are system main (random-access) memory
      and storage media capacities, removing the justification for some of
      the differences.