Draft: draft-ietf-taps-interface

Commentary: Tentatively answering my own questions in : Removed the messageContext here because the RendezvousError does not necessarily relate to a specific sent Message . If it does , the " reason " parameter can point to that message and/or a messageContext . The beginning of Section 7 actually already said that this IS the messageContext . I removed the word " implementation - specific " because to me this word made it sound like this reference ca n't be the messageContext . Split into two sentences and changed the second sentence to active voice . Also , I slightly reworded the beginning of Section 7 , which is now a bit clearer in my opinion . 
 When reading the current API draft , I found three minor issues related to Message Contexts . The RendezvousError ( Section 6.3 ) includes a messageContext ( which is even required ) , but neither the InitiateError nor the ListenError include one . Why ? Should this messageContext at least be optional?In Section 7.3 , it says " The Sent Event contains an implementation - specific reference to the Message to which it applies . " - Is this in addition to the messageContext ? If yes , why do we need both?In Section 9 , it says " To get or set Message Properties , the optional scope parameter is left empty , for framing meta - data , the framer is passed . " - I think this sentence is a bit hard to parse and it was n't immediately obvious to me what kind of framing meta - data this refers to . Perhaps this refers to Section 10.2 , so I think it 's worth adding a reference to that section here . Also , I suggest turning this into two sentences , with the sentence on framing meta - data specifying that this is per - Message metadata to be used by the framer . 
 Thanks a lot for doing this ! It clears things up nicely , I think .
Paragraph (version A):
The optional messageContext parameter supports per-message properties
and is described in message-props.  It can be used to identify send
events (see send-events) related to a specific message or to inspect
meta-data related to the message sent (see msg-ctx).
Paragraph (version B):
The optional messageContext parameter allows adding Message
Properties as described in message-props.  Moreover, the
messageContext can be used to identify Send Events related to a
specific Message (see send-events) or to inspect meta-data related to
the Message sent (see msg-ctx).
Paragraph (version A):
The Sent Event occurs when a previous Send Action has completed,
i.e., when the data derived from the Message has been passed down or
through the underlying Protocol Stack and is no longer the
responsibility of this interface.  The exact disposition of the
Message (i.e., whether it has actually been transmitted, moved into a
buffer on the network interface, moved into a kernel buffer, and so
on) when the Sent Event occurs is implementation-specific.  The Sent
Event contains an implementation-specific reference to the Message to
which it applies.
Paragraph (version B):
The Sent Event occurs when a previous Send Action has completed,
i.e., when the data derived from the Message has been passed down or
through the underlying Protocol Stack and is no longer the
responsibility of this interface.  The exact disposition of the
Message (i.e., whether it has actually been transmitted, moved into a
buffer on the network interface, moved into a kernel buffer, and so
on) when the Sent Event occurs is implementation-specific.  The Sent
Event contains a reference to the Message to which it applies.
Paragraph (version A):
The Expired Event occurs when a previous Send Action expired before
completion; i.e. when the Message was not sent before its Lifetime
(see msg-lifetime) expired.  This is separate from SendError, as it
is an expected behavior for partially reliable transports.  The
Expired Event contains an implementation-specific reference to the
Message to which it applies.
Paragraph (version B):
The Expired Event occurs when a previous Send Action expired before
completion; i.e. when the Message was not sent before its Lifetime
(see msg-lifetime) expired.  This is separate from SendError, as it
is an expected behavior for partially reliable transports.  The
Expired Event contains a reference to the Message to which it
applies.
Paragraph (version A):
A SendError occurs when a Message could not be sent due to an error
condition: an attempt to send a Message which is too large for the
system and Protocol Stack to handle, some failure of the underlying
Protocol Stack, or a set of Message Properties not consistent with
the Connection's transport properties.  The SendError contains an
implementation-specific reference to the Message to which it applies.
Paragraph (version B):
A SendError occurs when a Message could not be sent due to an error
condition: an attempt to send a Message which is too large for the
system and Protocol Stack to handle, some failure of the underlying
Protocol Stack, or a set of Message Properties not consistent with
the Connection's transport properties.  The SendError contains a
reference to the Message to which it applies.
Paragraph (version A):
To get or set Message Properties, the optional scope parameter is
left empty, for framing meta-data, the framer is passed.
Paragraph (version B):
To get or set Message Properties, the optional scope parameter is
left empty.  To get or set meta-data for a Framer, the application
has to pass a reference to this Framer as the scope parameter.