james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer ...@byteaction.de>
Subject Re: [VOTE] Non compliance disclaimer
Date Fri, 06 Oct 2006 06:33:29 GMT
That sound good. Any other ideas ?

Guillermo Grandes schrieb:
> +1 (If I can vote) BUT with a minor note (as Stefano says) or ideas:
> I prefer parameters documented, no-hidden, with a Note in config.xml, 
> and when it is possible, the parameters that are used to perhaps 
> indicate one feature/workarround not-RFC could be named according to 
> this, as example:
>  <!-- WARNING: This is Non-RFC compliant (default value: false) -->
>  <!-- see also: http://james.apache.org/code-standards.html -->
>  <X-AllowUglyMail>false</X-AllowUglyMail>
>  <NonRFCAllowUglyMail>false</NonRFCAllowUglyMail>
> Or anything that seems :-)
> Thanks :-)
> Guillermo
> ----- Original Message ----- From: "Danny Angus" <danny.angus@gmail.com>
> To: "james-server-dev" <server-dev@james.apache.org>
> Sent: Thursday, October 05, 2006 2:33 PM
> Subject: [VOTE] Non compliance disclaimer (was: Change in policy to for
> JAMES to violate RFCs)
>> All,
>> Please indicate your vote in the usual way (+1,0,-1) for the following:
>> The standards compliance policy statement on
>> http://james.apache.org/server/design_objectives.html is a pragmatic
>> one.
>> However the idea that the documentation be hidden is flawed, as it
>> highlights neither the feature nor the issue.
>> I believe that it should be highly visible, and contain a simple
>> disclaimer.
>> I therfore propose that the statement be extended to read as follows,
>> and linked to the code standards at
>> http://james.apache.org/code-standards.html
>> the proposed statement can be found in full at:
>> http://wiki.apache.org/james/StandardsComplianceStatement
>> and reads as follows:
>> standards compliance
>> This statement occasionally uses terms that appear in capital letters.
>> When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
>> NOT", and "MAY" appear capitalized, they are being used to indicate
>> particular requirements of this specification. A discussion of the
>> meanings of these terms appears in [RFC2119].
>> It is the existence of published "open" standards which allows
>> independant teams to develop interoperable software.
>> James attempts to support a number of these standards (most of which are
>> IETF RFC's) and in the areas covered by these standards the published
>> standard is our requirements document.
>> This sometimes leads to confusion where behaviour is not the subject of
>> a relevant standard, or conflict where common (de-facto) behaviour is
>> actually at odds with a supported standard.
>> We believe that it is our responsibility to adhere to the published
>> standard. If we allow our implementation to deviate it means that we are
>> tacitly encouraging the situation whereby interoperability is no longer
>> guarenteed by standards compliance alone, but also requires access to
>> undocumented and possibly even commercially licenced technology. There
>> is no easy route for a newcomer to aquire these secrets, and
>> interoperabilty becomes something only available to the elite.
>> The James policy for issues of non-compliance tries to tread the fine
>> line between a pragmatic acceptance of differing interpretation and
>> defects in implmenentations of the RFC's and an evangelical defence of
>> open standards as the key to freedom of interoperation.
>> In practice this policy is that certain well argued of cases of
>> non-compliance which can be *safely* worked around, will be tolerated by
>> James.
>> In cases (like jira issue JAMES-344) where variance from a published
>> standard is required this functionality SHOULD be disabled in James by
>> default, it MUST be prominently and clearly documented that this causes
>> James to violate the relevant standard and SHOULD require to be enabled
>> by explicit configuration, making its use a conscious decision of the
>> user rather than a decision taken by the James team.
>> The feature MUST be clearly documented and the documentation MUST
>> contain the following statement which MUST describe every violation of
>> each standard with which James claims to comply which is enabled by the
>> feature:
>>    "Certain features allow Apache James to handle mail which has been
>>    constructed or sent in a manner not in compliance with the standards
>>    which James implements.
>>    The feature documented here permits James to handle messages which do
>>    not comply with the following standards which James claims to
>> implement:
>>    RFC XXXX para Y.Y
>>    This feature has been disabled by default because James developers
>>    intend that James itself fully complies with the relevant published
>>    standards in the form in which it is distributed.
>>    The James project's policy is to encourage the developers of other
>> email
>>    software to comply with published standards. It is only by all 
>> parties
>>    conforming to published standards that interoperability can be
>>    guaranteed, this is a fundamental charateristic of the internet.
>>    You are free to enable this feature which has been developed for your
>>    benefit as carefully as any of James' other features."
>> In cases where the required behaviour is not within the scope of any
>> standard which James claims to support (such as behaviour which is a
>> de-facto standard or an internet draft RFC but not yet subject of a
>> standards track RFC) it is acceptable to implement the behaviour but it
>> SHOULD be adequately documented (for instance by refrence to an internet
>> draft or other public document) so that users can be clear about its
>> status and what to expect from James.
>> d.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> !EXCUBATOR:1,4525689a53071220920547!

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message