You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Norman Maurer <nm...@byteaction.de> on 2006/10/06 08:33:29 UTC
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" <da...@gmail.com>
> To: "james-server-dev" <se...@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
Re: [VOTE] Non compliance disclaimer
Posted by Guillermo Grandes <gu...@gmail.com>.
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" <se...@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" <da...@gmail.com>
>> To: "james-server-dev" <se...@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