Code change:
expectations, if any, can be defined within the field specification for a field intended for use in trailers. <ins> 6.6. Fields that describe the message itself, such as when and how the message has been generated, can appear in both requests and responses. 6.6.1. The "Date" header field represents the date and time at which the message was originated, having the same semantics as the Origination Date Field (orig-date) defined in RFC5322.  The field value is an HTTP-date, as defined in http.date. An example is A sender that generates a Date header field SHOULD generate its field value as the best available approximation of the date and time of message generation.  In theory, the date ought to represent the moment just before generating the message content.  In practice, a sender can generate the date value at any time during message origination. An origin server MUST NOT send a Date header field if it does not have a clock capable of providing a reasonable approximation of the current instant in Coordinated Universal Time.  An origin server MAY send a Date header field if the response is in the or class of status codes.  An origin server MUST send a Date header field in all other cases. A recipient with a clock that receives a response message without a Date header field MUST record the time it was received and append a corresponding Date header field to the message's header section if it is cached or forwarded downstream. A recipient with a clock that receives a response with an invalid Date header field value MAY replace that value with the time that response was received. A user agent MAY send a Date header field in a request, though generally will not do so unless it is believed to convey useful information to the server.  For example, custom applications of HTTP might convey a Date if the server is expected to adjust its interpretation of the user's request based on differences between the user agent and server clocks. 6.6.2. The "Trailer" header field provides a list of field names that the sender anticipates sending as trailer fields within that message. This allows a recipient to prepare for receipt of the indicated metadata before it starts processing the content. For example, a sender might indicate that a signature will be computed as the content is being streamed and provide the final signature as a trailer field.  This allows a recipient to perform the same check on the fly as it receives the content. A sender that intends to generate one or more trailer fields in a message SHOULD generate a header field in the header section of that message to indicate which fields might be present in the trailers. If an intermediary discards the trailer section in transit, the field could provide a hint of what metadata was lost, though there is no guarantee that a sender of Trailer will always follow through by sending the named fields. </ins> 7. HTTP request message routing is determined by each client based on

Related discussion:
text: This works well on multiple levels because these fields are not about the request or response context, but rather about the message itself. Date is now defined early and close to the date value definitions of 5.6.7. Trailer is now defined just after the description of trailers. Also, it avoids changing any xrefs from HTTP/3. Only the section heading and intro are new -- the moved text has not been changed.
Oops, that wasn't intentional. The Trailer field is the main one that goes both directions. It should really be in a different section. Date is the other.
I think we should move it to 6.6 (in the message abstraction, just after trailers are defined).
I also forgot that Date can be sent in requests. How about a 10.3 section on "Generation Context" that would contain Date and Trailer? I am a little worried that this might change the section numbering for HTTP/3, so we should check that first.
I checked HTTP/3 and there are no references to section 10 of [SEMANTICS].
Looks good, want to see it in situ tho