Change:
I was about to change this must to MUST, however, MUST and "sensible" doesn't work well together, so I proposed this recommendation instead.
I wrote SHOULD because the next sentence explain when you can use other default values, so it seem to me that only SHOULD makes sense. There is a MUST later saying that some default MUST be used.
Ah, ok!
I also like this and agree with the SHOULD. The MUST in the example that follows look odd to me though. I think that should be a MAY (or possibly a SHOULD).
The point about the MUST is that "default values MUST lead to a possible/implemented protocol". Maybe there is a better way to phrase that?
Btw. similar as in Arch I think we have to spread a couple more MUSTs, SHOULDs, and MAYs over the whole doc...
Not convinced that "default values MUST lead to an implemented protocol" is a MUST. If the TAPS default values do not lead to an implemented protocol (i.e. TCP or a protocol with similar functionality is not implemented), maybe you want applications that assume those values to get an error rather than transparently ending up with UDP? Maybe you know that your applications are aware and then you should be allowed to change them, but maybe you want to make sure that applications are aware that they get an unrelaible service and not a reliable service and then you should be allowed to keep the TAPS default values and generate an error.
I agree with NAME but I think this means we need more text explaining this. Any proposals?
Shouldn't this be: MUST provide some default that chooses an implemented protocol SHOULD use the ones we specify here The suggestion is to invert the sentences to clarify.
Or, we say that you can use the TCP defaults and raise an error if TCP isn't implemented.
I think it should be allowed to use the TAPS defaults and raise an error if no protocol that implements the TAPS defaults is available. In case the implementation prefers to do so. But I agree with Aaron that it is a corener case and in that sense perhaps not terribly important what we pick.
After thinking about this a bit more, I think that it is a must requirement that any chosen set of default values MUST NOT lead to an error, because what's otherwise the point about having default values....? However, I think we should add some big warning text that if other defaults are used that most be communicated to the users of this API others they might be really surprised...
I think this has moved in a curious direction. My thoughts are still that this has been edited in the wrong direction. I quite like the SHOULD. Whilst the language is fine, I really do not agree at all with the direction of the "the implementation MUST specify default Protocol Selection Properties that represents a configuration that can be implemented over the preferred protocol, such as UDP." This is not the way I saw TAPS - I expected the exact opposite outcome, i.e.: "the users of such an implementation MUST explicitly specify Properties that result in theimplemented over the preferred protocol, such as UDP."
NAME I lost a bit track here and your proposed text in the last comment doesn't parse fully. Can you make a concrete proposal what to change?
Sure, but this is different to your proposal, it is not clarifying your text: An implementation of this interface must provide sensible defaults for Selection Properties. The default values represent a configuration that can be implemented over TCP. If TCP is not supported by an implementation then an application using the default set of Properties might not succeed. For example, the application might need to be designed to also support a connectionless mode, and explicitly specify a different set of Protocol Selection Properties that result in a usable protocol.
Ready to merge
I approved this too early: I agree with NAME about the change to the second sentence.I agree with this. Previously we had some discussion on whether to make the defaults normative, see IETF 105 notes under "Parameters & Defaults" URL I don't really see a clear consensus in these notes, but I think your suggestion seems reasonable - different defaults for different platforms are possible, but then they have to be stated clearly.

Discussion:
other properties. An implementation of this interface must provide sensible defaults <del> for Selection Properties.  The defaults given for each property below represent a configuration that can be implemented over TCP.  An alternate set of default Protocol Selection Properties would represent a configuration that can be implemented over UDP. </del> <ins> for Selection Properties.  The recommended default values for each property below represent a configuration that can be implemented over TCP.  If these default values are used and TCP is not supported by a Transport Services implementation, then an application using the default set of Properties might not succeed in establishing a connection.  Using the same default values for independent Transport Services implementations can be beneficical when application are ported between different implementations, even if this default could lead to a connection failure, as, for example, an application needs to be explicitly designed to support a connectionless mode.  In this case the application can regonize the failure and explicitly specify a different set of Protocol Selection Properties that result in a usable protocol.  If default values other than those recommended below are used, it is recommended to clearly document the differences. </ins> 5.2.1.