Code change:
7. <del> This document defines potential statuses of Referenced Tokens as Status Type values.  If the Status List contains more than one bit per token (as defined by "bits" in the Status List), then the whole value of bits MUST describe one value.  A Status List can not represent multiple statuses per Referenced Token. The registry in this document describes the basic Status Type values required for the most common use cases.  Additional values may defined for particular use cases. </del> <ins> This document defines statuses of Referenced Tokens as Status Type values.  A status describes the state, mode, condition or stage of an entity that is represented by the Referenced Token. A Status List can not represent multiple statuses per Referenced Token.  If the Status List contains more than one bit per token (as defined by "bits" in the Status List), then the whole value of bits MUST describe one value.  Status Types MUST have a numeric value between 0 and 255 for their representation in the Status List.  The issuer of the Status List MUST choose an adequate "bits" (bit size) to be able to describe the required Status Types for its application. </ins> 7.1. <del> A status describes the state, mode, condition or stage of an entity that is described by the Status List.  Status Types MUST be numeric values between 0 and 255.  Status types described by this specification comprise: </del> <ins> This document creates a registry in iana-status-types that includes the most common Status Type values.  Additional values may defined for particular use cases.  Status Types described by this document comprise: 0x00 - "VALID" - The status of the Referenced Token is valid, correct or legal. 0x01 - "INVALID" - The status of the Referenced Token is revoked, annulled, taken back, recalled or cancelled. 0x02 - "SUSPENDED" - The status of the Referenced Token is temporarily invalid, hanging, debarred from privilege.  This state is reversible. </ins> <del> 0x00 - "VALID" - The status of the Token is valid, correct or legal. </del> <ins> 0x03 - "APPLICATION_SPECIFIC_3" - The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band. </ins> <del> 0x01 - "INVALID" - The status of the Token is revoked, annulled, taken back, recalled or cancelled.  This state is irreversible. </del> <ins> 0x0E - "APPLICATION_SPECIFIC_14" - The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band. </ins> <del> 0x02 - "SUSPENDED" - The status of the Token is temporarily invalid, hanging, debarred from privilege.  This state is reversible. </del> <ins> 0x0F - "APPLICATION_SPECIFIC_15" - The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band. </ins> The Status Issuer MUST choose an adequate "bits" (bit size) to be able to describe the required Status Types for the application.

Related discussion:
text: The first few entries are valid, revoked, suspended. There may be future well defined values that issuers and verifiers want global interoperability around. There may also be a need for private use of this space. This document should describe the "reserved for private use range", and leave room for enough globally interoperable and registered status values
We had similar ideas and totally agree
The section 7 explains how to setup the registry (URL) but we are missing a corresponding section in the IANA appendix