On Tue, 2013-05-07 at 09:25 +0200, Axel Luttgens wrote:
Reading RFCs is kind of an art.
That we certainly agree on :)
Let's have a look at RFC 2119:
Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.So, if you want to build your reasoning on those keywords for establishing compliancy or lack thereof, you should restrict yourself to RFCs posterior to RFC 2119 *and* coming with above phrase.
But that leaves earlier RFC's open, once again, to individual interpretation, since there is no specific type of "direction". I'm sure there are plenty of later RFC's that do not include "directions" because they are meant to be a guide. Remember, the POP3 RFC does include a "direction" elsewhere in it (as I previously mentioned), the fact it does not include a "direction" in relation to deletion or marked deleted messages, is open IMHO to be interpreted as being "your choice".
But then, §6 indicates that those keywords are to be used sparingly, not as a general mean to convey compliancy.
Perhaps because it should be up to individual implementers to decide how their software/systems are setup, unless something may be rather detrimental - I fail to see Timo's proposal as detrimental since it is not configured as default.
Ultimately the choice is ours, it is like everything server/network-ish, if we do not want a feature, we do not build it in, or enable the config (file) option to use that feature (kind of why I was disappointed that Timo removed the ability to disable many auth functions like we could do in 1.x series).
It's also like everything else with responsibility to running services, in each of our own countries, laws differ, we need to be aware of those laws (and of any country you host content in) with regards to what can or can not be done, either outright, or with provision (eg: clear statement of data retention in your T&C's or privacy policy etc).
Cheers Noel
