Subject: Re: References

From: John Stanley <[email-masked]>
Date: Mon, 25 Apr 2005 12:15:00 -0700 (PDT)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Please show me where the word "followup" is to be found in RFC 2822.

I won't bother doing so, because we've already covered RFC2822 using the
term "reply" in the relevant section, and that all replies are followups,
using any common-sense or even news-based definition of the word followup.
Not all followups are necessarily replies, but every "reply" is "an
article posted in response to another".

Since RFC2822 clearly does NOT mandate References headers in all replies,
then it just as clearly exempts some followups -- the same replies that
have no mandate for its use are the same followups that have no mandate.
You cannot say that all followups MUST have a References header without
also saying all replies MUST, since the latter is a proper subset of the
former.

> USEFOR incorparates, by reference, many concepts from RFC 2822,

Including, explicitely, the References header. Thus RFC2822 not only tells 
us how to construct the "proper Email [sic]" that you grant in your 
previous paragraph, but a "proper News" article, because USEFOR says that 
RFC2822 applies to news, too.

>But nowhere does USEFOR
>equate the concepts of "Email Reply" with "Netnews Followup".

It doesn't need to. It is quite disengenuous of you to pretend that
RFC2822 says "Email Reply" in the section about References headers, and to
pretend that there has to be some equating of the two phrases for RFC2822
to apply. I've quoted the specific parts of RFC2822 that talk about
"replies", and they do not limit themselves to email, and USEFOR-03
explicitely expands any limit of "Email Reply" that you may fictionalize
for the References header and RFC2822 to "News reply", as well.

And you know very well that the two concepts do not have to be equivalent
for one to apply to the other. All replies are followups using standard
common-sense and common-practice news definitions for the same.  If you
say, as RFC2822 does, and draft-usefor-03 brings into the news context,
that not all replies require a References header, then you just as
clearly say not all followups require a References header. This is now
the third time in two days I've covered this ground for you, Charles.

>I grant you that the concepts are sufficiently similar that, wherever we
>say that News Followups are different in some way from Email Replies (e.g.
>MUST rather than SHOULD),

Except we DO NOT say this. We EXPLICITELY say that the RFC2822 definition
of References applies (with a few small syntax differences) but we do NOT
say that one of the differences is that References is a MUST. You can say
that you grant that the concepts are similar, even though you have just
argued that they are completely different and thus statements about one
thing do not apply to the other, but you cannot grant that we say that
there is a mandate, because draft-usefor-03 and RFC2822 clearly says
otherwise.

>Our Chair has ruled that the correct place to say such things is in USEPRO
>rather than USEFOR.

Then the Chair has effectively ruled that References is optional as
defined in RFC2822 and that "followup" is a meaningless term, since nobody
past the poster can identify what is and is not a followup using the
optional definition of References. If the Chair thinks that we can say in
one news standard that References is an optional header (by referring to
the SHOULD appear and "may appear" definition in RFC2822) and then change
our minds in mid-stream by saying that it is MANDATORY in another news
standard, then he is demonstrating schizophrenia. Either it IS mandatory
in followups or it is not.

I'll be happy with whichever position we take: either RFC1036 had it right 
and References is MUST/MUST NOT and followups are thus identifiable; or 
RFC1036 has it wrong, References is SHOULD/MAY and followups are not 
identifiable and thus a meaningless term. But since it has already been 
changed, it now requires justification for bringing back the MUST/anything 
language, since RFC2119 clearly limits such language to serious matters, 
and we can no longer use the 'it was pre-existing' excuse. It's not 
existing anymore; can you justify bringing it back?

I'll even suggest that if you cannot justify the return of a mandate (and
do not just unilaterally reinsert it as is your wont to do with our work
products), we can create a specific header to replace References, call it
"Thread-Me-Next-To:" or "Display-Near:" or something similar that makes it
clear this is a display issue and not a protocol one, and make that
optional. That's fine. It's being honest then about the value of the
information and not pretending it is some critical protocol
interoperability thing we're trying to solve.

And before you start playing the "show me where it says X" game with 
RFC1036 and MUST/MUST NOT, I'll point out that RFC1036 predates RFC2119 
but it uses clear terms like "required" and "prohibited", which map into 
RFC2119 MUST/MUST NOT. But we've been through that before, too, so I don't 
expect this preemptive note to have any effect on your argument.

>If a poster intends a followup, then a References header is REQUIRED.

No. Refer to RFC2822, which says that References is only SHOULD and 
"may", and even talks about messages that are clearly replies (contains 
In-Reply-To) but has no References.

>> That is a change, despite your repeated denials.

>Exactly. That has never been denied. 

You've repeatedly denied it. You keep saying we can use your proposed
wording because it makes no difference from what was there originally,
regarding MUST/MUST NOT and followups.  There's a difference from how
things are now. There's a change.

>You cannot tell from looking at the
>References header whether the poster intended to write a followup, or
>merely intended that it should be threaded like a followup (with all the
>other benefits accruing from a References header).

Let's put back some context to this, shall we? If you put back the
MUST/MUST NOT dichotomy for the References header, which has been removed
from draft-usefor-03 now (but still exists in news today due to RFC1036),
then you can tell precisely if the poster intended a followup or not
because a followup MUST have the header and a non-followup MUST NOT.  
(The third option is the poster is stupid/incompetent/ignorant and cannot
properly form a news article, but let's stick with properly formattted
news articles and not try to guess at the meaning of broken ones, ok?) It
is only when you water down the References header as it has now been that
you cannot tell what was intended. An article with a References header
(under draft-usefor-03) might be a followup or it might not. An article
without a References header might not be a followup, or it might be. You
have no way of knowing. You can only guess. Technical standards are broken
if they involve guessing about things that are supposed to be important, 
especially when they could easily be written to remove the guessing.

>So f*****g what? Why should the reader care?

If it is not important to the reader, then the References header
absolutely does not merit any RFC2119 language regarding its use, much
less MUST. It is not an interoperability issue in any case, and if the
information that it conveys is "so fucking what?" for the reader, then
lets make it obsolete and be done with it. I'm fine with that. References
is obsolete. The term "followup" is removed from the drafts. Let's
git-r-done. When can we expect you to produce the next version with these 
changes we've agreed to?

---

From: Ken Murchison <[email-masked]>
Date: Tue, 26 Apr 2005 11:14:55 -0400

> in followups or it is not.

It is mandatory as stated in USEPRO.

I'll reiterate what I stated elsewhere in the thread.

USEFOR documents the proper syntax of the set of headers typically used 
  in news articles.  USEPRO documents how to properly construct an 
article from this set per the Netnews "protocol" or "etiquette"

-- 
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