Original text:
As with sending, the type of the Message to be passed is dependent on the implementation, and on the constraints on the Protocol Stacks <del> implied by the Connection's transport parameters.  The Message may also contain metadata from protocols in the Protocol Stack; which metadata is available is Protocol Stack dependent.  In particular, when this information is available, the value of the Explicit Congestion Notification (ECN) field is contained in such metadata. This information can be used for logging and debugging purposes, and for building applications which need access to information about the transport internals for their own operation. </del>  The Message Object must provide some method to retrieve an octet array containing application data, corresponding to a single message 8.1.  The application may check a property to determine if a received Message is the Final Message on a Connection.  For any Message that is marked as Final, the application can assume that there will be no Any calls to "Receive" once the Final Message has been delivered will result in errors. <del> 8.2. </del>  The Receive Event is intended to be fired once per application-layer Message sent by the remote endpoint; i.e., it is a desired property

Reviewer comments:
And add an early data metadata value.
I'll dig up relevant discussions from the TLS WG.
See, e.g.: URL
Looks like a good candidate for a read-only recv property…
NAME Aren't all receives read-only?
Looks good - minor nits noted in URL lgtmMuch better I think!

Revised text:
As with sending, the type of the Message to be passed is dependent on the implementation, and on the constraints on the Protocol Stacks  <ins> implied by the Connection's transport parameters. </ins> The Message Object must provide some method to retrieve an octet array containing application data, corresponding to a single message 8.1. <ins> Each Message may also contain metadata from protocols in the Protocol Stack; which metadata is available is Protocol Stack dependent.  The following metadata values are supported: 8.1.1. When available, Message metadata carries the value of the Explicit Congestion Notification (ECN) field.  This information can be used for logging and debugging purposes, and for building applications which need access to information about the transport internals for their own operation. 8.1.2. In some cases it may be valuable to know whether data was read as part of early data streams.  This is useful if applications need to treat early data separately, e.g., if early data has different security properties than data sent after connection establishment. In the case of TLS 1.3, client early data can be replayed maliciously (see I-D.ietf-tls-tls13).  Thus, receivers may wish to perform additional checks for early data to ensure it is idempotent or not replayed.  If TLS 1.3 is available and the recipient Message was sent as part of early data, the corresponding metadata carries a flag indicating as such.  If early data is enabled, applications should check this metadata field for Messages received during connection establishment and respond accordingly. 8.2. </ins> The application may check a property to determine if a received Message is the Final Message on a Connection.  For any Message that is marked as Final, the application can assume that there will be no Any calls to "Receive" once the Final Message has been delivered will result in errors.  <ins> 8.3. </ins> The Receive Event is intended to be fired once per application-layer Message sent by the remote endpoint; i.e., it is a desired property