I was probably unclear: options are great, but they should be
options, not required :) If the format can represent anything, that lets
us offer simple (read) and (write). If the reader and writer can take
lots of options via some unobtrusive means like keyword arguments,
that's a good thing.
An API spec needs to be as simple as possible, but no simpler. I am saying that there needs to be certain essential features of the API that all implementers must supply.
In particular, a compliant reader must accept a procedure argument which it calls when an unrecognized type is read, eithe binary or textual. This would receive the type code and the content (a bytevector or list in binary, a bytevector/string/list in text) and return the internal object that the reader should integrate into its final result.
By the same token, a compliant writer must accept a procedure that it calls when an object of an unknown type is to be written. This would be applied to the internal object and return two values, a type code and content (again, a bytevector or list, or a string in text).
Limits on recursion depth, number size, etc. are probably good for
production apps.
Unfortunately, any app can become a production app in the hands of a desperate hacker. Those are also essential features of the API.
By "essential" I do not mean that the user must supply the argument; the unknown-procedure arguments can raise an exception by default, and the other arguments (depth, length, string size, numeric value) can default to no restrictions. I mean that all implementations conforming to the SRFI must support them. These are matters of reliability and/or security.