Skip to content

Technical standard language is missing #171

@AramZS

Description

@AramZS

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions