jiebi/TextFlow huggingface dataset:
Original text:
If the Relying Party does not send an Accept Header, the response type is assumed to be known implicit or out-of-band.  The following are non-normative examples for a request and response for a Status List Token with type "application/statuslist+jwt":

Reviewer comments:
Rendered version: URL
We do not define how to respond to a status list request but have status codes on examples We might also need to add language for redirects?
Ok to merge with the minor suggestion.

Revised text:
If the Relying Party does not send an Accept Header, the response type is assumed to be known implicit or out-of-band. <ins> A successful response that contains a Status List Token MUST use an HTTP status code in the 2xx range. A response MAY also choose to redirect the client to another URI using a HTTP status code in the 3xx range, which clients SHOULD follow.  A client SHOULD detect and intervene in cyclical redirections (i.e., "infinite" redirection loops). </ins> The following are non-normative examples for a request and response for a Status List Token with type "application/statuslist+jwt":
Original text:
The Issuer MAY link to the Status List Aggregation URI in metadata that can be provided by different means like .well-known metadata as is used commonly in OAuth and OpenID, or via a VICAL extension for <del> ISO mDoc / mDL. </del>  The concrete specification on how this is implemented depends on the specific ecosystem and is out of scope of this specification.

Reviewer comments:
Rendered version: URL
We do not define how to respond to a status list request but have status codes on examples We might also need to add language for redirects?
Ok to merge with the minor suggestion.

Revised text:
The Issuer MAY link to the Status List Aggregation URI in metadata that can be provided by different means like .well-known metadata as is used commonly in OAuth and OpenID, or via a VICAL extension for  <ins> ISO mDoc / mDL.  If the Issuer is an OAuth Authorization Server according to RFC6749, it is RECOMMENDED to use "status_list_aggregation_endpoint" for its metadata defined by RFC8414. </ins> The concrete specification on how this is implemented depends on the specific ecosystem and is out of scope of this specification.
Original text:
14.6.  This section requests registration of the following media types RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838.

Reviewer comments:
Rendered version: URL
We do not define how to respond to a status list request but have status codes on examples We might also need to add language for redirects?
Ok to merge with the minor suggestion.

Revised text:
14.6. <ins> This specification requests registration of the following value in the IANA "OAuth Authorization Server Metadata" registry IANA.OAuth.Params established by RFC8414. Metadata Name: status_list_aggregation_endpoint Metadata Description: URL of the Authorization Server aggregating OAuth Token Status List URLs for token status management. Change Controller: IETF Reference: aggregation of this specification 14.7. </ins> This section requests registration of the following media types RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838.
Original text:
The HTTP response SHOULD use gzip Content-Encoding as defined in RFC9110.  8.3. Upon receiving a Referenced Token, a Relying Party MUST first perform

Reviewer comments:
We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL

Revised text:
The HTTP response SHOULD use gzip Content-Encoding as defined in RFC9110. <ins> If caching-related HTTP headers are present in the HTTP response, Relying Parties SHOULD prioritize the exp and ttl claims within the Status List Token over the HTTP headers for determining caching behavior. </ins> 8.3. Upon receiving a Referenced Token, a Relying Party MUST first perform
Original text:
11.  11.1. Implementers should be particularly careful for the correct parsing

Reviewer comments:
We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL

Revised text:
11. <ins> The Status List as defined in status-list only exists in cryptographically secured containers which allows checking the integrity and origin without relying on other aspects like transport security (e.g., the web PKI). </ins> 11.1. Implementers should be particularly careful for the correct parsing
Original text:
11.3. <del> When Relying Parties fetch the Status List, they need to be aware of its up-to-date status.  The 'ttl' (time-to-live) claim in the Status List Token provides one mechanism for setting a maximum cache time for the fetched data.  This property permits distribution of a Status List to a CDN or other distribution mechanism while giving guidance to consumers of the Status List on how often they need to fetch a fresh copy of the Status List even if that Status List is not expired. </del>  12.

Reviewer comments:
We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL

Revised text:
11.3.  <ins> When fetching a Status List Token, Relying Parties must carefully evaluate how long a Status List is cached for.  Collectively the "iat", "exp" and "ttl" claims when present in a Status List Token communicate how long a Status List should be cached and should be considered valid for.  The following diagram illustrates the relationship between these claims and how they are designed to influence caching. It is essential to understand the distinct purposes of the "ttl" and "exp" claims.  The "ttl" claim represents a duration to be interpreted relative to the time the Status List is fetched, indicating when a new version of the Status List may be available. In contrast, the "exp" claim specifies an absolute timestamp, marking the point in time when the Status List expires and MUST NOT be relied upon any longer.  Together, these claims provide guidance on when to check for updates ("ttl" claim) and when the Status List must be refreshed or replaced ("exp" claim). </ins> 12.
Original text:
status mechanism method member and a reference to the specification that defines it.  14.2.1. Status Method Value:

Reviewer comments:
We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL

Revised text:
status mechanism method member and a reference to the specification that defines it. <ins> JWT Status Mechanism Methods are registered by Specification Required [RFC5226] after a three-week review period on the jwt-reg- review@ietf.org mailing list, on the advice of one or more Designated Experts.  However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register JWT Status Mechanism Method: example"). Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA.  Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list. </ins> 14.2.1. Status Method Value:
Original text:
status mechanism method member and a reference to the specification that defines it.  14.4.1. Status Method Value:

Reviewer comments:
We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL

Revised text:
status mechanism method member and a reference to the specification that defines it. <ins> CWT Status Mechanism Methods are registered by Specification Required [RFC5226] after a three-week review period on the cwt-reg- review@ietf.org mailing list, on the advice of one or more Designated Experts.  However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register CWT Status Mechanism Method: example"). Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA.  Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list. </ins> 14.4.1. Status Method Value:
Original text:
Status List values.  The registry records the a human readable label, the bit representation and a common description for it.  14.5.1. Status Type Name:

Reviewer comments:
We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL

Revised text:
Status List values.  The registry records the a human readable label, the bit representation and a common description for it. <ins> Status Types are registered by Specification Required [RFC5226] after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts.  However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register Status Type name: example"). Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA.  Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list. </ins> 14.5.1. Status Type Name:
Original text:
single byte for every operation and thus keeping implementations simpler and less error prone. <del> The overall status list is encoded as a byte array.  Depending on </del>  the "bit-size" each byte corresponds to 8/(#bit-size) statuses (8,4,2, or 1).  The status of each Referenced Token is identified <del> using an index that maps to one or more specific bits within the byte array.  The index starts counting at 0 and ends with "size" - 1(being the last valid entry).  The bits within an array are counted from least significant bit "0" to the most significant bit ("7").  All bits of the byte array at a particular index are set to a status value. </del>  The complete byte array is compressed using gZIP RFC1952.

Reviewer comments:
after writing this I figured out changing the byte ordering, i.e. starting with byte 0 on the left might be a little more intuitive?
Yeah with fresh eyes I definately think that would be better.
reversed byte order and added the index to the ascii art

Revised text:
single byte for every operation and thus keeping implementations simpler and less error prone.  <ins> The overall Status List is encoded as a byte array.  Depending on </ins> the "bit-size" each byte corresponds to 8/(#bit-size) statuses (8,4,2, or 1).  The status of each Referenced Token is identified  <ins> using the "index" that maps to one or more specific bits within the byte array.  The index starts counting at 0 and ends with "size" - 1(being the last valid entry).  The bits within an array are counted from least significant bit "0" to the most significant bit ("7").  All bits of the byte array at a particular index are set to a status value. </ins> The complete byte array is compressed using gZIP RFC1952.
Original text:
base64 encoding without padding encoding as defined in Section 2 of RFC7515 and stored as a string. <del> Example of a two byte status list representing 16 statuses (1-bit status list) with indices 0 to 16 (2 bytes): </del>  Example of a more complex status list of length 12 using 2 bit statuses (3 bytes):  5. This document defines the possible statuses of Referenced Tokens as

Reviewer comments:
after writing this I figured out changing the byte ordering, i.e. starting with byte 0 on the left might be a little more intuitive?
Yeah with fresh eyes I definately think that would be better.
reversed byte order and added the index to the ascii art

Revised text:
base64 encoding without padding encoding as defined in Section 2 of RFC7515 and stored as a string.  <ins> Example of a Status List representing the statuses of 16 Referenced Tokens (1-bit status type) with indices 0 to 15 (2 bytes): These bits are concatenated: After compression and Base64URL encoding the generated Status List is: </ins> Example of a more complex status list of length 12 using 2 bit statuses (3 bytes): <ins> These bits are concatenated: byte 0 1 2 bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ values |1|1|0|0|1|0|0|1| |0|1|0|0|0|1|0|0| |1|1|1|1|1|0|0|1| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / status 3 0 2 1 1 0 1 0 3 3 2 1 index 3 2 1 0 7 6 5 4 11 10 9 8 _ __/ 0xC9 0x44 0xF9 This results in the byte array: After compression and Base64URL encoding the generated Status List is: </ins> 5. This document defines the possible statuses of Referenced Tokens as
Original text:
These bits are concatenated: <del> byte 0 1 2 bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ values |1|1|0|0|1|0|0|1| |0|1|0|0|0|1|0|0| |1|1|1|1|1|0|0|1| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / status 3 0 2 1 1 0 1 0 3 3 2 1 index 3 2 1 0 7 6 5 4 11 10 9 8 _ __/ 0xC9 0x44 0xF9 This results in the byte array: </del>  After compression and Base64URL encoding the generated Status List is:

Reviewer comments:
fixes the examples to use constant timestamps in gzip encoding minor changes/fixes to the ascii art / code blocks

Revised text:
These bits are concatenated:  <ins> Resulting in the byte array: </ins> After compression and Base64URL encoding the generated Status List is:
Original text:
Relying parties MUST reject JWTs that are not valid in all other respects per "JSON Web Token (JWT)" RFC7519. <del> 4.2.1. </del>  The following rules apply to validating the "status_list" (status list) claim

Reviewer comments:
reorder section on Referenced Token and Status List Token URL
I did a first review of this draft. As a newbie to the topic, I found the following issues: I miss a description of the fundamental concept, i.e. the status list itself is a JWT (issued by the same issuer issuing the JWTs), the status list JWT is obtained from a URL hosted by that issuer or another party, the link between the JWT and its status list is provided through data in the JWT. I suggest to add this in the Introduction (or an Overview) section. When reading Section 3.1. for the first time I was confused whether it describes the status list JWT or the JWT referring to the status list. I think it is the latter and it should be clear to the reader on first sight. I think the order of definition should be changed. Right now, I'm supposed to understand how a status list JWT is used in a JWT without even knowing what that status list JWT is. I suggest to change order: 1) Overview of the concepts, 2) specify status list JWT (structure and where/how to obtain), 3) embedding in a JWT (syntax, processing rules, ...).
Agree on 1+2. As mentioned in we need a better word describing the "Token" that is being described by the status List. I will make a PR using "Subject Token" as this comprises both JSON and CBOR formats. Agree on 3 as well.
For reordering it would make sense to get forward with the existing PRs first and do it afterwards..
Addressing some of these issues in
What's left to do: reorder Status List Token first and Referenced Token afterwards

Revised text:
Relying parties MUST reject JWTs that are not valid in all other respects per "JSON Web Token (JWT)" RFC7519.  <ins> 4.1.1. </ins> The following rules apply to validating the "status_list" (status list) claim
Original text:
it conveys statuses for.  The value MUST be computed using the algorithm described in jwt-status-list-claim-encoding. <del> 4.2.2. </del>  Each status of a Referenced Token MUST be represented with a bit size of 1,2,4, or 8.  Therefore up to 2,4,16, or 256 statuses for a

Reviewer comments:
reorder section on Referenced Token and Status List Token URL
I did a first review of this draft. As a newbie to the topic, I found the following issues: I miss a description of the fundamental concept, i.e. the status list itself is a JWT (issued by the same issuer issuing the JWTs), the status list JWT is obtained from a URL hosted by that issuer or another party, the link between the JWT and its status list is provided through data in the JWT. I suggest to add this in the Introduction (or an Overview) section. When reading Section 3.1. for the first time I was confused whether it describes the status list JWT or the JWT referring to the status list. I think it is the latter and it should be clear to the reader on first sight. I think the order of definition should be changed. Right now, I'm supposed to understand how a status list JWT is used in a JWT without even knowing what that status list JWT is. I suggest to change order: 1) Overview of the concepts, 2) specify status list JWT (structure and where/how to obtain), 3) embedding in a JWT (syntax, processing rules, ...).
Agree on 1+2. As mentioned in we need a better word describing the "Token" that is being described by the status List. I will make a PR using "Subject Token" as this comprises both JSON and CBOR formats. Agree on 3 as well.
For reordering it would make sense to get forward with the existing PRs first and do it afterwards..
Addressing some of these issues in
What's left to do: reorder Status List Token first and Referenced Token afterwards

Revised text:
it conveys statuses for.  The value MUST be computed using the algorithm described in jwt-status-list-claim-encoding.  <ins> 4.1.2. </ins> Each status of a Referenced Token MUST be represented with a bit size of 1,2,4, or 8.  Therefore up to 2,4,16, or 256 statuses for a