Subject: NEW: USEFOR -05 3.1 Injection-Date was mandatory

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 20 Jul 2005 16:45:35 GMT

Ticket please.

In Usefor-03, the Injection-Date header field was mandatory. In Usefor-04
it was made optional without any prior discussion in this WG. I request
that it be restored. The background to this is as follows:

The Injection-Date field was introduced about a year ago following
discussions on this WG.

The reason for introducing Injection-Date was that RFC 2822 had changed
the meaning of Date. It is now the date when the article was written
(which is a Good Thing), whereas much present software actually fills in
the date when it was injected. The date when an article was written may be
quite some time before before it gets injected. Think of a man who writes
an article on his laptop, but does not manage to get to an internet
connection until three days later. By that time, many sites will refuse
the article because their expiry limit is only 3 days.

This header field was therefore made "MUST generate" (and that is what
USEPRO still says). Clearly nobody will be generating this header on Day 1
of the new standard.When people do start generating it, no additional harm
will arise at sites that have not yet upgraded (they just ignore it, like
they do all unknown headers).  There are specific provisions in USEPRO for
sites to fall back to using the Date header when the Injection-Date header
is missing. Thus no compatibility issues (forward or backward) arise.

Since I had written "MUST generate", I therefore put this header into the
"mandatory" class in the old draft-13, and that is how it appeared
initially in USEFOR.

Sites are supposed to check that the Injection-Date (or failing that the
Date) falls within their expiry limits; failure to implement this check
can result in endless loops, which is the ultimate sin on Usenet. Indeed,
all well managed sites already do it (using Date) even though no current
standard tells them to (it's just part of the "folklore" on which Usenet
currently runs).

There are many news features we have introduced which will render existing
implementations technically non-compliant on the day this standard comes
out (folding of Newsgroups header fields, which MUST be accepted, is one
example). However, in all such cases we have carefully arranged that no
immediate harm arises (see the section on "Transitional Arrangements"
currently in USEPRO, though it may finally end up in an Appendix in
USEFOR). It was always considered that implementors would be more likely
to implement the new features more quickly if we wrote a few MUSTs to
encourage them (take your choice as to whether that counts as a carrot or
a stick :-) ). I don't see why this particular case should be treated any
differently, nor do I see any difference in strength between the terms
"mandatory" and "MUST".
 
-- 
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 02:09:26 +0200

Charles Lindsey wrote:
 
> This header field was therefore made "MUST generate"

Okay, let's say that my proposal to join it with Injection-Info
is a bad idea.  MUST => mandatory makes sense.  Bye, Frank

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 Jul 2005 20:10:02 +0100

>Ticket please.
I've created a ticked # 1088 for this.