Draft: draft-trammell-taps-interface

Commentary: This ends my promised pass - I hope that in particular the app intents people can take a look at some of my comments ( I wrote them inline as [ MICHAEL : blabla ] ) 
 changed base to master since landed
Paragraph (version A):
There need to be sensible defaults for the Transport Preferences.
There need to be sensible defaults for the Protocol Selection
Properties.  The defaults given in the following section represent a
configuration that can be implemented over TCP.  An alternate set of
default Protocol Selection Properties would represent a configuration
that can be implemented over UDP.
Paragraph (version B):
There need to be sensible defaults for the Transport Preferences as
well as Protocol Selection Properties.  The defaults given in the
following section represent a configuration that can be implemented
over TCP.  An alternate set of default Protocol Selection Properties
would represent a configuration that can be implemented over UDP.
Paragraph (version A):
Request not to delay acknowledgment (SACK) of Content: This
boolean property specifies whether an application considers it
useful to request for Content that its acknowledgment be sent out
as early as possible (SACK) instead of potentially being bundled
with other acknowledgments.  This property applies to connections
and connection groups.  This is not a strict requirement.  The
default is to not have this option.
Paragraph (version B):
Request not to delay acknowledgment of Content: This boolean
property specifies whether an application considers it useful to
request for Content that its acknowledgment be sent out as early
as possible instead of potentially being bundled with other
acknowledgments.  This property applies to connections and
connection groups.  This is not a strict requirement.  The default
is to not have this option.
Paragraph (version A):
Use Connection Groups with priorities: This boolean property
specifies whether an application considers it useful to create
Connection Groups and explicitly prioritize between Connections
within a Connection Group.
Paragraph (version B):
Use Connection Groups with priorities: This boolean property
specifies whether an application considers it useful to create
Connection Groups and explicitly prioritize between Connections
within a Connection Group.  This is not a strict requirement.  The
default is to not have this option.
Paragraph (version A):
This Intent specifies what the application expects the size of a
transfer to be.  It is a numeric property and given in Bytes.  This
Intent can also apply to individual Content.
Paragraph (version A):
This Intent specifies what delay characteristics the applications
prefers.  It provides hints for the transport system whether to
optimize for low latency or other criteria.  Note that setting this
Intents does not imply any guarantees on whether an application's
requirements can actually be satisfied.  This Intent can also apply
to individual Content.
Paragraph (version A):
This Intent describes what an application knows about its own ability
to deal with disruption of its communication, e.g., connection loss.
It provides hints of how well an application assumes it can recover
from such disturbances and can have an impact on the trade-off
between providing failover techniques and resource utilization.  This
Intent can also apply to individual Content.
Paragraph (version A):
The default is "Sensitive".
Paragraph (version A):
All transport parameters used in the pre-establishment phase are
collected in a TransportParameters object that is passed to the
Preconnection object.  For the sake of convenience, we suggests
implementing TransportParameters class as sub-class of an existing
Dictionary or Set class to allow in-place notion of Transport
Parameters.
Paragraph (version B):
All transport parameters used in the pre-establishment phase are
collected in a TransportParameters object that is passed to the
Preconnection object.
Paragraph (version B):
Note that most properties are only considered for connection
establishment and can not be changed later on. appendix-specify-
query-params gives an overview of what Transport Parameters can be
specified and queried during which phase.
Paragraph (version B):
Note that priority assignment ((see also groups for more details) is
not shared among cloned connections.  Therefore, the priority
assignment MUST NOT be realized using the connection level
TransportParameters object.
Paragraph (version B):
The Ready event occurs after Initiate has established a transport-
layer connection on at least one usable candidate Protocol Stack over
at least one candidate Path.  No Receive events (see receiving) will
occur before the Ready event for connections established using
Initiate.
Paragraph (version B):
An RendezvousError occurs when...
Paragraph (version A):
A SendError occurs when Content could not be sent due to an error
condition: some failure of the underlying Protocol Stack, or a set of
send parameters not consistent with the Connection's transport
parameters.
Paragraph (version A):
If Send Parameters should be overridden for a specific content, an
empty sent parameter Object can be acquired and all desired Send
Parameters can be added to that object.  A Send Parameters object can
be reused for sending multiple contents with the same properties.
Paragraph (version A):
The Send Parameters are organized in _Content Properties_, _Protocol
Properties_, and _Application Intents_.  The Send Parameters share a
single namespace with the Transport Parameters (see transport-
params).  This allows to specify Protocol Properties and that can be
overridden on a per content basis or Application Intents that apply
to a specific content.  See appendix-specify-query-params for an
overview.
Paragraph (version B):
A SendError occurs when Content could not be sent due to an error
condition: some failure of the underlying Protocol Stack, or a set of
send parameters not consistent with the Connection's transport
parameters.  The SendError contains an implementation-specific
reference to the Content to which it applies.
Paragraph (version B):
If Send Parameters should be overridden for a specific content, an
empty sent parameter Object can be acquired and all desired Send
Parameters can be added to that object.  A sendParameters object can
be reused for sending multiple contents with the same properties.
Paragraph (version B):
The Send Parameters are organized in _Content Properties_ and
_Application Intents_.  The Send Parameters share a single namespace
with the Transport Parameters (see transport-params).  This allows to
specify Protocol Properties and that can be overridden on a per
content basis or Application Intents that apply to a specific
content.  See appendix-specify-query-params for an overview.
Paragraph (version A):
This numeric property specifies the length of the checksum to be used
on the Content.  A value of 0 means that no checksum is required, and
a special value (e.g. -1) can be used to indicate full checksum
coverage (which is also the default).  Only full coverage is
guaranteed, any other requests are advisory.
Paragraph (version A):
On a bi-directional connection, this Intent specifies what amount of
data the application expects to receive in reply to the content sent.
It is a numeric property and given in Bytes.
Paragraph (version A):
This Intent specifies what bitrate the application wishes the content
to be sent with.  This is useful as input for any transport that does
packet pacing.  It is a numeric property and given in Bytes per
second.
Paragraph (version A):
On a bi-directional connection, this Intent specifies what bitrate
the application expects to receive in reply to the content sent.  It
is a numeric property and given in Bytes per second.
Paragraph (version B):
This numeric property specifies the length of the section of content,
starting from byte 0, that the application assumes will be received
without corruption due to lower layer errors.  It is used to specify
options for simple integrity protection via checksums.  By default,
the entire Content is protected by checksum.  A value of 0 means that
no checksum is required, and a special value (e.g. -1) can be used to
indicate the default.  Only full coverage is guaranteed, any other
requests are advisory.
Paragraph (version B):
This boolean property specifies, if true, that an application wants
this Content to be acknowledged immediately by the receiver.  In case
of reliable transmission, this informs the transport protocol on the
sender side faster that it can remove the Content from its buffer;
therefore this property can be useful for latency-critical
applications that maintain tight control over the send buffer (see
sending).
Paragraph (version B):
The Closed event can inform the application that the peer has closed
the Connection; however, there is no guarantee that a remote close
will be signaled.