Feat: update HTTP refs in protocol

[woutermont]

Following up on #471, this PR updates the references to HTTP RFCs from the updated 3864 and obsolete 723x and 7540 to the replacing 911x.

Changes

Commit	Target	Correction class	Note
ae93665	#resource	2 (no conformance impact; no change in semantics of 'resource')	update ref RFC7231 => RFC9110 in definition of resource
d9670da	#Client	2 (no conformance impact; no change in semantics of 'client')	update ref RFC7230/7231 => RFC9110/9112 in Client product class definition
d9670da	#Server	2 (no conformance impact; no change in semantics of 'server')	update ref RFC7230/7231 => RFC9110/9112 in Server product class definition
281b10d	#server-http	3 (possibly minor conformance impact, given broadness of reference; see changelogs [*] & [**])	updates ref RFC7231 => RFC9110 into separate server conformance statement for HTTP Semantics
281b10d 698fe3b	#server-http11	3 (possibly minor conformance impact, given broadness of reference; see changelog [***])	updates ref RFC7230 => RFC9112 in server conformance
281b10d	#server-http2	3 (possibly minor conformance impact, given broadness of reference; see changelog [****])	updates ref RFC7540 => RFC9113 in server conformance
281b10d	#client-http	3 (possibly minor conformance impact, given broadness of reference; see changelogs [*] & [**])	updates ref RFC7231 => RFC9110 into separate client conformance statement for HTTP Semantics
281b10d 698fe3b	#client-http11	3 (possibly minor conformance impact, given broadness of reference; see changelog [***])	updates ref RFC7230 => RFC9112 in client conformance + separate HTTP Semantics
281b10d	#client-http2	3 (possibly minor conformance impact, given broadness of reference; see changelog [****])	updates ref RFC7540 => RFC9113 in client conformance
2aecb43	#server-conditional-requests	3 (negligible conformance impact; see changelog [°])	removes RFC7232 in server conformance (already included in RFC9110)
2aecb43	#server-range-requests	3 (negligible conformance impact; see changelog [°°])	removes RFC7233 in server conformance (already included in RFC9110; MAY => MUST not problematic since servers may ignore range requests anyway)
2aecb43	#server-authentication	2 (no conformance impact; no changes [°°°])	removes RFC7235 in server conformance (already included in RFC9110)
2aecb43	#client-conditional-requests	3 (negligible conformance impact; see changelog [°])	removes RFC7232 in client conformance (already included in RFC9110; MAY => MUST not problematic since client conformance is conditional on its desire to do cache validation)
2aecb43	#client-range-requests	3 (negligible conformance impact; see changelog [°°])	removes RFC7233 in client conformance (already included in RFC9110; MAY => MUST not problematic since client conformance is conditional on its desire to use range requests)
2aecb43	#client-authentication	2 (no conformance impact; no changes [°°°])	removes RFC7235 in client conformance (already included in RFC9110)
1f4f218	#server-caching	3 (negligible conformance impact; see changelog [°°°°])	updates RFC7234 => RFC9111 in server conformance (and moves one paragraph up)
1f4f218	#client-caching	3 (negligible conformance impact; see changelog [°°°°])	updates RFC7234 => RFC9111 in client conformance (and moves one paragraph up)
04f183a	#client-content-type	2 (no conformance impact; method semantics has not changed	updates RFC7231 => RFC9110 after method list
a00c806	#reading-resources	2 (no conformance impact; method semantics not changed	updates RFC7231 => RFC9110 after method list
a00c806	#writing-resources	2 (no conformance impact; method semantics not changed	updates RFC7231 => RFC9110 after method list
e5c030a	#deleting-resources	2 (no conformance impact; method semantics not changed	updates RFC7231 => RFC9110 after method list
e5c030a	#server-disallow-delete	2 (no conformance impact; allow header semantics not changed	updates RFC7231 => RFC9110 after mention of allow header
e5c030a	#server-delete-side-effects	2 (no conformance impact; non-normative section	updates RFC7231 => RFC9110 reference
bd04820	#server-cors	2 (no conformance impact; status code semantics not changed	updates RFC7231 => RFC9110 after status code
bd04820	#server-cors-options	2 (no conformance impact; method semantics not changed	updates RFC7231 => RFC9110 after OPTIONS method
4a3c7ac	#accept-put	2 (no conformance impact; RFC9110 permanently removes part that was excluded specifically in protocol)	removes exclusion of accept-params, which no longer exist in RFC9110
e4adde5	#accept-put	2 (no conformance impact; RFC9110 only adds notation for case sensitive syntax, which does not clash with the wac-allow defintion)	updates reference RFC7231 (notation) => RFC9110 (notation) + corrects section numbers
5a25dd7	#accept-put	2 (no conformance impact; correction of invalid ABNF)	corrects invalid use of list syntax (no space allowed after #)
d5b1ad2	#accept-put	2 (no conformance impact; RFC9110 separates registry but refers to RFC3864)	updates ref RFC3864 => RFC9110 for header field registration
0424926	#consider-uri-http	2 (no conformance impact; considerations only shuffled, not changed	updates refs RFC7230/7231 => RFC9110/9112 in security considerations
9cf67a3	#bib-rfc3864	1 (no content change, only bibliography)	remove reference to obsolete RFC3864
9cf67a3	#bib-rfc7230	1 (no content change, only bibliography)	remove reference to obsolete RFC7230
9cf67a3	#bib-rfc7231	1 (no content change, only bibliography)	remove reference to obsolete RFC7231
9cf67a3	#bib-rfc7232	1 (no content change, only bibliography)	remove reference to obsolete RFC7232
9cf67a3	#bib-rfc7233	1 (no content change, only bibliography)	remove reference to obsolete RFC7233
9cf67a3	#bib-rfc7234	1 (no content change, only bibliography)	remove reference to obsolete RFC7234
9cf67a3	#bib-rfc7235	1 (no content change, only bibliography)	remove reference to obsolete RFC7235
9cf67a3	#bib-rfc7540	1 (no content change, only bibliography)	remove reference to obsolete RFC7540
abf8e7e 2ef4785	#bib-rfc9110	1 (no content change, only bibliography)	insert reference to replacing RFC9110
abf8e7e 2ef4785 ff3afc0	#bib-rfc9112	1 (no content change, only bibliography)	insert reference to replacing RFC9112
abf8e7e 2ef4785	#bib-rfc9113	1 (no content change, only bibliography)	insert reference to replacing RFC9113

HTML Preview | HTML Diff

If there still are any concerns about impact to conformance, you can check the relevant changelogs here:

• RFC7540 => RFC9113 (****)
• RFC7230 => RFC9112 (***)
• RFC7230 => RFC9110 (**)
• RFC7231 => RFC9110 (*)
• RFC7232 => RFC9110 (°)
• RFC7233 => RFC9110 (°°)
• RFC7235 => RFC9110 (°°°)
• RFC7234 => RFC9111 (°°°°)

On a sidenote: do you all manually update the HTML here? Bikeshed or ReSpec are quite handy in keeping track of references, amongst other things.

[csarven]

+1 to confining this PR to changes pertaining to updating some of the references. We can give citations and references for the whole document a pass in another PR, including improvements pertaining to style, guidelines, etc.

[csarven]

On a sidenote: do you all manually update the HTML here? Bikeshed or ReSpec are quite handy in keeping track of references, amongst other things.

Happy to give a short-ish response here but I suggest that we move the discussion on the topic elsewhere if anyone would like to follow-up.

Somewhat semi-automated.

• Majority of the references did not need to change or rarely need to change, so the "work" is insignificant. There is far more work (actual thinking) involved to document any changes to interoperability when the references are being updated in the specification than say (manually) updating the references text (which will go on unchanged for years any way).
• I've used https://specref.org/ website and API to get the information for the references, as well as respec's specref call. With respect to the citation style and markup, I've reused (with minor updates) what they've output. To stay compatible to what's somewhat in practice although I do not completely agree with all the decisions there - some of the decisions in the manual of style is better IMO, and we can process that separately.
• bikeshed and respec are great tools for what they are designed to do - simpler authoring, and preprocessing - but they are also opinionated software, and don't necessarily follow the W3C manual of style or other things to the dot. They require the authors to learn additional conventions with respect to the tooling - this may be fine for some editors, but I felt it was not something I wanted to pursue (see next point). I do however regularly consult to how/what those tools output.
• Insert speech here about why it is important to demonstrate Solid apps for authoring technical specifications both for the Solid ecosystem as well as exemplifying the fitness of the Solid Protocol such that conforming implementations enable users to... (hold on to your hats folks)... update HTML documents (in 2023).

[woutermont]

Alright! I've been through this best I can.

Contrary to the other reports I updated, there are some places here where there could be a minor impact on actual conformance to small changes in the details of RFC911x. I've tried to clearly indicate these in the table (rows with correction class 3), as well as give an assessment of the possible impact. This assesment is one of the following in all cases:

• 'negligible': There have been small adaptations to some details of the HTTP semantics. I've gone over them and, according to me, none of these will actually impact existing implementations. A few extra pairs of eyes could not hurt however, so I have in each case indicated where to find the relevant changes.

• 'minor': The server and client product classes are required to follow HTTP Semantics, HTTP/1.1 and recommended/optionally HTTP/2 in general. Since this means taking into account all of the small changes together, I suggest that a few other people also go through the complete list of changes to those specs, to see if there is anything in particular that might cause problems.

[elf-pavlik]

LGTM, I just left one nit-pick inline

[woutermont]

In personal communication, @joachimvh indicated he sees no problem in the updates.