It's a good question with an unsatisfying answer. Networking is kind of difficult.
Sitting down with an RFC and coding up what it says is nowhere near as simple as it seems like it should be:
* RFCs are often ambiguous, I've seen teams implement a protocol in a way that certainly seems to follow the RFC but won't be widely interoperable.
* RFCs are often incomplete, many protocols are specified across a lot of different RFCs, and by different authors, so it's easy to miss important details or even whole RFCs exacerbating the above point.
* RFCs are regularly released as protocols evolve and invalidate older versions of the protocol (or early experimental versions of the protocol, etc) often. Sometimes the newest RFC does a lot of work to disambiguate what would be allowed by older versions see for example this recent RFC https://httpwg.org/specs/rfc9110.html
* Independent of what the RFC says, there's what Cisco does (or MS or Google or other large influential imlementors).
* A lot of protocol implementations don't implement the full protocol (that is various extensions or rarely used features).
* A lot of protocol implementations implement what the RFC says in the most commonly aggreed on way, plus a compatibility options for other commonly used implementations, plus some oddball interpretations of the RFC that the authors like.
* There's vendor-specific extensions.
* There's common but unspecified behaviors that implementations tend to converge on, but which aren't easy to intuit.
* There's implementations that handle mixtures of versions (e.g. implementations of http 1.1 that handle 1.0 or 0.9 just fine are common).
And so on. So to answer the question "is 'it's correct' worth mentioning?" - yes, something along these lines tends to be important.
Of course "what does correct mean" is a giant can of worms....
In the case of hyper I think it means: an attempt to be extremely precise in what is allowed (and as close to the disambiguated RFCs as possible), and strict as well - not being particularly loose in what it accepts as input. That's my interpretation anway.
"Sitting down with an RFC and coding up what it says is nowhere near as simple as it seems like it should be"
I learned this for myself when I tried coding an IRC server for fun. Quickly found that I made more progress, faster by just using Wireshark to see what an established server was doing and copying that.
Sitting down with an RFC and coding up what it says is nowhere near as simple as it seems like it should be:
* RFCs are often ambiguous, I've seen teams implement a protocol in a way that certainly seems to follow the RFC but won't be widely interoperable.
* RFCs are often incomplete, many protocols are specified across a lot of different RFCs, and by different authors, so it's easy to miss important details or even whole RFCs exacerbating the above point.
* RFCs are regularly released as protocols evolve and invalidate older versions of the protocol (or early experimental versions of the protocol, etc) often. Sometimes the newest RFC does a lot of work to disambiguate what would be allowed by older versions see for example this recent RFC https://httpwg.org/specs/rfc9110.html
* Independent of what the RFC says, there's what Cisco does (or MS or Google or other large influential imlementors).
* A lot of protocol implementations don't implement the full protocol (that is various extensions or rarely used features).
* A lot of protocol implementations implement what the RFC says in the most commonly aggreed on way, plus a compatibility options for other commonly used implementations, plus some oddball interpretations of the RFC that the authors like.
* There's vendor-specific extensions.
* There's common but unspecified behaviors that implementations tend to converge on, but which aren't easy to intuit.
* There's implementations that handle mixtures of versions (e.g. implementations of http 1.1 that handle 1.0 or 0.9 just fine are common).
And so on. So to answer the question "is 'it's correct' worth mentioning?" - yes, something along these lines tends to be important.
Of course "what does correct mean" is a giant can of worms....
In the case of hyper I think it means: an attempt to be extremely precise in what is allowed (and as close to the disambiguated RFCs as possible), and strict as well - not being particularly loose in what it accepts as input. That's my interpretation anway.