[James Wiki] Update of "StandardsComplianceStatement" by DannyAngus

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "James Wiki" for change notification.

The following page has been changed by DannyAngus:
http://wiki.apache.org/james/StandardsComplianceStatement

New page:
= 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.