3 ms·

"Should" and "May" are such horrible words to encounter when implementing an RFC. Sometimes, implementing workarounds for ends that only implements "Must" is h

• linkdd 7y ago
  Funny how your comment also use "should" and "may" :) Anyway, those key words are used to allow flexibility in the implementation. Remember that a RFC is specific to a single version of a single protocol. Thus splitting everything in multiple RFCs will still implies complexity in the implementation, just not the same kind of complexity (what versions to use and when?). > Imperatives of the type defined in this memo must be used with care and sparingly. > In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) > For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. Source: https://www.ietf.org/rfc/rfc2119.txt https://www.ietf.org/rfc/rfc2119.txt
• Disposition 7y ago
  That wouldn't work too well with complex RFCs like X509, should is used for some backwards compatibility to earlier RFC revisions and many optional elements that would fragment the standard into dozens of extensions. IMHO implementors must implement a "should", not in the same sense of the binding requirement that "must" presents, but as a boolean possibility; the element may not be present, but it should never be ignored in a way that would break implementations making use of it.
• brudgers 7y ago
  RFC's are consensus documents. The optional parts address the concerns of stakeholders with existing products. This is an alternative to their veto or non-participation in the standards development process or development of competing standards for business survival.
• beojan 7y ago
  > In my opinion, RFCs should strive to limit the optional parts of a specification at a minimum If only USBIF had done that
• kstenerud 7y ago
  It's remarkably difficult to avoid "should" and "may" in any decently sized spec. I count 11 "shoulds" in [1] and 7 in [2], and I tried REALLY hard to keep them to a minimum :/ [1] https://github.com/kstenerud/concise-encoding/blob/master/cte-specification.md https://github.com/kstenerud/concise-encoding/blob/master/ct... [2] https://github.com/kstenerud/concise-encoding/blob/master/cbe-specification.md https://github.com/kstenerud/concise-encoding/blob/master/cb...
• battery_cowboy 7y ago
  Every international spec I've read contains should and may, but also includes must here and there.
• dodobirdlord 7y ago
  Expressed a different way, my take is that non-"must" clauses of an RFC should be cleanly severable, i.e. you could literally cut them out of the document and everything else would still make sense. How a full implementation handles interoperating with an implementation that declines an optional feature should be defined in the same place as the optional feature. Further, being able to interoperate with an implementation that declines an optional feature should be required at the same optionality level as the optional feature. It shouldn't be a "must" to support interoperability with an implementation that has declined to implement a "should". This has basically the same effect as pushing optional parts into extensions. There's the core RFC that defines the spec, and a bunch of optional features that two implementations can use by mutual agreement. To address some common concerns about the effect this would have on general interoperability, keep in mind that a clause that reads "In scenario Foo, implementations should do X and should not do Y, but may do Z" can be much more cleanly expressed as "In scenario Foo, implementations must do X or do Y or do Z".