Chapter 10 uses non RFC assertions

[egekorkan]

Chapter 10 talks about Abstract Servient Architecture. It is a non-normative chapter, yet it uses must, may, should in multiple places but not capitalized. This seems like a way to escape respec errors. A non-normative chapter is, as its negation implies, an informative chapter. If it is informative, why is the reader met with assertive words like must, may etc.? In W3C specifications (also IETF, OpenAPI, CloudEvents, etc.) these words do not mean much if not used capitalized, i.e. we can say must as much as we want but it does not constrain implementations in any way if we don't say MUST.

Thus, I propose to either remove these words and rephrase the sentences or make the chapter normative and change the words to their capitalized forms.

[egekorkan]

Doing a case-sensitive search of the word must reveals this in many other places in the document, even normative chapters like 8.1.3.

[mlagally]

@EGE: Can you please drive the discussion?

[egekorkan]

What is the decision? Should we first make them assertions that can be easily tracked via the assertion script and then discuss whether they make sense?

[mlagally]

@egekorkan
This section is informative, however I think some of these assertions would make sense somewhere else.
To be completely transparent it would be useful to tag them with the RFC2119 tags.

[mlagally]

Arch call on June 23rd: We should leave this section alone for 1.1 and may be revisiting it in the 2.0 scope.