Draft: draft-ietf-taps-impl

Commentary: Just some points about the new text on framers in the API draft : In 10.2 it is specified in which order multiple framers run on incoming and outgoing messages , it is however never specified what the order looks like on Start and Stop events . In 10.6 , "  . DeliverAndAdvanceReceiveCursor " appears to be missing the " Data " argument that is present in " MessageFramer . Deliver " . Also in 10.6 , in the second paragraph it says : When it is probably meant to say While the framer implementation is able to notify the Connection that it has finished handling a Start event ( by calling  . MakeConnectionReady ) , there is no such way for Stop events . 
 As notes for the responses to these points : If there are multiple framers , the " lowest " one ( the one closest to the transport ) would receive start first , and the next would get the start event when the lower one is ready . Similar for stop . Good calls on the missing data argument and the typo re application vs framer . I was thinking to use the failConnection call to complete a stop , potentially with no error ?
Paragraph (version A):
Common Message Framers can be provided by the Transport Services
implementation, but an implemention ought to allow custom Message
Framers to be defined by the application or some other piece of
software.  This section describes one possible interface for defining
Message Framers as an example.
Paragraph (version B):
Common Message Framers can be provided by the Transport Services
implementation, but an implementation ought to allow custom Message
Framers to be defined by the application or some other piece of
software.  This section describes one possible interface for defining
Message Framers as an example.
Paragraph (version B):
Similarly, when a Message Framer generates a "Stop" event, the framer
implementation has the opportunity to write some final data or clear
up its local state before the "Closed" event is delivered to the
Application.  The framer implementation can indicate that it has
finished with this.
Paragraph (version B):
Should the framer implementation deem the candidate selected during
racing unsuitable it can signal this by failing the Connection prior
to marking it as ready.  If there are no other candidates available,
the Connection will fail.  Otherwise, the Connection will select a
different candidate and the Message Framer will generate a new
"Start" event.
Paragraph (version A):
Upon receiving this event, a framer implementation is responsible for
performing any necessary transformations and sending the resulting
data to the next protocol.  Implementations SHOULD ensure that there
is a way to pass the original data through without copying to improve
performance.
Paragraph (version B):
Upon receiving this event, a framer implementation is responsible for
performing any necessary transformations and sending the resulting
data back to the Message Framer, which will in turn send it to the
next protocol.  Implementations SHOULD ensure that there is a way to
pass the original data through without copying to improve
performance.
Paragraph (version A):
To deliver a Message to the application, the framer implementation
can either directly deliever data that it has allocated, or deliver a
range of data directly from the underlying transport and
simulatenously advance the receive cursor.
Paragraph (version B):
To deliver a Message to the application, the framer implementation
can either directly deliver data that it has allocated, or deliver a
range of data directly from the underlying transport and
simultaneously advance the receive cursor.