Change:
Message Properties can be set and queried using the Message Context: <del> These Message Properties may be generic properties or Protocol Specific Properties. </del> <ins> These Message Properties may be generic properties or protocol- specific Properties. </ins> For MessageContexts returned by send Events (see send-events) and receive Events (see receive-events), the application can query

Discussion:
This implements the change I suggested in , and it also replaces "Protocol Specific Properties" with "protocol-specific Properties".
The example could be even more useful perhaps: /Protocol-specific Properties MUST use the protocol acronym as the Namespace (e.g., a connection could support a TCP-specific Transport Property, such as {{tcp-uto}}, in a protocol-specific parameter called ./
Done, in line with your suggestion. The wording is slightly different for several reasons: really using would be confusing because that particular property doesn't exist (there are, if you will, sub-properties). The {{tcp-uto}} reference expands as "Section ...", so using "such as" doesn't work; it's not a "protocol-specific parameter" but a "protocol-specific property". Oh and the connection is a Connection :-)
Specific suggestion you could start from: "For IETF protocols, the name of a Protocol-specific Property SHOULD be specified in a IETF document published in the RFC Series."
P.S. I would also be happy to continue with another recommendation, for additional transport properties that was proposed which says something like add it to the RFC.
URL are all the current protocols defined their Namespace in the respective RFCs? can we put a example reference? can we be more detailed on "SHOULD be defined in an RFC" actually mean?
My understanding is that this is meant as guidance for implementations, and for future RFCs to be written. If I write a TAPS system and provide a property that exists in QUIC only (and cannot reasonably be mapped to other protocols), then I should call it "quic.propertyname" - much like the TCP-specific properties in section 8.2. Similarly, future RFCs should define such namespaces if they offer properties that are protocol-specific. It seems that this second sentence poses quite a burden on the IETF in general, and may not be realistic - will people follow this? Suggested solution: remove the second sentence, and add a reference to section 8.2 to the first sentence to show an example.
I'm not sure removing the sentence is the right thing to do. To me this is like the rules to add to a registry, and we should simply describe what they ought to do: what I thought was intended was that the IETF ought to publish the binding in a RFC that defines the thing with a property, or (if necessary) a separate RFC.

It sounded like a too broad demand to make - e.g., RFC 9000 should then have such stuff in it. What if we would phrase this more like, e.g.: "Future RFCs that extend Transport Service systems SHOULD define property names under these namespaces."
I don’t read the problem the same here… your text suggests a property name needs to be in the spec itself - which might be good — but is more than my proposal that said the property name for transport systems SHOULD be defined in the RFC series. Although we might decide to say both. The potential problem as a WG Chair here is that there is no mechanism to remind or check that this is done. To me, it seems like if we had a registry, then we would have an IETF process to encourage ID authors to do the things in 4.1 and 4.2 of interface.
Ok, the phrase "SHOULD be in the RFC series" makes this leave the domain of my IETF knowledge - are we talking about an IANA registry here? Can we use a capital SHOULD as a request to IANA? Or what other form would that take? What would it mean to make such a SHOULD request to the IETF ("RFC series") as a whole? Suggestion: I update my PR to not remove the sentence, merge the PR without closing this issue, and you propose text?