Reply wasn't posted; will test new post

ruby-talk
1

http://www.faqs.org/rfcs/rfc1036.html
http://www.faqs.org/rfcs/rfc2119.html

dblack@wobblini.net:

THE MISSING MESSAGES DO *NOT* VIOLATE USENET RFC.

Here are some excerpts from RFC-1036 (which obsoleted RFC-850):

2.1.4. Subject
[...] If the message is submitted in response to another message
(e.g., is a follow-up) the default subject should begin with the
four characters "Re: ", and the "References" line is required.
[...]

2.2.5 References
[...] User interfaces need not make use of this header, but all
automatically generated follow-ups should generate the
"References" line for the benefit of systems that do use it, and
manually generated follow-ups (e.g., typed in well after the
original message has been printed by the machine) should be
encouraged to include them as well.

Based on this, I would definitely say that "Re: " messages without
a References header are in violation of this RFC.

EXCEPT that the statements are "should" (see RFC2119 noted above)
and the header itself is optional. No news software should reject
any message missing the References header, even if best practices
would indicate that the References header is strongly recommended
when "Re: " is present. Both In-Reply-To and References are
*optional* in RFC2822 (the successor to RFC822). The real problem
with RFC1036 is that it (1) requires English (e.g., "Re: ")
backreferences, and (2) attempts to codify usage rules with
technical rules.

So, no, technically, messages missing "References:" are not in
violation of RFC1036.

(And no, there's *nothing* that I can do to force them there in
Outlook.)

-austin

···

On Thu, 10 Jun 2004, daz wrote:

--
austin ziegler * austin.ziegler@evault.com

2

"Austin Ziegler" <Austin.Ziegler@evault.com> schrieb im Newsbeitrag
news:04232E9E93B2D54FB1DCCCFF8C4DDB6A188ECB@ev-exch01.corp.evault.com...

RFC 1036 - Standard for interchange of USENET messages (RFC1036)
RFC 2119 - Key words for use in RFCs to Indicate Requirement Lev (RFC2119)

dblack@wobblini.net:
>> THE MISSING MESSAGES DO *NOT* VIOLATE USENET RFC.
> Here are some excerpts from RFC-1036 (which obsoleted RFC-850):

> 2.1.4. Subject
> [...] If the message is submitted in response to another message
> (e.g., is a follow-up) the default subject should begin with the
> four characters "Re: ", and the "References" line is required.
> [...]

> 2.2.5 References
> [...] User interfaces need not make use of this header, but all
> automatically generated follow-ups should generate the
> "References" line for the benefit of systems that do use it, and
> manually generated follow-ups (e.g., typed in well after the
> original message has been printed by the machine) should be
> encouraged to include them as well.

> Based on this, I would definitely say that "Re: " messages without
> a References header are in violation of this RFC.

EXCEPT that the statements are "should" (see RFC2119 noted above)
and the header itself is optional. No news software should reject
any message missing the References header, even if best practices
would indicate that the References header is strongly recommended
when "Re: " is present. Both In-Reply-To and References are
*optional* in RFC2822 (the successor to RFC822). The real problem
with RFC1036 is that it (1) requires English (e.g., "Re: ")
backreferences, and (2) attempts to codify usage rules with
technical rules.

So, no, technically, messages missing "References:" are not in
violation of RFC1036.

Somehow this thread reminds me of discussions about GPL and LGPL.
Apparently there's still too much room for interpretation in these texts
although they were meant to clarify things...

Regards

    robert

···

> On Thu, 10 Jun 2004, daz wrote:

3

Hi --

dblack@wobblini.net:
>> THE MISSING MESSAGES DO *NOT* VIOLATE USENET RFC.
> Here are some excerpts from RFC-1036 (which obsoleted RFC-850):

> 2.1.4. Subject
> [...] If the message is submitted in response to another message
> (e.g., is a follow-up) the default subject should begin with the
> four characters "Re: ", and the "References" line is required.
> [...]

> 2.2.5 References
> [...] User interfaces need not make use of this header, but all
> automatically generated follow-ups should generate the
> "References" line for the benefit of systems that do use it, and
> manually generated follow-ups (e.g., typed in well after the
> original message has been printed by the machine) should be
> encouraged to include them as well.

> Based on this, I would definitely say that "Re: " messages without
> a References header are in violation of this RFC.

EXCEPT that the statements are "should" (see RFC2119 noted above)
and the header itself is optional. No news software should reject
any message missing the References header, even if best practices
would indicate that the References header is strongly recommended
when "Re: " is present. Both In-Reply-To and References are
*optional* in RFC2822 (the successor to RFC822). The real problem
with RFC1036 is that it (1) requires English (e.g., "Re: ")
backreferences, and (2) attempts to codify usage rules with
technical rules.

According to the above, References is "required", not "strongly
recommended", for follow-ups. Also, this apparently applies to all
follow-ups, while the adding on of "Re: " is only at "should" level.

So, no, technically, messages missing "References:" are not in
violation of RFC1036.

They're certainly in violation of parts of it :slight_smile: Here's another one:

   2.2.5. References

      This field lists the Message-ID's of any messages prompting the
      submission of this message. It is required for all follow-up
      messages, and forbidden when a new subject is raised.

(part of the [...] in my earlier excerpt) If References is truly
optional (that is, can be put or not put on any message), then someone
went to an awful lot of trouble for nothing in writing this paragraph
:slight_smile: The "forbidden" part is interesting too, because it also
weighs in on the side of References not being truly optional.

Anyway, I'm not a big fan of this aspect of the document. At best,
burying a requirement inside a paragraph on a header you've already
declared to be optional is a low-percentage way to go about it.

Meanwhile, I think Dennis is implementing the dummy-message thing, so
that any messages without references will be sent through as answers
to a message that exists for that purpose. This is sub-optimal, from
the threading point of view, but at least gets the posts through.

(And no, there's *nothing* that I can do to force them there in
Outlook.)

(Don't worry, I wasn't holding my breath :slight_smile:

David

···

On Fri, 11 Jun 2004, Austin Ziegler wrote:

> On Thu, 10 Jun 2004, daz wrote:

--
David A. Black
dblack@wobblini.net

4

Robert Klemme wrote:

So, no, technically, messages missing "References:" are not in
violation of RFC1036.

Somehow this thread reminds me of discussions about GPL and LGPL.
Apparently there's still too much room for interpretation in these texts
although they were meant to clarify things...

I think part of the issue is the use of these modal auxiliaries.
(Thanks, Mrs. Sharp, my elementary English teacher who died last
month at 84.)

Some RFCs use "must" for things that are mandatory and "should" for
things that are recommended or suggested. Or something like that.
They also use the terms "may" and "can" (I believe).

I don't know whether all RFCs do this. I don't think they do.

IIRC, the "technolegal" documents like this tend to capitalize
these: "The client MAY do this, it MUST do that..."

But anyway, I haven't a clue what this part of this RFC actually
means.

Hal

5

David A. Black wrote:

Meanwhile, I think Dennis is implementing the dummy-message thing, so
that any messages without references will be sent through as answers
to a message that exists for that purpose. This is sub-optimal, from
the threading point of view, but at least gets the posts through.

First evidence of that is Austin's post that you're replying to :slight_smile:

···

-----------------------------------------------------------------------------
From: "Austin Ziegler"
Newsgroups: comp.lang.ruby
Subject: Re: Reply wasn't posted; will test new post
Date: Fri, 11 Jun 2004 01:36:20 +0900
Message-ID: <04232E9E93B2D54FB1DCCCFF8C4DDB6A188ECB@ev-exch01.corp.evault.com>
References: <this_is_a_dummy_message-id@rubygate>
NNTP-Posting-Host: neutron.zrz.tu-berlin.de
X-received-from: This message has been automatically forwarded from ...
X-Mail-Count: 103103
In-Reply-To: <this_is_a_dummy_message-id@rubygate>
-----------------------------------------------------------------------------

I think it would still work without the "In-Reply-To:" duplicate
(if Dennis wants to try that next).

It didn't break my threading but I don't get much trouble with that, anyway.
It /does/ break out of the sub-thread, but that's no different to what
would have happened before the change.
It threaded by Subject:, then Date: which some people might find
/preferable/ on news when reading a complete thread ?

Good signs! -- Watching out for a reply from the OP (Botp Peña).

daz

-----
test reply - please ignore

kind regards -botp
-----

6

There's an RFC for that :slight_smile: Seriously, I'm pretty sure there's an RFC that defines the meaning of "must", "should", "compliant", etc., that some RFCs reference.

cheers,
Mark

···

On Jun 10, 2004, at 4:03 PM, Hal Fulton wrote:

I think part of the issue is the use of these modal auxiliaries.
(Thanks, Mrs. Sharp, my elementary English teacher who died last
month at 84.)

Some RFCs use "must" for things that are mandatory and "should" for
things that are recommended or suggested. Or something like that.
They also use the terms "may" and "can" (I believe).

I don't know whether all RFCs do this. I don't think they do.

7

Mark Hubbart wrote:

> I think part of the issue is the use of these modal auxiliaries.
> (Thanks, Mrs. Sharp, my elementary English teacher who died last
> month at 84.)
>
> Some RFCs use "must" for things that are mandatory and "should" for
> things that are recommended or suggested. Or something like that.
> They also use the terms "may" and "can" (I believe).
>
> I don't know whether all RFCs do this. I don't think they do.

There's an RFC for that :slight_smile: Seriously, I'm pretty sure there's an RFC
that defines the meaning of "must", "should", "compliant", etc., that
some RFCs reference.

cheers,
Mark

Austin posted the link, today.
http://www.faqs.org/rfcs/rfc2119.html

I'm sure Mrs. Sharp didn't check it :wink:

daz

···

On Jun 10, 2004, at 4:03 PM, Hal Fulton wrote:

8

Hi --

···

On Fri, 11 Jun 2004, Mark Hubbart wrote:

On Jun 10, 2004, at 4:03 PM, Hal Fulton wrote:

> I think part of the issue is the use of these modal auxiliaries.
> (Thanks, Mrs. Sharp, my elementary English teacher who died last
> month at 84.)
>
> Some RFCs use "must" for things that are mandatory and "should" for
> things that are recommended or suggested. Or something like that.
> They also use the terms "may" and "can" (I believe).
>
> I don't know whether all RFCs do this. I don't think they do.

There's an RFC for that :slight_smile: Seriously, I'm pretty sure there's an RFC
that defines the meaning of "must", "should", "compliant", etc., that
some RFCs reference.

Yes, I think that's RFC2119, the one Austin mentioned. They don't
tell you how to resolve blatant contradictions, unfortunately :slight_smile:

David

--
David A. Black
dblack@wobblini.net