RE: WebSocket ALPN identifier

My initial reaction is “yes” to both questions.  😊

So the idea is that HTTP clients make a request to an endpoint that might be a WebSocket endpoint, but it instead directs them to make a request elsewhere using HTTP/1.1 which will upgrade to WebSockets?  Why wouldn’t it just Alt-Svc the HTTP resource that the client already expects to support WebSocket upgrades?

Or are you actually talking about HTTP-over-WebSockets?

From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk]
Sent: Wednesday, August 23, 2017 10:33 AM
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: WebSocket ALPN identifier

Bare with me,

Imagine a hypothetical system that wants to use Alt-Svc to direct clients to a particular WebSocket endpoint that can deliver appropriately framed HTTP resources.

To support this, I’m thinking of using the ALPN identifier(s) “ws” and “wss”. Since they don’t already exist in the IANA registry<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Ftls-extensiontype-values%2Ftls-extensiontype-values.xhtml%23alpn-protocol-ids&data=02%7C01%7CMichael.Bishop%40microsoft.com%7Cbe1ba0347f82410470b908d4ea4d70c0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636391065721565917&sdata=DLWk3ZJlcK7ML2yI3lk4IPLVBVwYNsMbYcuTJyuPu%2FU%3D&reserved=0>, I have thought about a short I-D similar to draft-ietf-rtcweb-alpn<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-rtcweb-alpn&data=02%7C01%7CMichael.Bishop%40microsoft.com%7Cbe1ba0347f82410470b908d4ea4d70c0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636391065721565917&sdata=XaQPVL3yX8rFKj7TEJvRiRfOxNHTx2lvKypaTinvsBs%3D&reserved=0>.

I do not intend for the proposed identifiers to be used for actual TLS ALPN during handshake. However, I don’t want to preclude that if there’s a desire to do so.

Is this idea too far in the realm of absurdity? Is HTTPbis the appropriate WG to pursue this in?

Regards
Lucas