Change:
Appendix B of the API draft provides a sample concrete definition of the API, written in Go. Having concrete examples of the API is clearly useful, but I question whether this draft is the right place for them, since we don't want to bless a particular API variant. Suggest this appendix be moved to either the implementation draft, or a separate example API implementation draft.
The intention here is to show that the API is reasonably expressible and expressive in at least one modern language. I'd be more than happy to replace it with links to the code and documentation for now though. (Eventually, examples would be more useful than the sketch though.)
NAME makes sense.
Looks good to me.Looks good to me

Discussion:
In the following sections, we describe the details of application interaction with Objects through Actions and Events in each phase of <del> a connection, following the phases described in TAPS-ARCH.  An example interface sketch in Go is shown in appendix-api-sketch. </del> <ins> a connection, following the phases described in TAPS-ARCH. </ins> 5.

any time by using the following call on the Connection object: Note that most properties are only considered for connection <del> establishment and can not be changed later on. appendix-specify- query-params gives an overview of what Transport Parameters can be specified and queried during which phase. </del> <ins> establishment and can not be changed after a connection is established; however, they can be queried.  See introspection. </ins> A Connection gets its Transport Parameters either by being explicitly configured via a Preconnection, or by inheriting them from an

with the Transport Parameters (see transport-params).  This allows to specify Protocol Properties and that can be overridden on a per- Message basis or Application Intents that apply to a specific <del> Message.  See appendix-specify-query-params for an overview. </del> <ins> Message. </ins> Send Parameters may be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given Message is

correspond to the properties given in transport-params and can only be queried. <del> Transport Features of the protocols that were selected, once the Connection has been established.  These features correspond to the properties given in transport-params and can only be queried. </del> <ins> Transport Features of the protocol stacks that were selected and instantiated, once the Connection has been established.  These features correspond to the properties given in transport-params and can only be queried.  Instead of preference levels, these features have boolean values indicating whether or not they were selected.  Note that these transport features may not fully reflect the specified parameters given in the pre-establishment phase.  For example, a certain Protocol Selection Property that an application specified as Preferred may not actually be present in the chosen Protocol Stack Instances because none of the currently available transport protocols had this feature. </ins> Protocol Properties of the Protocol Stack in use (see protocol- props below).  These can be set or queried.  Certain specific <del> procotol queries may be read-only, on a protocol and property </del> <ins> procotol queries may be read-only, on a protocol- and property- </ins> specific basis. Path Properties of the path(s) in use, once the Connection has

provisioning domain, measurements by the protocol stack, or other sources.  They can only be queried. <del> appendix-specify-query-params gives a more detailed overview of the different types of properties that can be set and queried at different times. </del> 9.1. Protocol Properties represent the configuration of the selected