ietf-wg-httpapi / rfc7807bis

Revision of RFC7807: HTTP Problem Details
Other
20 stars 8 forks source link

Deprecating media type? #16

Closed sdatspun2 closed 3 years ago

sdatspun2 commented 3 years ago

Note that because extensions are effectively put into a namespace by the problem type, it is not possible to define new "standard" members without defining a new media type

@mnot Pardon my ignorance here...what was the reason to tie "standard" members with a media type and not with schema (at least for JSON and XML)? It locks the definition but it also makes it extremely difficult to evolve. Should this be revisited?

It would be much easier to resolve #6 and #8 if we could made backward-compatible changes to schemas.

mnot commented 3 years ago

The media type advertises that the content is of a certain format; if you make backwards-compatible changes to that, you're going to break some processors.

mnot commented 3 years ago

Is there something actionable here, or can we close this?

dret commented 3 years ago

i am still struggling with this a little. i am assuming this actually talks about forward-compatible changes, i.e. an updated format processed by old processors. i am not sure what the title of this issue refers to looking at the comments, though. but it seems that following the usual practice of not making "breaking changes" should be fine, right? this means not changing any definitions of the existing members, and only adding members that can be safely ignored.

mnot commented 3 years ago

Sorry, I should have typed backwards _in_compatible changes. Compatible changes are fine.

mnot commented 3 years ago

So, can we close?