Closed
Description
Looking at https://spec.openapis.org/oas/latest.html it still references RFC 7231 when referring to HTTP. But that specification was obsoleted by RFC 9110 in June 2022. I am not confident enough to make the change myself, but if somebody can point me at some "here's how to change the OpenAPI spec" primer, I'd be more than happy to give it a try.
Activity
handrews commentedon May 13, 2024
@dret we don't change the published specs (except when something happens like GitHub breaking their own markdown rendering, but in that case we're changing a broken link to work again, not changing the actual contents).
It's not clear to me if updating obsoleted RFCs is something we do in patch releases or if we want to leave those and only change them in a minor release. Process issues related to this:
handrews commentedon May 13, 2024
We're kind of buried in a backlog of issues trying to define and document this:
dret commentedon May 13, 2024
handrews commentedon May 13, 2024
I didn't make this reference, so I don't know, but I assume because it's actually in WHATWG's URL "Living Standard" which doesn't even acknowledge the existence of relative URI-references [EDIT: as a syntax independent from a browser-supplied base URI], among many other failures to cover 3986, which claims to "obsolete". And then the author refuses to define relative references because, (and I quote) there is a "lack of browser-related use cases" 🤦
Plus, WHATWG specs are pseudocode tied to browser implementations. They're completely unreadable for anyone else IMNSHO.
While I've been working on the parameter serialization areas, I have debated mentioning WHATWG. But to me, referencing WHATWG URL in an API spec that's based off of RFC3986 is asking for trouble. It introduces a conflicting set of terminology, a dismissive attitude of the work of past spec authors, and an aggressively browser-centric worldview that outright dismisses the utility or relevance of any other context at all.
handrews commentedon May 13, 2024
To be clear: I think the WHATWG specs do a valuable thing by standardizing implementation concerns. If they just did that on top of the existing RFCs and W3C specs that define grammars, syntax, and semantics, it would have been fanstatic. But instead they act like those other concerns, audiences, and environments are so unimportant that they refuse to address them while attempting to prevent anyone else from doing so. We're an API spec, not a browser spec, so we are solidly outside of what they consider valid or relevant, as they've made clear over and over.
handrews commentedon May 13, 2024
Oh and WHATWG URL's encoding set for
application/x-www-form-urlencoded
is different from RFC6570's form expansion operator, and I can't figure out how to explain that in our spec with out a multi-paragraph digression, and I just do not have any idea how to deal with that (despite my ranting, if someone comes up with a coherent way to refernce and explain all of that, I would happily support. I'm just at a loss with it)dret commentedon May 13, 2024
handrews commentedon May 13, 2024
@dret thanks – my reaction was probably excessive so I apologize for that. Honestly, it's mostly that I don't know what to do with the mess. There's just no good answer.
Anyway, if you want to keep this focused on 7231 vs 9110 you're welcome to hide or delete this digression (or if you don't have permissions, lmk and I'll do it), or close this and re-file the main point.
handrews commentedon May 14, 2024
@OAI/tsc review request: Should we replace obsoleted RFC references in patch releases, or can we only do that in a point release? They are obsoleted whether we update them or not, but idk how that's viewed in this context.
lornajane commentedon May 14, 2024
I think we should not update in patch releases, in case there's an impacting change. We reference enough 3rd party docs that it would be significant work to review if any of their wording change could possibly impact ours. Let's stick to doing that in minor versions, would be my recommendation. (with the proviso that all rules can be broken if there are good reasons!)
2 remaining items
lornajane commentedon Jun 13, 2024
Discussed in TDC and there's a weak consensus that we should not make this sort of change in a patch release unless there's a strong reason to. Unless someone can go through in enough detail to be sure we're not unintentionally changing things that might impact our users, this should wait until the minor release or until someone has the bandwidth to carefully check all the implications.
I'll leave this open for us to pick up in 3.2