james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Hoffmann ...@byteaction.de>
Subject Re: [VOTE] Non compliance disclaimer (was: Change in policy to for JAMES to violate RFCs)
Date Thu, 05 Oct 2006 19:08:23 GMT
+1

Danny Angus schrieb:
> 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
> 
> !EXCUBATOR:1,4524fbf153077419620673!


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


Mime
View raw message