Code change:
6.5.2. <ins> The "Trailer" header field (field.trailer) can be sent to indicate fields likely to be sent in the trailer section, which allows recipients to prepare for their receipt before processing the content.  For example, this could be useful if a field name indicates that a dynamic checksum should be calculated as the content is received and then immediately checked upon receipt of the trailer field value. </ins> Like header fields, trailer fields with the same name are processed in the order received; multiple trailer field lines with the same name have the equivalent semantics as appending the multiple values <del> as a list of members, even when the field lines are received in separate trailer sections.  Trailer fields that might be generated more than once during a message MUST be defined as a list-based field even if each member value is only processed once per field line received. Trailer fields are expected (but not required) to be processed one trailer section at a time.  That is, for each trailer section received, a recipient that is looking for trailer fields will parse the received section into fields, invoke any associated processing for those fields at that point in the message processing, and then append those fields to the set of trailer fields received for the overall message. This behavior allows for iterative processing of trailer fields that contain incremental signatures or mid-stream status information, and fields that might refer to each other's values within the same section.  However, there is no guarantee that trailer sections won't shift in relation to the content stream, or won't be recombined (or dropped) in transit.  Trailer fields that refer to data outside the present trailer section need to use self-descriptive references (i.e., refer to the data by name, ordinal position, or an octet range) rather than assume it is the data most recently received. Likewise, at the end of a message, a recipient MAY treat the entire set of received trailer fields as one data structure to be considered as the message concludes.  Additional processing expectations, if any, can be defined within the field specification for a field intended for use in trailers. </del> <ins> as a list of members.  Trailer fields that might be generated more than once during a message MUST be defined as a list-based field even if each member value is only processed once per field line received. At the end of a message, a recipient MAY treat the set of received trailer fields as a data structure of key/value pairs, similar to (but separate from) the header fields.  Additional processing expectations, if any, can be defined within the field specification for a field intended for use in trailers. </ins> 7.

Related discussion:
text: Trailers that come after the body has well-defined semantics (i.e. metadata applicable to the entire body). Interleaved, mid-stream trailers are considered and implemented as extensions, and maybe we should delay adding them to the core semantics. This is however an important topic for HTTPAPI, IMO.
See related mailing list thread at .
Discussed at Feb 21 interim; sentiment is to remove it; NAME to create a PR.
WFM, thanks.