On Apr 29, 2015, at 7:30 PM, Dimitri Maziuk wrote: > Based on "be liberal in what you accept and conservative in what you > produce", the writer should
Postel's Robustness principle is a mistake. See RFC 3117 for elaboration, at http://tools.ietf.org/html/rfc3117#page-16 Counter-intuitively, Postel's robustness principle ("be conservative in what you send, liberal in what you accept") often leads to deployment problems. Why? When a new implementation is initially fielded, it is likely that it will encounter only a subset of existing implementations. If those implementations follow the robustness principle, then errors in the new implementation will likely go undetected. The new implementation then sees some, but not widespread deployment. This process repeats for several new implementations. Eventually, the not-quite-correct implementations run into other implementations that are less liberal than the initial set of implementations. The reader should be able to figure out what happens next. Accordingly, explicit consistency checks in a protocol are very useful, even if they impose implementation overhead. Or from http://cacm.acm.org/magazines/2011/8/114933-the-robustness-principle-reconsidered/fulltext : What has happened here is the bad implementation has survived because of the liberality of all the other implementations. This will never be detected until version 3 of the protocol comes along - or some implementation violates the "accept" side of the Robustness Principle and starts doing more careful checking. ... Or http://www.tbray.org/ongoing/When/200x/2004/01/11/PostelPilgrim for an example with XML. There has been much discussion on the topic. On the pro-ish side, which recommends a "patch" to the law, see http://langsec.org/papers/postel-patch.pdf . > - if a record contains forbidden values, stop writing to the file, > with an error. Yes, I agree with this. What constitutes "forbidden"? Only those that would violate the spec? Or also those that will cause problems in normal deployment? That is, what is the problem that a fix is trying to solve? Format conformity, or something more nebulous but also more useful? I lean strongly towards the latter. If there is an error, does the writer generate a partial record, or does the writer validate all of the fields before writing? Or does it finish generating a syntactically complete record, and then generate an error? What happens if write() is called again after there was an error? > With the reader it looks like you can't help it if someone makes a value > like "> 55" or "$$$$". With that caveat, you should be able to find tags > and read everything in between as a value. For what it's worth, those values are acceptable. The following is legal, according to the specification: > DT12 55 > 55" $$$$ second line > <new_tag> corresponding value $$$$ $$$$ Cheers, Andrew da...@dalkescientific.com ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Rdkit-discuss mailing list Rdkit-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
