Change:
specific PvD instances or interface instances, and should be preferred over these options. <ins> 5.2.10. This property specifies whether an application wants to use the connection for sending and/or receiving data.  Possible values are: The connection must support sending and receiving data The connection must support sending data The connection must support receiving data In case a unidirectional connection is requested, but unidirectional connections are not supported by the transport protocol, the system should fall back to bidirectional transport. </ins> 5.3. Most security parameters, e.g., TLS ciphersuites, local identity and

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!