From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Mon Apr 26 2004 - 14:37:21 CDT
In <Pine.LNX.4.53.0404231117010.11180@a.shell.peak.org> John Stanley <stanley@peak.org> writes:
>Charles Lindsey (chl@clerew.man.ac.uk):
>>>>#3 *needs* to be in USEFOR, because it is saying that using anything other
>>>>than "Re: " makes the followup agent non-compliant. Saying things like
>>>>that is a proper thing to do in a standards document.
>>Actually, it is proposed to be a SHOULD NOT, but yes, there needs to be a
>>REASON.
>No, the text you used above is clearly a MUST NOT, since you say that
>anything other than "Re: " is non-conforming, and MUST NOT is the only
>2119 imperative that has that meaning.
Ah! I am beginning to see where you are coming from. It is your
understanding of the word "compliant" (or "conforming" if you prefer),
which is not actually defined in RFC 2119. My understanding of the word is
the following, which I find in various RFCs - for example RFCs 1123, 2110,
2557 and 2616.
An implementation is not compliant if it fails to satisfy one or more
of the MUST requirements for the protocols it implements. An
implementation that satisfies all the MUST and all the SHOULD
requirements for its protocols is said to be "unconditionally
compliant"; one that satisfies all the MUST requirements but not all
the SHOULD requirements for its protocols is said to be
"conditionally compliant."
All of which suggests that implementations should, in general, be striving
for full unconditional compliance, which means that violating a SHOULD is
a serious matter, only to be done if there is a severe cost penalty or
other exceptional circumstance and with the expectation that it could
cause problems (or even non-interoperability) elsewhere. It certainly does
not mean "this requirement is optional", because we have the word "MAY"
for that.
>.... It can sort
>them by day of week, astrological sign of the author, or any other damn
>thing it wants to. Being outside the scope of this standard means that
>an agent that sorts articles in alphabetical order of the right-most path
>entry cannot be "broken" w.r.t. this standard, because we have no business
>saying it is broken.
Indeed this standard does not say anything about how reading agents are to
present articles to the reader, and therefore we have no business saying
that a reading agent is "broken" if it chooses some particular method.
However, I see that this has not prevented you from saying that all sorts
of reading agents are "broken" if they do things of which you disapprove.
However, the question of what reading agents do is not what we are talking
about. We are trying to establish what followup agents need to do in order
to comply with our standard. In which case preventing problems with
reading agents (where we know full well what they in practice do and don't
do) may well merit a SHOULD NOT for the followup agent.
>Now, those agents that claim they are threading articles, and are telling
>users that "this article is a sibling of that article" based on Subject
>headers IS BROKEN, because our standard DOES specifiy how sibling
>relationships are reported, and it DOES NOT involve the Subject header in
>any way, shape, or form.
There! You have just accused some reading agents of being "BROKEN", even
though you have said above that we have no business saying that.
>Here, Charles, I do it once more for you. This is my proposed text for
>item two of 8.6:
>2. The Subject-content SHOULD be copied from the subject-content of the
>precursor.
> NOTE: Some reading agents expect the unencoded string "Re: " at
> the beginning of the Subject-content of a followup, and consider
> this when sorting articles for display. Further, most expect just
> one instance of "Re: ", and do not treat any other string in this
> manner. Followup agents may want to keep this in mind when
> generating Subject-content for followups. Note that the SHOULD
> requirement allows followup agents the freedom to prepend the
> requisite string if they so desire.
Yes, but "SHOULD be copied from ... the precursor automatically implies
"SHOULD NOT have a Re: prepended" (note that we are talking about the
default state before the user does any overriding). And you just cannot
say "SHOULD NOT" and then say "but of course you have the freedom to
ignore that 'SHOULD NOT'". You cannot say that making your implementation
only conditionally compliant is a trivial matter, especially when you know
full well that almost every existing implementation will then be rendered
"conditionally compliant" - and indeed you are actively encouraging them
to be so and to remain so.
>I'll also point out that the last sentence of the note is redundant, since
>the definition of SHOULD in RFC2119 already tells readers that the
>followup agent can do something besides simply copying the content if it
>has a reason to.
No, it doesn't just have to have a "reason"; it has to have a "valid
reason in *particular* circumstances to ignore a *particular* item", with
"full implications ... understood and carefully weighed". That doesn't
sound to me like something you expect lots if implementations to continue
doing indefinitely.
-- 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: chl@clerew.man.ac.uk 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