Look into Alt-Svc model for CoAP Protocol Negotiation

[bsilverajan]

RFC 7838 specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration. This issue looks into the viability of employing a similar mechanism for CoaP and alternative transports.

[chrysn]

I've summarized the IMO relevant parts of Alt-Svc in https://github.com/t2trg/transports/blob/master/meeting-20190716/chrysn-preparation.md

My takeaway: If we follow their model 1:1, we can

• get rid of URI aliasing and
• don't need to trust the alternative-transport pointers,

but have to deal with

• not being able to use it for unauthenticated services and
• possibly having to send Proxy-Scheme and/or Uri-Host repeatedly,

and aliasing is one-way only (which I see as a good thing conceptually, but if any-to-any maps are desired in an application, things get huge).

It may be possible to adapt from Alt-Svc to get the properties we desire, or to have two distinct methods (a straight-forward and waterproof Alt-Svc-style, and an additional way for servers to declare URI aliases).