Code change:
more. connection-props provides a list of Connection Properties, while <del> Selection Properties are listed in the subsections below.  Many properties are only considered during establishment, and can not be changed after a Connection is established; however, they can still be queried.  The return type of a queried Selection Property is Boolean, where "true" means that the Selection Property has been applied and "false" means that the Selection Property has not been applied.  Note that "true" does not mean that a request has been honored.  For example, if "Congestion control" was requested with preference level "Prefer", but congestion control could not be supported, querying the "congestionControl" property yields the value "false".  If the preference level "Avoid" was used for "Congestion control", and, as requested, the Connection is not congestion controlled, querying the "congestionControl" property also yields the value "false". </del> <ins> Selection Properties are listed in the subsections below.  Selection Properties are only considered during establishment, and can not be changed after a Connection is established.  After a Connection is established, Selection Properties can only be read to check the properties used by the Connection.  Upon reading, the Preference type of a Selection Property changes into Boolean, where "true" means that the selected Protocol Stack supports the feature or uses the path associated with the Selection Property, and "false" means that the Protocol Stack does not support the feature or use the path. Implementations of Transport Services systems may alternatively use the two Preference values "Require" and "Prohibit" to represent "true" and "false", respectively. </ins> An implementation of the Transport Services API must provide sensible defaults for Selection Properties.  The default values for each

Related discussion:
text: Perhaps we could rephrase this part of the API draft to use that terminology, e.g., the application can query the actually used protocol stack and then know which Transport Features it supports. I would strongly prefer using our existing terminology to introducing yet another term. Good question. I vaguely remember discussing this, and I think folks felt like querying the Selection Properties that the application had set was not very useful at that stage. The other text you quoted indeed sounds a bit complicated and maybe it can be reworded to be clearer. Curious to hear what my co-authors and/or other TAPS participants think!
I completely second what NAME wrote. With regards to querying the Transport Features selected vs. getting the preferences provided earlier, I remember we had lengthy discussions and somewhat converged to the current state. Primary arguments ware Multiple read/query variants are confusing Original Preferences are not really useful - if you really want to read them later, keep the Preferences Object Constrained implementations don't want to be forced to store them. NAME based on these arguments, what option would you prefer a) different get/query operations of selection properties after the connection has been set up b) the current way of "mutating" preferences with clearer description in the text
Just to add: having finally gotten around to carefully reading this, I also completely agree with everything NAME wrote. This is exactly how I would have answered, and her suggestions are exactly what I think should be done to address these comments. I also agree with NAME that these were the arguments regarding querying the querying issue, and I agree with the arguments as well. The quoted text containing the example is a great catch! Such a terribly convoluted paragraph. I have a nagging feeling that this was my fault! :-(
PR tries to solve this; the PR itself contains a full explanation of my rationale for the changes. Please take a look!
Great, this looks good to me now. I think now it is simple enough that we don't need an example anymore.Looks good, one clarification suggestedWorks for me (with NAME changes). I would propose a slight rewording -> and add a hint that this exposing can also be implemented differently.