-
Notifications
You must be signed in to change notification settings - Fork 24
Description
Technical standards generally take similar shapes regardless of who and where they are produced. If a protocol or standard is intended to be implemented by others developers expect clear and specific language, often highlighted, that speaks to what implementers are required to do and capable of doing.
As an example which should be familiar: examine the MCP documentation
The use here of MUST, MAY and SHOULD are standard across specifications and vital to any developer (or machine system) looking to parse, understand, and implement these standards. What is required to do in order to make the standard work in the expected MUST be done. What is suggested behavior that reasonable extenders should expect to see on the use side and support on the host side SHOULD be done but may meet other requirements that mean it is not always required. What is never required, but can be useful MAY be done.
These descriptors are badly needed in this specification to make it clear to read and potentially to use. My explanations above are simple, but please refer to language and definitions at RFC2119 for clear definitions and reference points.
Please follow internationally recognized best practices to make this parsable by technical experts.
Thanks.