Draft: draft-ietf-taps-impl

Commentary: Capitalization seems to be a problem for us . We need to make things uniform . At first , I reacted to seeing " connection " as parameters in this PR , because we use the term " Connection " to refer to a TAPS - provided connection ( as opposed to a connection of the underlying system ) , and so , de - capitalizing the term here may look better , but it is also somewhat imprecise . This said , we do the same with other capitalized terms too , here and in the API draft - e.g. , " messageContext " . Should we generally agree to begin terms with a lowercase letter when they are used as parameters in code examples ? I think we have this in most places , though at least the API draft has several counterexamples ... e.g. , the server example code : Preconnection : = NewPreconnection(LocalSpecifier , TransportProperties , SecurityParameters ) ( .. )  -ConnectionReceived < Connection 
 From discussion on 
 This was a mistake . As I wanted to do this now , I noticed that all occurrences of capitalized terms as parameters are objects that are defined and used elsewhere in the code examples . For example : Preconnection : = NewPreconnection(RemoteSpecifier , TransportProperties , SecurityParameters ) refers to  etc . , being objects that are initialized some lines above . Making them appear in lower case everywhere would be awkward , this is then a much more drastic change to our pseudocode . As a result , I think it 's fine to leave things as they are , and I suggest to close this issue with no action . 
 Framers : What is the difference between the Final message property and the separate IsEndOfMessage event argument ? 
 Also there , the term MessageContext could use a definition 
 and searching " isEndOfMessage " tells me that there is no text describing this parameter . Regarding the question , the difference should be clear : seems self - explanatory , whereas indicates that the Message carrying it is the last one of the Connection . So , this is End of the Message vs. End of the Connection . 
 Sounds like this needs a reference to the API doc , and change IsEndOfMessage to endOfMessage to match the API . 
 Probably fix with 
 I think this looks ok ( and thanks for doing this ! ) , but see also my comment about making things uniform wrt . capitalization : if we merge this PR , we should also do one that does the same with the API draft . Thanks LGTM ! Although I noticed another nit that can perhaps be fixed in the same PR even if not directly related to the parameter names . Regarding the capitalization I think we can merge this PR and then have a separate issue for the capitalization as we will need to fix this either way .
Paragraph (version A):
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):
Once the framer implementation has completed its setup or handshake,
it can indicate to the application that it is ready to handling data
with this call.
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 call.
Paragraph (version A):
Message Framers generate an event whenever a Connection sends a new
Message.
Paragraph (version B):
Message Framers generate an event whenever a Connection sends a new
Message.  The parameters to the event align with the Send call in the
API (Section 9.2 of I-D.ietf-taps-interface).
Paragraph (version A):
In order to parse a received flow of data into Messages, the Message
Framer notifies the framer implementation whenever new data is
available to parse.
Paragraph (version B):
In order to parse a received flow of data into Messages, the Message
Framer notifies the framer implementation whenever new data is
available to parse.  The parameters to the the events and calls for
receiving data with a framer align with the Receive call in the API
(Section 9.3 of I-D.ietf-taps-interface).