Original text:
applications can involve issuing a token whereby certain semantics about the token can change over time which are important to be able to communicate to relying parties in an interoperable manner, such as <del> whether the token is considered revoked by its issuer. This document defines a status list using JWT and CWT for representation that is capable of communicating the individual statuses of multiple tokens.  The document also defines how an issuer of a token references a status list in a JWT or CWT which has a status to convey. </del>  The following diagram depicts the basic conceptual relationship.  2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Reviewer comments:
NAME Whats' failing on the build here?
breaks the build All RFC references are resolved interally and linked
There are possible applications of this draft that go beyond just verifiable credentials, hence we do not want to use that term in this draft IMO. "Token" is already a term broadly used in this space e.g CWT and JWT both use it, "subject" was used in this context because it is also a term used heavily w.r.t tokens, feel free to suggest alternative terminology but at this point I think subject token is the best I've heard suggested.
can we simply use JWT/CWT instead of creating any kind of abstraction term like ? One person i asked for feedback associated with a token used to communicate a subject of an email.
or, bottomline, please stick to . is very confusing.
I'm with Tobias on this and prefer introducing a new term here. Otherwise things get really weird because the status list is also a JWT/CWT and a token. We need something that clearly separated the status list token and the other token. I think subject token is the best we have. Also subject is leaving towards what we have as credentialSubject in the VC world, so the term subject is kind of established in this context
I am really strongly against "Subject Token". Not only because it is not intuitive (I have been asking various people in this space and no one would associate what it trying to be conveyed), but we should not be introducing a new term in this already confusing ecosystem. Moreover, this status list mechanism can be used with a JWT/CWT that does not necessarily contain a subject (like SD-JWT-VC), so using a term subject because it is widely used is not a sufficient reason. Keep referring to it as a token, because this draft should not be opinionated about what is in the JWT/CWT whose status is being expressed should be fine, if a "status list JWT/CWT" is always referred as such. there are multiple occurrences where "status list JWT" is referred to simply as a JWT which should be fixed IMO.
We need clear terminology for: the status list token (i think this one fits pretty well) the credential / token that is bound to the status list I do believe only calling it token will cause confusion with the status list token. We can also call it something else like credential if we do a proper introduction of the term in the beginning?
Why call "status list token" and not "status list JWT/CWT"?
agreed on call: rename Status List to Status List Token introduce Status List for the actual bitarray rename Subject Token to Referenced Token remove Status List Provider for now and introduce it later if neccessary
btw sd-jwt vc spec mentions status provider :)
NAME NAME can you approve this PR?
Hi, thinking more about this, status list Token is being referenced in the token-whose-name-we-are-trying-to-find, so it's the status list token that is actually a "referenced token". Can we call token-whose-name-we-are-trying-to-find "a Token with reference"?
Yes, I agree and had the same thoughts when I changed the PR. I assume Referencing Token could be better. But let's accept this PR and move discussion to an issue instead...
Multiple approvals and discussions on editors calls, merging
opened issue to continue the terminology discussionok. Then please migrate the TODOs afterwards.

Revised text:
applications can involve issuing a token whereby certain semantics about the token can change over time which are important to be able to communicate to relying parties in an interoperable manner, such as  <ins> whether the token is considered invalidated or suspended by its issuer. This document defines a Status List in JWT and CWT representations that describes the individual statuses of multiple Referenced Tokens. The statuses of all Referenced Tokens are conveyed via a bit array in the Status List.  Each Referenced Token is allocated an index during issuance which represents a position within this bit array and the value of the bit(s) at this position correspond to the Referenced Token's status.  The document also defines how an issuer of a Referenced Token in JWT or CWT representation references a Status List Token.  Status Lists may be composed for expressing a range of Status Types, the document defines basic Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types.  The Status List Token may be used by an issuer in the Issuer-Holder-Verifier model, as described in (XXX) to express the status of verifiable credentials (Referenced Tokens) issued by an issuer. </ins> The following diagram depicts the basic conceptual relationship. <ins> 1.1. Revocation mechanisms are an essential part for most identity ecoosystems.  In the past, revocation of X.509 TLS certificates has been proven difficult as traditional certificate revocation lists (CRLs) have limited scalability and the Online Certificate Status Protocol (OCSP) has additional privacy risks as the client is leaking the requested website to a third party.  OSCP stapling is adressing some of these problems at the cost of less up-to-date data.  Modern approaches use accumulator-based revocation registries and Zero- Knowledge-Proofs to accomodate for this privacy gap but face scalability issues again. The approach of this specification seeks to find a balance between scalability, security and privacy by minimizing the status information to mere bits and compressing the resulting binary data. Thereby a Status List may contain statuses of 100.000 or more Referenced Tokens, but still remain relatively small.  Placing large amounts of Referenced Tokens into the same list also enables a herd privacy towards the Issuer. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",