Change:
a per-Message basis using the Transmission Profile Message Property; see send-profile. <ins> 9.1.13. This property specifies an upper-bound rate that a transfer is not expected to exceed (even if flow control and congestion control allow higher rates), and/or a lower-bound rate below which the application does not deem a data transfer useful.  It is given in bits per second. 9.1.14. This property specifies, for the case TCP becomes the chosen transport protocol: a time value to be advertised via the User Timeout Option (UTO) for the TCP at the remote endpoint to adapt its own "Timeout for aborting Connection" (see {#conn-timeout}) value accordingly a boolean (default false) to control whether the UTO option is enabled for a connection.  This applies to both sending and receiving. a boolean (default true) which controls whether the "Timeout for aborting Connection" (see {#conn-timeout}) may be changed based on a UTO option received from the remote peer.  This boolean becomes false when "Timeout for aborting Connection" (see {#conn-timeout}) is used. All of the above parameters are optional (e.g., it is possible to specify "User Timeout Enabled" as true, but not specify an Advertised User Timeout value; in this case, the TCP default will be used). </ins> 9.2. Asynchronous introspection is also possible, via the SoftError Event.

Discussion:
This does the following things with the properties from the appendix, based on URL direction of communication: moved to the main text "Suggest a timeout to the Remote Endpoint": moved to the main text but explicitly described as a TCP-specific property; also changed it to contain all the parameters that UTO really has traffic category: removed. Mirja said "Let's see if there's anything in the implementation document that actually needs this information" but I figured that chances are low, and if this really happens we can still re-introduce this later. size to be sent or received: removed duration: removed send or receive bit-rate: changed this to specify an upper and/or lower bound cost preferences: kept in the appendix, but inserted mirja's comment "Not convinced cost preferences are on the right level." (NAME what did you mean with "on the right level"?)
Cost doesn't seem to mean too much for the transport layer. I guess it could e.g. make more sense to specified which link technology you prefer (e.g. wifi over cellular) (which would be on a less abstract level). However, still not sure what the right level is...
I'm not so keen on specifying link technology - a transport only knows the local link - and that can be very different to the technology of the path bottleneck. Maybe cost isn't that bad - sometimes the presence of cost IS known, or at least a decision could try to be made to minimise cost. It's hard to do more than hint at this.
Thinking about cost prefernce a bit further and with respect to NAME comment that this could part of an layer on top of taps, I would prefer to not include it expect we have some concrete implementation example guidance in the implementation draft.
NAME that all sounds very reasonable to me, thanks for clarifying! So it seems fit where the cost preferences are now in this PR - I left them in the appendix for now, with a mark saying that we'll see if there will suitable text in the implementation draft.
Thanks for doing this! I have just two suggestions about what section to place the properties in. About the Cost Preferences discussion, I think having both this and the less abstract interface preference in there makes sense, and then the implementation can map those properties to each other.

The alternative would be to make this part of the "layer on top of the TAPS API", which some of the other Intents would end up on as well. If we do this, I think it might make sense to keep the other Intents in the appendix for now (instead of deleting them like this PR does).lgtm!