How Leshan should behave with Non Compliant Implementations ?
"How Leshan should behave with foreign peers which does not strictly respect specifications."
This is a recurrent question that Leshan developers asks itself. Here we will try to explain our current position about this.
By the past, when we began to face interoperability issues caused by Non-Compliant Implementations, we started to follow the robustness principle (also known as Postel's law) which could be resume by : "be conservative in what you send, be liberal in what you accept".
This is more or less what we tried to do with Leshan v1.x (targeting LWM2M v1.0.x)
Why we finally think this is not a good idea ?
- Hard to decide which "out of specifications behavior" should be accepted and which should not.
- Supporting all corner cases could make the code base bigger and harder to maintain.
- Be not strict with inputs could hide issues.
- As Leshan is open source and pretty popular it is often used as foreign peer when implementing new LWM2M library or LWM2M product and this is better to let know developers that they do not strictly respect the specification.
- Supporting non-compliant behavior could make it widespread and so could force other implementation to support it too.
- Finally, robustness principle could lead to lack of robustness / security / an interoperability. (see criticism like The Harmful Consequences of the Robustness Principle)
Just above, we see that tolerating non-compliance leads to many problems and finally is bad for interoperability. So since Leshan v2.x (targeting LWM2M v1.1.x) development, we aim to be more strict and add more input compliance checks. This is an ideal goal, not exactly the state of current code base but at least this should guide us for our future choices.
This should make life easier for new implementation and make life less easy for implementation which does not strictly follow specification and so should encourage them to update/fix their issues.
Of course we understand, that sometime it is needed to deal with some foreign peers which do not strictly follow specifications. In this case, solution is needed at short term waiting that implementations fix and deploy a new version.
So, we will try to design Leshan in a way that you could change default behavior to support this "bad behavior". (Not always in an easy way but at least should be doable)
Some interoperability issue could also come from specification miss-interpretation / ambiguity / inconsistency or design issue.
Ideally this could be limited by developing implementations and standard in parallel.
Perhaps the best situation of all is where the standards and implementations are being developed in parallel. ... ... Ambiguities in the standard were exposed quickly, as were well-meaning features that were unnecessarily difficult to implement.
(source: The robustness principle reconsidered - Eric Allman)
Unfortunately, we are not in that case but we should try to deal with this kind of issue anyway. Below is attempt to describe how we should/could do that.
Discussion between committers and/or contributor should remove the miss-interpretation.
If consensus is not emerging or if we finally face an ambiguity / inconsistency in specification, we should try to get more clarification with specification authors though IETF mailing list or public github of OMA.
A source of interoperability issue could be errors in examples.
Even using examples can be controversial. Examples are never normative (standards buzzword for authoritative); that is, if there is a conflict between an example and the body of the text, the text wins. Also, examples are seldom complete. They may demonstrate some piece of the protocol but not all the details. In theory if you removed all the examples from a standard, then the meaning of that standard would not change at all, the sole raison d'être being to aid comprehension. The problem is that some implementers read the examples (which are often easier to understand than the actual text of the standard) and implement from those, thus missing important details of the standard. This has caused some authors of standards to eschew the use of examples altogether.
(Source : The robustness principle reconsidered - Eric Allman)
This is a common mistake which are not always fixed (e.g. TLV example error ). If this is the case, this should be reported to authors but waiting we will generally follow specification body text and not the example.
Sometime we can discover something which looks like a design issue in the standard. Of course this should be discuss with authors to ensure this is the case and to find a solution.
If finally, no solution is found and Leshan Team think that there is no better way than not strictly follow the specification, this should be strongly documented (e.g. by creating a wiki page) with links about all discussions about this. This last case should be avoided as much as possible. We target to be as near as possible of the specification.
