Original text:
Ordered: when this is false, this disables the requirement of in- order-delivery for protocols that support configurable ordering.  Safely Replayable: when this is true, this means that the Message can be used by mechanisms that might transfer it multiple times - messages, such as UDP, can only be used with Messages that are Safely Replayable. <del> Final: when this is true, this means that a transport connection can be closed immediately after transmission of the message. </del>  Corruption Protection Length: when this is set to any value other than "Full Coverage", it sets the minimum protection in protocols <del> that allow limiting the checksum length (e.g.  UDP-Lite). </del>  Reliable Data Transfer (Message): When true, the property specifies that the Message must be reliably transmitted.  When multiple small Messages can incur high overhead if each needs to be enqueued separately.  To avoid this, the application can indicate a batch of Send actions through the API.  When this is used, the <del> implementation should hold off on processing Messages until the batch </del>  is complete. 5.2.

Reviewer comments:
Section 5.1.2: "the implementation should hold off on processing Messages until the batch is complete" assumes that there is indeed a context-switch penalty. Batch semantics are only for hints to the implementation/protocol stack, and this advice only applies when that hint allows the stack to reduce context switch penalty. Correct? (If so, this should be noted explicitly)
Actually 5.1.3. This reads odd to me, I'd expected myself more like: "When this is used, the implementation can defer the processing Messages until the batch is complete." (eliminating "off on", also from this sentence?)
Agreed, I think your text reads better NAME should it be "... defer the processing of Messages ..." though? I think it also solves the question from NAME as it is now expressed as an opportunity for the implementation.
I believe these are all editorial. First, this list needs some front matter: "protocols should implement each of the following Message Properties on send as follows" or similar. "Ordered" should state that protocols that do not support configurable ordering may ignore the property. "Final" should note that it is not mandatory to close the connection after a Final message. "Corruption Protection Length" should note that it can be ignored basically everywhere but UDP-Lite. One open question: is it an error to send a Message after a Final message, and does the protocol implementation need to handle this itself?
... "Corruption Protection Length" should note that it can be ignored basically everywhere but UDP-Lite. ... In protocols such as UDP-Lite, various tunnels would, DCCP allows, etc.
I think it should be an error to send a Message after a Final message and the implementation of the transport services system should handle it. If it is not an error, then it will fail sometimes and sometimes not depending on if the connection is closed or not, that seems less useful to me.

Revised text:
Ordered: when this is false, this disables the requirement of in- order-delivery for protocols that support configurable ordering. <ins> When the protocol stack does not support configurable ordering, this property may be ignored. </ins> Safely Replayable: when this is true, this means that the Message can be used by mechanisms that might transfer it multiple times - messages, such as UDP, can only be used with Messages that are Safely Replayable.  <ins> Final: when this is true, this means that the sender will not send any further messages.  The Connection need not be closed (in case the Protocol Stack supports half-close operation, like TCP).  Any messages sent after a Final message will result in a SendError. </ins> Corruption Protection Length: when this is set to any value other than "Full Coverage", it sets the minimum protection in protocols  <ins> that allow limiting the checksum length (e.g.  UDP-Lite).  If the protocol stack does not support checksum length limitation, this property may be ignored. </ins> Reliable Data Transfer (Message): When true, the property specifies that the Message must be reliably transmitted.  When multiple small Messages can incur high overhead if each needs to be enqueued separately.  To avoid this, the application can indicate a batch of Send actions through the API.  When this is used, the  <ins> implementation can defer the processing of Messages until the batch </ins> is complete. 5.2.