Subject: Fwd: http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-03.txt

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 11 Apr 2005 10:56:25 +0100

------- Forwarded message -------
From: "Dr John Stockton" <[email-masked]>
To: "Charles. H. Lindsey" <[email-masked]>
Subject:  
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-03.txt
Date: Sun, 10 Apr 2005 19:44:55 +0100

I've also been reading
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-03.txt,
April 2005.

"Changes since draft-ietf-usefor-usefor-01
...
    o  Only allow "UT and "GMT" in Date header; disallow all other <obs-
       zone>."

AIUI, it is UTC and not UT that is distributed by time servers, in which
case a label UT would in practice be incorrect in principle.  UT != UTC.
Anyway, IIRC, UT is GMT, except when it is the University of Texas.

Note that while input of UTC should allow 23:59:60, in this context
output should not generate it, since an error of <= one second is better
than a risk of a receiving agent getting upset about it.  A posting
agent can just wait for a leap second to have finished.

However, I see that the tenor of 3.1.2 is incompatible with the
introduction of UTC.

"1.1  Basic Concepts
    "Netnews" is a set of protocols for generating, storing and
    retrieving news "articles" (which are a subset of Email messages)"

They are surely not a subset of E-mail messages.  They might be
described as similar.  But E-mail is now commonly HTML & News should not
be; I'd omit the parenthetic analogy.

"1.2  Scope
...
    An best ..."   Ouch.

"1.5  Definitions
...
      When an article is posted to more than one newsgroup, it
    is said to be "crossposted"; ..."

'When a single [copy of an ] article ...' ???

"2.2  Headers"    and elsewhere.

The common understanding of "Header[s]" is "That cabalistic stuff before
the message starts", whereas Header is evidently used here to refer to a
logical line starting with such as "Date: ".

ISTM that, clear definitions notwithstanding, there is an undue risk of
reader error unless there is a very clear written distinction in all
references to the entire heading material, the logical (de-folded)
lines, and the physical (to CRLF) lines.  That part got me confused.

"3.1.2  Date"

ISTM that "GMT" is useful to the human reader, as indicating a choice of
the world standard time rather than the local one.  My Turnpike here
uses +0000 in Winter Time, which carries an expectation that it will use
+0100 in Summer Time, and that the relevant agent is in the London time
zone.  GMT would carry no such implication.  Then agents such as Google
should be encouraged to use GMT rather than -0800, if they cannot use
the author's zone.  In other words, I suggest un-deprecation of GMT
(and/or UT/UTC).

Presumably absence of a numeric offset indication, while not allowed,
would be treated as +0000.

"3.3.1  Lines"

This may not be needed for the transmission of News; but it is very
useful for Kill Rules.  Therefore, IMHO it should be compulsory, not
obsolete (unless replaced by, say, 'Bytes').

"5.  Security Considerations
...
    Agents that generate message-ids for news articles
    SHOULD ensure that they are unpredictable."

It would be undesirable to lose the ability to kill-rule on partial
message-ID, or to kill spam addressed to message-IDs using partial ID,
or to search news databases on partial ID.  Therefore, I suggest
something like "incompletely predictable".  The right hand side in fact
should be predictable.

Example : the first two of the last four characters of a Turnpike
message-ID are, for a given setup, constant over long periods of time;
mine are currently Fw.  Therefore, it could be useful for me to kill all
mail to .*fw..@<here>, provided that I have no user called
halfwit@<here> or similar.  AIUI, newer Turnpike allows the user to
choose the last few characters of the left part, which is even better as
a kill target.

Regards,

-- 
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: Charles Lindsey <[email-masked]>
Date: Mon, 11 Apr 2005 13:12:43 +0100 (BST)

>http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-03.txt,

I think most of these points are for Ken Murchison to answer. So I shall
just make a few comments.

>Anyway, IIRC, UT is GMT, except when it is the University of Texas.

The only reason these two <zone>s remain in the draft is that they are in
current widespread use (well, GMT is anyway). So they must continue to be
accepted, even though they MUST NOT be generated in future. Generally
speaking, neither news nor email software cares in the least about the
subtleties of UTC vs GMT. Times, as they appear in Date headers, are just
approximations to the time the article was written, and cannot be assumed
to be accurate to better than a few minutes.

>Note that while input of UTC should allow 23:59:60,...

That format for time is already permitted by RFC 2822, though I doubt any
operating system ever produces it in real practice.

>be; I'd omit the parenthetic analogy.

Yes, it might be better to say "(whose format is a subset of that for
Email messages)". Ken?

>'When a single [copy of an ] article ...' ???

I am not convinced that needs changing.

>logical line starting with such as "Date: ".

We took a conscious decision to use the terminology in widespread use,
rather than that defined in RFC 2822. The new NNTP draft is following that
same approach. So the "cabalistic stuff" is the "Headers" (plural) and the
Date header, for example, is a "Header" (singular).

>lines, and the physical (to CRLF) lines.  That part got me confused.

I think (hope) that the draft always makes it clear from the context when
a single "header line" is being discussed.

>the author's zone.  In other words, I suggest un-deprecation of GMT

I don't think there has ever been any expectation that you can guess, from
somebody's Date header, whether that somebody lives in a location where
daylight saving applies. And I believe Madrid also uses +0000 in Winter
(and if Madrid doesn't, then Lisbon surely will - and what about
Casablanca)?

Generally speaking, the poster's timezone, as written, should be preserved
as the article propagates or gets stored (indeed, gratuitous changes of
headers are forbidden by Usepro). I find it useful to know whether someone
really was taking the trouble to stay up late to respond to my messages.

>would be treated as +0000.

Possibly.

>obsolete (unless replaced by, say, 'Bytes').

I think the WG agreed early on that this header had passed its
sell-by-date, though I do not think we intended it to be declared
"obsolete" as the current Usefor draft implies. I think "obsolescent" is
the right term. At least the draft does define exactly which lines are
supposed to get counted, which had always been a bit vague hitherto.

>something like "incompletely predictable".  The right hand side in fact

RFC 2822 RECOMMENDS (which is a pretty strong term) that the RHS
should be the domain of the sender (or of his ISP), and Usefor inherits
that RECCOMENDATION.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 11 Apr 2005 11:45:43 -0700

Charles Lindsey <[email-masked]> writes:
> "Dr John Stockton" <[email-masked]> writes:

>> obsolete (unless replaced by, say, 'Bytes').

Kill Rules are based on overview information, not on article headers
except in unusual situations (since killing on full headers is very slow).
Overview contains its own line count that has nothing to do with an
article header; this is specified by the NNTP protocol.

You will find, if you analyze articles in the wild, that a significant
percentage of Lines headers are wrong.

> "obsolete" as the current Usefor draft implies.

I believe that we did.  We intended it to be declared obsolete in the
sense that nothing should generate it and nothing should use it.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 12 Apr 2005 10:31:54 +0100

>sense that nothing should generate it and nothing should use it.
Exactly. I don't think any clarification in the document is needed.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 12 Apr 2005 11:23:40 GMT

>article header; this is specified by the NNTP protocol.

I think it is up to individual implementors of reading agents whether to
provide kill file facilities on all headers, or only on those in the
overview; some do, some don't.

>percentage of Lines headers are wrong.

Indeed, but any killfile rule is likely to be expressed as "kill all
articles where Lines > 1000", in which case absolute accuracy of the line
count hardly matters. But I agree that there are better ways of killing
overly long articles.

>sense that nothing should generate it and nothing should use it.

The wording actually used, which has not changed since our very early
drafts, was

   This header is to be regarded as obsolete, and it will likely be
   removed entirely in a future version of this standard. In the
   meantime, its use is deprecated.

Which to me indicates "It is not obsolete yet, but it soon will be, so it
is not really a good idea to use it". I think we did it that way because
we wanted to document the correct way to do the count (because
implementations regularly did it wrong), but there was still a widespread
usage of it, which was likely to continue for some while.

To my mind, the proper word to describe that situation is "obsolescent",
rather than "obsolete".

---

From: Russ Allbery <[email-masked]>
Date: Tue, 12 Apr 2005 11:52:37 -0700

John Stockton <[email-masked]> writes:

> I use Turnpike.  It has kill-rules acting on article headers.  With a
> general rule using a RegExp one can kill or accept by a wide variety of
> criteria.  But in the controlling dialogue of the version that I use
> there is specific provision for "Number of lines ... (as recorded in the
> header)" - enter a number, rather than compose a RegExp - evidently, an
> Internet Expert must have considered Lines to be useful information..

> I find this useful in newsgroups where a few users tend to post whole
> web pages, computer programs, or essays.

Yes.  I'm not disagreeing about the usefulness of that sort of killfile
rule.  I'm saying that Turnpike should apply that rule against the
overview information, which is guaranteed to be correct.  You'll get
exactly the same results, faster, and more reliably.

If it's using the Lines header in the article, it's getting occasionally
bogus results right now.  The standard is intended to tell Turnpike and
other news readers that do this to stop and use the overview information
instead.  Declaring this to be a bug in Turnpike is fully intentional.

> That will not meet with universal agreement.

It generally does as soon as people understand what I mean when I say that
a better version of that information is already in the overview data.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 12 Apr 2005 11:59:29 -0700

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

>> except in unusual situations (since killing on full headers is very
>> slow).  Overview contains its own line count that has nothing to do
>> with an article header; this is specified by the NNTP protocol.

> overview; some do, some don't.

Except for Lines.  Lines should always be applied against overview.

> articles where Lines > 1000", in which case absolute accuracy of the
> line count hardly matters. But I agree that there are better ways of
> killing overly long articles.

Like EXACTLY THAT KILLFILE RULE, but applied against the
guaranteed-accurate overview information.

> Which to me indicates "It is not obsolete yet, but it soon will be, so
> it is not really a good idea to use it". I think we did it that way
> because we wanted to document the correct way to do the count (because
> implementations regularly did it wrong), but there was still a
> widespread usage of it, which was likely to continue for some while.

> To my mind, the proper word to describe that situation is "obsolescent",

I think I see what you're saying -- it's not obsolete in the sense that
Path is obsolete (where news servers actually reject messages containing
the header).  I'm fine with the wording; I guess I don't really care
whether that means "obsolete" or "obsolescent" as long as the key point is
expressed: don't use the header and don't bother creating it.

---

From: Richard Clayton <[email-masked]>
Date: Tue, 12 Apr 2005 20:20:10 +0100

In message <[email-masked]>, Russ Allbery
<[email-masked]> writes
>overview information, which is guaranteed to be correct.  

which it can already do :)

.... assuming of course that its heuristics (and configuration) mean
that it is indeed fetching the overview info and it isn't just using
HEAD commands (that will always "work") ...  in the real world, clients
currently have to guess (or be told) what facilities to use; and tend to
err in favour of features that are bound to be available...

... hence the value of NNTP v2 :)

>instead.  Declaring this to be a bug in Turnpike is fully intentional.

John should add  USEXOVER=YES to the appropriate [NEWS xxx] part of his
configuration file  :)  and the "bug" will not bite him

- -- 
richard @ highwayman . com                       "Nothing seems the same
                          Still you never see the change from day to day
                                And no-one notices the customs slip away"

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 13 Apr 2005 15:27:14 GMT

>expressed: don't use the header and don't bother creating it.

Eh? Since when has Path been obsolete. Are you confusing it with some
other ancient header?

---

From: Russ Allbery <[email-masked]>
Date: Wed, 13 Apr 2005 13:02:53 -0700

> Eh? Since when has Path been obsolete. Are you confusing it with some

Er, sorry, not Path, Received.  Bleh.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 20 Apr 2005 19:45:12 GMT

>Er, sorry, not Path, Received.  Bleh.

Ah! But in that case I don't think servers should be rejecting such
headers. If the article has been wandering in any out of both email and
news systems, then it is sometimes useful to have the full history recorded
(though I might agree that if there was a mailing list involved I might
not want to know what happened before it reached the mailing list).

---

From: Russ Allbery <[email-masked]>
Date: Wed, 20 Apr 2005 16:44:43 -0700

Charles Lindsey <[email-masked]> writes:

> news systems, then it is sometimes useful to have the full history
> recorded (though I might agree that if there was a mailing list involved
> I might not want to know what happened before it reached the mailing
> list).

Then I don't understand the distinction you're drawing between obsolete
and obsolescent.  As near as I could tell, the only difference in practice
was that servers were rejecting the former headers, but now you're saying
that they shouldn't even do that.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 21 Apr 2005 15:44:40 GMT

>that they shouldn't even do that.

Generally speaking, our draft has always said (and I think Usefor still
says) that if you see a header that you do not recognize as a news header,
you just leave it be and ignore it. Essentially the same applies in Mail.

The only time you should be worrying is if you DO recognize it as a news
header, and can see that it is malformed and likely to cause trouble
elsewhere (and especially so if you are an injecting agent).

---

From: Russ Allbery <[email-masked]>
Date: Thu, 21 Apr 2005 12:04:23 -0700

>> and obsolescent.  As near as I could tell, the only difference in
>> practice was that servers were rejecting the former headers, but now
>> you're saying that they shouldn't even do that.

> says) that if you see a header that you do not recognize as a news
> header, you just leave it be and ignore it. Essentially the same applies
> in Mail.

I got this part, but it doesn't answer my confusion above.  What's the
difference between obsolete and obsolescent?

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 22 Apr 2005 12:09:06 GMT

>difference between obsolete and obsolescent?

"Obsolete" means this is no longer an official Netnews header. It would be
labelled as "obsolete" in the IANA Registy of headers.

"Obsolescent" means that is is still an official Netnews header (just),
but that its continued use is discouraged (for reasons that are given),
and that it is likely to be declared fully obsolete in a future standard.

Our earlier drafts uses the words "is to be regarded as obsolete", which
falls slightly short of "is obsolete" and would IMO be better expressed as
"obsolescent", if indeed that is the meaning we wish to convey (it was
certainly the meaning I intended to convey in those drafts).

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 23 Apr 2005 00:33:26 +0200

Charles Lindsey wrote:

> "Obsolete" means this is no longer an official Netnews
> header. It would be labelled as "obsolete" in the IANA
> Registy of headers.

Bruce has created a draft with mail headers found in obsolete
RfCs.  Among others Fcc: found in RfC 724 obsoleted by RfC 733.

For news we'd declare See-Also: and Also-Control: as obsolete,
as soon as Henry publishes s-o-1036 for information (obsoleted
by - I'm an optimist here - draft-ietf-usefor-usefor-04.tx)

> "Obsolescent" means that is is still an official Netnews
> header (just), but that its continued use is discouraged
> (for reasons that are given), and that it is likely to be
> declared fully obsolete in a future standard.

Now as pessimist:  There won't be any future standard, UseFor
is the last news standard before its death.  So Lines: will be
obsolescent "forever" until the last news server goes jabber,
or atom over soap based on beep, or whatever comes next.  Bye.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 24 Apr 2005 17:07:49 +0100

>by - I'm an optimist here - draft-ietf-usefor-usefor-04.tx)
In order to close this issue I suggest that the USEFOR document can 
include few sentences describing what do we mean when calling a 
particular header "obsolete".

>obsolescent "forever"
I tend to share your pessimism, but maybe for a slightly different reason.

> until the last news server goes jabber,

---

From: Ken Murchison <[email-masked]>
Date: Tue, 26 Apr 2005 10:02:19 -0400

> Yes, it might be better to say "(whose format is a subset of that for

Yes, I'll make this change.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Ken Murchison <[email-masked]>
Date: Tue, 26 Apr 2005 10:08:05 -0400

> particular header "obsolete".

Care to craft some text and tell me where you'd like to see it?

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 27 Apr 2005 10:38:20 +0200

> Care to craft some text and tell me where you'd like to see

IMHO all that should be done is to update this statement:

| As a result, this header is to be regarded as obsolete, and
| it will likely be removed entirely in a future version of
| this standard.

  As a result, this header is to be regarded as obsolescent.
  Servers and UAs MUST accept but SHOULD ignore it, and SHOULD
  NOT generate it.

For the obsolete headers in 3.3 you already have a definition:

| Articles containing these headers MUST NOT be generated.
| Persons writing new agents SHOULD ignore any former meanings
| these headers.

That should be "of these headers", but the sentence makes no
sense, the handling depends on the header field.  Probably new
agents MUST ignore the former meaning of the obsolete header
fields.  But for Also-Control I'd opt for the same procedure
as for a Subject: cmsg without a corresponding Control:

Oops, "new" problem:

Subject: cmsg is not mentioned anywhere in usefor-03, that's a
serious bug.  It's mentioned in usepro-03, but it only says
that this is now obsolete.  That's of course FUBAR, it's a
severe security violation.  We cannot jump from RfC 1036 to a
completely different procedure at date X.  AFAIK RfCs must not
have a flag day.
  
Even if it's only in theory (which it's not, Subject: cmsg has
serious difficulties to propagate, the last time I checked it
Google ignored a Subject: Re: cmsg, and that's not the only
oddity with a Subject: cmsg)

Maybe publishing Henry's s-o-1036 first could formally save
this situation, otherwise Subject: cmsg is IMO a showstopper.

                          Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Wed, 27 Apr 2005 10:57:51 -0700

>   Servers and UAs MUST accept but SHOULD ignore it, and SHOULD

I dislike saying that servers MUST accept a header, since servers are not
required to accept *any* article.  I would also leave in the bit about
removing it in a future version of the standard.

> completely different procedure at date X.  AFAIK RfCs must not

I think USEFOR does need an explicit mention that subjects starting with
cmsg should not be considered control messages, to document the change
from RFC 1036.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 28 Apr 2005 14:59:39 +0200

Russ Allbery wrote:
 
> I dislike saying that servers MUST accept a header

Yes, we have some seriouss case of "Deja-Vu" on this
list, I'm not immune, sorry.  What I really wanted to
say, there's a difference between the "Lines:" and
other obsolete header fields in 3.3.

"Lines:" is deprecated _now_ by the future Usefor RfC.
It was optional and unreliable in s-o-1036.  

Some other headers mentioned in 3.3 are something I've
never seen or heard of:  Relay-Version, Posting-Version,
Date-Received.  

s-o-1036 says "thoroughly obsolete" about these three
header fields listed in its appendix A.3, that was 1994.

Finally there are some headers introduced by s-o-1036
that didn't make it (unlike Supersedes):  See-Also,
Article-Names, Article-Replacing, and Also-Control.

Strange, my copy of s-o-1036 (Jan 17 1994) says
"Article-Replacing", Usefor-03 says "Article-Updates".

Nothing of this is critical, but Also-Control could be
a special case like Subject: cmsg cancel.  It would be
really easier to build on s-o-1036, pro forma.  Even if
the future Usefor RfC is published only one second after
s-o-1036 it could eliminate some weird logical problems.

                            Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 28 Apr 2005 14:09:23 GMT

>removing it in a future version of the standard.

I agree (though there is a general caveat in USEPRO that the right of any
server to drop any article on the floor overrides any "MUST" requirement).

But I am happy with the s/obsolete/obsolescent/.

>cmsg should not be considered control messages, to document the change

No, I think it is a protocol issue, and the mention in USEPRO is
sufficient.

Any I do not share Frank's worries about a flag day. That usage is already
ignored by most servers, so nobody should be relying on its working
anymore. If the few remaining servers that honour it suddenly become
non-compliant the day our RFC gets published, then so be it. The sky will
not immediately fall in, but anyone continuing to use or accept the
practice will be severaly sat upon. In any case, I have not seen or heard
of anybody actually trying to use the feature in earnest for many years.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 28 Apr 2005 10:06:04 -0700

>> I think USEFOR does need an explicit mention that subjects starting
>> with cmsg should not be considered control messages, to document the
>> change from RFC 1036.

> No, I think it is a protocol issue, and the mention in USEPRO is

The transformation of a message from a regular news message to a control
message because of the presence of five characters at the beginning of the
Subject line sounds like a syntax and semantics issue to me, even if we're
just warning that it used to be interpreted that way.  cmsg changes the
semantic meaning of the message entirely, if honored.

I don't feel too strongly about it, though.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 29 Apr 2005 01:37:12 +0200

Russ Allbery wrote:

 [cmsg]
> I don't feel too strongly about it, though.

Okay, but it's not nice when it has serious problems with the 
propagation.  An error message "administrative restriction"
is also not exactly clear.  Or if we'd expect gateways to do
something special, or better nothing unless they are forced
to bypass an "administrative restriction" we have to say so
somewhere.  Not in usefor-x, that was probably a bad idea.

But the usepro-03 text pretends that there's actually no
problem at all with Subject: cmsg.  And that's not the case,

The attempts to avoid obsolete problems are the problem -
not some old servers trying to act on Subject: cmsg, but
the many servers trying to protect old servers are a pain.

And they won't stop this immediately only because a new RfC
wants it.  Let's forget Also-Control unless you're sure that
it could be a similar problem.

                      Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Thu, 28 Apr 2005 16:45:55 -0700

> somewhere.  Not in usefor-x, that was probably a bad idea.

A subject starting with "cmsg " needs to be prohibited in anything that
isn't a control message.  I don't feel strongly about whether that should
be in USEFOR or USEPRO, although to me it feels like a format issue, but
it needs to be in there somewhere.  It's premature to assume that cmsg no
longer receives special handling; we're not done with that transition.  We
might never be, frankly.  Using cmsg in the Subject header of regular
posts will cause significant interoperability problems.

> it could be a similar problem.

Also-Control simply SHOULD NOT be used, but that's more USEPRO.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 29 Apr 2005 15:33:26 GMT

>it needs to be in there somewhere.

If you want to say that, then USEFOR is clearly the right place to say it.

But evidently Frank doesn't want that to be said (he is complaining about
current systems that object when you try to do it), and I don't think I
want to do it either. Better just to let the usage die away (which USEPRO
requires). Otherwise we shall find new software coming on stream that
objects to 'cmsg' in Subjects (just to comply with the new USEFOR) just as
the last remaining servers that might have interpreted that 'cmsg' are
being withdrawn. Eventually, we shall have wide deployment of a mandatory
requirement for Subject header which is there to solve a problem that no
longer exists.

>  It's premature to assume that cmsg no

How likely is it that people will 'accidentally' write Subject headers
starting with 'cmsg'? How much of a problem are such headers causing at
the present time? And if they do write such a header (without any intent
to cause a Control action), how likely is it that it will be meaningful
enough to cause some untoward effect? If it ain't actually broke at the
present time, then don't waste time trying to fix it.

But if the WG really wants this prohibition including, then let it say so,
in which case USEFOR is the place to do it.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 29 Apr 2005 09:32:28 -0700

Charles Lindsey <[email-masked]> writes:

> But evidently Frank doesn't want that to be said (he is complaining
> about current systems that object when you try to do it), and I don't
> think I want to do it either. Better just to let the usage die away
> (which USEPRO requires).

That isn't going to actually happen in any sort of reasonable time frame.

> Otherwise we shall find new software coming on stream that objects to
> 'cmsg' in Subjects (just to comply with the new USEFOR) just as the last
> remaining servers that might have interpreted that 'cmsg' are being
> withdrawn.

I wonder if any of us will live long enough to see the last remaining
servers that interpreted cmsg be withdrawn.

> starting with 'cmsg'?

This doesn't seem like a relevant question to me.  Standards aren't
concerned only with things that can happen accidentally.

> How much of a problem are such headers causing at the present time?

They aren't propagated.  They have huge interoperability problems at the
present time.

> And if they do write such a header (without any intent to cause a
> Control action), how likely is it that it will be meaningful enough to
> cause some untoward effect?

That's not the breakage that I'm worried about (control messages should be
authenticated anyway instead of cancels, and it's pretty hard to write a
cancel control message accidentally).  The article will mysteriously
disappear, which is a different kind of breakage.

> If it ain't actually broke at the present time, then don't waste time
> trying to fix it.

It's very broken at the present time.