Draft: draft-ietf-taps-interface

Commentary: I think this discussion has converged and found a happy ending .
Paragraph (version A):
This specification treats Events and errors similarly.  Errors, just
as any other Events, may occur asynchronously in network
applications.  However, it is recommended that implementations of
this interface also return errors immediately, according to the error
handling idioms of the implementation platform, for errors that can
be immediately detected, such as inconsistency in Transport
Properties.  Errors can provide an optional reason to give the
application further details as to why the error occured.
Paragraph (version B):
This specification treats Events and errors similarly.  Errors, just
as any other Events, may occur asynchronously in network
applications.  However, it is recommended that implementations of
this interface also return errors immediately, according to the error
handling idioms of the implementation platform, for errors that can
be immediately detected, such as inconsistency in Transport
Properties.  Errors can provide an optional reason to give the
application further details as to why the error occurred.
Paragraph (version A):
Transport Properties are divided into Selection, Connection, and
Message Properties.  During pre-establishment, Selection Properties
(see selection-props) are used to specify which paths and protocol
stacks can be used and are preferred by the application, and
Connection Properties (see connection-props) can be used to influence
decisions made during establishment and to fine-tune the eventually
established connection.  These Connection Properties can also be used
later, to monitor and fine-tune established connections.  The
behavior of the selected protocol stack(s) when sending Messages is
controlled by Message Properties (see message-props).
Paragraph (version B):
Transport Properties are divided into Selection, Connection, and
Message Properties.  Selection Properties (see selection-props) can
only be set during pre-establishment.  They are only used to specify
which paths and protocol stacks can be used and are preferred by the
application.  Connection Properties (see connection-props) can also
be set during pre-establishment but may be changed later.  They are
used to inform decisions made during establishment and to fine-tune
the established connection.
The behavior of the selected protocol stack(s) when sending Messages
is controlled by Message Properties (see message-props).
Paragraph (version A):
Note that configuring Connection Properties and Message Properties on
Preconnections is preferred over setting them later.  Early
specification of Connection Properties allows their use as additional
input to the selection process.  Protocol Specific Properties, which
enable configuration of specialized features of a specific protocol,
see Section 3.2 of I-D.ietf-taps-arch, are not used as an input to
the selection process but only support configuration if the
respective prototocol has been selected.
Paragraph (version B):
Note that configuring Connection Properties and Message Properties on
Preconnections is preferred over setting them later.  Early
specification of Connection Properties allows their use as additional
input to the selection process.  Protocol Specific Properties, which
enable configuration of specialized features of a specific protocol,
see Section 3.2 of I-D.ietf-taps-arch, are not used as an input to
the selection process but only support configuration if the
respective protocol has been selected.
Paragraph (version B):
Transport Properties MUST always be specified while security
parameters are OPTIONAL.
Paragraph (version A):
The identification of a specific Provisioning Domain (PvD) is defined
to be implementation- and system-specific, since there is not a
portable standard format for a PvD identitfier.  For example, this
identifier may be a string name or an integer.  As with requiring
specific interfaces, requiring a specific PvD strictly limits path
selection.
Paragraph (version B):
The identification of a specific Provisioning Domain (PvD) is defined
to be implementation- and system-specific, since there is not a
portable standard format for a PvD identifier.  For example, this
identifier may be a string name or an integer.  As with requiring
specific interfaces, requiring a specific PvD strictly limits path
selection.
Paragraph (version A):
Once Initiate is called, the candidate Protocol Stack(s) may cause
one or more candidate transport-layer connections to be created to
the specified remote endpoint.  The caller may immediately begin
sending Messages on the Connection (see sending) after calling
Initate(); note that any idempotent data sent while the Connection is
being established may be sent multiple times or on multiple
candidates.
Paragraph (version B):
Once Initiate is called, the candidate Protocol Stack(s) may cause
one or more candidate transport-layer connections to be created to
the specified remote endpoint.  The caller may immediately begin
sending Messages on the Connection (see sending) after calling
Initiate(); note that any idempotent data sent while the Connection
is being established may be sent multiple times or on multiple
candidates.
Paragraph (version A):
Like all Actions in this interface, the Send Action is asynchronous.
There are several Events that can be delivered in response to Sending
a Message.  Exactly one Event (Sent, Expired, or SendError) will be
delivered in reponse to each call to Send.
Paragraph (version B):
Like all Actions in this interface, the Send Action is asynchronous.
There are several Events that can be delivered in response to Sending
a Message.  Exactly one Event (Sent, Expired, or SendError) will be
delivered in response to each call to Send.
Paragraph (version A):
The Events that may be sent after InitiateWithSend() are equivalent
to those that would be sent by an invocation of Initate() 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 InitiateError
signaling the failure of Connection establishment.