content-warning: do we need to limit `warnings` semantic?

[ioggstream]

Note

The spec says

   When an condition occurs that can not be defined as a "hard error"
   (i.e., that allows clients to continue treating the resulting
   response as a success), additional information about this condition
   can be returned to the API client

In my understanding, this sentence suggests to limit the usage of warnings to non-hard-error.

We can just define warnings and let people use whenever their application logic requires it.

I

[andrecedik]

What we're trying to achieve is to create a standard way of returning warning information to a client. So from my point of view there is only this use case.

There are only two other options:

1. Allow hard errors to be returned in the warnings object This makes no sense at all, since you are mixing errors and warnings which is what we're trying to get rid of.

2. Be open about when to return warnings From what I've gotten from the feedback to the first version of our I-D, this is what happened with the Warning Header, that was/will be removed. The spec got interpreted in different ways and in the end it was best to remove it, since its original purpose was lost.