From nobody Fri Jun 9 18:56:00 2017 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A173712700F for ; Fri, 9 Jun 2017 18:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjIgLGq2-LAC for ; Fri, 9 Jun 2017 18:55:56 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA94126CD6 for ; Fri, 9 Jun 2017 18:55:55 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id v111so48302986wrc.3 for ; Fri, 09 Jun 2017 18:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+bqbIUes72I7p9MWXG3RxKnVu2cq8Id+5vSiIR3EvCM=; b=nTvidbCd0yjVd4/cUbxVIendK4kJDuWgDwtSFxnFxQv8PdbOh8752rG0hDVRVj82Ze vAD/c9cJ4TjoCYf8WVHt11WvO1nr9/g8QLbMnpGx29fXoEuNQsZQ5QSRAtbSEuYgvT46 e7DaKASr0+QM13C+dOTvCQhDCK09yEYUz0xrnmlcH41ylZ/TybX0CY3bT+4u28HoSV3Y tH0XXWxi/0k5l1xt6ePN1dwPr8I0ni9474Al2k9zB9OcdoSAUHX3QtVMiRSwWkZH7XQV BbyUYoOUKqtSkBaO7fa5p/Zf+Rvsu1fOkRLMtxUc9hLaT6Hh5REFxR0/aHM6/QvzTb+2 sv9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+bqbIUes72I7p9MWXG3RxKnVu2cq8Id+5vSiIR3EvCM=; b=NxHyYhUGxc5jLInL40cns+6iw9zsDfUCb/ROGgluXvuKuzm08q5MSsEztuHQQOpfEY 4LXVL1OeD5Y3OY6LXwK3F624lZY2U8Ed7LNBKtF2vGrnBieslb+6cqQunk1510I9hIGv Yp8zx0t3x9hVtVtSNmcB60dX1rdnMohe2Ot20iXbhQ48M4rE0jC7S07I6mU/GWHZahGp qIIcQ6Ikk0qPtCpt/DA3nSrKL+2uvWujUmWJjcJsN3sb46iFJS/RDQjcBuPUjvSLG1Dm N5VaVMVmdVaHHIUun/xa+jmjh0tcH7UocW7N7+xoXCR5ydxR+Hht49fEnSo80/IFum/g 0gMw== X-Gm-Message-State: AODbwcAZ/KatgEisrScR069Rr498I1wLwVy1vlJeAuh56AzpebQvtwEr pQK/at09+OaUg+LGEWN5IoPETX4HKj1q X-Received: by 10.223.160.68 with SMTP id l4mr846335wrl.130.1497059754225; Fri, 09 Jun 2017 18:55:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.94.206 with HTTP; Fri, 9 Jun 2017 18:55:53 -0700 (PDT) In-Reply-To: References: From: Wenbo Zhu Date: Fri, 9 Jun 2017 18:55:53 -0700 Message-ID: To: Greg Wilkins , Takeshi Yoshino Cc: Hybi Content-Type: multipart/alternative; boundary="94eb2c065238dc49c205519162d8" Archived-At: Subject: Re: [hybi] The future of WebSockets, and the WiSH proposal X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 01:55:59 -0000 --94eb2c065238dc49c205519162d8 Content-Type: text/plain; charset="UTF-8" Hi Greg, On Thu, Apr 27, 2017 at 2:36 AM, Greg Wilkins wrote: > > Takeshi, > > I note that in your drafts introduction you say: > >> when HTTP/1.1 is used as the underlying protocol, full-duplex >> communication may >> be broken if the client, server or any proxy chooses to buffer or reject >> earlier 2xx >> responses > > > Which is a clear and accurate statement of the key problem facing any > forever-frame based transport, regardless of what framing protocol is used > within those forever-frames. So while using the standard WS framing is > admirable, as is the usage of bidirectional communications, I do not see > why this is any more than WiSHful thinking that buffering or simplex > proxies will prevent universal coverage of the WS semantic. > WiSH as a framing format (MIME type) doesn't assume any specific L7 protocol. The above text is a warning against deploying long-lived & duplex bidi over HTTP/1.1, but short or simplex HTTP/1.1 transactions can certainly use WS framing v.s. SSE or application defined framing. > > So if I understand your intent correctly, you wish to define WS over HTTP > semantics in a way that is transport independent, so it will work for both > HTTP/1 and HTTP/2 so that WS can benefit from the single connection muxing > available in HTTP/2 when that is available. > > The problem with this approach is that the HTTP semantics just does not > support full-duplex streaming transport and thus it is bound to fail now > and potentially in the future when new proxy standards may be developed. > This is not true. The HTTP/2 spec explicitly require proxies to allow early 2xx responses. There are also environments where proxies are controlled by services (inc. no proxy). > > I think the effort would be better spent working with the HTTPbis working > group to get the WS semantic accepted over HTTP/2 framing in a way that > distinguishes the content from a normal HTTP message that might be stored > and forwarded. > For e2e encrypted traffic, proxies really shouldn't buffer anything, or WS will have the same issue. Otherwise, the C-T alone could serve as the signal. Maybe it's time to update https://tools.ietf.org/html/rfc6202. A lot of its content seems out of date, or incorrect, or applicable to WS too (or any TCP based protocol). We now also have data that shows how often WS connections are broken in the wild. - Wenbo > > regards > > > > > > > > > > -- > Greg Wilkins CTO http://webtide.com > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --94eb2c065238dc49c205519162d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg,


On Thu, Apr 27, 2017 at 2:36 AM, Greg Wilkins <gregw@webt= ide.com> wrote:

Takeshi,

I note = that in your drafts introduction you say:=C2=A0
when HTTP/1.1 is used as the underlying protoco= l, full-duplex communication may=C2=A0
be broken if the client, server o= r any proxy chooses to buffer or reject earlier 2xx
responses

Which is a clear and accurate statement of the key pr= oblem facing any forever-frame based transport, regardless of what framing = protocol is used within those forever-frames.=C2=A0 So while using the stan= dard WS framing is admirable, as is the usage of bidirectional communicatio= ns, I do not see why this is any more than WiSHful thinking that buffering = or simplex proxies will prevent universal coverage of the WS semantic.
WiSH as a framing format (MIME type) doesn't a= ssume any specific L7 protocol. The above text is a warning against deployi= ng long-lived & duplex bidi over HTTP/1.1, but short or simplex HTTP/1.= 1 transactions can certainly use WS framing v.s. SSE or application defined= framing.
=C2=A0

So if I understand your intent = correctly, you wish to define WS over HTTP semantics in a way that is trans= port independent, so it will work for both HTTP/1 and HTTP/2 so that WS can= benefit from the single connection muxing available in HTTP/2 when that is= available. =C2=A0 =C2=A0

The problem with this ap= proach is that the HTTP semantics just does not support full-duplex streami= ng transport and thus it is bound to fail now and potentially in the future= when new proxy standards may be developed.
Th= is is not true. The HTTP/2 spec explicitly require proxies to allow early 2= xx responses. There are also environments where proxies are controlled by s= ervices (inc. no proxy).=C2=A0

=C2=A0

=
I think the effort would be better spent working with the HTTPbis work= ing group to get the WS semantic accepted over HTTP/2 framing in a way that= distinguishes the content from a normal HTTP message that might be stored = and forwarded.
For e2e encrypted traffic, prox= ies really shouldn't buffer anything, or WS will have the same issue. O= therwise, the C-T alone could serve as the signal.

Maybe it's time to update=C2=A0https://tools.ietf.org/html/rfc6202.= A lot of its content seems out of date, o= r incorrect, or applicable to WS too (or any TCP based protocol). We now also have data that shows how often WS conne= ctions are broken in the wild.
<= br>
- Wenbo



=C2=A0

regards








_______________________________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi


--94eb2c065238dc49c205519162d8-- From nobody Sat Jun 10 06:18:29 2017 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A971A12896F for ; Sat, 10 Jun 2017 06:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhRNmU8yCxpK for ; Sat, 10 Jun 2017 06:18:25 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CBB4126CF9 for ; Sat, 10 Jun 2017 06:18:25 -0700 (PDT) Received: from [192.168.1.73] (91.55.252.52) by smtpx20.serverdata.net (206.225.164.37) with Microsoft SMTP Server (TLS) id 8.3.485.1; Sat, 10 Jun 2017 06:18:24 -0700 To: Andy Green , Takeshi Yoshino , Anne van Kesteren CC: "hybi@ietf.org" , Tobias Oberstein References: <20c1e950-2c04-70eb-2372-bc9ba11c2de1@warmcat.com> From: Tobias Oberstein Message-ID: Date: Sat, 10 Jun 2017 15:18:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20c1e950-2c04-70eb-2372-bc9ba11c2de1@warmcat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: de-LU Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [hybi] The future of WebSockets, and the WiSH proposal X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 13:18:28 -0000 >> The bottom of the background section of the I-D >> (https://tools.ietf.org/html/draft-yoshino-wish-02#section-2) is >> unintentionally (I forgot to update it) left to be talking about using >> WiSH framing over fetch()/Streams to improve the WebSocket ecosystem >> without introducing any dedicated browser code. This is also a >> possible option though it requires developers to include Polyfill in >> their code. > > The basic problem underneath all this is the guys who defined http/2 > considered ws so declasse This was also my impression, Google powerplay (in this case), trying to shove sth down everyones throat, mostly skewed towards their very specific interests. HTTP/1.1 + caching + WebSocket is a complete solution that works for me, I just don't need HTTP/2 nor WebSocket over HTTP/2. From my point of view, the "future of WebSocket" is bright as the technology stands. I'd rather take up another initiative at WebSocket multiplexing and/or message priorization extensions. /Tobias From nobody Wed Jun 21 08:50:15 2017 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7F512EB72; Wed, 21 Jun 2017 08:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8o5ij8YUQhH; Wed, 21 Jun 2017 08:49:57 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 04A4912EB71; Wed, 21 Jun 2017 08:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1498060121; d=isode.com; s=june2016; i=@isode.com; bh=EQRj0u9RvCLnA3702jqWQWFCWk5HNTx2YMVwA6PWyNw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=f9rI+UFg8rZhQyA5VEmmh/G49ngA0P14sKQHJOaZuD6sZH1tfgCJE12CJKkgAltmE+nmdM s2IZ5yD3R5gUixL/6qJgGjRgZgOAFYryKqcqwl0qfz1bmcD6BItXkNT8Khdg+wncNt0qjb jbzRlqNZ8flFVtUWlKyBBisaqvP7qw0=; Received: from [192.168.0.3] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 21 Jun 2017 16:48:41 +0100 From: Alexey Melnikov To: dispatch@ietf.org, "hybi@ietf.org" Message-ID: <594A9557.9080707@isode.com> Date: Wed, 21 Jun 2017 16:48:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [hybi] Publication request for draft-bormann-hybi-ws-wk-00 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 15:49:59 -0000 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 ietf@ietf.org mailing list or reply to this email. Thank you, Alexey From nobody Thu Jun 22 09:29:16 2017 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B46129AEA; Thu, 22 Jun 2017 09:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=annevk.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lb09w-o9k-ED; Thu, 22 Jun 2017 09:29:10 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F761129AE7; Thu, 22 Jun 2017 09:29:09 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTP id 6B42339207F; Thu, 22 Jun 2017 09:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=annevk.nl; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc: content-type; s=annevk.nl; bh=METoWYvKO85ms7Deb3JFmGd8WDs=; b=Q0 ykebSE9QyJpC9HKGrVMF1GCs9d2HmJGzwDmFvLFeW7OMcVn47UtCpa1YMu8X7acz sTphgKeFmksL/9yrTQA3Q80qIdsWi073nKz2XnvOwXRdJkExSeubsXce1C7/v/Qc D9uOLBcnzGPS8d4xev31sMByEglQxYJaFjI5jXkbE= Received: from mail-yb0-f174.google.com (mail-yb0-f174.google.com [209.85.213.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: annevk@annevk.nl) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTPSA id 4AE02392075; Thu, 22 Jun 2017 09:29:09 -0700 (PDT) Received: by mail-yb0-f174.google.com with SMTP id f192so6257467yba.2; Thu, 22 Jun 2017 09:29:09 -0700 (PDT) X-Gm-Message-State: AKS2vOyUgY4howhlj5mOgfOXZZhyZQAlbYTrU1ZRn2DSLXDFaTaemcxc ORZr/okEupr3KghSQnYQbCX2N5ywDg== X-Received: by 10.37.175.17 with SMTP id a17mr2493729ybh.9.1498148948568; Thu, 22 Jun 2017 09:29:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.216.81 with HTTP; Thu, 22 Jun 2017 09:29:08 -0700 (PDT) In-Reply-To: <594A9557.9080707@isode.com> References: <594A9557.9080707@isode.com> From: Anne van Kesteren Date: Thu, 22 Jun 2017 18:29:08 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Alexey Melnikov Cc: dispatch@ietf.org, "hybi@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [hybi] Publication request for draft-bormann-hybi-ws-wk-00 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 16:29:15 -0000 On Wed, Jun 21, 2017 at 5:48 PM, Alexey Melnikov wrote: > 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. 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 nobody Thu Jun 22 09:33:52 2017 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE8112945A; Thu, 22 Jun 2017 09:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWcLM1wCN8vm; Thu, 22 Jun 2017 09:33:49 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A39D1270A3; Thu, 22 Jun 2017 09:33:49 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A6DF620B78; Thu, 22 Jun 2017 12:33:48 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute3.internal (MEProxy); Thu, 22 Jun 2017 12:33:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=BNtUoP xhhffV+JCfTiT0T0jj9UpbRHFijM8CF6jPyVs=; b=m8GCcwkis5y3kmjjjrGHfa RCLqJfU0iXKQcDybQ8IoWgPu9dBE5t6dfi7gyyO7DnjGQndnWradI9k4oTMup/8s P7sF5Wo/1o5hBPEoOIyxd/lg6FuPW9/fvI7Ea+u0xrowO+kRKGDm5wKZkyp0Q8wE PU4LUNDhES0xuNo991Ej01uL6xHsOUF4oFsCRGDtVeEd7ISuSBsE+5RLTBHdBgCo E8gd/f7STr6JUMRCRu4HeoptbCb5gCM1Tayd8z767zJyZVuyTeKLMfY6IqF0lo+j 7QCVG7SiZk7CZshTgHAv2V2Fv4CRqpsakXHIzk3/G0C9FK7Kjx0jjKosbjIwopCA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 87F2A9E23D; Thu, 22 Jun 2017 12:33:48 -0400 (EDT) Message-Id: <1498149228.3653703.1018087584.5D4E9087@webmail.messagingengine.com> From: Alexey Melnikov To: Anne van Kesteren Cc: hybi@ietf.org, dispatch@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-72841c42 In-Reply-To: References: <594A9557.9080707@isode.com> Date: Thu, 22 Jun 2017 17:33:48 +0100 Archived-At: Subject: Re: [hybi] [dispatch] Publication request for draft-bormann-hybi-ws-wk-00 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 16:33:51 -0000 On Thu, Jun 22, 2017, at 05:29 PM, Anne van Kesteren wrote: > On Wed, Jun 21, 2017 at 5:48 PM, Alexey Melnikov > wrote: > > 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. > > 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 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 nobody Thu Jun 22 11:13:21 2017 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B164C129418; Thu, 22 Jun 2017 11:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=annevk.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcOGONNeRNqH; Thu, 22 Jun 2017 11:13:12 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF9C1201FA; Thu, 22 Jun 2017 11:13:12 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 1243A10AFBD; Thu, 22 Jun 2017 11:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=annevk.nl; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc: content-type; s=annevk.nl; bh=LISz2mtFY1hVfCrb4VfWZgsFbKQ=; b=Ie kg7sFEBdr2i7hnLK1GRQnFT6mcoJko/NesZSq00M6LEAxcqGZv8CWk0FY4TWAGE1 Iz+yZp5waEWyDfTL12RL3b6oXpsxsyzCE6YLwCbXSEYGA6RmroPmRBRtXQwh/IS5 r+7QyDVG7EHJ0+s0NauWs8PabAUwEIkR4ozxGqFmA= Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.161.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: annevk@annevk.nl) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id D9D8510AFB8; Thu, 22 Jun 2017 11:13:11 -0700 (PDT) Received: by mail-yw0-f176.google.com with SMTP id l75so9020857ywc.3; Thu, 22 Jun 2017 11:13:11 -0700 (PDT) X-Gm-Message-State: AKS2vOzMvteCx+8qDyUBx/40yEpNueFlwY5NBxto2RDvJRH5Cwwlzt69 jHm1tHfJX9CRMmhh0j/B6uXO2eMczA== X-Received: by 10.129.128.132 with SMTP id q126mr2834236ywf.259.1498155190704; Thu, 22 Jun 2017 11:13:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.216.81 with HTTP; Thu, 22 Jun 2017 11:13:10 -0700 (PDT) In-Reply-To: <1498149228.3653703.1018087584.5D4E9087@webmail.messagingengine.com> References: <594A9557.9080707@isode.com> <1498149228.3653703.1018087584.5D4E9087@webmail.messagingengine.com> From: Anne van Kesteren Date: Thu, 22 Jun 2017 20:13:10 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Alexey Melnikov Cc: "hybi@ietf.org" , dispatch@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [hybi] [dispatch] Publication request for draft-bormann-hybi-ws-wk-00 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 18:13:14 -0000 On Thu, Jun 22, 2017 at 6:33 PM, Alexey Melnikov wrote: > On Thu, Jun 22, 2017, at 05:29 PM, Anne van Kesteren wrote: >> On Wed, Jun 21, 2017 at 5:48 PM, Alexey Melnikov >> wrote: >> > 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. >> >> 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 > > 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. 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.) -- https://annevankesteren.nl/ From nobody Fri Jun 23 03:35:25 2017 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B5D1274D0 for ; Fri, 23 Jun 2017 03:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWuJ3TG5Vgzd for ; Fri, 23 Jun 2017 03:35:16 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F56128B8D for ; Fri, 23 Jun 2017 03:35:15 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id k67so59432349wrc.2 for ; Fri, 23 Jun 2017 03:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eANuT5PwY6b1sXp9p1mqXRdIDkgWa91Q6z53UN3EK1Q=; b=VyG7EBCNdLi7HFAHa9p2N9t14g8opLAeJ2lmWkfMTHCpM3gS4m8UzktBmc9Dy6aRV8 gXMc0dneduLXYmVOBboGkFW0Ph7ZM/du9PlbcFrDz5FTY0ArzQT3avIB32eBruxmQM9K aQOfqn2JrKTiNzCav7NwwhurSZNiz2FgeFsFD0AsAJEFQVW0yCrjAnbMq2hLzb4aLuDe 0c4Ds7AH3hLN93vyRI5uXtcuucoL9h90q9vuwCNGPTaYTr+hZbZdmfw+k9AT73TjuIgq 6ue/+J9RMW37igQ4eRKFAMCUx3isCBYX8Y61BELmthi/nQ44o2Uag8IjkRluOSHscs36 nGlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eANuT5PwY6b1sXp9p1mqXRdIDkgWa91Q6z53UN3EK1Q=; b=itWQ5UvC7nL4v1PX9i0dsq7Cw6GPFLjuKjYfZlWA2VetGBY25FXZDgTOHeij1cKqCE gBAA/s7Iz4MCFnH3HOTAIZWjjEOrvhesmD8K3aXNWfFXS1pL4+klT0LJSynfbjwDDSJs YagW74fUSPcu2itcpP50OHeB3THD7yOtTrt1gTsknKgoFuE9IdfySPOxxGTH0Ja3y+51 B0sUuTLETtf4CcS3fgrFuJ2Oe/F4bS7mMrhjyBNPyd1F0WjmDRxiQLmmJ9DqvKskr09a 3zzcpYTH3IimrUzAq8S6LN9OnxeUcXx6+vZGvppMVAimRX47rQ1yU0MCNgeMW9czuIr+ v9WA== X-Gm-Message-State: AKS2vOxgoiqObByQMZZME8ETxFTg9uJEyP2kyxcSenlZVlCloJcjlUfR zDYxRXH9MFYXHQu56Lnsgv2Xl9jUdvbJ X-Received: by 10.28.229.6 with SMTP id c6mr4939229wmh.49.1498214113734; Fri, 23 Jun 2017 03:35:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.218.3 with HTTP; Fri, 23 Jun 2017 03:35:12 -0700 (PDT) In-Reply-To: References: <594A9557.9080707@isode.com> <1498149228.3653703.1018087584.5D4E9087@webmail.messagingengine.com> From: Adam Rice Date: Fri, 23 Jun 2017 19:35:12 +0900 Message-ID: To: Anne van Kesteren Cc: Alexey Melnikov , dispatch@ietf.org, "hybi@ietf.org" Content-Type: multipart/alternative; boundary="001a1145b51a0c758205529e281b" Archived-At: Subject: Re: [hybi] [dispatch] Publication request for draft-bormann-hybi-ws-wk-00 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 10:35:19 -0000 --001a1145b51a0c758205529e281b Content-Type: text/plain; charset="UTF-8" On 23 June 2017 at 03:13, Anne van Kesteren wrote: > 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.) > 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? --001a1145b51a0c758205529e281b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --001a1145b51a0c758205529e281b-- From nobody Fri Jun 23 03:42:10 2017 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBAD129C07; Fri, 23 Jun 2017 03:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Npjac0IP0LFK; Fri, 23 Jun 2017 03:42:07 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7BD127180; Fri, 23 Jun 2017 03:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1498214526; d=isode.com; s=june2016; i=@isode.com; bh=vqXr8AEY2IPYaxf0W8a70LQF0htxKbkBr0mg3n6Ksek=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=xNhyUPuptu5SVQqmR9YsTBD0ppRCQtsfrp9ClfIA8c2aHvS2AobDx2h0phSHt9kIxOqoPj GiNRSJQl3qTEn6BM+NpW09vwe0oQzIe8E4yeaLqMfLYFiO4YIrOf/b3jK7bU6EoZRa3MUQ xyJtKPDNHR08dnAcNIMD9SEpqMuG3qE=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 23 Jun 2017 11:42:06 +0100 To: Adam Rice , Anne van Kesteren Cc: dispatch@ietf.org, "hybi@ietf.org" References: <594A9557.9080707@isode.com> <1498149228.3653703.1018087584.5D4E9087@webmail.messagingengine.com> From: Alexey Melnikov Message-ID: <6eb360bd-0d5c-4559-85c9-99716cf846ba@isode.com> Date: Fri, 23 Jun 2017 11:41:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------35A2D17180D210AF4059E5D9" Content-Language: en-US Archived-At: Subject: Re: [hybi] [dispatch] Publication request for draft-bormann-hybi-ws-wk-00 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 10:42:09 -0000 --------------35A2D17180D210AF4059E5D9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 23/06/2017 11:35, Adam Rice wrote: > On 23 June 2017 at 03:13, Anne van Kesteren > wrote: > > 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.) > > > 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 . --------------35A2D17180D210AF4059E5D9 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

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


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?
=C2=A0
Sections 7.3 and 7.4 of <https://datatracker.ietf= .org/doc/draft-ietf-core-coap-tcp-tls/?include_text=3D1>.


--------------35A2D17180D210AF4059E5D9-- From nobody Fri Jun 23 04:18:51 2017 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DB1129687 for ; Fri, 23 Jun 2017 04:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLDUOpJZIJok for ; Fri, 23 Jun 2017 04:18:47 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14BA129353 for ; Fri, 23 Jun 2017 04:18:46 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id k67so60963982wrc.2 for ; Fri, 23 Jun 2017 04:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9eXKMLaHtify5+wwQiTH/IevKkwsa3yIGSJ0XqDM1CE=; b=J3jD0dNEOHM9YZZRloLhQle/HbOqHYkodXn7wMo9Tspy+sEDb97irFp/OB4PAOE90N woGxnho7yvUKLFPGHX7+OCRH3GcS/o2ipBvazOZmdkOp62hdmvU1KZHQ1hH490v33WbN d94Gs9jkpd7wmpCIdp4863/ioyVoZ2taDgBoDa6zNLIQtDOXCBwlD0sjyZTzkXVXhpAe 9R3jLxufjNSyr/vGP9rhsAPzuSqugTNEbJkHC+pE3f3CEzGCfAIFjY0R9ShgAuUNDmu5 6/FQoFd08nz9q4c5S5eJzqV5HV4pwhrX69s2P0ZxftMncaEDg4nxx83NJvIFagy/pT3N jKdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9eXKMLaHtify5+wwQiTH/IevKkwsa3yIGSJ0XqDM1CE=; b=IKhCmxhH7y2Ibm4CoQXuSzqhFMxX7TSDmXq4MAliRzrSPJIomzdg9SWqhB+Nzzgo/u Xil/y39khZOnth/UmiPyrKhxBppbCebIJx/gUSegW5L643vgbhBj/7wjgtFAJYzVo/Xv jlNHlrt3kQleXuILnHF82eHVAGE4g7rl7HVFAYjRQQHA2qU4KqpUHBkQ7DTS7g7x742l s4lrHjwqKZndvnmURHRYPaRCXy9Rb4NPMU0dNvQbgxz9d+sXZaW/8AIxiNaroFpN5Wlj Tf8uHG1Fe6pxc/ptvHrNjc6UylSLkMs+2zAeX5KgSLZy5DPaBwMUwUhTTv0hIxE3RxDv 7LgQ== X-Gm-Message-State: AKS2vOxAFmX39q+q0ld5MxSRhUuEHdXTXnwvCCNaFSKFPMAHo3VKNaVG WFhsRbwKHfKc4rLVnczCWFbObwakJUaF X-Received: by 10.223.135.105 with SMTP id 38mr5097065wrz.23.1498216724846; Fri, 23 Jun 2017 04:18:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.218.3 with HTTP; Fri, 23 Jun 2017 04:18:44 -0700 (PDT) In-Reply-To: <6eb360bd-0d5c-4559-85c9-99716cf846ba@isode.com> References: <594A9557.9080707@isode.com> <1498149228.3653703.1018087584.5D4E9087@webmail.messagingengine.com> <6eb360bd-0d5c-4559-85c9-99716cf846ba@isode.com> From: Adam Rice Date: Fri, 23 Jun 2017 20:18:44 +0900 Message-ID: To: Alexey Melnikov Cc: Anne van Kesteren , dispatch@ietf.org, "hybi@ietf.org" Content-Type: multipart/alternative; boundary="001a1147fd6eaea7dd05529ec315" Archived-At: Subject: Re: [hybi] [dispatch] Publication request for draft-bormann-hybi-ws-wk-00 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 11:18:49 -0000 --001a1147fd6eaea7dd05529ec315 Content-Type: text/plain; charset="UTF-8" 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 wrote: > On 23/06/2017 11:35, Adam Rice wrote: > > On 23 June 2017 at 03:13, Anne van Kesteren wrote: > >> 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.) >> > > 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 doc/draft-ietf-core-coap-tcp-tls/?include_text=1> > > . > > > --001a1147fd6eaea7dd05529ec315 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah, I see, it's already planned to be used for coap-ov= er-WebSocket. Sounds good to me.

On 23 June 2017 at 19:41, Alexey Melnikov <al= exey.melnikov@isode.com> wrote:
=20 =20 =20

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

On 23 June 2017 at 03:13, Anne van Kesteren <annevk@annevk.= nl> wrote:
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.)

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?
=C2=A0
 Sections 7.3 and 7.4 of <https://datatracker.ietf.org/doc/draft-ietf-core-coa= p-tcp-tls/?include_text=3D1>.



--001a1147fd6eaea7dd05529ec315--