Subject: [hybi] Publication request for draft-bormann-hybi-ws-wk-00

From: Alexey Melnikov <[email-masked]>
Date: Wed, 21 Jun 2017 16:48:39 +0100

Hi,

RFC 5785 defined a path prefix, "/.well-known/", that can be used by
well-known URIs, specifically for the "http" and "https" URI schemes.
Other URI schemes like "coap" also opted-in into using .well-known.

RFC 6455 defined WebSocket protocol and "ws"/"wss" URI schemes. It
hasn't however opted-in into using the .well-known registry defined by
RFC 5785. draft-bormann-hybi-ws-wk-00 is fixing this deficiency.

I am going to start IETF LC on this document. Please send your comments
to [email-masked] mailing list or reply to this email.

Thank you,
Alexey

---

From: Anne van Kesteren <[email-masked]>
Date: Thu, 22 Jun 2017 18:29:08 +0200

> RFC 5785. draft-bormann-hybi-ws-wk-00 is fixing this deficiency.

In practice (and in the specification that supersedes parts of the
RFC) the scheme in use is already http/https:

  https://fetch.spec.whatwg.org/#websocket-protocol

-- 
https://annevankesteren.nl/

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 22 Jun 2017 17:33:48 +0100

>   https://fetch.spec.whatwg.org/#websocket-protocol

I think this is an orthogonal thing, as ws/wss URI schemes are also used
in not HTTP contexts. So basically draft-bormann-hybi-ws-wk-00 doesn't
affect Fetch.

---

From: Anne van Kesteren <[email-masked]>
Date: Thu, 22 Jun 2017 20:13:10 +0200

> in not HTTP contexts. So basically draft-bormann-hybi-ws-wk-00 doesn't

The /.well-known/ thing only makes sense with respect to the WebSocket
handshake, no? And that's already defined to be an HTTP request. So
I'm not sure why any /.well-known/ things with regard to HTTP would
not already apply. (One of the reasons Fetch made this
change/clarification is to make sure HSTS, CSP, etc. would all apply
to WebSocket as well.)

---

From: Adam Rice <[email-masked]>
Date: Fri, 23 Jun 2017 19:35:12 +0900

> change/clarification is to make sure HSTS, CSP, etc. would all apply

If understand correctly, this permits a well-known WebSocket endpoint to be
registered under /.well-known/, so it's not just about HTTP-compatibility.

I don't see any problems with the proposal, as long as it's actually going
to be used. Is there a list of expected use-cases somewhere?

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 23 Jun 2017 11:41:36 +0100

On 23/06/2017 11:35, Adam Rice wrote:

> On 23 June 2017 at 03:13, Anne van Kesteren <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> If understand correctly, this permits a well-known WebSocket endpoint 
> to be registered under /.well-known/, so it's not just about 
> HTTP-compatibility.

Right.
>
> I don't see any problems with the proposal, as long as it's actually 
> going to be used. Is there a list of expected use-cases somewhere?
Sections 7.3 and 7.4 of 
<https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/?include_text=1>.

---

From: Adam Rice <[email-masked]>
Date: Fri, 23 Jun 2017 20:18:44 +0900

Ah, I see, it's already planned to be used for coap-over-WebSocket. Sounds
good to me.

On 23 June 2017 at 19:41, Alexey Melnikov <[email-masked]> wrote:

> If understand correctly, this permits a well-known WebSocket endpoint to
> be registered under /.well-known/, so it's not just about
> HTTP-compatibility.
>
>
> Right.
>
>
> Sections 7.3 and 7.4 of <https://datatracker.ietf.org/
> doc/draft-ietf-core-coap-tcp-tls/?include_text=1>