Subject: Ticket status, USEFOR - Sept 21

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 21 Sep 2005 13:58:14 +0200

It's been a long time since the last one.
Here's the current list - 17 USEFOR tickets open.

1003 USEFOR 3.1.3 - Cleanup ABNF for msg-id
 "Text proposed"
 We still don't have a good resolution of Frank's "what is the right hand
 side of a message-ID supposed to be" issue.

1028 USEFOR 3.1.2 Date: What zones should be on the MUST accept list?
 "Text accepted"

1029 USEFOR 3.2.2 References: Should comments be a MUST NOT?
 "No consensus"

1032 USEFOR general: Document changes from RFC 1036
 "Text needed" - waiting for Ken to propose text

1046 USEFOR 5. MIME boundary security considerations
 "Text needed"

1047 USEFOR 3.1.6: Path field delimiters and components
 "Text proposed"

1052 USEFOR general: Document changes from RFC 2822
 "Text proposed" - appendix C of -05.

1053 USEFOR 2.1 Relationship to RFC 2822
 "Text Proposed" - my August 12 message.

---- the tickets below this line are new since the previous summary ---

1078 USEFOR 3.1.5: need to describe meaning of Newsgroups header field in 
email
  "Text proposed" (by Charles)

1079 USEFOR 2.1: List all header fields which don't allow comments
  "No discussion"

1080 USEFOR 3.2.14: MIME parameters for Injection-Info and Archive
  header field need more text/updated syntax
   "No consensus"

1082 USEFOR 3.2.9: Need more text about Approved header field semantics?
   "Text proposed"

1084 USEFOR 2.1, 3: Names for ABNF productions redefining 822 constructs
   "Proposed No Change"

1088 USEFOR 3.2.1: Should Injection-Date header be mandatory or optional?
   "Text needed" (I think consensus is "MUST generate, MUST NOT require")

1101 USEFOR 3: Empty article bodies - yes/no?
   "No discussion"

1102 USEFOR 1: Definition of "agents" or of "server/UA"?
   "No consensus" (although I'm not sure if many care)

1132 UEFOR 3.1.6: Outlaw IP address in path-identity?
   "Text accepted" (although the actual text is in #1047, and not finished)

When discussing the specific issues, please include the number in the 
subject header, and STAY ON TOPIC.

Thanks!

                        Harald

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 21 Sep 2005 18:14:16 +0200

> It's been a long time since the last one.

Thanks, I've no clear idea why it doesn't work anymore:
Deleting the old certificate (+ browser restart + get
the new July 11 certificate) didn't help, and...

http://jce.iaik.tugraz.at/servlet/demo.sslserverinfo.SSLServerInfoServlet
http://jce.iaik.tugraz.at/servlet/demo.sslclientinfo.SSLClientInfoServlet

...claim that SSL_RSA_WITH_RC4_128_MD5 "should" work,
as it does with say ietf.org or amazon.  It's not the
known obvious problem with a bogus Netscape "security
library error" message.

If the IETF has yet no patent on "security by obscurity"
I volunteer to submit an I-D explaining the advantange of
TLS user ietf password ietf in relation to ROT-13.  </rant>

> 1028 USEFOR 3.1.2 Date: What zones should be on the
> MUST accept list?  "Text accepted"

That should be ready as soon as the syntax is fixed,
IIRC s/from/orig-date/

> 1029 USEFOR 3.2.2 References: Should comments be a
> MUST NOT? "No consensus"

The usefor-05 text (SHOULD NOT) is IMHO fine.

> 1046 USEFOR 5. MIME boundary security considerations

Some text was proposed 13 weeks ago in:
<http://article.gmane.org/gmane.ietf.usenet.format/28928>

Bruce had no problem with the two examples (one about
2822, another about 2231), and while he suggested that
implementors might be only too naive to get it right,
he didn't object that the 2046 authors probably didn't
want any syntactical nightmares for a MIME boundary.

>  "Text proposed" - appendix C of -05.

"MUST accept obs-phrase" and "MUST accept GMT" are no
differences from 2822.  That appendix could be shorter:

| A more restricted syntax of msg-id (to be used by the
| Message-ID, References, and Supersedes header fields).

That says it all, the following details are irrelevant
for appendix C:

- Comments are not allowed in the Message-ID header field.

- The length of a msg-id MUST NOT exceed 250 octets.

- The <obs-phrase> construct MUST be accepted.

- The obsolete timezone "GMT" MUST be accepted in the Date
- header field.

+ Most obsolete constructs in chapter 4 of [RfC 2822] are
+ not necessarily accepted.  Two exceptions which still
+ must be accepted are <obs-phrase> and timezone "GMT".

> 1079 USEFOR 2.1: List all header fields which don't allow
> comments "No discussion"

That's new for me or I missed it.  Anything relevant for
news servers (Xref, Message-ID, Distribution, Newsgroups,
Control, Supersedes, Expires, Date, Path, what else ?)

> 1082 USEFOR 3.2.9: Need more text about Approved header
> field semantics? "Text proposed"

Where's that proposed text ?

> 1084 USEFOR 2.1, 3: Names for ABNF productions redefining
> 822 constructs  "Proposed No Change"

Yes, some kind of rough consensus IIRC.

> 1101 USEFOR 3: Empty article bodies - yes/no?

Actually one proposal to reject it.

>    "No consensus" (although I'm not sure if many care)

Some (excl. Russ) prefer to say "server/UA" in usefor-06.

                            Bye, Frank

---

From: Richard Clayton <[email-masked]>
Date: Wed, 21 Sep 2005 17:51:07 +0100

In message <[email-masked]>, Frank Ellermann
<[email-masked]> writes

>Actually one proposal to reject it.

they turn up in some of the binary groups...

the Subject header field says "Please post X" and the body is empty

        this seems quite sensible

they also turn up from some mass posting programs with the Subject
saying "Here is X (0/17)" (and then you get 17 more articles with
UUENCODEd data, or whatever).  The intent of the author of the posting
tool was that "0/N" would contain a chatty bit of text, but this
particular poster could not be bothered to type anything in and so the
article is empty

        this seems dumb

they also turn up in text newsgroups, where people push the wrong
button, this is also dumb and unpopular....

... so sometimes it's dumb and sometimes its very sensible. I don't see
that as a reason for forbidding them in the standard.

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 21 Sep 2005 19:11:55 +0200

Richard Clayton wrote:

> sometimes it's dumb and sometimes its very sensible. I don't
> see that as a reason for forbidding them in the standard.

We could keep the s-o-1036 idea (roughly "UAs should warn")
in USEAGE later.
                           Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Wed, 21 Sep 2005 11:18:43 -0700

> that as a reason for forbidding them in the standard.

Some servers (INN notably) reject articles with an empty body at the
moment, although I've been thinking about changing INN in that respect as
it's a pain for mail to news gatewaying.  If we allow them, we probably
need to warn somewhere (USEPRO, probably) that propagation may not be
great.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 22 Sep 2005 22:02:07 GMT

>That says it all, the following details are irrelevant

No they are not.

>- Comments are not allowed in the Message-ID header field.

Comments are still allowed in References (at the moment), so it it not
necessarily all the places msg-id is used. In any case, it is an important
change from RFC 2822, worthy of separate mention.

>- The length of a msg-id MUST NOT exceed 250 octets.

Also worthy of separate mention.

>+ must be accepted are <obs-phrase> and timezone "GMT".

Yes, that is better. but I would rather say:

 - The obsolete syntax is in general not required to be accepted, except
for the following two cases:
     1 ...
     2 ...

Other differences not yet mentioned in Appendix C:

2.2  The content of the first line of a header MUST NOT consist of WSP
     only (though such SHOULD be accepted). Observe that continuation
     lines of headers also MUST NOT consist of WSP only, as in RFC 2822.

2.4  All agents MUST support header lines up to 998 octets, but there is
     no RECOMENDED limit of 78 characters as in RFC 2822. There is mention
     of a purely advisory limit of 79 (with a reference to USEAGE).

2.6  There must not be more than one header with a given header-name,
     except where explicitly sanctioned by the appropriate standard. In
     particular, there MUST NOT be more than one Keywords-header.

2.9 (was 1.6) RFC 2047 and RFC 2231 are fully integrated into the Netnews.

2.10 (was 1.7) All the Content-* MIME headers are considered to be
     incorporated into Netnews and MUST be accepted in articles at, least
     to the extent required by RFC 2049.

Note. Those wordings come from
http://www.imc.org/ietf-usefor/drafts/rfc2822-diffs.txt. I do not propose
thos particular words, but the points need to be covered. Ken?

Also, in http://www.imc.org/ietf-usefor/mail-archive/msg01901.html, i made
the following suggestion:

I have also suggested, to Ken, adding at the end of the new Appendix C:

   NOTE: The effect of all these differences still preserves the property
   that the articles that Usefor permits to be generated form a proper
   subset of the articles that are required to be acceptable to RFC 2822.

-- 
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: Fri, 23 Sep 2005 12:05:18 +0200

Charles Lindsey wrote:

 [Message-ID details irrelevant in appendix C] 

> Comments are still allowed in References (at the moment),
> so it it not necessarily all the places msg-id is used. In
> any case, it is an important change from RFC 2822, worthy
> of separate mention.

Maybe we could join this issue with #1079, and just enumerate
all header fields without CFWS:

+ The following header fields mainly of interest for servers
+ allow no comments (CFWS):  Control, Distribution, Lines,
+ Message-ID, Newsgroups, Path, and Xref.

Neither Date nor Expires qualify for that list, it's the same
<date-time> as in 2822 (modulo "magic SP" and obs-* excl. GMT)

I want to kill simple open tickets, and that would be #1079.

> Also worthy of separate mention.

Maybe, but then please near the main entry for Message-ID:

| A more restricted syntax of msg-id (to be used by the
| Message-ID, References, and Supersedes header fields).
+
+ The length of a msg-id MUST NOT exceed 250 octets.

 
>  - The obsolete syntax is in general not required to be
>    accepted, except for the following two cases:
>      1 ...
>      2 ...

Okay, or maybe mix it, "...not required to be accepted. Two
exceptions....".

###############################################################
 
> 2.2  The content of the first line of a header MUST NOT
>      consist of WSP only (though such SHOULD be accepted).
[...]

Yes, that belongs to the set "magic SP" + "unstructured not
only WSP":

| A SP (space) is REQUIRED after the colon (':') following
| header field name.

+ The first line of a header field MUST contain non-whitespace
+ characters of the header field body.  All header fields have
+ a non-whitespace header field body.  Header fields such as
+ the Subject cannot be empty or blank.

- An <unstructured> header field body MUST contain at least one
- non-whitespace character (header fields such as Subject can
- not be empty).

> 2.4  All agents MUST support header lines up to 998 octets,
>      but there is no RECOMENDED limit of 78 characters as in
>      RFC 2822.

First, I disagree, second, there is no section 2.4 in USEFOR.
Non-existing sections can't introduce differences from 2822.

> 2.6

There is no section 2.6 in USEFOR => no difference from 2822.
 
> 2.9 (was 1.6)

There is no section 2.9 in USEFOR.  1.6 does not talk about
header fields with the same name.  There's no problem with
one, two, three, or 1000 Archived-At or Keywords or what else.
This is no difference from 2822.

> 2.10 (was 1.7)

There is no section 2.9 in USEFOR-05.  There is also no 1.7.
Minimal MIME compatibility (2049) is implicitly addressed in
section 2.3.  This is no difference from 2822 (1.1 scope):

| There are several extensions published, such as the MIME
| document series [RFC2045, RFC2046, RFC2049], which describe
| mechanisms for the transmission of such data through
| electronic mail, either by extending the syntax provided
| here or by structuring such messages to conform to this
| syntax.  Those mechanisms are outside of the scope of this
| standard.

Appendix C cannot enumerate everything that's not in 2822, it
is about _differences_ : 2822-feature A corresponding to a
USEFOR-feature-A' where A is slightly _different_ from A'.

MIME Content-* header fields don't exist in 2822, like a Path
or Followup-To, so it's pointless to list this in appendix C.

Above all stick to usefor-05.  Talking about new non-existing
sections replacing old non-existing sections makes no sense :-(

                           Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 23 Sep 2005 12:36:00 +0200

> + Message-ID, Newsgroups, Path, and Xref.

Sorry, I forgot Supersedes in this 1079-goes-1052-proposal:

+ The following header fields mainly of interest for servers
+ allow no comments (CFWS):  Control, Distribution, Lines,
+ Message-ID, Newsgroups, Path, Supersedes, and Xref.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 23 Sep 2005 14:15:08 GMT

>>    "No consensus" (although I'm not sure if many care)

However, we need to decide one way or another. Currently, most definitions
are duplicated in both USEFOR and USEPRO. That was not intended to be
permanent. My preference is to define the specialized ones in USEPRO,
where they are extensively used. My analysis has shown that USEFOR can
manage quite well on just two (user agent and news-server/whatever), and I
have offered to propose the detailed changes if the principle appears
acceptable.

>Some (excl. Russ) prefer to say "server/UA" in usefor-06.

Here is a suggestion for a slightly different terminology.

At present, "user agent" encompasses posting agent, followup agent and
reading agent. That seems fine.

We need a similar term to encompass injecting agent, relaying agent and
serving agent. So far, I have come up with news-server (with an awkward
hyphen in it).

My suggestion now is to s/serving agent/storage agent/ throughout USEPRO
(and anywhere else) and then to use "serving agent" to encompass the other
three. In some ways, "storage agent" is more descriptive of what they
actually do, and something involving "serving/server" is more in line with
what the world out there uses for the wider encompassing concept.

USEFOR would then "user agent" and "serving agent" (or sometimes just
"agent").

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 23 Sep 2005 17:05:00 +0200

>  "Text Proposed" - my August 12 message.

news://news.gmane.org/[email-masked]
http://mid.gmane.org/[email-masked]

Some proposed to replace "; agents may choose to accept such
articles, reject such articles or modify such articles." by a
period, otherwise that's ready from my POV.

In my parallel universe the following tickets are "ready" and
only waiting for usefor-06:  #1028, #1029, #1046, #1052 (that
is appendix C), #1053, #1078 (I've not yet seen or missed the
proposed text), #1079, #1082 (I've not yet seen or missed the
proposed text), #1084, #1088 (MUST generate, MUST NOT require
as proposed by Harald), #1101, #1132 (added to #1047, no IPs
in path-identity).

That's 12 of 17, the five remaining issues are: #1003 (3:3:1
with a potential rough 6:1 consensus to derive from 2822 for
the <msg-id>), #1032 (text for appendix B needed), #1047 (the
Path), #1080 (Injection-Info, waiting for Bruce's and Charles'
final proposals), #1102 (use UA/server in USEFOR).

Maybe a good time for a usefor-06:  It confuses me when Charles
talks about new sections replacing non-existing old sections
like "2.10 (was 1.7)".

#1032 and #1102 are no showstoppers.  #1003 could be solved by
a poll during an "internal last call" for usefor-07 (?).

For #1080 we either pick one of two proposals, or there's only
one proposal.  Or we use 3.2.14 as is adding [CFWS] everywhere.

In other words, #1047 is the bottle-neck, but it's possible to
join the recent proposals.
                             Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 23 Sep 2005 17:16:59 +0200

Charles Lindsey wrote:

> USEFOR would then "user agent" and "serving agent"
> (or sometimes just "agent").

I'm at a loss why "serving agent" should be better than
"news-server", but otherwise that could finish #1102
(for USEFOR-06) => editor's choice.  Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 23 Sep 2005 14:39:02 GMT

>> MUST accept list?  "Text accepted"

Actually, it is further than that, since I think the accepted text is
already in USEFOR-05.

>That should be ready as soon as the syntax is fixed,

Agreed.

>The usefor-05 text (SHOULD NOT) is IMHO fine.

Me2

><http://article.gmane.org/gmane.ietf.usenet.format/28928>

My feeling is that security problems in 2045 should be fixed in 2045bis,
and security problems in 2231 should be fixed in 2231bis.

In any case, I do not quite follow what your two examples are intended to
show.

>Control, Supersedes, Expires, Date, Path, what else ?)

Add Followup-To, Lines
But remove Expires, Date (unchanged from 2822)

> The Approved header field indicates the mailing addresses (and 
> possibly the full names) of the persons or entities approving the 
> article for posting. Its principal uses are in moderated articles and 
> in group control messages [USEPRO].

[The last sentence has been added]

There should also be a sentence (maybe in a NOTE) such as the following

   The presence of a this header implies a claim to have authority to post
   the article, thus assisting other sites to determine whether to accept
   or act upon it.

in order to explain the semantics of this header.

>Yes, some kind of rough consensus IIRC.

Me2

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 23 Sep 2005 14:48:23 GMT

>> that as a reason for forbidding them in the standard.

The only reason is a sentence in son-of-1036 to the effect that some
software reacts badly to bodyless articles.

Calling Henry! What software did you have in mind, and is that software
still in current use? If not, then we don't need the restriction.

>need to warn somewhere (USEPRO, probably) that propagation may not be

Is that rejection when INN is injecting, or when it is relaying?

If the former, it is no problem (the article is returned to the poster and
he fixes it). And you remove the restriction in future releases.

But if it is the latter, then that is a serious problem given the
widespread use of INN, and we would need to say something somewhere.

Are you aware of other software with this problem?

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 23 Sep 2005 15:59:49 GMT

>1003 USEFOR 3.1.3 - Cleanup ABNF for msg-id

I have 3 issues:

1. 3.1.3 1st para:

s/and some news software might have trouble with the full range of
  possible <msg-id>s permitted by [RFC2822];
 /and news software complying with [NNTP] would have trouble with the full
  range of possible <msg-id>s permitted by [RFC2822];/

(where NNTP means the new standard currently with the RFC Editor).

2. <[email-masked]>
   <"ab.cd"@example.com>
   <"ab.\cd"@example.com>
(I think that small change has already been accepted)

3. If domain literals are used, the syntax found in Section 4.1.3 of
   [RFC2821] is RECOMMENDED.

The IPv6Address notation in RFC 2821 is unusual, and I hear might be
dropped in 2821bis. Better to say

or else omit it entirely.

   If domain literals are used, they SHOULD take the form of an
   <IPv4address> or <IPv6address> [RFC 3986].

> side of a message-ID supposed to be" issue.

I am happy that the NOTE at the end of 3.1.3 says all that needs to be
said.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 23 Sep 2005 19:06:40 +0200

Charles Lindsey wrote:

> My feeling is that security problems in 2045 should be fixed
> in 2045bis

Sure, in that case it would be 2046bis.  But as long as they
are not fixed, and we mandate to support MIME+ 2231+ (2)822
CFWS, we have to list this known problem.

Nobody's working on 2046bis at the moment, only MIME part 4
(2048bis) is ready.

> I do not quite follow what your two examples are intended to
> show.

Bruce's example shows that a MIME boundary can be very tricky
if you add 2822 CFWS, my example shows the same for 2231.

"Naive MIME implementations" (as Bruce put it) won't get this
"right", in fact we're not completely sure what "right" is in
the case of a boundary (2046 + 2231 suggest that at least some
syntax oddities shouldn't be used for a boundary).

With that insecure and unclear situation there are two choices:
Delete MIME in USEFOR falling back to a pre-s-o-1036 position
with a 2822 "out-of-scope" approach, or simply document this
"security consideration".

> But remove Expires, Date (unchanged from 2822)

ACK, I also forgot Followup-To.  It's not "server territory",
but it will end up there (as Newsgroups), and it's the same
<newsgroup-list> without CFWS => Posting or followup agents
trying to add comments in Followup-To are doomed.

  [#1082]
>> The Approved header field indicates the mailing addresses
>> (and possibly the full names) of the persons or entities
>> approving the article for posting. Its principal uses are
>> in moderated articles and in group control messages
>> [USEPRO]

#1082 => ready.

>    The presence of a this header implies a claim to have
>    authority to post the article, thus assisting other sites
>    to determine whether to accept or act upon it.

USEPRO or USEAGE details, that's IMHO irrelevant for USEFOR:

Of course it's a claim, and of course this header field has a
technical purpose (explained elsewhere).

                             Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 23 Sep 2005 19:33:46 +0200

Charles Lindsey wrote:

> s/and some news software might have trouble with the full
> range of possible <msg-id>s permitted by [RFC2822];
> /and news software complying with [NNTP] would have trouble
> with the full range of possible <msg-id>s permitted by
> [RFC2822];/

How about "...software and [NNTP] have..." ?  There's trouble
elsewhere with the 2822-concept, not limited to NNTP, and not
only "might have".

>    <[email-masked]>

No problem, that shows "one dot in the middle is no excuse
for using a quoted-string".

> <IPv4address> or <IPv6address> [RFC 3986].

Yes, we'll probably use STD 66 also in other contexts.  For
2821bis I fear it can't simply forbid leading IPv4-zeros, and
so far John never commented my feeble attempts to get rid of
the strange IPv6-tag in 2821bis.  Or the ugly dcontent (with
NO-WS-CTL) for his hypothetical "General-Address-Literal".

> I am happy that the NOTE at the end of 3.1.3 says all that
> needs to be said.

That's where I think that <id-domain> won't need this NOTE,
and your (= you and Harald) discussion about some "artificial
subdomains" in another protocol (NAI) was also interesting
for this issue.
                       Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 23 Sep 2005 16:12:55 GMT

>1047 USEFOR 3.1.6: Path field delimiters and components

Discussion ongoing

>  "Text proposed" (by Charles)

I think there was support from Russ, maybe others.

>  header field need more text/updated syntax

Discussion ongoing

>1084 USEFOR 2.1, 3: Names for ABNF productions redefining 822 constructs

Agree

>   "Text needed" (I think consensus is "MUST generate, MUST NOT require")

On Aug 26th I proposed:

     NOTE: [USEPRO] REQUIRES this header field to be inserted whenever an
     article in injected into the network. However, since it is newly
     introduced in this standard, agents MUST continue to accept articles
     generated by earlier systems which do not include it. For this
     reason, it has not formally been designated as "mandatory".

---

From: Russ Allbery <[email-masked]>
Date: Fri, 23 Sep 2005 13:06:55 -0700

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

>> moment, although I've been thinking about changing INN in that respect
>> as it's a pain for mail to news gatewaying.  If we allow them, we
>> probably need to warn somewhere (USEPRO, probably) that propagation may
>> not be great.

> Is that rejection when INN is injecting, or when it is relaying?

INN only cares when injecting.

> Are you aware of other software with this problem?

Not off-hand, but it wouldn't surprise me if it existed.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 23 Sep 2005 13:15:02 -0700

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

>> 1078 USEFOR 3.1.5: need to describe meaning of Newsgroups header field
>> in email

> I think there was support from Russ, maybe others.

Looking over the current ticket, I'm completely ambivalent, neither
supporting it nor not supporting it.  The gain in clarity competes with
the weird feeling about defining headers for e-mail in a news document.

>      NOTE: [USEPRO] REQUIRES this header field to be inserted whenever
>      an article in injected into the network. However, since it is newly
>      introduced in this standard, agents MUST continue to accept
>      articles generated by earlier systems which do not include it. For
>      this reason, it has not formally been designated as "mandatory".

RFC 2119 language doesn't belong in notes.  If it's part of the protocol,
it should be in the main body of the text.

Other than that, I think this is too wordy.  Let's just say:

    This header field MUST be inserted whenever an article is injected.
    However, software that predates this standard does not use this
    header, and therefore agents MUST accept articles without the
    Injection-Date header field.

I assume the fallback to Date is described elsewhere.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 26 Sep 2005 11:26:52 GMT

>the weird feeling about defining headers for e-mail in a news document.

Newsgroups is "our" header, so we get to say what it means. Otherwise,
some mail standard will rush in and say it wrong (look at 'Supersedes').
Indeed, it was such a proposal by Jacob Palme (years ago) that caused it
to appear in our drafts, and he declared himself satisfied by what we had
written.

>it should be in the main body of the text.

I think Harald agreed recently that RFC 2119 language in NOTEs was fine if
it just quoted some other document, or drew attention to a consequence
which could be deduced from such other documents.

>    Injection-Date header field.

No, the intent was to explain why it was not in the section for
"mandatory" headers, as might have been expected.

Here is another attempt:

      NOTE: [USEPRO] REQUIRES this header field to be inserted whenever an
      article in injected into the network. However, it has not formally
      been designated as "mandatory" since articles generated by earlier
      systems which do not include it still need to be accepted.

>I assume the fallback to Date is described elsewhere.

Yes.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 26 Sep 2005 11:43:26 GMT

>elsewhere with the 2822-concept, not limited to NNTP, and not

Fine, so long as NNTP gets mentioned as a major reason.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 26 Sep 2005 10:17:01 -0700

> to appear in our drafts, and he declared himself satisfied by what we
> had written.

This argument doesn't convince me to be other than ambivalent.

>>>      an article in injected into the network. However, since it is
>>>      newly introduced in this standard, agents MUST continue to accept
>>>      articles generated by earlier systems which do not include
>>>      it. For this reason, it has not formally been designated as
>>>      "mandatory".

>> RFC 2119 language doesn't belong in notes.  If it's part of the
>> protocol, it should be in the main body of the text.

> I think Harald agreed recently that RFC 2119 language in NOTEs was fine
> if it just quoted some other document, or drew attention to a
> consequence which could be deduced from such other documents.

I can see the justification for that, but that's not what that second MUST
is.  That second MUST is a statement about the article format and about
what parsers have to implement, not a provision that's just copied from
another document.  I don't think it should be in a NOTE.

>       systems which do not include it still need to be accepted.

I prefer my wording and do not support this proposal.  I don't think it's
necessary to explicitly talk about the mandatory designation, and I do
want to see that MUST in there to make it very explicit what the required
behavior is.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 27 Sep 2005 10:25:22 GMT

>want to see that MUST in there to make it very explicit what the required

If some particular header is defined in the syntax, and is declared to be
optional rather than mandatory, then it follows without further verbiage
that compliant agents MUST accept articles without it.

Therefore your proposed sentence (not in a NOTE) adds nothing.

However, a NOTE drawing attention to its slightly unusual status, and for
the removal of any possible doubt, is perfectly in order.