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 Danny Angus <da...@gmail.com> on 2006/10/05 14:33:44 UTC
[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
Re: [VOTE] Non compliance disclaimer (was: Change in policy to for JAMES to violate RFCs)
Posted by Bernd Fondermann <be...@googlemail.com>.
+1
:-) wow, what a comeback!
Bernd
On 10/5/06, Danny Angus <da...@gmail.com> wrote:
> 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
Re: [VOTE] Non compliance disclaimer (was: Change in policy to for JAMES to violate RFCs)
Posted by Guillermo Grandes <gu...@gmail.com>.
+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
Re: [VOTE] Non compliance disclaimer (was: Change in policy to for JAMES to violate RFCs)
Posted by Danny Angus <da...@gmail.com>.
On 05/10/06, Stefano Bagnara <ap...@bago.org> wrote:
> So I think that we should simply add a small sentence and a
> link/reference to the big statement.
>
> Hope this can be considered in this vote.
Seems reasonable to me.
---------------------------------------------------------------------
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 (was: Change in policy to for
JAMES to violate RFCs)
Posted by Stefano Bagnara <ap...@bago.org>.
+1 BUT with a minor note: I think that "the documentation MUST contain
the following statement" and then a 6 sentece statement is too much as
the requirement. We'll probably have minor things that will need this
disclaimer and it would not make sense to paste 20 lines of comments
above every configuration parameter containing possible compliance problems.
So I think that we should simply add a small sentence and a
link/reference to the big statement.
Hope this can be considered in this vote.
Stefano
Danny Angus wrote:
> 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
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
Re: [VOTE] Non compliance disclaimer
Posted by Norman Maurer <nm...@byteaction.de>.
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 (was: Change in policy to for JAMES to violate RFCs)
Posted by "Noel J. Bergman" <no...@devtech.com>.
+1
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org