Change:
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 <del> (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 </del> <ins> (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 </ins> 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

Discussion:
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?
NAME I thought about your suggestion, but my problem with that is that Transport Properties are actually: An actual Object in the API Also used for introspecting and manipulating Connections Therefore, 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 don't like any of the alternatives either.