From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Wed Apr 28 2004 - 09:17:12 CDT
In <408EAC6F.1040503@erols.com> Bruce Lilly <blilly@erols.com> writes:
>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.
Which is exactly the point I was trying to make, though it might have been
better if I had said 'It... does not mean "this recommendation is
optional" ...'.
[John]
>>>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.
Yes it does. It states that followup agents have the "freedom" to break
the implicit "SHOULD NOT have a Re: prepended". I.e. is is inviting agents
to ignore what we both agree (see above) is a "strong recommendation". If
you want to give them that sort of freedom, then you need a "MAY" in there
somewhere.
>> 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.
Eh? You are saying that "X is deprecated" is consistent with saying "you
have the freedom to do X"?
In any case, we do not want to deprecate prepending "Re: ", if only
because at least half this WG want to positively encourage it. Which is
why I am pressing for the neutral "take it or leave it" position. I am
quite happy to try and "discourage" it in USEAGE in due course.
>> 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!
Well at least we are agreed on the strength of the meaning of "SHOULD".
Yes, if we wanted to deprecate "Re: ", then John's wording would be fine
(but maybe not his NOTE). But we are not going to get anywhere near a
rough consensus for such deprecation.
-- 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