james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillermo Grandes" <guillermo.gran...@gmail.com>
Subject Re: [VOTE] Non compliance disclaimer (was: Change in policy to for JAMES to violate RFCs)
Date Thu, 05 Oct 2006 20:17:23 GMT
+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


Mime
View raw message