Subject: [httpapi] Multiple Problems in RFC7807bis

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Feb 2022 10:54:18 +1100

Hi everyone,

We've been discussing how to talk about conveying multiple problems in RFC7807bis here:
  https://github.com/ietf-wg-httpapi/rfc7807bis/issues/6

Towards the end of that conversation (as of now), we seem to be converging on how to do this. Copying my comments from there:

~~~
We currently:

	• Describe how to design extensions to accommodate multiple instances of the same type
	• Describe how to use 207 Multi-Status to convey multiple problems with different types/status codes
	• Do not describe how one might convey multiple problems with different types but the same status code.

I think (1) is fine and good.

Right now, (2) seems like it's recommending the pattern, but doesn't define an actual type for use in that situation. That's not great. If we're going to show that pattern, we should probably define the type for use in that situation (especially since we have a registry now). However, I have serious doubts about the wisdom of recommending that pattern, and feel like we should either remove that text, or at least heavily contextualise it.

Regarding (3) -- again, if we want to document that, we should define a type. I tend to think we shouldn't, though.

If we retract (2) and don't attempt (3), we might want to add some text along the lines of:

When an API encounters multiple problems that do not share the same type, it is RECOMMENDED that the most relevant or urgent problem be represented in the response. While it is possible to create generic "batch" problem types that convey multiple, disparate types, they do not map well into HTTP semantics.
~~~

So far, there seems to be support for removing (2) and adding text similar to that proposed.

What do people think? 

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 9 Feb 2022 15:48:05 +0100

> So far, there seems to be support for removing (2) and adding text similar to that proposed.

I didn't have time to read all of the discussion, but one thing comes to
mind: *if* status 207 is used, it needs to be consistent with the base
definition from the WebDAV spec (*) .

"A Multi-Status response conveys information about multiple resources in
situations where multiple status codes might be appropriate." --
<https://greenbytes.de/tech/webdav/rfc4918.html#multi-status.response>

Using it for the case of "there are multiple issues with your request
affecting a single resource" seems to bend that too much...

Best regards, Julian

(*) or the definition needs to be formally extended