Change:
Prefer, Require) for the level of preference of a given property during protocol selection; see selection-props. <ins> 4.2. This document defines a language- and platform-independent interface to a Transport Services system.  Given the wide variety of languages and language conventions used to write applications that use the transport layer to connect to other applications over the Internet, this independence makes this interface necessarily abstract.  While there is no interoperability benefit to tightly defining how the interface be presented to application programmers in diverse platforms, maintaining the "shape" of the abstract interface across these platforms reduces the effort for programmers who learn the transport services interface to apply their knowledge in multiple platforms.  We therefore make the following recommendations: Actions, Events, and Errors in implementations of this interface SHOULD carry the names given for them in the document, subject to capitalization and punctuation conventions in the language of the implementation, unless the implementation itself uses different names for substantially equivalent objects for networking by convention. Implementations of this interface SHOULD implement each Selection Property, Connection Property, and Message Context Property specified in this document, exclusive of appendices, even if said implementation is a non-operation, e.g.  because transport protocols implementing a given Property are not available on the platform. </ins> 5. The pre-establishment phase allows applications to specify properties

Discussion:
Now that the document is targeted for the standards track, its purpose (i.e. what exactly it standardizes, and what it does not) should be made clear. This is made a little more difficult because, as an abstract API we intend to be implementable in any reasonable language (i.e. no brainfuck kthxbye), Here's what I think the scope is: message-orientation asynchronicity of event and reception asynchronicity of resolution and initiation the "shape" of the API: objects and events, and interactions between them, with a RECOMMENDATION that you use the same names ("unless this facility is implemented in terms of a networking interface that already has different names or naming conventions for equivalent objects" or something like that). an MTI set of selection, connection, and message properties, and definitions (though not names) of these properties. a larger fully defined set of selection, connection, and message properties, such that if a system implements a given property it must implement it as described.
Why would we not want to make a recommendation on the names of properties? We'll need to name them in the drafts anyway, if we're to cross-reference them from elsewhere, and at that point there's no benefit in not recommending re-use of those names in concrete API implementations.
I think providing consistent naming across different implementations will be a key argument for the adoption of the abstract interface. The strongest argument for sticking to BSD Sockets is that they somehow look the same on all platforms. We should not miss the change to at least give recommendations about how to name the individual objects and properties. Implementations can and should extend and divert from it where it makes sense, but recommending names should help the individual APIs look at least similar.
There are different kinds of things we can recommend names for. objects actions events properties We have pretty good recommendations for the first three (though different languages have e.g. different capitalization conventions). Names of properties are descriptive, though, and would make bad code names, so if we want to do the fourth we have some work to do. What I would propose to do for Bangkok: assume we recommend names for the first three, open an issue for recommended property names (which is necessary for NAME registry project anyway).
Looks good! Just one comment in re-reading a section more carefully, not blocking.I especially like the "Scope of the Interface Definition" text! Really nice and useful to have IMO