On 18/dic/2012, at 09:49, Felix Meschberger wrote: > Hi, > > Just remember that "MAY" is difficult to handle by developers: Can I depend > on it or not ? What if the "MAY" feature does not exist ? What if I develop > on an implementation providing the "MAY" feature and then running on an > implementation not providing the "MAY" feature ? > > In essence, a "MAY" feature basically must be considered as non-existing :-( > > All in all, please don't use "MAY". Thanks from a developer ;-)
I remember such a pain when dealing with browser compliance to HTTP spec some years ago, SHOULD / MAY [NOT] were my enemies :-) Apart from that, I agree with MichaelM (with the exception that I'd keep MAY out using either MUST or MUST NOT, with a slight preference on MUST). My 0.02 cents, Tommaso > > Regards > Felix > > Am 18.12.2012 um 09:37 schrieb Marcel Reutegger: > >> Hi, >> >>> To address 1) I suggest we define a set of clear cut cases where any >>> Microkernel implementations MUST merge. For the other cases I'm not sure >>> whether we should make them MUST NOT, SHOULD NOT or MAY merge. >> >> I agree and I think three cases are sufficient. MUST, MUST NOT and MAY. >> MUST is for conflicts we know are easy and straight forward to resolve. >> MUST NOT is for conflicts that are known to be problematic because there's >> no clean resolution strategy. >> MAY is for conflicts that have a defined resolution but we think happen >> rarely and is not worth implementing. >> >> I don't see how SHOULD NOT is useful in this context. >> >> regards >> marcel >
