From: Bruce Lilly (blilly@erols.com)
Date: Tue Apr 27 2004 - 13:54:39 CDT
Charles Lindsey wrote:
> 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
Of course it is; that is what a "strong recommendation" (the meaning of
SHOULD) indicates!
> It certainly does
> not mean "this requirement is optional", because we have the word "MAY"
> for that.
One might have hoped that our Editor would have a better grasp of the
language. Something which is "optional" is not in any way, shape, or form a
"requirement". It is an option. One cannot meaningfully speak of an "optional"
"requirement". That is gibberish.
> 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.
As the Subject field has only human readable content, and is in any event
the responsibility of the user, there are no relevant issues for any 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.
No, John has said that an agent that claims to have established a relationship
between two articles which can only be determined by examining References
fields, when said agent has not examined References fields, is making a false
claim. And he's right that there is no cause to embody any such language
in Standards Track documents, and indeed *he* has not proposed doing so.
>>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).
So far, more or less OK.
> And you just cannot
> say "SHOULD NOT" and then say "but of course you have the freedom to
> ignore that 'SHOULD NOT'".
John's text does not say to ignore the SHOULD in his text.
> 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.
No, that's what is inherent in making "Re: " deprecated. In no way does
it encourage implementations not to heed that deprecation.
>>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.
Quite so; that is the point of deprecation!