Change:
be specified if a peer-to-peer Rendezvous is to occur based on the Preconnection. <del> Transport Properties: Transport Properties can be specified as part of a Preconnection to allow the application to configure the Transport System and express their requirements, prohibitions, and preferences.  There are three kinds of Transport Properties: </del> <ins> Transport Properties: Transport Properties allow the application to express their requirements, prohibitions, and preferences and configure the Transport System.  There are three kinds of Transport Properties: </ins> <del> Selection Properties (preestablishment) </del> <ins> Selection Properties (preestablishment) that can only be specified on a Preconnection. </ins> <del> Connection Properties (preestablishment) </del> <ins> Connection Properties (preestablishment) that may be changed on the Connection. </ins> <del> and Message Properties (datatransfer); note that Message Properties can also be specified during data transfer to affect specific Messages. </del> <ins> Message Properties (datatransfer) that can also be specified during data transfer to affect specific Messages. </ins> Connection: A Connection object represents one or more active transport protocol instances that can send and/or receive Messages

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.