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
Date Sat, 07 Oct 2006 00:38:00 GMT
mmm, I'm thinking about this, tomorrow more! :-)

--- Invention is one per cent inspiration, ninety-nine per cent
     transpiration. (Edison)

----- Original Message ----- 
From: "Norman Maurer" <nm@byteaction.de>
To: "James Developers List" <server-dev@james.apache.org>
Sent: Friday, October 06, 2006 8:33 AM
Subject: Re: [VOTE] Non compliance disclaimer


> 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
>


---------------------------------------------------------------------
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