Draft: draft-ietf-taps-interface

Commentary: This merges Message References with the Message Context ( and adds a reply call to the Message Context to enable the transport system to assign a response to the same underlying transport the request was received on . This is another result of the discussion around PR and implements most o the API part for 
 The technical idea behind this PR is fine IMO ; though I agree with that the messageContext parameter could be used instead of adding an extra parameter . 
 I agree with that linking replies with requests should be better done using the message context . However , this requires answering some design questions : Should one be able to pass the message context from a message we received to the send of the reply ? This would be really elegant , but may limit implementations . Should the returned by send really be an opaque identifier ( as specified in this request ) or should it me a message context object ? If we answer both with yes , I am happy to write more text in message contexts , otherwise , I am happy to move setting the request - reference to the message context . 
 I updated the PR to address comments . merged the functionality of msgRef ( which was not described anyway ) into the Message Context . merged send and receive Message Context . realised the reply functionality using the Message Context . clarified what the the Message Context is / does Sorry for the force pushes , I accidentally fixed too many whitespace errors . 
 I did a merge and update pass to address comments and also a way to get the original request 's Message Context from the reply 's MessageContext 
 Agreed , but this is not a problem introduced by the PR , but that existed before for the and the MessageContext object . Making the returned value a MessageContext object and clarifying that the MessageContexts used in and are the same kind of object improves this in my opinion , but may in fact not be sufficient . The question is whether we need to fix this in this PR or ( if there are no other things blocking this ) should merge the PR and do the cleanup in a separate PR . 
 - should we press the Merge button on this one ? 
 I 'd like to hear the response for returning a message from Send ... I 'm OK to merge , but would want an issue to revisit that point . 
 In the interface draft ,  is part of 4 callbacks ( RendezvousError , Sent , Expired and SendError ) , however it is never mentioned what  is . As the Send action does not have any return value it is also unclear how the application is actually supposed to know what  references to . 
 I 'm fine with this - I tend to think that the right thing to do is to merge in this PR now , and then fix afterwards if there 's something left that needs fixing .
Paragraph (version B):
where messageData is the data object to send.
Paragraph (version B):
The optional messageContext parameter supports per-message properties
and is described in message-props.  If provided, the Message Context
object returned is identical to the one that was passed.
Paragraph (version B):
The optional endOfMessage parameter supports partial sending and is
described in send-partial.
Paragraph (version B):
The MessageContext returned by Send 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.
Paragraph (version B):
Note that message properties are per-Message, not per-Send if partial
Messages are sent (send-partial).  All data blocks associated with a
single Message share properties specified in the Message Contexts.
For example, it would not make sense to have the beginning of a
Message expire, but allow the end of a Message to still be sent.
Paragraph (version B):
A Received event indicates the delivery of a complete Message.  It
contains two objects, the received bytes as messageData, and the
metadata and properties of the received Message as messageContext.
Paragraph (version B):
Most Message Framers fall into one of two categories: - Header-
prefixed record formats, such as a basic Type-Length-Value (TLV)
structure - Delimeter-separated formats, such as HTTP/1.1.