Change:
This event notifies the application when at least one of the paths underlying a Connection has changed.  Changes occur on a single path when the PMTU changes as well as when multiple paths are used and <del> paths are added or removed, or a handover has been performed. </del> <ins> paths are added or removed, the set of local endpoints changes, or a handover has been performed. </ins> 9.

Discussion:
This makes the following changes: Add , , , and actions to existing connections Update the description of the event to note that it's generated if the set of local endpoints available changes Update the peer-to-peer example to show how these can be used to support Trickle ICE
For multipath transport protocols, the transport can automatically manage the set of local and remote endpoints its using, and the application doesn't need to be aware of this. For non-multipath transport protocols used peer-to-peer, the peers need to be aware of changes to the set of local and remote endpoints, so they can trigger updates to the NAT binding discovery. This can't be done automatically, since to implement Trickle ICE, it's necessary to pass the updated set of candidates to the peer via an out-of-band signalling channel, before passing them in to the connection to probe connectivity. Accordingly, we need: A way to add/remove remote endpoints on an existing connection A way to add/remove local endpoints on an existing connection A way to detect when the set of local endpoints has changed To implement Trickle ICE, adding and removing remote endpoints has to be an explicit action, since changes to the set of remote endpoints are communicated to the peer via out-of-band signalling. Similarly, when implementing Trickle ICE, changes to the set of local endpoints have to be communicated to the peer via out-of-band signalling, so the application has to be notified about them. It could be possible to automatically add/remove local endpoints to an existing connection, if the Preconnection left the local endpoints unspecified. But if the set of local endpoints was specified, the application will need to make a choice which ones it adds/removes when the set changes.
I would really like to see an example of how an application that relies on ICE learns about new candidates as they are discovered - the callback pattern is not clear to me yet.
See also
It feels to me like there's a bit of a gap between how software ought to discover Endpoint Object identifiers for Remote Endpoints versus Local Endpoints. Remote Endpoint identifiers are likely to be defined by the kind of software being used acting on some user input (web browser requesting a page, DNS server recursing, etc.), and these identifiers are resolved through existing internet architecture. Importantly, there's not really any way to check a valid input would work until for a Remote Endpoint. This isn't really true for identifiers on Local Endpoints.

While it's true that discovering these things is system-specific, a TAPS API implementation ought to provide a vehicle for discovering what inputs are valid. Two reasons I think it's reasonable to support discovery of local addresses and interfaces include: It'd be unfortunate for TAPS-consuming software to rely on system-specific APIs to implement a UX for configuring that software. Given diversity of public cloud offerings and wide use of multi-cloud deployments, it's reasonable to expect folks to want to dynamically discover what local network addresses and interfaces exist in their environment. If the intent is to not define an API to discover these identifiers, the document should be clarified to discuss what Errors can be returned by and Actions on Local Endpoints. (This is coming from a perspective that "error early, error often" is a best practice, which is admittedly subjective.) If there is agreement to add (for example) and Actions on a Local Endpoint, these should be documented. Further, the and Actions on a Local Endpoint should be described to return an Error when the supplied input would not exist in the results returned by the corresponding call at the time the Action was called. In either case, it would be useful to mention that a successful invocation of a Action is not a guarantee that initiating the precondition will succeed.
This all makes sense to me, and sounds like some things should indeed be added. I'm a little afraid that adding "GetInterface" could cause a rat tail of "GetWhateverElse" ideas... is there a good way to keep that from happening? Something more generic, perhaps - "GetLocalSystemProperties", and explain that such properties could, e.g., contain a list of interfaces? Regarding early failure, I agree with your suggestions too; note that, even though a Preconnection itself is just a passive data structure (or Object holding data), the call to create it can already fail (some details are in section 3.1 of the implementation draft). I think that's the earliest type of failure that we specify (and since this is an abstract API, I'm not sure if we should start specifying that calls to define an Endpoint (which is where "WithInterface" and such are found) could fail too - the endpoints could just be a 100% passive data structure that's handed over, there might not be any calls involved... so I think it's enough to specify failure of the Preconnection creation).

I think that's a fair concern, and I think a API could work. Two concerns with a single API entry point for Local Endpoint identifier discovery: It provides no means for enumerating interface(s) by address(es) or vice versa without some argument signifying how the caller wants the data returned. It's more likely to cause future API and ABI versioning headaches for implementers when new identifiers are deemed useful for discovery, and require changing the returned data structure. I'm not sure how to effectively allay concerns about adding a billion discovery APIs. I don't think discovery is needed for Transport Properties: I see that as a TAPS API implementer's documentation problem (and consumer's reading-the-documentation problem), and maybe that's worth a sentence of rationale somewhere. I also do not think that a service port discovery API is particularly useful in modern systems (and there are many service discovery protocols to choose from for the cases they are). would then have to reference a yet-to-be-defined local transport concept; since a Local Endpoint is effectively defined by a 3-tuple of interface, address, and port, I think it's unlikely new discovery APIs would be requested / added frequently. Great point! If the system changes between discovery and such that a previously-valid Preconnection is now invalid, the inverse is also possible. Happy to scope this issue only to the point of discovery APIs.
Rendezvous lets you enumerate local endpoint candidates via Preconnection.Resolve(). In general, you shouldn't be enumerating the local endpoints for client-to-server connections, as it will limit the ability to do happy eyeballs, etc.
We can add clarity in the existing rendezvous section to explain that this list could be used for other purposes, but people should be careful.
I'm considering cases like proxies, where interface choice might be important for routing / peering / cost decisions. I agree it's generally not something one would want to do for clients-with-people-behind-them. Thanks for pointing out this is possible with Rendezvous!
I'm trying to write some text to resolve this and as it turns out I'm a bit confused by what Preconnection.Resolve() will return: the set of local and remote endpoints supplied to the preconnection to attempt to rendezvous using; or the set of all potential local endpoints (if none has been specified).
LGTM, thanks a lot for doing this!