Draft: draft-ietf-taps-interface

Commentary: Interface , section 4.1.2 : Why the limitation to aliases ? Specifying a protocol might limit the utility of connection racing , so should perhaps be discouraged , but does it break anything to specify a protocol for a non - alias Endpoint ? 
 Interim : suggest to remove the second sentence . 
 They are currently just called " Table " 
 In the interface draft , Section 1.1 : Where is the event sent ? Perhaps ? 
 Interim : add " to the application " ( but double check , related to framers ) 
 Could alternatively say the same another way around : " Applications can use these events ... " ( i.e. avoid saying only applications do this ) . 
 Section 6 in impl - draft has the parts where the framer objects receive events . There is no terminology section in implementation , so not sure if the terminology section in API should cover it as well . 
 We already say this in the intro text to this section , but I can tweak the structure and add some additional text to make this more clear . 
 The appendix text about convenience functions talks about " implementations should " provide various things . This reads strangely to me . I think these are not requirements and the text should be more in the form of it can be useful for implementations to provide various things . 
 How about : " implementations can provide special actions for adding each preference level i.e , TransportProperties . Set(someproperty , avoid ) would be equivalent to TransportProperties . Avoid(someproperty ): ... " 
 EstablishmentError . Fixed in an upcoming PR .
Paragraph (version A):
This API is described in terms of Objects with which an application
can interact; Actions the application can perform on these Objects;
Events, which an Object can send to an application asynchronously;
and Parameters associated with these Actions and Events.
Paragraph (version B):
Parameters associated with these Actions and Events.
Paragraph (version B):
Events are sent to the application or application-supplied code (e.g.
framers, see framing) for processing; the details of event processing
are platform- and implementation-specific.
Paragraph (version A):
In order to scope an alias to a specific transport protocol, an
Endpoint can specify a protocol identifier.  These identifiers MUST
only be set for aliases.
Paragraph (version B):
In order to scope an alias to a specific transport protocol, an
Endpoint can specify a protocol identifier.
Paragraph (version A):
The Events that may be sent after InitiateWithSend() are equivalent
to those that would be sent by an invocation of Initiate() followed
immediately by an invocation of Send(), with the caveat that a send
failure that occurs because the Connection could not be established
will not result in a SendError separate from the InitiateError
signaling the failure of Connection establishment.
Paragraph (version B):
The Events that may be sent after InitiateWithSend() are equivalent
to those that would be sent by an invocation of Initiate() followed
immediately by an invocation of Send(), with the caveat that a send
failure that occurs because the Connection could not be established
will not result in a SendError separate from the EstablishmentError
signaling the failure of Connection establishment.
Paragraph (version A):
InitiateError<> occurs when a Connection created with Initiate()
transitions from Establishing state to Closed state due to an
error.
Paragraph (version B):
EstablishmentError<> occurs when a Connection created with
Initiate() transitions from Establishing state to Closed state due
to an error.
Paragraph (version A):
No events will occur on a Connection after it is Closed; i.e.,
after a Closed<> event, an InitiateError<> or ConnectionError<>
will not occur on that connection.  To ensure this ordering,
Closed<> will not occur on a Connection while other events on the
Connection are still locally outstanding (i.e., known to the
interface and waiting to be dealt with by the application).
Paragraph (version B):
No events will occur on a Connection after it is Closed; i.e.,
after a Closed<> event, an EstablishmentError<> or
ConnectionError<> will not occur on that connection.  To ensure
this ordering, Closed<> will not occur on a Connection while other
events on the Connection are still locally outstanding (i.e.,
known to the interface and waiting to be dealt with by the
application).