Draft: draft-ietf-taps-arch

Commentary: I propose this diff instead — just indent Transport Properties where it is , as a sub - part of Preconnection : 
 Tried that … looks strange : 
 eh ... it looks a little odd but it is technically more correct . 
 So the whole point of this text is to introduce the term Transport Properties I think . Otherwise we could have just removed it as the three kinds are described in detail in later sections . Perhaps we can just insert this as running text at the end of the Preconnection description instead to make it look less awkward . Something like : Selection Properties ( Section 4.1.2 ) can only be specified as part of a Preconnection . Connection Properties ( Section 4.1.2 ) may also be specified as part of a Preconnection , but may also be changed on the Connection . Together with Message Properties ( Section 4.1.4 ) , which can also be specified during data transfer to affect specific Messages , they are the three kinds of Transport Properties that an application can specify to configure the Transport System and express its requirements , prohibitions , and preferences . 
 I double - checked with the interface : there . transport properties are also an object that is passed to the preconnection and that can retrieved from a connection . Therefore , I made it a Connection Object and slightly rephrased the text . Does this work better ? 
 This is very similar to where we started I think , so did not help much for me unfortunately . I still do not think it fits as a Connection Object on the same level as the rest . What did you think about my suggestion to introduce it in running text as part of the description of the Preconnection ? 
 I thought about your suggestion , but my problem with that is that Transport Properties are actually : actual Object in the API used for introspecting and manipulating   , putting them into the Preconnection seems wrong to me . 
 In 4.1.1 Connection Objects we have Transport Properties as one of the bullets . But Transport Properties are not Connection Objects so this text does not really belong in this section . I suggest to move it to the next section on Pre - Esatblishment where we also describe Selection / Connection Properties or Change the name of Section 4.1.1 . 
 Agreed , this rearrangement is not great , but I do n't like any of the alternatives either .
Paragraph (version A):
Preconnection: A Preconnection object is a representation of a
potential connection.  It has state that describes parameters of a
Connection that might exist in the future: the Local Endpoint from
which that Connection will be established, the Remote Endpoint
(preestablishment) to which it will connect, and Selection
Properties (preestablishment) that influence the paths and
protocols a Connection will use.  A Preconnection can be fully
specified such that it represents a single possible Connection, or
it can be partially specified such that it represents a family of
possible Connections.  The Local Endpoint (preestablishment) MUST
be specified if the Preconnection is used to Listen for incoming
connections.  The Local Endpoint is OPTIONAL if it is used to
Initiate connections.  The Remote Endpoint MUST be specified in
the Preconnection that is used to Initiate connections.  The
Remote Endpoint is OPTIONAL if it is used to Listen for incoming
connections.  The Local Endpoint and the Remote Endpoint MUST both
be specified if a peer-to-peer Rendezvous is to occur based on the
Preconnection.
Paragraph (version B):
Preconnection: A Preconnection object is a representation of a
potential connection.  It has state that describes parameters of a
Connection that might exist in the future: the Local Endpoint from
which that Connection will be established, the Remote Endpoint
(preestablishment) to which it will connect, and Transport
Properties that influence the paths and protocols a Connection
will use.  A Preconnection can be fully specified such that it
represents a single possible Connection, or it can be partially
specified such that it represents a family of possible
Connections.  The Local Endpoint (preestablishment) MUST be
specified if the Preconnection is used to Listen for incoming
connections.  The Local Endpoint is OPTIONAL if it is used to
Initiate connections.  The Remote Endpoint MUST be specified in
the Preconnection that is used to Initiate connections.  The
Remote Endpoint is OPTIONAL if it is used to Listen for incoming
connections.  The Local Endpoint and the Remote Endpoint MUST both
be specified if a peer-to-peer Rendezvous is to occur based on the
Preconnection.
Paragraph (version A):
and Message Properties (datatransfer); note that Message
Properties can also be specified during data transfer to affect
specific Messages.
Paragraph (version B):
Selection Properties (preestablishment) that can only be
specified on a Preconnection.
Paragraph (version B):
Connection Properties (preestablishment) that may be changed on
the Connection.
Paragraph (version B):
Message Properties (datatransfer) that can also be specified
during data transfer to affect specific Messages.