Make clear which sections of the spec are normative

[TomCJones]

Many of the previous issues relate to when and where definitions are made and used in the spec. The current best practice for specs includes these two features which probably need to be made to the spec before it is to be submitted for standardization.
1> mark non-normative sections to avoid many of the comments that would otherwise proliferate. For example the abstract should be non-normative. (Some specs mark normative sections as well.)
2> put all definitions (including definitions by reference) in a very early section. One recent example is the definition of "block chain" which appears often but is not defined and, apparently, not agreed by all on the team.

[mwherman2000]

Many of the previous issues relate to when and where definitions are made and used in the spec.

I believe if we can get an agreeable “picture” of what we’re talking about, the correct words will come a lot easier …at least, that’s my experience in the past.
The ARM is posted here:
Decentralized Identifiers (DIDs) Architecture Reference Model (ARM).

Scroll down the page to the heading Version 0.11 – December 30, 2018 and start reading from there. If you need/want more background, start reading from the top.

[mwherman2000]

[This text has been copied/moved from #158. #158 was subsequently closed.]

In terms of the scope of the draft DID spec, what is considered Normative (and in-scope), Informative (and in-scope) and just plain out of scope?

This is closely related to issue #157 but different. It's is also related to issue #138.

I propose the following green highlight regions of the INDY ARM be considered Normative topics (and in-scope); yellow regions encompass Informative (Not Normative) topics ...and may or may not be considered in-scope.

INDY ARM Reference: Hyperledger Indy/Sovrin Comprehensive Architecture Reference Model (INDY ARM) - latest version

[msporny]

PR da535c8 marks every section as either non-normative or normative. This resolves the original issue that was raised.

There is a larger question around which specification text should be normative and which should not be normative. That question is handled by the specification going through the standardization process.

Closing issue as resolved. Please re-open if you do not agree.