Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Status size missing from BitstringStatusList #176

Closed
timothee-haudebourg opened this issue Sep 13, 2024 · 4 comments
Closed

Status size missing from BitstringStatusList #176

timothee-haudebourg opened this issue Sep 13, 2024 · 4 comments
Assignees
Labels
CR1 This item was processed during the first Candidate Recommendation phase. discuss This issue is a discussion with no clear change requested normative The item is normative in nature. pending 7 day close

Comments

@timothee-haudebourg
Copy link

timothee-haudebourg commented Sep 13, 2024

Hi, since the Draft 16 April 2024, the status_size property has been moved from BistringStatusList to BistringStatusListEntry. I understand it is sometimes necessary to know the status size from the entry without having to fetch the entire list, but removing it entirely from BitstringStatusList introduces some major issues in my opinion:

  • It is now impossible to decode a status list without possessing a status list entry.
  • The status size parameter must be passed around in many places of the implementation, making it error prone.
  • This differs from IETF Token Status Lists, making it hard to implement a common API.
@msporny msporny added normative The item is normative in nature. CR1 This item was processed during the first Candidate Recommendation phase. labels Sep 16, 2024
@msporny
Copy link
Member

msporny commented Sep 17, 2024

There is a related comment here for why the spec is in the state that it is in right now: #175 (comment)

@iherman
Copy link
Member

iherman commented Sep 29, 2024

The issue was discussed in a meeting on 2024-09-27

  • no resolutions were taken
View the transcript

4.5. The BitstringStatusList.statusMessages and statusSize properties are still being referenced (issue vc-bitstring-status-list#175)

See github issue vc-bitstring-status-list#175.

Manu Sporny: There is maybe only one implementer for this feature at this point.

See github issue vc-bitstring-status-list#176.

Manu Sporny: Dont think it is currently marked as at risk.
… Actually it is already marked at risk.
… So we are waiting for implementations.

Brent Zundel: My understanding is mesur implements these features.

Manu Sporny: Great. I think Spruce may also be using it, so leaving it in awaiting implementations.

@timothee-haudebourg
Copy link
Author

I just want to point out that this change is affecting the vc-barcodes CCG where status list entries should be described in a compact way. Adding the statusMessages and statusSize properties would go against that. See w3c-ccg/vc-barcodes#19

@msporny
Copy link
Member

msporny commented Nov 30, 2024

Yes, correct, the statusSize and statusMessages properties are not supported in vc-barcodes (due to encoding size restrictions in barcode formats). The placement of the statusMessages and statusSize properties were made after a variety of requirements were discussed and agreed upon in the WG. There are no plans to change the current design.

Please let us know if we're missing anything (I think we understand your concern and have responded to those concerns as best we can). I'm going to mark this issue as pending close and will get confirmation from the WG before closing it.

@msporny msporny added pending 7 day close discuss This issue is a discussion with no clear change requested labels Nov 30, 2024
@msporny msporny closed this as completed Dec 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CR1 This item was processed during the first Candidate Recommendation phase. discuss This issue is a discussion with no clear change requested normative The item is normative in nature. pending 7 day close
Projects
None yet
Development

No branches or pull requests

3 participants