Add section on expected server HTTP status codes

[msporny]

It has been suggested that the specification should articulate what HTTP status codes are sent by servers, and expected by clients, when certain operations, such as dereferencing occur. This issue has been created to track that concern.

[OR13]

we should also comment on accept / content type headers as well.

[Sakurann]

TPAC VC WG: normative statements. idea is to learn from DI example.

[iherman]

The issue was discussed in a meeting on 2023-09-15

• no resolutions were taken

View the transcript

1.4. Add section on expected server HTTP status codes (issue vc-status-list-2021#64)

See github issue vc-status-list-2021#64.

Manu Sporny: need approval from the group to talk about potential http response status codes ... request by mike jones.
… if you do things with status lists with HTTP, what should you expect ...
… from HTTP status codes ...
… if you operate over http these are the things that you can expect to see from servers ....
… looking to see if anyone that would oppose to adding a section on operating over http and expecting http error codes.

Brent Zundel: any opposition as that for a path forward?

Kristina Yasuda: sgtm.
… when this was raised we deliberately didn't do right away ... what has changed? why is it ok to do this now?

Joe Andrieu: just wanted to clarify, the intention is to not use non-normative language, right?

Manu Sporny: what has changed, kristina, is that we figured out a way to do it without raising objections, a design pattern in the status list that people din't reject.

Kristina Yasuda: it needs to be normative.

Manu Sporny: joe, if you are using HTTP these things MUST be done.

Joe Andrieu: +1 to normative. just wanted to understand the scope of the proposal.

Brent Zundel: prefer normative, since we've found a way to do that.

Manu Sporny: mike, wdyt, would you more normative language around this?

mike: yeah.

Manu Sporny: as long as no one opposed, we'd use normative language.
… i'll take that.

[msporny]

PR #111 has been raised to address this issue. This issue will be closed once PR #111 has been merged.

[msporny]

PR #111 has been merged, closing.