From nobody Mon Jul 1 17:11:10 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4325E12018B for ; Mon, 1 Jul 2019 17:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 MSjYl1_52XW5 for ; Mon, 1 Jul 2019 17:11:06 -0700 (PDT) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 C350B1200CE for ; Mon, 1 Jul 2019 17:11:05 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id v20so5793808uao.3 for ; Mon, 01 Jul 2019 17:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ErjktmO96yYtHf5d0JvZ+dCc0IBmQf3bwAHhiPxYwYk=; b=pw4s1wXUamcfQ5PB5T6pn0RciUBCTirGFGSz4bzf2Cf1VeR79W5y6+Gt6QOgKrd69W HDYfVp+tk+OQrEwxWXqXeZ34ed7wWthn9STkheDVwQq47RkXPg52IGk3p4GKar2/SAbb vxGQU9rRg5pVh9riMqHK/0roLHq20DD2G36/257NdooQVgAJHOvnxsXm6x1jPhCtcbZq 7rk0H50GXj/tVsrcBWED5VOFvqWtCw8bEsYzFw1voDP9lEkYFgZQZBhfErzd3vRrO/ba p+Lzmk7ULluzmr7fEooGcjxK2gQqc0RqWuRsGuhr5DL4tA+xhhzP9XBYZxRethvEeMhs lnZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ErjktmO96yYtHf5d0JvZ+dCc0IBmQf3bwAHhiPxYwYk=; b=Fnd/LvJBDQYlEwfB7VgDT4CKGYTgom1SrQAu70bZh3Mj6qsB/hQjCAkrNS8qwAl3Mu dPXea+ERbNsi/JwSFtlOf+T4UHxSxPCmjwhqrfGvzsX1vdD70kLliyRQi+zc6dm6YpKU fdfJzLYtRLb4QICtvCXQtwC7m9sayuL4oPEN/mIYUQ4ixs5JfwZCctiqqdxZuc+Gnbqn wSoeA8QafQ9DbhBs/Z89hSoPqh92c6khHcd3uzkt6SDbPAQmLnzeUyp2Z3CRFEec8s2+ k/f7CrYCDz8K+YEPV7s3VNkiCXEd/ihg48QUMYfWd8NI4A+8F3L/s6elBnv5KYvEFji7 5iZA== X-Gm-Message-State: APjAAAU/FdhAlRRQhWBzvSQZ9kQCDnNJscYCUVTsyb0pQ+tM2dFE2MIq xTP9dRhAsorkkuPMnPw36QZf8KRHd1RfqYtJX1x0CQ== X-Google-Smtp-Source: APXvYqyjiCg66e9DyeplWu4G94QSMLcTusoM98fuP9EU6Hes6d43XdB+hoc8qTFx9GDvQ9IkyxK+534lV7OZwi7Dp2U= X-Received: by 2002:a9f:28e4:: with SMTP id d91mr16909795uad.30.1562026264099; Mon, 01 Jul 2019 17:11:04 -0700 (PDT) MIME-Version: 1.0 References: <98EF12E4-4BF2-4FBC-852B-776A0E0118BE@westhawk.co.uk> In-Reply-To: <98EF12E4-4BF2-4FBC-852B-776A0E0118BE@westhawk.co.uk> From: Peter Thatcher Date: Mon, 1 Jul 2019 17:10:27 -0700 Message-ID: To: T H Panton Cc: Victor Vasiliev , dispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000009a4947058ca7946c" Archived-At: Subject: Re: [dispatch] Dispatching WebTransport X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 00:11:09 -0000 --0000000000009a4947058ca7946c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 17, 2019 at 7:13 AM T H Panton wrote: > > > On 17 Jun 2019, at 14:35, Victor Vasiliev < > vasilvv=3D40google.com@dmarc.ietf.org> wrote: > > Hello friendly IETF dispatchers, > > I am writing about new work I want to bring to IETF. The proposal is > called WebTransport. It=E2=80=99s a combination of a Web API currently u= nder > development in W3C WICG [0], a protocol framework and some protocols that > fit into that framework. Combined, they would allow web applications to > establish WebSocket-like connections that instead of ordered reliable > messages use multiple streams and datagrams (datagrams are unreliable and > streams do not have head-of-line blocking). This is highly useful for > real-time and other latency sensitive applications. > > > Establish connections to where ? Between eachother P2P ? Or to any server= ? > Or just to the originating server only? > Any server or p2p. > > > # Background > > Historically, the only networking operations available to the Web > applications were sending HTTP requests and receiving HTTP responses. Th= at > model does not fit all applications well, so over time, more mechanisms > were added. The two most relevant here are WebSockets (RFC 6455) and RTC > Data Channels (draft-ietf-rtcweb-data-channel). WebSockets are a way for > Web applications to do bidirectional communication over a TCP connection; > they work great if TCP fits your transport needs, but perform poorly if > your application is latency sensitive and would, in non-Web context, use = a > UDP-based protocol. There are many different kinds of applications like > that, but I would like to highlight two major categories which I to some > extent surveyed when coming up with this proposal: > > 1. Custom client-server chat/multimedia protocols (faster-than-DASH > video streaming, game streaming, etc). Those are usually developed by > teams with a good amount of resources, and they are interested in tail= oring > the setup for their use case. > 2. Game developers. Online games are commonly real-time in nature and > benefit dramatically from ability to give up on transmitting old > information. They usually use some in-house UDP-based protocol, and o= ften > need to run on unusual platforms. > > WebRTC Data Channels are a mechanism that provides a WebSocket-like > interface with unreliable delivery features. On the wire, it=E2=80=99s > SCTP-over-DTLS, established using ICE and SDP. In theory, this provides > users with enough functionality to build anything they need, since SCTP > messages can be unreliable and unordered. In practice, while > RtcDataChannel is fairly straightforward to use for browser-to-browser > peer-to-peer communication, it has seen much lower adoption than WebSocke= ts > in the client-server scenario, even considering the fact that its use cas= es > is naturally more niche. > > The main reason for this is the incredible complexity of the WebRTC > stack. WebSockets are a fairly straightforward overlay on top of TCP and > TLS; there is a wide variety of implementations out there, and it's > fairly easy to write a new one (I wrote on myself in less than 1,000 line= s > of C++). With data channels, however, once there is no browser to abstra= ct > all of the complexity away, the web developers are required to understand > and implement (or at least integrate) SDP, ICE, STUN, DTLS and userspace > SCTP. While a lot of those have simplifications for this use case (ICE > Lite) and some protocols listed have a variety of implementations widely > available (DTLS), the entire system still requires going through hundreds > of pages of RFCs in order to understand it well enough to implement. Thi= s > complexity barrier has precluded Data Channel adoption by communities of > smaller developers who don=E2=80=99t have resources to implement them, no= tably game > developers (see [1] and [2] for some discussion). > > > Much, but not all, of the complexity of the webRTC stack is due to the NA= T > traversal and security commitments you need to do P2P. > If you exclude the need to do NAT traversal and P2P > then it _could_ be much simpler. But it also gives you E2E encryption and > low latency as side effects! > > In client/server mode, WebTransport doesn't require any of that, so it is a lot more simple. Work is in progress decoupling the APIs from the (dreaded) SDP and > simplifying the developer experience. > > What work? > That said, it is by no means un-managable - I've implemented pretty much > the whole stack from scratch for small devices and I know of 2 other > implementations which don't use libusrsctp > > Maybe not for you, but we regularly get emails from people saying things like "It would be great to delete the mess of the WebRTC stack if there's a simpler protocol available. ICE/DTLS/SCTP all scare me". > > > Even among the people who got past the complexity barrier, the feedback I > heard almost universally is that WebRTC Data Channels are hard to work > with. From the feedback I gathered, the main problem is usually around t= he > transport protocol itself. Userspace SCTP is essentially a monoculture: > virtually all implementations use libusrsctp, a 80,000-line adaptation of > FreeBSD SCTP implementation. This lack of tool choice is fairly painful > since latency-sensitive real-time applications often require quite a bit = of > tuning on the transport side to get the best performance (custom congesti= on > control, etc). In addition, the limitations on the message size stemming > from both the API itself and the lack of widespread support for message > interleaving (RFC 8260) means that the developers have to roll their own > framing on top of SCTP messages if they want to avoid head-of-line-blocki= ng > (this is particularly bad because the framing overhead in data channels i= s > already large as-is). > > > SCTP is well defined nice protocol that suffers (IMHO) from a lack of > 'coolness' due to being used by the telcos for most of it's life. > The head-of-line issue is a problem, but entirely fixable with small > tweaks to SCTP protocol. (read it wasn't in the original requirements - s= o > it doesn't do it). > It's been fixable for a very long time. I have my doubts about when it will actually get fixed. > > > In summary, we have a system that technically provides what everyone > wants, but that nobody is happy with, and that is not usable by all but t= he > most well-resourced users. > > > I'd point out that 2.5bn endpoints support it right now - including > _every_ smartphone shipped in the last 2 years. Last I heard DataChannel > traffic was 0.1% of chrome's traffic > which is _astonishingly_ high > > > # Proposal > > Our initial idea for fixing this was to take QUIC and do what WebSocket > did to TCP: add security features that would make it safe to expose on th= e > Web (by adding origin checks, etc), but otherwise expose it as-is. This > would get us out of libusrsctp monoculture (QUIC is not yet finished, but > it already has a fairly diverse implementation ecosystem, see [3]), and > remove all P2P-related complexity involving SDP and ICE. The original > proposal for that was called QuicTransport; we showed it to various peopl= e, > and the feedback we got is that (1) the API should not be tied to a > particular transport (since we already switched once from SCTP to QUIC, > tying it to QUIC specificially would not be wise), and (2) it shouldn=E2= =80=99t > fail hard when QUIC is unavailable. > > > It would be _great_ if that abstraction could _also_ work over SCTP data > channels. That way you could cover the P2P use cases too. > QUIC can be p2p. In fact, we already have it implemented in Chrome (in an original trial). The WebTransport API could run on top of SCTP, and you could probably make a JS polyfill for it. But I'm not sure why anyone would bother. > As a result of that feedback, we abstracted it into a general-purpose > framework called WebTransport. The overview draft, > > https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 > > describes the framework itself, mainly the requirements the transport > protocols have to satisfy to be usable on the web through the API. Withi= n > this framework, we propose the following protocols: > > - QuicTransport -- a simple WebSocket-like adaptation of QUIC, > described in https://tools.ietf.org/html/draft-vvv-webtransport-quic-0= 0 > - Http3Transport -- a mechanism that allows creating custom non-HTTP > streams within an HTTP/3 session, described in > https://tools.ietf.org/html/draft-vvv-webtransport-http3-00.. This is > sort of a version of RFC 8441 for QuicTransport. > - FallbackTransport -- a TCP-based transport with multiplexed streams > that can be used when QUIC is not available (e.g. on network that requ= ire > CONNECT proxy). We don=E2=80=99t have a draft specifically for this, = and there are > at least two approaches we could take here: either reusing HTTP/2 as a > transport (i.e. just use draft-kinnear-httpbis-http2-transport), or > building a protocol with QUIC-like semantics on top of WebSockest. Th= e > earlier is a more straightforward way; the latter has the advantage of > being fully polyfillable in JavaScript. > > > # Discussion > > At this point, I am fairly certain that there is a problem here that need= s > to be addressed. I am formally requesting ART area to take this problem = on. > > > I'd really like to be clear what that problem is. > > Web developers routinely ask for an unreliable websocket, or something close to UDP (but it needs to be secure). It turns out that ICE/DTLS/SCTP is too complex to fill that roll. I believe the drafts above would be a good starting point for discussion. > The design that they describe went through several iterations based on th= e > feedback I got when I discussed this work within a more narrow audience > (mostly people in QUIC working group), so we=E2=80=99re hopefully at leas= t looking > in the right direction here. I am requesting feedback on this proposal, > both on the overall plan and the specifics described in the drafts. I ho= pe > to discuss this in depth in Montreal, both at dispatch and (in more depth= ) > at a side-meeting. > > > Tim. > > > Thanks, > Victor. > > [0] https://github.com/WICG/web-transport > [1] https://discourse.wicg.io/t/webtransport-proposal/3508/9 > [2] https://news.ycombinator.com/item?id=3D13266692 > [3] https://github.com/quicwg/base-drafts/wiki/Implementations > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0000000000009a4947058ca7946c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 17, 2019 at 7:13 AM T H P= anton <thp@westh= awk.co.uk> wrote:


On 17 Jun 2019,= at 14:35, Victor Vasiliev <vasilvv=3D40google.com@dmarc.ietf.org>= ; wrote:

Hello friendly IETF dispat= chers,

I am writing about new work I want to bring to IETF.=C2=A0 Th= e proposal is called WebTransport.=C2=A0 It=E2=80=99s a combination of a We= b API currently under development in W3C WICG [0], a protocol framework and= some protocols that fit into that framework.=C2=A0 Combined, they would al= low web applications to establish WebSocket-like connections that instead o= f ordered reliable messages use multiple streams and datagrams (datagrams a= re unreliable and streams do not have head-of-line blocking).=C2=A0 This is= highly useful for real-time and other latency sensitive applications.
<= /div>

Establish connections to where = ? Between eachother P2P ? Or to any server? Or just to the originating serv= er only?=C2=A0

Any server= or p2p.
=C2=A0


# B= ackground

Historically, the only networking operations available to = the Web applications were sending HTTP requests and receiving HTTP response= s.=C2=A0 That model does not fit all applications well, so over time, more = mechanisms were added.=C2=A0 The two most relevant here are WebSockets (RFC= 6455) and RTC Data Channels (draft-ietf-rtcweb-data-channel).=C2=A0 WebSoc= kets are a way for Web applications to do bidirectional communication over = a TCP connection; they work great if TCP fits your transport needs, but per= form poorly if your application is latency sensitive and would, in non-Web = context, use a UDP-based protocol.=C2=A0 There are many different kinds of = applications like that, but I would like to highlight two major categories = which I to some extent surveyed when coming up with this proposal:
    <= li>Custom client-server chat/multimedia protocols (faster-than-DASH video s= treaming, game streaming, etc).=C2=A0 Those are usually developed by teams = with a good amount of resources, and they are interested in tailoring the s= etup for their use case.
  1. Game developers.=C2=A0 Online games are co= mmonly real-time in nature and benefit dramatically from ability to give up= on transmitting old information.=C2=A0 They usually use some in-house UDP-= based protocol, and often need to run on unusual platforms.=C2=A0=C2=A0
WebRTC Data Channels are a mechanism that provides a WebSocket-like i= nterface with unreliable delivery features.=C2=A0 On the wire, it=E2=80=99s= SCTP-over-DTLS, established using ICE and SDP.=C2=A0 In theory, this provi= des users with enough functionality to build anything they need, since SCTP= messages can be unreliable and unordered.=C2=A0 In practice, while RtcData= Channel is fairly straightforward to use for browser-to-browser peer-to-pee= r communication, it has seen much lower adoption than WebSockets in the cli= ent-server scenario, even considering the fact that its use cases is natura= lly more niche.

The main reason for this is the incredible complexit= y of the WebRTC stack.=C2=A0 WebSockets are a fairly straightforward overla= y on top of TCP and TLS; there is a wide variety of implementations out the= re, and it's fairly=C2=A0easy to write a new one (I wrote on myself in = less than 1,000 lines of C++).=C2=A0 With data channels, however, once ther= e is no browser to abstract all of the complexity away, the web developers = are required to understand and implement (or at least integrate) SDP, ICE, = STUN, DTLS and userspace SCTP.=C2=A0 While a lot of those have simplificati= ons for this use case (ICE Lite) and some protocols listed have a variety o= f implementations widely available (DTLS), the entire system still requires= going through hundreds of pages of RFCs in order to understand it well eno= ugh to implement.=C2=A0 This complexity barrier has precluded Data Channel = adoption by communities of smaller developers who don=E2=80=99t have resour= ces to implement them, notably game developers (see [1] and [2] for some di= scussion).

Much, but not al= l, of the complexity of the webRTC stack is due to the NAT traversal and se= curity commitments you need to do P2P.
If you exclude = the need to do NAT traversal and P2P
then it _could_ be much simp= ler. But it also gives you E2E encryption and low latency as side effects!<= /div>

=C2=A0
=C2=A0In= client/server mode, WebTransport doesn't require any of that, so it is= a lot more simple.=C2=A0

Work is in progress deco= upling the APIs from the (dreaded) SDP and simplifying the developer experi= ence.


What= work?=C2=A0 =C2=A0
=C2=A0
That said, it is by no means un-= managable - I've implemented pretty much the whole stack from scratch f= or small devices and I know of 2 other implementations which don't use = libusrsctp=C2=A0


Maybe not for you, but we regularly get emails from people saying th= ings like "It would be great to delete the mess of the WebRTC stack if= there's a simpler protocol available. ICE/DTLS/SCTP all scare me"= .
=C2=A0
<= div>

Even among the people who got past the complexity barrier, the feedback I = heard almost universally=C2=A0is that WebRTC Data Channels are hard to work= with.=C2=A0 From the feedback I gathered, the main problem is usually arou= nd the transport protocol itself.=C2=A0 Userspace SCTP is essentially a mon= oculture: virtually all implementations use libusrsctp, a 80,000-line adapt= ation of FreeBSD SCTP implementation.=C2=A0 This lack of tool choice is fai= rly painful since latency-sensitive real-time applications often require qu= ite a bit of tuning on the transport side to get the best performance (cust= om congestion control, etc).=C2=A0 In addition, the limitations on the mess= age size stemming from both the API itself and the lack of widespread suppo= rt for message interleaving (RFC 8260) means that the developers have to ro= ll their own framing on top of SCTP messages if they want to avoid head-of-= line-blocking (this is particularly bad because the framing overhead in dat= a channels is already large as-is).

SCTP is well defined nice protocol that suffers (IMHO) from a lack= of 'coolness' due to being used by the telcos for most of it's= life.
The head-of-line issue is a problem, but entirely fixable = with small tweaks to SCTP protocol. (read it wasn't in the original req= uirements - so it doesn't do it).
It's been fixable for a very long time.=C2=A0 I have my do= ubts about when it will actually get fixed.
=C2=A0


In summary, we have a system that technical= ly provides what everyone wants, but that nobody is happy with, and that is= not usable by all but the most well-resourced users.

I'd point out that 2.5bn endpoints support i= t right now - including _every_ smartphone shipped in the last 2 years. Las= t I heard DataChannel traffic was 0.1% of chrome's traffic=C2=A0
<= div>which is _astonishingly_ high


# Proposal

Our initial idea for fixing= this was to take QUIC and do what WebSocket did to TCP: add security featu= res that would make it safe to expose on the Web (by adding origin checks, = etc), but otherwise expose it as-is.=C2=A0 This would get us out of libusrs= ctp monoculture (QUIC is not yet finished, but=C2=A0 it=C2=A0already has a = fairly diverse implementation ecosystem, see [3]), and remove all P2P-relat= ed complexity involving SDP and ICE.=C2=A0 The original proposal for that w= as called QuicTransport; we showed it to various people, and the feedback w= e got is that (1) the API should not be tied to a particular transport (sin= ce we already switched once from SCTP to QUIC, tying it to QUIC specificial= ly would not be wise), and (2) it shouldn=E2=80=99t fail hard when QUIC is = unavailable.


It would b= e _great_ if that abstraction could _also_ work over SCTP data channels. Th= at way you could cover the P2P use cases too.

QUIC can be p2p.=C2=A0 In fact, we already have it imp= lemented in Chrome (in an original trial).

The Web= Transport API could run on top of SCTP, and you could probably make a JS po= lyfill for it.=C2=A0 But I'm not sure why anyone would bother.


As a result of = that feedback, we abstracted it into a general-purpose framework called Web= Transport.=C2=A0 The overview draft,

=C2=A0 https:= //tools.ietf.org/html/draft-vvv-webtransport-overview-00

describ= es the framework itself, mainly the requirements the transport protocols ha= ve to satisfy to be usable on the web through the API.=C2=A0 Within this fr= amework, we propose the following protocols:
  • QuicTransport -- a = simple WebSocket-like adaptation of QUIC, described in https:= //tools.ietf.org/html/draft-vvv-webtransport-quic-00
  • Http3Trans= port -- a mechanism that allows creating custom non-HTTP streams within an = HTTP/3 session, described in https://tools.ietf.org/html/dra= ft-vvv-webtransport-http3-00..=C2=A0 This is sort of a version of RFC 8= 441 for QuicTransport.
  • FallbackTransport -- a TCP-based transport w= ith multiplexed streams that can be used when QUIC is not available (e.g. o= n network that require CONNECT proxy).=C2=A0 We don=E2=80=99t have a draft = specifically for this, and there are at least two approaches we could take = here: either reusing HTTP/2 as a transport (i.e. just use draft-kinnear-htt= pbis-http2-transport), or building a protocol with QUIC-like semantics on t= op of WebSockest.=C2=A0 The earlier is a more straightforward way; the latt= er has the advantage of being fully polyfillable in JavaScript.
# Discussion

At this point, I am fairly certain that there is a pr= oblem here that needs to be addressed.=C2=A0 I am formally requesting ART a= rea to take this problem on.

I'd really like to be clear what that problem is.=C2=A0


Web developers routinely ask for a= n unreliable websocket, or something close to UDP (but it needs to be secur= e).=C2=A0 =C2=A0It turns out that ICE/DTLS/SCTP is too complex to fill that= roll.=C2=A0=C2=A0

I b= elieve the drafts above would be a good starting point for discussion.=C2= =A0 The design that they describe went through several iterations based on = the feedback I got when I discussed this work within a more narrow audience= (mostly people in QUIC working group), so we=E2=80=99re hopefully at least= looking in the right direction here.=C2=A0 I am requesting feedback on thi= s proposal, both on the overall plan and the specifics described in the dra= fts.=C2=A0 I hope to discuss this in depth in Montreal, both at dispatch an= d (in more depth) at a side-meeting.

<= /div>
Tim.

_______________________________________________
dispatch mailing listdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--0000000000009a4947058ca7946c-- From nobody Mon Jul 1 17:14:11 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFC0120186 for ; Mon, 1 Jul 2019 17:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 QGSbgAGaOh2G for ; Mon, 1 Jul 2019 17:14:05 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 973CC1200CE for ; Mon, 1 Jul 2019 17:14:05 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id a186so10075553vsd.7 for ; Mon, 01 Jul 2019 17:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=056xF5+2LhgmNcKt5Xb1ZmNZYO372EFxR0eQJWSW0TY=; b=jrqKicc3ZlLZhrFIw051Br0g1MziPxlvNzUwCqEghYe0rkaWZ9KZHdo4xROxHIzSJ9 9A1aLji9HeHWKfNRcWtp3/y8uqvVSBGcgfTuYgpxEZY1iv08Sq6lT8PNgjV63qRRMIm3 UPGezmtOFjQ/snoZnNxo2yr3Z1fh/rLuuwK+6FlQbPTWiLPegzXhBoA2zkKtJL9dDHVm dwufmMTU4h+zVTNZrQ/FPjf2yINAcLy5Ebip4K1GpQJfE3FUi981BrE3hA63qRJPAs8I FQwILmHnCDEa0uXdpwNK35aCt8qp0YSbI0AKXFded97fi7kSGBMireLmnP8eL6JMIYaB HjWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=056xF5+2LhgmNcKt5Xb1ZmNZYO372EFxR0eQJWSW0TY=; b=naLiwd3DazsGG8rAoeCScQtTpc+UIHLK5Kz+21YW3WGDpNsFZfBcNx87n5KztbKvBr Yzn/DGoU6004JCMK6QM+DQ5PaDSJ0Eh3w8pfdpI+ykQblTTWbuEPmw2DZa9QAnS1ETXZ 8KSPFuNY+2cy8ajqh51v0K6QR4hlOgR4wNy12sSJv3FdMfetDU741xVgR2PUQTKKKvWd Rb98SL9AE7SCVob6kJ1biCBZPbfABB14SVCPmjkOm9RPTaayeLTUy3JoHp4mUBfS0Wij E0rf2wiSrxvqHfoLKwR2PoxZLJhgh89gYpoB0NUm0TbdZsU9U560FR4tY9et6Mw9hNmK V2cA== X-Gm-Message-State: APjAAAW+2LEQG6Tq0jYetEDnJOCkSutNsyv5flMV6HvGQn9blu71l9OJ ZvE4tRmDHZnsOL7HXUZxlKfFV2YMpVed0bfTxFeCZg== X-Google-Smtp-Source: APXvYqzQg+ahiCqqlbHtYOiKuTENGMgmfT9D41ni/AJ/JDz2WfhBDI6YApKX43ey2Fhne9oWyie1iLgPrqVb8uwjhjg= X-Received: by 2002:a67:d48b:: with SMTP id g11mr15927513vsj.63.1562026444124; Mon, 01 Jul 2019 17:14:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Mon, 1 Jul 2019 17:13:28 -0700 Message-ID: To: Sergio Garcia Murillo Cc: dispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000005537c8058ca79f80" Archived-At: Subject: Re: [dispatch] Dispatching WebTransport X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 00:14:10 -0000 --0000000000005537c8058ca79f80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 17, 2019 at 7:52 AM Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > From the draft: > > WebTransport [OVERVIEW ] is a protocol framework that enables clients > constrained by the Web security model to communicate with a remote > server using a secure multiplexed transport. > > > Although while I agree with your analysis regarding current webrtc dc and > sctp status, if this is a pure client-to-server transport, why is webrtc > mentioned in the background at all? shouldn't this be a replacement of > websockets and NOT of the webrtc datachannels? > It's both a better WebSocket and a better RTCDataChannel. Take your pick of how you look at it. > Best regards > Sergio > > > On 17/06/2019 15:35, Victor Vasiliev wrote: > > Hello friendly IETF dispatchers, > > I am writing about new work I want to bring to IETF. The proposal is > called WebTransport. It=E2=80=99s a combination of a Web API currently u= nder > development in W3C WICG [0], a protocol framework and some protocols that > fit into that framework. Combined, they would allow web applications to > establish WebSocket-like connections that instead of ordered reliable > messages use multiple streams and datagrams (datagrams are unreliable and > streams do not have head-of-line blocking). This is highly useful for > real-time and other latency sensitive applications. > > # Background > > Historically, the only networking operations available to the Web > applications were sending HTTP requests and receiving HTTP responses. Th= at > model does not fit all applications well, so over time, more mechanisms > were added. The two most relevant here are WebSockets (RFC 6455) and RTC > Data Channels (draft-ietf-rtcweb-data-channel). WebSockets are a way for > Web applications to do bidirectional communication over a TCP connection; > they work great if TCP fits your transport needs, but perform poorly if > your application is latency sensitive and would, in non-Web context, use = a > UDP-based protocol. There are many different kinds of applications like > that, but I would like to highlight two major categories which I to some > extent surveyed when coming up with this proposal: > > 1. Custom client-server chat/multimedia protocols (faster-than-DASH > video streaming, game streaming, etc). Those are usually developed by > teams with a good amount of resources, and they are interested in tail= oring > the setup for their use case. > 2. Game developers. Online games are commonly real-time in nature and > benefit dramatically from ability to give up on transmitting old > information. They usually use some in-house UDP-based protocol, and o= ften > need to run on unusual platforms. > > WebRTC Data Channels are a mechanism that provides a WebSocket-like > interface with unreliable delivery features. On the wire, it=E2=80=99s > SCTP-over-DTLS, established using ICE and SDP. In theory, this provides > users with enough functionality to build anything they need, since SCTP > messages can be unreliable and unordered. In practice, while > RtcDataChannel is fairly straightforward to use for browser-to-browser > peer-to-peer communication, it has seen much lower adoption than WebSocke= ts > in the client-server scenario, even considering the fact that its use cas= es > is naturally more niche. > > The main reason for this is the incredible complexity of the WebRTC > stack. WebSockets are a fairly straightforward overlay on top of TCP and > TLS; there is a wide variety of implementations out there, and it's > fairly easy to write a new one (I wrote on myself in less than 1,000 line= s > of C++). With data channels, however, once there is no browser to abstra= ct > all of the complexity away, the web developers are required to understand > and implement (or at least integrate) SDP, ICE, STUN, DTLS and userspace > SCTP. While a lot of those have simplifications for this use case (ICE > Lite) and some protocols listed have a variety of implementations widely > available (DTLS), the entire system still requires going through hundreds > of pages of RFCs in order to understand it well enough to implement. Thi= s > complexity barrier has precluded Data Channel adoption by communities of > smaller developers who don=E2=80=99t have resources to implement them, no= tably game > developers (see [1] and [2] for some discussion). > > Even among the people who got past the complexity barrier, the feedback I > heard almost universally is that WebRTC Data Channels are hard to work > with. From the feedback I gathered, the main problem is usually around t= he > transport protocol itself. Userspace SCTP is essentially a monoculture: > virtually all implementations use libusrsctp, a 80,000-line adaptation of > FreeBSD SCTP implementation. This lack of tool choice is fairly painful > since latency-sensitive real-time applications often require quite a bit = of > tuning on the transport side to get the best performance (custom congesti= on > control, etc). In addition, the limitations on the message size stemming > from both the API itself and the lack of widespread support for message > interleaving (RFC 8260) means that the developers have to roll their own > framing on top of SCTP messages if they want to avoid head-of-line-blocki= ng > (this is particularly bad because the framing overhead in data channels i= s > already large as-is). > > In summary, we have a system that technically provides what everyone > wants, but that nobody is happy with, and that is not usable by all but t= he > most well-resourced users. > > # Proposal > > Our initial idea for fixing this was to take QUIC and do what WebSocket > did to TCP: add security features that would make it safe to expose on th= e > Web (by adding origin checks, etc), but otherwise expose it as-is. This > would get us out of libusrsctp monoculture (QUIC is not yet finished, but > it already has a fairly diverse implementation ecosystem, see [3]), and > remove all P2P-related complexity involving SDP and ICE. The original > proposal for that was called QuicTransport; we showed it to various peopl= e, > and the feedback we got is that (1) the API should not be tied to a > particular transport (since we already switched once from SCTP to QUIC, > tying it to QUIC specificially would not be wise), and (2) it shouldn=E2= =80=99t > fail hard when QUIC is unavailable. > > As a result of that feedback, we abstracted it into a general-purpose > framework called WebTransport. The overview draft, > > https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 > > describes the framework itself, mainly the requirements the transport > protocols have to satisfy to be usable on the web through the API. Withi= n > this framework, we propose the following protocols: > > - QuicTransport -- a simple WebSocket-like adaptation of QUIC, > described in https://tools.ietf.org/html/draft-vvv-webtransport-quic-0= 0 > - Http3Transport -- a mechanism that allows creating custom non-HTTP > streams within an HTTP/3 session, described in > https://tools.ietf.org/html/draft-vvv-webtransport-http3-00. This is > sort of a version of RFC 8441 for QuicTransport. > - FallbackTransport -- a TCP-based transport with multiplexed streams > that can be used when QUIC is not available (e.g. on network that requ= ire > CONNECT proxy). We don=E2=80=99t have a draft specifically for this, = and there are > at least two approaches we could take here: either reusing HTTP/2 as a > transport (i.e. just use draft-kinnear-httpbis-http2-transport), or > building a protocol with QUIC-like semantics on top of WebSockest. Th= e > earlier is a more straightforward way; the latter has the advantage of > being fully polyfillable in JavaScript. > > > # Discussion > > At this point, I am fairly certain that there is a problem here that need= s > to be addressed. I am formally requesting ART area to take this problem = on. > > I believe the drafts above would be a good starting point for discussion. > The design that they describe went through several iterations based on th= e > feedback I got when I discussed this work within a more narrow audience > (mostly people in QUIC working group), so we=E2=80=99re hopefully at leas= t looking > in the right direction here. I am requesting feedback on this proposal, > both on the overall plan and the specifics described in the drafts. I ho= pe > to discuss this in depth in Montreal, both at dispatch and (in more depth= ) > at a side-meeting. > > Thanks, > Victor. > > [0] https://github.com/WICG/web-transport > [1] https://discourse.wicg.io/t/webtransport-proposal/3508/9 > [2] https://news.ycombinator.com/item?id=3D13266692 > [3] https://github.com/quicwg/base-drafts/wiki/Implementations > > _______________________________________________ > dispatch mailing listdispatch@ietf.orghttps://www.ietf.org/mailman/listin= fo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0000000000005537c8058ca79f80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 17, 2019 at 7:52 AM Sergi= o Garcia Murillo <ser= gio.garcia.murillo@gmail.com> wrote:
=20 =20 =20
From the dra= ft:

   WebTransport [OVERVIEW] is=
 a protocol framework that enables clients
   constrained by the Web security model to communicate with a remote
   server using a secure multiplexed transport.

Although whi= le I agree with your analysis regarding current webrtc dc and sctp status, if this is a pure client-to-server transport, why is webrtc mentioned in the background at all? shouldn't this be a replacement of websockets and NOT of the webrtc datachannels?

It's both a better WebSocket and a better RTCDataChanne= l.=C2=A0 Take your pick of how you look at it.


Best regards=
Sergio


On 17/06/201= 9 15:35, Victor Vasiliev wrote:
=20
Hello friendly IETF dispatchers,

I am writing about new work I want to bring to IETF.=C2=A0 The proposal is called WebTransport.=C2=A0 It=E2=80=99s a combination o= f a Web API currently under development in W3C WICG [0], a protocol framework and some protocols that fit into that framework.=C2=A0 Combined, they would allow web applications to establish WebSocket-like connections that instead of ordered reliable messages use multiple streams and datagrams (datagrams are unreliable and streams do not have head-of-line blocking).=C2=A0 Th= is is highly useful for real-time and other latency sensitive applications.

# Background

Historically, the only networking operations available to the Web applications were sending HTTP requests and receiving HTTP responses.=C2=A0 That model does not fit all applications well, so over time, more mechanisms were added.=C2=A0 The two most relevant here are WebSockets (RFC 6455) and RTC Data Channels (draft-ietf-rtcweb-data-channel).=C2=A0 WebSockets are a way for We= b applications to do bidirectional communication over a TCP connection; they work great if TCP fits your transport needs, but perform poorly if your application is latency sensitive and would, in non-Web context, use a UDP-based protocol.=C2=A0 There ar= e many different kinds of applications like that, but I would like to highlight two major categories which I to some extent surveyed when coming up with this proposal:
  1. Custom client-server chat/multimedia protocols (faster-than-DASH video streaming, game streaming, etc).=C2=A0 Those are usually developed by teams with a good amount of resources, and they are interested in tailoring the setup for their use case.
  2. Game developers.=C2=A0 Online games are commonly real-time in nature and benefit dramatically from ability to give up on transmitting old information.=C2=A0 They usually use some in-house UDP-based protocol, and often need to run on unusual platforms.=C2=A0=C2=A0
WebRTC Data Channels are a mechanism that provides a WebSocket-like interface with unreliable delivery features.=C2=A0 O= n the wire, it=E2=80=99s SCTP-over-DTLS, established using ICE and SD= P.=C2=A0 In theory, this provides users with enough functionality to build anything they need, since SCTP messages can be unreliable and unordered.=C2=A0 In practice, while RtcDataChannel is fairly straightforward to use for browser-to-browser peer-to-peer communication, it has seen much lower adoption than WebSockets in the client-server scenario, even considering the fact that its use cases is naturally more niche.

The main reason for this is the incredible complexity of the WebRTC stack.=C2=A0 WebSockets are a fairly straightforward overlay on top of TCP and TLS; there is a wide variety of implementations out there, and it's fairly=C2=A0easy to write a= new one (I wrote on myself in less than 1,000 lines of C++).=C2=A0 With data channels, however, once there is no browser to abstract all of the complexity away, the web developers are required to understand and implement (or at least integrate) SDP, ICE, STUN, DTLS and userspace SCTP.=C2=A0 While a lot of those have simplifications for this use case (ICE Lite) and some protocols listed have a variety of implementations widely available (DTLS), the entire system still requires going through hundreds of pages of RFCs in order to understand it well enough to implement.=C2=A0 This complexity barrier has precluded Data Channel adoption by communities of smaller developers who don=E2=80=99t hav= e resources to implement them, notably game developers (see [1] and [2] for some discussion).

Even among the people who got past the complexity barrier, the feedback I heard almost universally=C2=A0is that WebRTC Data Channe= ls are hard to work with.=C2=A0 From the feedback I gathered, the main problem is usually around the transport protocol itself.=C2=A0 Userspace SCTP is essentially a monoculture: virtually all implementations use libusrsctp, a 80,000-line adaptation of FreeBSD SCTP implementation.=C2=A0 This lack of tool choice is fair= ly painful since latency-sensitive real-time applications often require quite a bit of tuning on the transport side to get the best performance (custom congestion control, etc).=C2=A0 In additio= n, the limitations on the message size stemming from both the API itself and the lack of widespread support for message interleaving (RFC 8260) means that the developers have to roll their own framing on top of SCTP messages if they want to avoid head-of-line-blocking (this is particularly bad because the framing overhead in data channels is already large as-is).

In summary, we have a system that technically provides what everyone wants, but that nobody is happy with, and that is not usable by all but the most well-resourced users.

# Proposal

Our initial idea for fixing this was to take QUIC and do what WebSocket did to TCP: add security features that would make it safe to expose on the Web (by adding origin checks, etc), but otherwise expose it as-is.=C2=A0 This would get us out of libusrsct= p monoculture (QUIC is not yet finished, but=C2=A0 it=C2=A0already ha= s a fairly diverse implementation ecosystem, see [3]), and remove all P2P-related complexity involving SDP and ICE.=C2=A0 The origina= l proposal for that was called QuicTransport; we showed it to various people, and the feedback we got is that (1) the API should not be tied to a particular transport (since we already switched once from SCTP to QUIC, tying it to QUIC specificially would not be wise), and (2) it shouldn=E2=80=99t fail hard when QUI= C is unavailable.

As a result of that feedback, we abstracted it into a general-purpose framework called WebTransport.=C2=A0 The overview draft,

=C2=A0 https://tools.ietf.org/html/draft-vvv-webt= ransport-overview-00

describes the framework itself, mainly the requirements the transport protocols have to satisfy to be usable on the web through the API.=C2=A0 Within this framework, we propose the following protocols:
  • QuicTransport -- a simple WebSocket-like adaptation of QUIC, described in https://tools.ietf.org/html/dr= aft-vvv-webtransport-quic-00
  • Http3Transport -- a mechanism that allows creating custom non-HTTP streams within an HTTP/3 session, described in https://tools.ietf.org/html/draft-vvv-webtransport-http3-00.=C2= =A0 This is sort of a version of RFC 8441 for QuicTransport.
  • FallbackTransport -- a TCP-based transport with multiplexed streams that can be used when QUIC is not available (e.g. on network that require CONNECT proxy).=C2=A0 W= e don=E2=80=99t have a draft specifically for this, and there are= at least two approaches we could take here: either reusing HTTP/2 as a transport (i.e. just use draft-kinnear-httpbis-http2-transport), or building a protocol with QUIC-like semantics on top of WebSockest.=C2=A0 T= he earlier is a more straightforward way; the latter has the advantage of being fully polyfillable in JavaScript.

# Discussion

At this point, I am fairly certain that there is a problem here that needs to be addressed.=C2=A0 I am formally requesting ART area to take this problem on.

I believe the drafts above would be a good starting point for discussion.=C2=A0 The design that they describe went through severa= l iterations based on the feedback I got when I discussed this work within a more narrow audience (mostly people in QUIC working group), so we=E2=80=99re hopefully at least looking in the = right direction here.=C2=A0 I am requesting feedback on this proposal, bo= th on the overall plan and the specifics described in the drafts.=C2= =A0 I hope to discuss this in depth in Montreal, both at dispatch and (in more depth) at a side-meeting.

Thanks,
=C2=A0 Victor.

[0] https://github.com/WICG/web-transport

= 
____________=
___________________________________
dispatch mailing list
dispatch@ietf.org
https://www.i=
etf.org/mailman/listinfo/dispatch


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--0000000000005537c8058ca79f80-- From nobody Tue Jul 2 01:22:56 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2D31201F3 for ; Tue, 2 Jul 2019 01:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 zujdG1V3L3Uv for ; Tue, 2 Jul 2019 01:22:49 -0700 (PDT) Received: from smtp001-out2.apm-internet.net (smtp001-out2.apm-internet.net [85.119.248.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8821200B3 for ; Tue, 2 Jul 2019 01:22:48 -0700 (PDT) Received: (qmail 32838 invoked from network); 2 Jul 2019 08:22:46 -0000 X-APM-Out-ID: 15620557663283 X-APM-Authkey: 255286/0(159927/0) 207 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 2 Jul 2019 08:22:46 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 8113A18A05A5; Tue, 2 Jul 2019 09:22:46 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YrB1Nfcei33z; Tue, 2 Jul 2019 09:22:46 +0100 (BST) Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 42E8818A058A; Tue, 2 Jul 2019 09:22:46 +0100 (BST) From: westhawk Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1845883D-ED67-40B4-9361-470C110417B2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 2 Jul 2019 09:22:45 +0100 In-Reply-To: Cc: Victor Vasiliev , dispatch@ietf.org To: Peter Thatcher References: <98EF12E4-4BF2-4FBC-852B-776A0E0118BE@westhawk.co.uk> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dispatch] Dispatching WebTransport X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 08:22:53 -0000 --Apple-Mail=_1845883D-ED67-40B4-9361-470C110417B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (Top post - the quote level was getting unwieldy so I=E2=80=99ve = trimmed quite a bit from the discussion - hopefully it still makes = sense) > On 2 Jul 2019, at 01:10, Peter Thatcher wrote: >=20 >=20 >=20 > On Mon, Jun 17, 2019 at 7:13 AM T H Panton > wrote: >=20 >=20 >> On 17 Jun 2019, at 14:35, Victor Vasiliev = > wrote: >>=20 >> Hello friendly IETF dispatchers, >>=20 >> I am writing about new work I want to bring to IETF. The proposal is = called WebTransport. It=E2=80=99s a combination of a Web API currently = under development in W3C WICG [0], a protocol framework and some = protocols that fit into that framework. Combined, they would allow web = applications to establish WebSocket-like connections that instead of = ordered reliable messages use multiple streams and datagrams (datagrams = are unreliable and streams do not have head-of-line blocking). This is = highly useful for real-time and other latency sensitive applications. >=20 > Establish connections to where ? Between eachother P2P ? Or to any = server? Or just to the originating server only?=20 >=20 > Any server or p2p. > =20 Ok, great, but the requirements are different, and the OP seemed to be = claiming simplifications that to my mind only work client - server. >=20 > In client/server mode, WebTransport doesn't require any of that, so = it is a lot more simple.=20 Right. See above. But that becomes a null statement if you do want P2P = support . >=20 > Work is in progress decoupling the APIs from the (dreaded) SDP and = simplifying the developer experience. >=20 >=20 > What work? =20 Slow, slow, adoption of the ORTC interfaces.=20 > =20 > That said, it is by no means un-managable - I've implemented pretty = much the whole stack from scratch for small devices and I know of 2 = other implementations which don't use libusrsctp=20 >=20 >=20 > Maybe not for you, but we regularly get emails from people saying = things like "It would be great to delete the mess of the WebRTC stack if = there's a simpler protocol available. ICE/DTLS/SCTP all scare me=E2=80=9D.= Yeah, but not as much as ICE/QUIC-RT scares me. (which by the way = isn=E2=80=99t documented _anywhere_). > =20 >=20 >>=20 >> Even among the people who got past the complexity barrier, the = feedback I heard almost universally is that WebRTC Data Channels are = hard to work with. =46rom the feedback I gathered, the main problem is = usually around the transport protocol itself. Userspace SCTP is = essentially a monoculture: virtually all implementations use libusrsctp, = a 80,000-line adaptation of FreeBSD SCTP implementation. This lack of = tool choice is fairly painful since latency-sensitive real-time = applications often require quite a bit of tuning on the transport side = to get the best performance (custom congestion control, etc). In = addition, the limitations on the message size stemming from both the API = itself and the lack of widespread support for message interleaving (RFC = 8260) means that the developers have to roll their own framing on top of = SCTP messages if they want to avoid head-of-line-blocking (this is = particularly bad because the framing overhead in data channels is = already large as-is). >=20 > SCTP is well defined nice protocol that suffers (IMHO) from a lack of = 'coolness' due to being used by the telcos for most of it's life. > The head-of-line issue is a problem, but entirely fixable with small = tweaks to SCTP protocol. (read it wasn't in the original requirements - = so it doesn't do it). >=20 > It's been fixable for a very long time. I have my doubts about when = it will actually get fixed. With that being the view from a browser team you can see why people = choose not to donate time to submit patches that fix it. > =20 >=20 >>=20 >> In summary, we have a system that technically provides what everyone = wants, but that nobody is happy with, and that is not usable by all but = the most well-resourced users. >=20 > I'd point out that 2.5bn endpoints support it right now - including = _every_ smartphone shipped in the last 2 years. Last I heard DataChannel = traffic was 0.1% of chrome's traffic=20 > which is _astonishingly_ high >=20 >>=20 >> # Proposal >>=20 >> Our initial idea for fixing this was to take QUIC and do what = WebSocket did to TCP: add security features that would make it safe to = expose on the Web (by adding origin checks, etc), but otherwise expose = it as-is. This would get us out of libusrsctp monoculture (QUIC is not = yet finished, but it already has a fairly diverse implementation = ecosystem, see [3]), and remove all P2P-related complexity involving SDP = and ICE. The original proposal for that was called QuicTransport; we = showed it to various people, and the feedback we got is that (1) the API = should not be tied to a particular transport (since we already switched = once from SCTP to QUIC, tying it to QUIC specificially would not be = wise), and (2) it shouldn=E2=80=99t fail hard when QUIC is unavailable. >>=20 >=20 > It would be _great_ if that abstraction could _also_ work over SCTP = data channels. That way you could cover the P2P use cases too. >=20 > QUIC can be p2p. In fact, we already have it implemented in Chrome = (in an original trial). On top of ICE with a laughable security model no media and no RFC - not = a good basis (yet) for others to implement. >=20 > The WebTransport API could run on top of SCTP, and you could probably = make a JS polyfill for it. But I'm not sure why anyone would bother. 2.5 billion shipped endpoints. near 100% penetration in smartphones = today. >=20 > I'd really like to be clear what that problem is.=20 >=20 >=20 > Web developers routinely ask for an unreliable websocket, or something = close to UDP (but it needs to be secure). It turns out that = ICE/DTLS/SCTP is too complex to fill that roll. =20 I agree. If they want unreliable websockets to their servers, then we = can cut out most of the layers and produce something based on QUIC very simply. If they want P2P and want it to carry media (especially = audio) then there is a _lot_ of work to do to ensure it is usable, = secure etc. It seems to me the right way forward is to define a data-only interface = and PoC implementation that: 1) works with QUIC to the originating server almost immediately on one = or 2 of the QUIC stacks 2) has a polyfill on top of data channels so it can be used P2P = immediately 3) a companion GOLang/python server side implementation on top of the = existing webRTC (non usrsctp) libraries. 4) serves as a target/requiements for the necessary protocol work on = Quic-RT The realtime media can be added later. T. --Apple-Mail=_1845883D-ED67-40B4-9361-470C110417B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 (Top = post  - the quote level was getting unwieldy so I=E2=80=99ve = trimmed quite a bit from the discussion - hopefully it still makes = sense)

On 2 Jul 2019, at 01:10, Peter Thatcher = <pthatcher@google.com> wrote:



On Mon, Jun 17, 2019 at 7:13 AM T H Panton <thp@westhawk.co.uk> wrote:


On 17 Jun 2019, at 14:35, = Victor Vasiliev <vasilvv=3D40google.com@dmarc.ietf.org> wrote:

Hello friendly = IETF dispatchers,

I am writing about new = work I want to bring to IETF.  The proposal is called = WebTransport.  It=E2=80=99s a combination of a Web API currently = under development in W3C WICG [0], a protocol framework and some = protocols that fit into that framework.  Combined, they would allow = web applications to establish WebSocket-like connections that instead of = ordered reliable messages use multiple streams and datagrams (datagrams = are unreliable and streams do not have head-of-line blocking).  = This is highly useful for real-time and other latency sensitive = applications.

Establish connections to where ? = Between eachother P2P ? Or to any server? Or just to the originating = server only? 

Any server or p2p.
 

Ok, great, but the requirements are different, and = the OP seemed to be claiming simplifications that to my mind only = work
client - server.


 In client/server mode, WebTransport doesn't require any = of that, so it is a lot more simple. 

Right. = See above. But that becomes a null statement if you do want P2P support = .


Work is in progress = decoupling the APIs from the (dreaded) SDP and simplifying the developer = experience.


What work?  =  

Slow, = slow, adoption of the ORTC interfaces. 

 
That said, it is by no means = un-managable - I've implemented pretty much the whole stack from scratch = for small devices and I know of 2 other implementations which don't use = libusrsctp 


Maybe not for you, but we regularly get = emails from people saying things like "It would be great to delete the = mess of the WebRTC stack if there's a simpler protocol available. = ICE/DTLS/SCTP all scare me=E2=80=9D.
Yeah, but not as much as ICE/QUIC-RT scares me. = (which by the way isn=E2=80=99t documented _anywhere_).

 


Even among the = people who got past the complexity barrier, the feedback I heard almost = universally is that WebRTC Data Channels are hard to work = with.  =46rom the feedback I gathered, the main problem is usually = around the transport protocol itself.  Userspace SCTP is = essentially a monoculture: virtually all implementations use libusrsctp, = a 80,000-line adaptation of FreeBSD SCTP implementation.  This lack = of tool choice is fairly painful since latency-sensitive real-time = applications often require quite a bit of tuning on the transport side = to get the best performance (custom congestion control, etc).  In = addition, the limitations on the message size stemming from both the API = itself and the lack of widespread support for message interleaving (RFC = 8260) means that the developers have to roll their own framing on top of = SCTP messages if they want to avoid head-of-line-blocking (this is = particularly bad because the framing overhead in data channels is = already large as-is).

SCTP is well defined = nice protocol that suffers (IMHO) from a lack of 'coolness' due to being = used by the telcos for most of it's life.
The = head-of-line issue is a problem, but entirely fixable with small tweaks = to SCTP protocol. (read it wasn't in the original requirements - so it = doesn't do it).

It's been fixable for a very long = time.  I have my doubts about when it will actually get = fixed.

With = that being the view from a browser team you can see why people choose = not to donate time to submit patches that fix it.

 


In summary, we have a system that = technically provides what everyone wants, but that nobody is happy with, = and that is not usable by all but the most well-resourced users.

I'd point out that 2.5bn endpoints = support it right now - including _every_ smartphone shipped in the last = 2 years. Last I heard DataChannel traffic was 0.1% of chrome's = traffic 
which is _astonishingly_ = high


# Proposal

Our initial idea for fixing this was to take QUIC and do what = WebSocket did to TCP: add security features that would make it safe to = expose on the Web (by adding origin checks, etc), but otherwise expose = it as-is.  This would get us out of libusrsctp monoculture (QUIC is = not yet finished, but  it already has a fairly diverse = implementation ecosystem, see [3]), and remove all P2P-related = complexity involving SDP and ICE.  The original proposal for that = was called QuicTransport; we showed it to various people, and the = feedback we got is that (1) the API should not be tied to a particular = transport (since we already switched once from SCTP to QUIC, tying it to = QUIC specificially would not be wise), and (2) it shouldn=E2=80=99t fail = hard when QUIC is unavailable.


It would be _great_ if that abstraction = could _also_ work over SCTP data channels. That way you could cover the = P2P use cases too.

QUIC can be p2p.  In fact, we = already have it implemented in Chrome (in an original = trial).

On = top of ICE with a laughable security model no media and no RFC - not a = good basis (yet) for others to implement.


The WebTransport API = could run on top of SCTP, and you could probably make a JS polyfill for = it.  But I'm not sure why anyone would = bother.

2.5 = billion shipped endpoints. near 100% penetration in smartphones = today.


I'd = really like to be clear what that problem is. 


Web developers routinely ask for an = unreliable websocket, or something close to UDP (but it needs to be = secure).   It turns out that ICE/DTLS/SCTP is too complex to = fill that roll.  

I agree. If they want unreliable websockets to = their servers, then we can cut out most of the layers and produce = something based on QUIC
very simply. If they want P2P and want = it to carry media (especially audio) then there is a _lot_ of work to do = to ensure it is usable, secure etc.

It= seems to me the right way forward is to define a data-only interface = and PoC implementation that:

1) = works with QUIC to the originating server almost immediately on one or 2 = of the QUIC stacks
2) has a polyfill on top of data channels = so it can be used P2P immediately
3) a companion GOLang/python = server side implementation on top of the existing webRTC (non usrsctp) = libraries.
4) serves as a target/requiements for the necessary = protocol work on Quic-RT

The = realtime media can be added later.

T.



= --Apple-Mail=_1845883D-ED67-40B4-9361-470C110417B2-- From nobody Tue Jul 2 02:46:20 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7068412004E for ; Tue, 2 Jul 2019 02:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 0uTKbXfew-LM for ; Tue, 2 Jul 2019 02:46:17 -0700 (PDT) Received: from smtp001-out2.apm-internet.net (smtp001-out2.apm-internet.net [85.119.248.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF4012004C for ; Tue, 2 Jul 2019 02:46:16 -0700 (PDT) Received: (qmail 66332 invoked from network); 2 Jul 2019 09:46:14 -0000 X-APM-Out-ID: 15620607746630 X-APM-Authkey: 255286/0(159927/0) 443 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 2 Jul 2019 09:46:14 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 00DB918A06D1; Tue, 2 Jul 2019 10:46:13 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8Df0tftKnbyC; Tue, 2 Jul 2019 10:46:13 +0100 (BST) Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id C6A0918A05FD; Tue, 2 Jul 2019 10:46:13 +0100 (BST) From: westhawk Message-Id: <447CFF6A-37FB-422F-B65D-4BB76F2E5CB0@westhawk.co.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_2F147E74-942D-4835-8111-E17AC09DAC91" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 2 Jul 2019 10:46:13 +0100 In-Reply-To: Cc: Victor Vasiliev , dispatch@ietf.org To: Peter Thatcher References: <98EF12E4-4BF2-4FBC-852B-776A0E0118BE@westhawk.co.uk> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dispatch] Dispatching WebTransport X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 09:46:19 -0000 --Apple-Mail=_2F147E74-942D-4835-8111-E17AC09DAC91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 2 Jul 2019, at 01:10, Peter Thatcher wrote: >=20 > Maybe not for you, but we regularly get emails from people saying = things like "It would be great to delete the mess of the WebRTC stack if = there's a simpler protocol available. ICE/DTLS/SCTP all scare me=E2=80=9D.= To be clear, I utterly sympathise with this viewpoint - no one in their = right minds wants to pull libwebrtc into their server codebase. I took one look at it and decided to write a fresh implementation that = better suited my needs. The fact that I could do that is due to the existence of RFCs for all of = the webRTC stack layers. When implementing the datachannel I did ask a few questions of the = experts, their replies were pointers to the relevant bits of the RFCs. QUIC-RT simply isn=E2=80=99t in that = position yet. T. --Apple-Mail=_2F147E74-942D-4835-8111-E17AC09DAC91 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 2 Jul 2019, at 01:10, Peter Thatcher <pthatcher@google.com> wrote:

Maybe not for you, but we = regularly get emails from people saying things like "It would be great = to delete the mess of the WebRTC stack if there's a simpler protocol = available. ICE/DTLS/SCTP all scare = me=E2=80=9D.

To be = clear, I utterly sympathise with this viewpoint - no one in their right = minds wants to pull libwebrtc into their server codebase.

I took one look at it and decided to write a fresh = implementation that better suited my needs.
The fact that I = could do that is due to the existence of RFCs for all of the =  webRTC stack layers.

When = implementing the datachannel I did ask a few questions of the experts, = their replies were pointers
to the relevant bits of the RFCs. = QUIC-RT simply isn=E2=80=99t in that position yet.

T.

= --Apple-Mail=_2F147E74-942D-4835-8111-E17AC09DAC91-- From nobody Mon Jul 8 11:48:58 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82721206F4 for ; Mon, 8 Jul 2019 11:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.204 X-Spam-Level: X-Spam-Status: No, score=-16.204 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 xBv5ZJkltaQB for ; Mon, 8 Jul 2019 11:48:52 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 7D57B120738 for ; Mon, 8 Jul 2019 11:48:17 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id u3so8900522vsh.6 for ; Mon, 08 Jul 2019 11:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9W7vZ91kfCiohRf/RF8Dob18AIHm59SGwc91LE+ifI8=; b=LH29mj08dim0Zs5KubDldj0q/1ePDUH482Kg4aUiftcMZQRfRbDU4isZ3k2zuZeLCO FZhiYsxZ4Lzg+T1pNQ30PQVZ0dd45klXHsdk+b7S4e4ycK4XCkjXZxya18llv8/EACcX Nng+KYkcUoqLfoonhFmFajOJph/2WIiflZeNme8pETO1Li5cvez9bwiHkUpym2NmX5xE jm21RTU5wabscjkQAgXCv1qujZLMz/p+U8Ha7ChzFiAdzqRyGgVOLsTIFaxKe+eV5G/+ I1OW9mjgg2q8exrNTxuHK+dAU4eDL3rs5Xprwj78F/s7b5xvcRSwcWm8MnlS371bD7mH 6XpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9W7vZ91kfCiohRf/RF8Dob18AIHm59SGwc91LE+ifI8=; b=QHz/io/LEYNeTWi+ozopfTnysf0Ux3Sr+/pGcMyI4u3urtN0dWiOIAwSD78R0MJkKz 0/+V4fzJfP8LRZ1UUJdw2gwBSsabbltMv79Vfdp82Ok23QsDiRlwXPkQ0ldTDxSa2YRl SaWSneO76qZgCrjPkslCrGDO0Lzu+mbirH7KpiUql32GhEJAwGXP36ExU3gV377pNsGR cn+g97dsLg73GL/i7KWVLLX4c7Pg9fhFNmVcEnhSpxPpEW3AO8h3raH/8oTzkOofwI6F lB7iQhqSn4uPWzDgisgzSyLH9ZJzMe7qHLM0N3Erx0vbfxtgq/eTe0AzuNdCR8X3Cj9B sC6A== X-Gm-Message-State: APjAAAUyTOmKwZbRWWMvQzgCeqAIEk/hGCTyy1Cz9zVihPBHRBvMaQ9r s729LGRb8Yn0RWNE6BRqNrKBDkdiKAKDos3yn7o9ThLUiTBVQw== X-Google-Smtp-Source: APXvYqzaRVsZiT9yADIuiQH2Rixdrmu1L7OLKnMrpf2f4Mo4GUtSJKVxQEHETCXpiK+iGdS6j1ykn6Y9hbbwND+LW2U= X-Received: by 2002:a67:e41a:: with SMTP id d26mr11237795vsf.71.1562611695787; Mon, 08 Jul 2019 11:48:15 -0700 (PDT) MIME-Version: 1.0 References: <98EF12E4-4BF2-4FBC-852B-776A0E0118BE@westhawk.co.uk> In-Reply-To: From: Peter Thatcher Date: Mon, 8 Jul 2019 11:47:39 -0700 Message-ID: To: westhawk Cc: Victor Vasiliev , dispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000000d2dce058d2fe3a8" Archived-At: Subject: Re: [dispatch] Dispatching WebTransport X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 18:48:56 -0000 --0000000000000d2dce058d2fe3a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 2, 2019 at 1:22 AM westhawk wrote: > (Top post - the quote level was getting unwieldy so I=E2=80=99ve trimmed= quite a > bit from the discussion - hopefully it still makes sense) > > On 2 Jul 2019, at 01:10, Peter Thatcher wrote: > > > > On Mon, Jun 17, 2019 at 7:13 AM T H Panton wrote: > >> >> >> On 17 Jun 2019, at 14:35, Victor Vasiliev < >> vasilvv=3D40google.com@dmarc.ietf.org> wrote: >> >> Hello friendly IETF dispatchers, >> >> I am writing about new work I want to bring to IETF. The proposal is >> called WebTransport. It=E2=80=99s a combination of a Web API currently = under >> development in W3C WICG [0], a protocol framework and some protocols tha= t >> fit into that framework. Combined, they would allow web applications to >> establish WebSocket-like connections that instead of ordered reliable >> messages use multiple streams and datagrams (datagrams are unreliable an= d >> streams do not have head-of-line blocking). This is highly useful for >> real-time and other latency sensitive applications. >> >> >> Establish connections to where ? Between eachother P2P ? Or to any >> server? Or just to the originating server only? >> > > Any server or p2p. > > > > Ok, great, but the requirements are different, and the OP seemed to be > claiming simplifications that to my mind only work > client - server. > > > In client/server mode, WebTransport doesn't require any of that, so it i= s > a lot more simple. > > > Right. See above. But that becomes a null statement if you do want P2P > support . > > > Work is in progress decoupling the APIs from the (dreaded) SDP and >> simplifying the developer experience. >> >> > What work? > > > Slow, slow, adoption of the ORTC interfaces. > > >> That said, it is by no means un-managable - I've implemented pretty much >> the whole stack from scratch for small devices and I know of 2 other >> implementations which don't use libusrsctp >> >> > Maybe not for you, but we regularly get emails from people saying things > like "It would be great to delete the mess of the WebRTC stack if there's= a > simpler protocol available. ICE/DTLS/SCTP all scare me=E2=80=9D. > > > Yeah, but not as much as ICE/QUIC-RT scares me. (which by the way isn=E2= =80=99t > documented _anywhere_). > > > >> >> >> Even among the people who got past the complexity barrier, the feedback = I >> heard almost universally is that WebRTC Data Channels are hard to work >> with. From the feedback I gathered, the main problem is usually around = the >> transport protocol itself. Userspace SCTP is essentially a monoculture: >> virtually all implementations use libusrsctp, a 80,000-line adaptation o= f >> FreeBSD SCTP implementation. This lack of tool choice is fairly painful >> since latency-sensitive real-time applications often require quite a bit= of >> tuning on the transport side to get the best performance (custom congest= ion >> control, etc). In addition, the limitations on the message size stemmin= g >> from both the API itself and the lack of widespread support for message >> interleaving (RFC 8260) means that the developers have to roll their own >> framing on top of SCTP messages if they want to avoid head-of-line-block= ing >> (this is particularly bad because the framing overhead in data channels = is >> already large as-is). >> >> >> SCTP is well defined nice protocol that suffers (IMHO) from a lack of >> 'coolness' due to being used by the telcos for most of it's life. >> The head-of-line issue is a problem, but entirely fixable with small >> tweaks to SCTP protocol. (read it wasn't in the original requirements - = so >> it doesn't do it). >> > > It's been fixable for a very long time. I have my doubts about when it > will actually get fixed. > > > With that being the view from a browser team you can see why people choos= e > not to donate time to submit patches that fix it. > > > >> >> >> In summary, we have a system that technically provides what everyone >> wants, but that nobody is happy with, and that is not usable by all but = the >> most well-resourced users. >> >> >> I'd point out that 2.5bn endpoints support it right now - including >> _every_ smartphone shipped in the last 2 years. Last I heard DataChannel >> traffic was 0.1% of chrome's traffic >> which is _astonishingly_ high >> > >> >> # Proposal >> >> Our initial idea for fixing this was to take QUIC and do what WebSocket >> did to TCP: add security features that would make it safe to expose on t= he >> Web (by adding origin checks, etc), but otherwise expose it as-is. This >> would get us out of libusrsctp monoculture (QUIC is not yet finished, bu= t >> it already has a fairly diverse implementation ecosystem, see [3]), and >> remove all P2P-related complexity involving SDP and ICE. The original >> proposal for that was called QuicTransport; we showed it to various peop= le, >> and the feedback we got is that (1) the API should not be tied to a >> particular transport (since we already switched once from SCTP to QUIC, >> tying it to QUIC specificially would not be wise), and (2) it shouldn=E2= =80=99t >> fail hard when QUIC is unavailable. >> >> >> It would be _great_ if that abstraction could _also_ work over SCTP data >> channels. That way you could cover the P2P use cases too. >> > > QUIC can be p2p. In fact, we already have it implemented in Chrome (in a= n > original trial). > > > On top of ICE with a laughable security model no media and no RFC - not a > good basis (yet) for others to implement. > > It's the same security model as the RTCDataChannel uses, and it can transfer media just fine (transport doesn't care if it's media or not). As for RFCs, there are ICE and QUIC RFCs. What more do you need? If you tried to write a "ICE + QUIC" RFC, I'm pretty sure it would be all boilerplate and no actual text. > > The WebTransport API could run on top of SCTP, and you could probably mak= e > a JS polyfill for it. But I'm not sure why anyone would bother. > > > 2.5 billion shipped endpoints. near 100% penetration in smartphones today= . > > >> I'd really like to be clear what that problem is. >> >> > Web developers routinely ask for an unreliable websocket, or something > close to UDP (but it needs to be secure). It turns out that ICE/DTLS/SC= TP > is too complex to fill that roll. > > > I agree. If they want unreliable websockets to their servers, then we can > cut out most of the layers and produce something based on QUIC > very simply. If they want P2P and want it to carry media (especially > audio) then there is a _lot_ of work to do to ensure it is usable, secure > etc. > > When you say "a lot" of work, what do you mean? You can already send audio on top of the QUIC-based WebTransport we have in origin trial and it's usable and secure. It would be nice to have low-level audio codec APIs in the browser (which we are working on), but it's feasible to do audio codecs in WASM in conjunction with WebAudio. The only thing that seems like an issue is proving out whether or not one can implement a good audio jitter buffer in WASM/JS (or port NetEq). That is work left to be done, indeed. Is that what you were referring to? > It seems to me the right way forward is to define a data-only interface > and PoC implementation that: > > 1) works with QUIC to the originating server almost immediately on one or > 2 of the QUIC stacks > I'm not completely sure what you mean here by "one or two of the QUIC stacks", but see #3 below for code that can (hopefully soon) can do the server side. 2) has a polyfill on top of data channels so it can be used P2P immediately > 3) a companion GOLang/python server side implementation on top of the existing webRTC (non usrsctp) libraries. I have one in progress: https://github.com/pthatcherg/quic-go/blob/gquic/example/webtransport/serve= r.go . I don't quite have it working, but it's close. And there is also this one: https://github.com/pion/webrtc/blob/736e0bb5062c473a61d9aae0dbb3bac7f32db37= 7/quictransport.go 4) serves as a target/requiements for the necessary protocol work on Quic-R= T > > The realtime media can be added later. > > T. > > > > --0000000000000d2dce058d2fe3a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 2, 2019 at 1:22 AM westha= wk <thp@westhawk.co.uk> wro= te:
(Top post =C2=A0- the quote level was getti= ng unwieldy so I=E2=80=99ve trimmed quite a bit from the discussion - hopef= ully it still makes sense)

On 2 = Jul 2019, at 01:10, Peter Thatcher <pthatcher@google.com> wrote:



On Mon, Jun 17, 2019 at 7:13 AM T H Panton <thp@westhawk.co.uk> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">


On 17 Jun 2019, at 14:35, Victor Vasiliev <vasilv= v=3D40google.com@dmarc.ietf.org> wrote:

Hello friendly IETF dispatchers,
=
I am writing about new work I want to bring to IETF.=C2=A0 The proposal= is called WebTransport.=C2=A0 It=E2=80=99s a combination of a Web API curr= ently under development in W3C WICG [0], a protocol framework and some prot= ocols that fit into that framework.=C2=A0 Combined, they would allow web ap= plications to establish WebSocket-like connections that instead of ordered = reliable messages use multiple streams and datagrams (datagrams are unrelia= ble and streams do not have head-of-line blocking).=C2=A0 This is highly us= eful for real-time and other latency sensitive applications.

Establish connections to where ? Between = eachother P2P ? Or to any server? Or just to the originating server only?= =C2=A0

Any server or p2p.=
=C2=A0

Ok, gre= at, but the requirements are different, and the OP seemed to be claiming si= mplifications that to my mind only work
client - server.

=C2=A0In client/server mode, WebTransport doesn't require= any of that, so it is a lot more simple.=C2=A0

Right. See above. But that becomes a null statement if= you do want P2P support .


Work is in progress deco= upling the APIs from the (dreaded) SDP and simplifying the developer experi= ence.


What= work?=C2=A0 =C2=A0

Slow,= slow, adoption of the ORTC interfaces.=C2=A0
=C2=A0
That said, it is by no means un-man= agable - I've implemented pretty much the whole stack from scratch for = small devices and I know of 2 other implementations which don't use lib= usrsctp=C2=A0


<= div>Maybe not for you, but we regularly get emails from people saying thing= s like "It would be great to delete the mess of the WebRTC stack if th= ere's a simpler protocol available. ICE/DTLS/SCTP all scare me=E2=80=9D= .

Yeah, but not as much a= s ICE/QUIC-RT scares me. (which by the way isn=E2=80=99t documented _anywhe= re_).

=C2=A0


Even among the people who got past the complexity barrier, the feed= back I heard almost universally=C2=A0is that WebRTC Data Channels are hard = to work with.=C2=A0 From the feedback I gathered, the main problem is usual= ly around the transport protocol itself.=C2=A0 Userspace SCTP is essentiall= y a monoculture: virtually all implementations use libusrsctp, a 80,000-lin= e adaptation of FreeBSD SCTP implementation.=C2=A0 This lack of tool choice= is fairly painful since latency-sensitive real-time applications often req= uire quite a bit of tuning on the transport side to get the best performanc= e (custom congestion control, etc).=C2=A0 In addition, the limitations on t= he message size stemming from both the API itself and the lack of widesprea= d support for message interleaving (RFC 8260) means that the developers hav= e to roll their own framing on top of SCTP messages if they want to avoid h= ead-of-line-blocking (this is particularly bad because the framing overhead= in data channels is already large as-is).

SCTP is well defined nice protocol that suffers (IMHO) from= a lack of 'coolness' due to being used by the telcos for most of i= t's life.
The head-of-line issue is a problem, but entirely f= ixable with small tweaks to SCTP protocol. (read it wasn't in the origi= nal requirements - so it doesn't do it).
=

It's been fixable for a very long time.=C2=A0 I hav= e my doubts about when it will actually get fixed.

With that being the view from a browser team you = can see why people choose not to donate time to submit patches that fix it.=

=C2=A0


In sum= mary, we have a system that technically provides what everyone wants, but t= hat nobody is happy with, and that is not usable by all but the most well-r= esourced users.

I'd poi= nt out that 2.5bn endpoints support it right now - including _every_ smartp= hone shipped in the last 2 years. Last I heard DataChannel traffic was 0.1%= of chrome's traffic=C2=A0
which is _astonishingly_ high


# Propos= al

Our initial idea for fixing this was to take QUIC and do what Web= Socket did to TCP: add security features that would make it safe to expose = on the Web (by adding origin checks, etc), but otherwise expose it as-is.= =C2=A0 This would get us out of libusrsctp monoculture (QUIC is not yet fin= ished, but=C2=A0 it=C2=A0already has a fairly diverse implementation ecosys= tem, see [3]), and remove all P2P-related complexity involving SDP and ICE.= =C2=A0 The original proposal for that was called QuicTransport; we showed i= t to various people, and the feedback we got is that (1) the API should not= be tied to a particular transport (since we already switched once from SCT= P to QUIC, tying it to QUIC specificially would not be wise), and (2) it sh= ouldn=E2=80=99t fail hard when QUIC is unavailable.


It would be _great_ if that abstraction could = _also_ work over SCTP data channels. That way you could cover the P2P use c= ases too.

QUIC can be p2p= .=C2=A0 In fact, we already have it implemented in Chrome (in an original t= rial).

On top of ICE with= a laughable security model no media and no RFC - not a good basis (yet) fo= r others to implement.


It's the same security model as the RTCDataChannel uses, and it can t= ransfer media just fine (transport doesn't care if it's media or no= t).=C2=A0 As for RFCs, there are ICE and QUIC RFCs.=C2=A0 What more do you = need?=C2=A0 If you tried to write a "ICE=C2=A0+ QUIC" RFC, I'= m pretty sure it would be all boilerplate and no actual text.

The WebTransport API could run on top = of SCTP, and you could probably make a JS polyfill for it.=C2=A0 But I'= m not sure why anyone would bother.

=
2.5 billion shipped endpoints. near 100% penetration in smartphones t= oday.


I= 9;d really like to be clear what that problem is.=C2=A0


Web developers routinely ask for an unre= liable websocket, or something close to UDP (but it needs to be secure).=C2= =A0 =C2=A0It turns out that ICE/DTLS/SCTP is too complex to fill that roll.= =C2=A0=C2=A0

I agree. If = they want unreliable websockets to their servers, then we can cut out most = of the layers and produce something based on QUIC
very simply. If= they want P2P and want it to carry media (especially audio) then there is = a _lot_ of work to do to ensure it is usable, secure etc.


When you say "a lot" of work= , what do you mean?=C2=A0 You can already send audio on top of the QUIC-bas= ed WebTransport we have in origin trial and it's usable and secure.=C2= =A0 It would be nice to have low-level audio codec APIs in the browser (whi= ch we are working on), but it's feasible to do audio codecs in WASM in = conjunction with WebAudio.

The only thing that see= ms like an issue is proving out whether or not one can implement a good aud= io jitter buffer in WASM/JS (or port NetEq).=C2=A0 That is work left to be = done, indeed.=C2=A0 Is that what you were referring to?

=C2=A0
It seems to me the = right way forward is to define a data-only interface and PoC implementation= that:

1) works with QUIC to the originating serve= r almost immediately on one or 2 of the QUIC stacks

I'm not completely sure what you mean here b= y "one or two of the QUIC stacks", but see #3 below for code that= can (hopefully soon) can do the server side.

2) has a polyfill on top of data channels so it can be us= ed P2P immediately
=C2=A03) a companion = GOLang/python server side implementation on top of the existing webRTC (non= usrsctp) libraries.

I have one in progress:=C2=A0= https://github.com/pthatcherg/quic-go/blob/gquic/example/w= ebtransport/server.go=C2=A0.=C2=A0 I don't quite have it working, b= ut it's close.

4) serves as a target/requiements for th= e necessary protocol work on Quic-RT

The realtime = media can be added later.

T.

<= /div>

--0000000000000d2dce058d2fe3a8-- From nobody Wed Jul 10 09:49:24 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F1E120047; Wed, 10 Jul 2019 09:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 vOgqjvBYF19u; Wed, 10 Jul 2019 09:49:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 DA65712013C; Wed, 10 Jul 2019 09:49:13 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6AGn5Cq050092 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Jul 2019 11:49:07 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1562777347; bh=NP8pIBsRIBG8hlMGrHR73lKGae1N1X/wvPyBksVcNEg=; h=From:Subject:Date:Cc:To; b=O0IyGcWCTPekPRXDXA2+jTW7tBHPJAtTu8VYY2NXiJUr5SRFMW77ZdNAnHzCChLAL v/JNPBUDywOCWWhVHPniWEq4weT6r4uoMD0SHLZVmxjyPgRbNnRYGfBCscEwxYUvtV puXK5dEu6mm2YXAiubKV1Xi+CcHpCGvzc/R15vQQ= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_13569C3C-8FDE-4DAC-A21C-8B47C77E9CB4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Wed, 10 Jul 2019 11:48:59 -0500 Cc: Mary Barnes , ART ADs To: DISPATCH X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [dispatch] IETF105 DISPATCH Agenda X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 16:49:16 -0000 --Apple-Mail=_13569C3C-8FDE-4DAC-A21C-8B47C77E9CB4 Content-Type: multipart/alternative; boundary="Apple-Mail=_FCB44BC9-46B4-420E-8735-BF7A98600854" --Apple-Mail=_FCB44BC9-46B4-420E-8735-BF7A98600854 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All, The preliminary agenda for the IETF105 DISPATCH meeting ia available at = https://datatracker.ietf.org/meeting/105/materials/agenda-105-dispatch-00 = . A text version is copied below for your convenience, but please bear = in mind that the agenda may change between now and the meeting. Also, please notice that DISPATCH will be in the last afternoon session = on Monday, rather than the usual Monday morning session. Thanks! Ben =E2=80=94=E2=80=94=E2=80=94 # Agenda DISPATCH @IETF-105 - v2 DISPATCH Meeting ---------------- ### Status and agenda bash - Chairs and ADs (10 min) ### WebTransport - Victor Vasiliev (20 min) = [Overview](https://tools.ietf.org/html/draft-vvv-webtransport-overview-00)= [QUIC = Transport](https://tools.ietf.org/html/draft-vvv-webtransport-quic-00) [H3 = Transport](https://tools.ietf.org/html/draft-vvv-webtransport-http3-00) = [Discussion](https://mailarchive.ietf.org/arch/msg/dispatch/sIih9gBhJ4_fao= N0GrQ9Xweue2w) See [DISPATCH wiki](https://trac.ietf.org/trac/dispatch/wiki) for = additional links to materials. ART AREA Meeting ---------------- ### BoFs and meetings of interest - ADs (10 min) ### Real Time Internet Peering Protocol (RIPP) - Cullen Jennings (10 = min) = [Draft](https://tools.ietf.org/html/draft-rosenbergjennings-dispatch-ripp-= 02) ### BCP 190 Applicability to TRANS - TBD (10 min) = [Discussion](https://mailarchive.ietf.org/arch/msg/trans/_P51dDMy_-Mo3lojb= ijQPySv3q8) ## AOB --Apple-Mail=_FCB44BC9-46B4-420E-8735-BF7A98600854 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi All,

The preliminary agenda = for the IETF105 DISPATCH meeting ia available at https://datatracker.ietf.org/meeting/105/materials/agenda-105-d= ispatch-00. A text version is copied below for your convenience, but = please bear in mind that the agenda may change between now and the = meeting.

Also, = please notice that DISPATCH will be in the last afternoon session on = Monday, rather than the usual Monday morning session.

Thanks!

Ben

=E2=80=94=E2=80=94=E2=80=94=

# Agenda DISPATCH @IETF-105 - v2

DISPATCH Meeting 
----------------

### Status and agenda bash - Chairs and ADs (10 = min)

### = WebTransport - Victor Vasiliev (20 min)

[Overview](https://tools.ietf.org/html/draft-vvv-webtransport-overview-00<= /a>)  
[QUIC Transport](https://tools.ietf.org/html/draft-vvv-webtransport-quic-00)=  
[H3 Transport](https://tools.ietf.org/html/draft-vvv-webtransport-http3-00= )  
[Discussion](https://mailarchive.ietf.org/arch/msg/dispatch/sIih9gBhJ4_faoN0= GrQ9Xweue2w)
  
See [DISPATCH wiki](https://trac.ietf.org/trac/dispatch/wiki) for additional = links to materials.

ART AREA Meeting 
----------------

### BoFs and meetings of interest - ADs (10 min)

### Real Time Internet = Peering Protocol (RIPP) - Cullen Jennings (10 min)

[Draft](https://tools.ietf.org/html/draft-rosenbergjennings-dispatch-ri= pp-02)

### = BCP 190 Applicability to TRANS - TBD (10 min)

[Discussion](https://mailarchive.ietf.org/arch/msg/trans/_P51dDMy_-Mo3lojbij= QPySv3q8)

##= AOB
= --Apple-Mail=_FCB44BC9-46B4-420E-8735-BF7A98600854-- --Apple-Mail=_13569C3C-8FDE-4DAC-A21C-8B47C77E9CB4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAl0mFvsACgkQgFZKbJXz 1A0u3g/+M1OBgA1uWAxWVdCRSQ/Xx3NCs4Azl27WO8nq5NR1vNUlwdyQciMXERzp wjD0dTC9h+aeUw3ifvj4Y5m8jMN6QHQKsj4cYGSjnbmpBJZO2hlfamZq+8ILOoQt wRjIVycIy+iQafxowfPGIB+Z58nD0BaERn+PTx+A1E3UrFrpi0FebcxyLIeBrEBd BYV6O/aGGBSMpvJ6k13Mb1FpR0SuPTp63OtiScOgB7YOVy9aHwdtH39cs0Je7dpg k3o/iE1B8qY7uBQsdvIJWqR9O9qLDBdJUQ3NaVj4VLNYn0y9nFU3Uo5I9zVhkiiU MFBUvOn+F3u+clzMXwdO55QSNG5+eDIDDdEE9QO5PaFBwWQafGBfAQpQoD/xfhIg OdQEmV35T0OkzlmZ4c9CxpYalbHBrs1KcNrZdFzWfDFTPSV0rYmHBpecuJJ14gO5 /984ky2NvOV1EUQoYEETQBBGvu0Ekj+GpdrcNSdcF11HSK8XsigP8/dxRkr8TW7R iqPb11+0XVn9wqMMGExasr8u3kiIbTyiiodBtaxo/zFIJxiIP97RpDCl+By/jfBL Pk63ETsWSd8Rk7ep6p2k4ganKa1xcOsauV9RfMMJpP55LMyDeiyNnO3zYSaN4nRI UqfMgXevYAMEuSOGe++ViehkTU2WrwcHOJ0G4oTygq09uSqcC+8= =6/Jy -----END PGP SIGNATURE----- --Apple-Mail=_13569C3C-8FDE-4DAC-A21C-8B47C77E9CB4-- From nobody Wed Jul 10 13:00:01 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDE712004D for ; Wed, 10 Jul 2019 12:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LIK-LGh4x2SS for ; Wed, 10 Jul 2019 12:59:58 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 0355512004A for ; Wed, 10 Jul 2019 12:59:58 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id i21so3338924ljj.3 for ; Wed, 10 Jul 2019 12:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=UkaZpjXGJe07DPF25YfVJJOZBLxqNrT2zrRUdEju3yA=; b=f9k1k0Wu+tnnTZzUX6oX1bsjJTKsRsuo+BAuSwLhmBiT7ohWVL0DudL2e1noe48Qt0 Z6jRpqa3cGeAO33LBtjLVz823TPlpfV5+v7tFVbRfs6yPPC7bHC8cH5DsFTMf2KDd/HY htRexxN35m5ecXXRkNI/5IMmV8uDX+ssBeB4AIjCiebr4I+vtHe0dF0iMJFuWFrLKX5z 17Yp5d/Kuv4Cg8WyM7U0BwzPWmwbb9nZfsT0gr+zSa3Q5Y4fWadJQ/xGx6fKWGRhrKrd j0ZRJvVDfKOVUWzUUFVj+FDpBWg/kY+GUChY4txeHLOkEGwLIhylfNPtEHXA3qBmqCX1 Dfrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=UkaZpjXGJe07DPF25YfVJJOZBLxqNrT2zrRUdEju3yA=; b=mqUNOvtaeIJ7xjmQ+jblcEBCvKQFInYyIy/RnqGffKOr89Wl0htw2505Zbt6QnQEMZ WJsbSvxLThdf0Iv4S7q4LlQL0woWqzMkXkLom7SluC74xuSHBDtJAaLE7j6fttZKPfkl Zdc/KvuuISwZPVoi/kkqiGQeAMCWx6qEcei0mnT1vXNboU5Nyi8dqX6rNw6kVUxFx3y2 c0BYd5we3RFuimTWBPVJB3apLhKY60GumzGY4XOBxhEjhWNrY4TaSw32NwcBiMIvOzfp 9SJh9BlwqYNivV5v9N/j7ww32okff7SS9RPjjxn0umu4MK+lPyLfHHjMZA5mQHT/T2yl HkOw== X-Gm-Message-State: APjAAAViwf0BzKtNK4yfSJqvvczNJ8WauiQ8GkHiP5EtGbcSU6PLLyIC cnPFNYh0K4BpO88rmoSAX1inaoS6dejb0CwjIpH9KVmp X-Google-Smtp-Source: APXvYqzo/xYo/g5RBK+xVnrNMN0hLjazDxu095lHu9HxHwsOrcR2pa1pQupsrN+hd90on7HjRCXrrMnSBPtterELjJw= X-Received: by 2002:a2e:89ca:: with SMTP id c10mr20903ljk.106.1562788795639; Wed, 10 Jul 2019 12:59:55 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Wed, 10 Jul 2019 12:59:45 -0700 Message-ID: To: DISPATCH list Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary="00000000000005eca2058d591fcd" Archived-At: Subject: Re: [dispatch] Dispatching WebTransport (boiling it down) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 20:00:00 -0000 --00000000000005eca2058d591fcd Content-Type: text/plain; charset="UTF-8" Inaki Baz Castillo said: "if this is a pure client-to-server transport, why is webrtc mentioned in the background at all? shouldn't this be a replacement of websockets and NOT of the webrtc datachannels?" [BA] Indeed. The protocol proposals in draft-vvv-webtransport-quic and draft-vvv-webtransport-http3 relate to the client/server scenario, and so issues relating to peer-to-peer operation, ICE, WebRTC, W3C APIs, etc. seem to be peripheral. To my mind, draft-vvv-webtransport-http3 appears to raise the following question: "Do we need additional work to update "Bootstrapping WebSockets with HTTP/2" (RFC 8441), in order to enable bootstrapping {bi-directional stream, uni-directional stream, datagrams} on HTTP/3"? Given that QUIC offers relief from TCP's head-of-line blocking problems, one can make the case that WebTransport(s) over HTTP/3 will perform better than WebSocket(s) over HTTP/2. Also, I can see uses for a uni-directional stream (server -> client or client -> server). And with the recent interest in streaming over unreliable transport (e.g. SRT), the datagram mode could come in handy as well. Since draft-ietf-quic-transport only covers bi-directional and uni-directional streams, it might make sense to focus on that functionality initially and then add datagrams support once we understand how and where QUIC datagrams (as described in draft-pauly-quic-datagram ) will be progressed. --00000000000005eca2058d591fcd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Inaki Baz Castillo said:=C2=A0

"if this is a pure client-to-server transp= ort, why is webrtc mentioned in the background at all? shouldn't this b= e a replacement of websockets and NOT of the webrtc datachannels?&qu= ot;

[BA] Indeed.=C2=A0 The protocol proposals in d= raft-vvv-webtransport-quic and draft-vvv-webtransport-http3 relate to the c= lient/server scenario, and so issues relating to peer-to-peer operation, IC= E, WebRTC, W3C APIs, etc. seem to be peripheral.=C2=A0

=
To my mind, draft-vvv-webtransport-http3 appears to raise the followin= g question:=C2=A0

"Do we need additional work= to update "Bootstrapping WebSockets with HTTP/2" (RFC 8441), in orde= r to enable bootstrapping {bi-directional stream, uni-directional stream, d= atagrams} on HTTP/3"?=C2=A0

Given that QUIC o= ffers relief from TCP's head-of-line blocking problems, one can make th= e case that WebTransport(s) over HTTP/3 will perform better than WebSocket(= s) over HTTP/2. Also, I can see uses for a uni-directional stream (server -= > client or client -> server). And with the recent interest in stream= ing over unreliable transport (e.g. SRT), the datagram mode could come in h= andy as well.=C2=A0

Since draft-ietf-quic-transpor= t only covers bi-directional and uni-directional streams, it might make sen= se to focus on that functionality initially and then add datagrams support = once we understand how and where QUIC datagrams (as described in=C2=A0draft= -pauly-quic-datagram ) will be progressed.






--00000000000005eca2058d591fcd-- From nobody Thu Jul 11 01:35:15 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DD0120133 for ; Thu, 11 Jul 2019 01:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.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 bwzIXIJHjk-U for ; Thu, 11 Jul 2019 01:35:08 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 01653120122 for ; Thu, 11 Jul 2019 01:35:07 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id 8so2028675uaz.11 for ; Thu, 11 Jul 2019 01:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RN/GWNU0l+3xHAz/gV8y5FxR8FfG/O/wBsK4XrKEgW8=; b=jQ7fMl0G4hGQE36CRtuX3+RiNof15vUd8e9qvRhWETC4nIY07rzh/61Ava+RaQ3vT2 ZaTGdafeVNGcSUs+VQHsCMUmslGc1/c1EF1T4QJ2seao0THrYah3T83edLFBFdY311vn E+IQmDKikCjCkbNcLAQagVTNXJeOmVmXA6JpJPq+d/spsejXIiF1J1X/5QyNWmx8GG6J J71TTaFb1Y9wuTF2r+RfrjYfp0cTkrrH41pGmp/+pbkThZz1bqhWoG6j+qJK87qHDRwd X3Viyb+V9jYGS4W8wSaQW9Wa3BjcHsPnyTVBZRTgSIJq/5ASOb99Hd3szANyE7KZ/Utk AjPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RN/GWNU0l+3xHAz/gV8y5FxR8FfG/O/wBsK4XrKEgW8=; b=mhnNWb7L7ccrW+3RFog6c5Fx9jET10N1XNnur2AjDuDC3zJ2AAVlQvNIXPKePRyXwd fFnRsgKddUaVIHbDPE5nZwlXK8baVpOj44+aiM+UP2LNxHfHxkZlAWp5ha0PQMElUpK+ MARAk5eCUXcnCfnqFsf8Q4LYB9C4XiPjzBLvjewjZKHJdqqMLK+1vepwVf7P2JT3/+Nc jXdu3vnAhBZcX6dI6bdLfrmnwPxeMxUizxh32tSjig6PWkboj5aTLlnFMxD1mJGF700c O0emno6WB0vtW7+Ai7CbWJgbbP32Ox8Q6kcNpcHM0/yCQkZpJS1LfMvC3YuMzezu0CMC 2VJw== X-Gm-Message-State: APjAAAULp7TPZcAeFa1R90U4D1wFbGQmWZaMsn6LCsESe1gqx7lPfvtn pkG1PlxdlZ+p9Cb6eLoH0Z8FyhtABT35TIbAj+0= X-Google-Smtp-Source: APXvYqwUnhz2m6wVS/VBgm/wkeCIyzbl9djOQgL4mFfx6PHycGR+HWSLRgw6zgjVOJFj/hLRYNHIVNlQ9so60A0qqv0= X-Received: by 2002:ab0:5922:: with SMTP id n31mr2301366uad.103.1562834106737; Thu, 11 Jul 2019 01:35:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 11 Jul 2019 10:34:55 +0200 Message-ID: To: Bernard Aboba Cc: DISPATCH list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dispatch] Dispatching WebTransport (boiling it down) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 08:35:10 -0000 On Wed, 10 Jul 2019 at 21:59, Bernard Aboba wrote= : > > Inaki Baz Castillo said: > > "if this is a pure client-to-server transport, why is webrtc mentioned in= the background at all? shouldn't this be a replacement of websockets and N= OT of the webrtc datachannels?" Actually I did not say that =F0=9F=91=86 :) --=20 I=C3=B1aki Baz Castillo From nobody Sun Jul 21 15:24:35 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF63120048 for ; Sun, 21 Jul 2019 15:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] 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 eFdP__BmH5s7 for ; Sun, 21 Jul 2019 15:24:32 -0700 (PDT) Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [198.46.93.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E982F12001E for ; Sun, 21 Jul 2019 15:24:31 -0700 (PDT) Received: from [31.133.149.60] (port=50243 helo=dhcp-953c.meeting.ietf.org) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hpJDO-000Hnk-B5 for dispatch@ietf.org; Sun, 21 Jul 2019 14:18:05 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_062439E6-0EE2-4208-BAFC-56CBFB0FFFE5"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Sun, 21 Jul 2019 17:17:52 -0400 To: dispatch@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [dispatch] Thoughts on draft-rosenbergjennings-dispatch-ripp-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 22:24:35 -0000 --Apple-Mail=_062439E6-0EE2-4208-BAFC-56CBFB0FFFE5 Content-Type: multipart/alternative; boundary="Apple-Mail=_A892FA49-03ED-4103-B980-7A6A6EE9EF20" --Apple-Mail=_A892FA49-03ED-4103-B980-7A6A6EE9EF20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 General: For the most part, I like the idea of a draft that basically = says, =E2=80=9Cwe tried to be pure but failed. This proposal is not pure = but it for the most part represents running code.=E2=80=9D PHB will be = happy (ref. the NAT discussion on the IETF list). Section 1.1: background Will much of it be meaningful to a protocol implementer in a year, no = less five? I.e., referencing Kubernetes, Istio, CanaryDeploys, etc., = more especially without going into detail as to what they are? Sure, if = you are an AWS developer you know them like the back of your hand. = However, not many folks in IETF-land are. 1.2: Why is it =E2=80=98unfortunate=E2=80=99 that people want to deploy cloud = applications that interact with the PSTN? Is that not an opportunity? I = would take out the initial =E2=80=9CUnfortunately.=E2=80=9D It=E2=80=99s = just a statement of fact that applications like to call and be called to = most any person on the planet on a fully interoperable basis. There needs to be more justification than =E2=80=9CWeb people don=E2=80=99= t understand SIP.=E2=80=9D You might want to explain how RIPP is = different than ParlayX. I would offer that RIPP:ParlayX::LDAP:X.500, but = you don=E2=80=99t say that anywhere. All the draft implies is Web people = cannot grok SIP and SIP does not grok Web deployment, which does not = reflect well on either community. The last paragraph of 1.2 implies that SIP is the source of robocalls = and a mechanism that will be even easier to inject boatloads of calls = will be better. Please explain how this will be so (or remove the = assertion). As you know, I personally wish it would be so, so PLEASE = give me ammunition! 1.4: Given the virtual mandate to use SIP over TCP, is saying =E2=80=9Cwe can = finally use HTTP over UDP=E2=80=9D not kind of a retrograde assertion? REQ 12 (supporting only audio) is an odd requirement. Moreover, most = applications in the U.S. would require at least RTT support if not = video. I am not a lawyer, but since we are talking interoperability with = the PSTN, one is likely to run into Section 255 and 706 issues if RTT = (and video) is not there from day one. REQ 13 looks totally duplicative of REQ 10 (use secure caller ID = technologies). Is there a distinction? If so, please make it clearer Section 3.6: This is a place where we need to distinguish between theory and reality. = In theory, SIP could provide end-to-end media security. In practice, no = one figured it out. The good news is RIPP is no worse than SIP as it is = deployed today. Moreover, RIPP is no worse than HTTP. My concern is RIPP = structurally will never have end-to-end media security. While that is no = worse than today, will we be running into some privacy expectations of = users and regulators? For example, a RIPP server can record everything. = Problems here are (1) in the U.S. that is likely to be a violation of = the Wiretap Act and (2) people can use those recordings for very = nefarious purposes (see RealTalk, Lyrebird, etc.). Section 8.2: Just curious: why MUST NOT the identifier included the authority = component for uniqueness? Is that a Web best practice? A reference or = explanation would be helpful. Section 8.3: What are the capabilities *of*? Are they codec parameters? Are they = decoded stream parameters? Are they codec dependent? Is there any value = to these parameters, outside parameterized codec negotiation that I am = missing? For example, is the max-bitrate the decoded maximum bitrate or the = bitrate of the codec? What is the purpose? If I come up with a cool LPC that can do better than G.711 with 4000 = samples per section, why cannot I use it? BIG ONE: force-cbr Do we require a CBR codec or do we require uniform packet sizes (in = bytes)? If the former, why not just ask for a CBR codec in the request. = If the latter, change the parameter to something like =E2=80=9Crequire = privacy.=E2=80=9D There are much better ways of achieving privacy than = using a CBR codec; see e.g., = https://repository.library.georgetown.edu/handle/10822/1040699 = Section 8.4: I agree with Cullen. It goes against the design principle of using = HTTP/3 for transport and then start putting application semantics into = the transport layer. Is there a reason to break layers, e.g., for load = balancing or something else? Section 8.7 Why 20 for forward and 10 for reverse? Are these rules of thumb, = calculated optimal places to start, SWAGs, or irrelevant? Also (and in Section 8.8), what about the speed of light and the = appearance of blocking? Section 8.8 Perhaps I missed it, but what happens if a byway appears to be blocked = for a =E2=80=98while=E2=80=99? Since this is voice and this is UDP and I = am tolerant of packet loss, do I care a packet was lost? Also, I=E2=80=99m= highly skeptical of 1:1 packet:ack this protocol offers. That sounds = like a bad thing for LANs and a terrible thing for WANs. Really? Section 8.10 I kind of agree with Cullen=E2=80=99s point, but here is an opposite = observation that I came up with before I saw Cullen=E2=80=99s point = (that SIP result codes don=E2=80=99t cover ISDN). Why have a separate = =E2=80=98rejected=E2=80=99 result in light of =E2=80=98failed.=E2=80=99 = Unless rejected is referencing the SIP 607 result code, I would think = all the call center cares about is whether the call completed and if it = did not, will a retry be likely to succeed or fail. There are a ton of typos in the draft. I=E2=80=99d be happy to hand my = mark-up to whomever wants it in DISPATCH. --Apple-Mail=_A892FA49-03ED-4103-B980-7A6A6EE9EF20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
General: For the most part, I like the idea of a draft that = basically says, =E2=80=9Cwe tried to be pure but failed. This proposal = is not pure but it for the most part represents running code.=E2=80=9D = PHB will be happy (ref. the NAT discussion on the IETF = list). 

Section 1.1: background
Will much of it be meaningful to a protocol implementer in a = year, no less five? I.e., referencing Kubernetes, Istio, CanaryDeploys, = etc., more especially without going into detail as to what they are? = Sure, if you are an AWS developer you know them like the back of your = hand. However, not many folks in IETF-land are.

1.2:
Why is it = =E2=80=98unfortunate=E2=80=99 that people want to deploy cloud = applications that interact with the PSTN? Is that not an opportunity? I = would take out the initial =E2=80=9CUnfortunately.=E2=80=9D It=E2=80=99s = just a statement of fact that applications like to call and be called to = most any person on the planet on a fully interoperable basis.

There needs to be more = justification than =E2=80=9CWeb people don=E2=80=99t understand SIP.=E2=80= =9D You might want to explain how RIPP is different than ParlayX. I = would offer that RIPP:ParlayX::LDAP:X.500, but you don=E2=80=99t say = that anywhere. All the draft implies is Web people cannot grok SIP and = SIP does not grok Web deployment, which does not reflect well on either = community.

The = last paragraph of 1.2 implies that SIP is the source of robocalls and a = mechanism that will be even easier to inject boatloads of calls will be = better. Please explain how this will be so (or remove the assertion). As = you know, I personally wish it would be so, so PLEASE give me = ammunition!

1.4:
Given the virtual mandate to use = SIP over TCP, is saying =E2=80=9Cwe can finally use HTTP over UDP=E2=80=9D= not kind of a retrograde assertion?

REQ 12 (supporting only audio) is an = odd requirement. Moreover, most applications in the U.S. would require = at least RTT support if not video. I am not a lawyer, but since we are = talking interoperability with the PSTN, one is likely to run into = Section 255 and 706 issues if RTT (and video) is not there from day = one.

REQ 13 = looks totally duplicative of REQ 10 (use secure caller ID technologies). = Is there a distinction? If so, please make it clearer

Section 3.6:
This is a place where we need to distinguish between theory = and reality. In theory, SIP could provide end-to-end media security. In = practice, no one figured it out. The good news is RIPP is no worse than = SIP as it is deployed today. Moreover, RIPP is no worse than HTTP. My = concern is RIPP structurally will never have end-to-end media security. = While that is no worse than today, will we be running into some privacy = expectations of users and regulators? For example, a RIPP server can = record everything. Problems here are (1) in the U.S. that is likely to = be a violation of the Wiretap Act and (2) people can use those = recordings for very nefarious purposes (see RealTalk, Lyrebird, = etc.).

Section = 8.2:
Just curious: why MUST NOT the identifier = included the authority component for uniqueness? Is that a Web best = practice? A reference or explanation would be helpful.

Section 8.3:
What are the capabilities *of*? Are they codec parameters? = Are they decoded stream parameters? Are they codec dependent? Is there = any value to these parameters, outside parameterized codec negotiation = that I am missing?

For example, is the max-bitrate the decoded maximum bitrate = or the bitrate of the codec? What is the purpose?
If = I come up with a cool LPC that can do better than G.711 with 4000 = samples per section, why cannot I use it?

BIG ONE: force-cbr
Do we require a CBR codec or do we require uniform packet = sizes (in bytes)? If the former, why not just ask for a CBR codec in the = request. If the latter, change the parameter to something like = =E2=80=9Crequire privacy.=E2=80=9D There are much better ways of = achieving privacy than using a CBR codec; see e.g., https://repository.library.georgetown.edu/handle/10822/1040699<= /a>

Section = 8.4:
I agree with Cullen. It goes against the = design principle of using HTTP/3 for transport and then start putting = application semantics into the transport layer. Is there a reason to = break layers, e.g., for load balancing or something else?

Section 8.7
Why 20 for forward and 10 for reverse? Are these rules of = thumb, calculated optimal places to start, SWAGs, or = irrelevant?
Also (and in Section 8.8), what about = the speed of light and the appearance of blocking?

Section 8.8
Perhaps I missed it, but what happens if a byway appears to = be blocked for a =E2=80=98while=E2=80=99? Since this is voice and this = is UDP and I am tolerant of packet loss, do I care a packet was lost? = Also, I=E2=80=99m highly skeptical of 1:1 packet:ack this protocol = offers. That sounds like a bad thing for LANs and a terrible thing for = WANs. Really?

Section 8.10
I kind of agree with = Cullen=E2=80=99s point, but here is an opposite observation that I came = up with before I saw Cullen=E2=80=99s point (that SIP result codes = don=E2=80=99t cover ISDN). Why have a separate =E2=80=98rejected=E2=80=99 = result in light of =E2=80=98failed.=E2=80=99 Unless rejected is = referencing the SIP 607 result code, I would think all the call center = cares about is whether the call completed and if it did not, will a = retry be likely to succeed or fail.


There are a ton of typos in the draft. I=E2=80=99d be happy = to hand my mark-up to whomever wants it in DISPATCH.
= --Apple-Mail=_A892FA49-03ED-4103-B980-7A6A6EE9EF20-- --Apple-Mail=_062439E6-0EE2-4208-BAFC-56CBFB0FFFE5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEfEc/N7T7IfiAuDEHDDCGh758rskFAl001oAACgkQDDCGh758 rsksXw//WwZPcimzUI/05EpsMtQEDGztRO7ZZFR/4lQQCXONCFyr7F/ylin+GAbT IujRKOdE0ef1GFupKQQJIwmCh5tm9mIKDqNfRQrv+Vd9g60u8wZ6DG2BNiDFVO0n EHUEUSKxBWZ2gv9rYF08mw0ME50kUbmKn868ORzE3KSeTdwWgIwcX6gKe6sRuPZQ iBQoRmT1Fx7R3ily8HXpOrlsw+59wM0HZXini3yKshohc6iY3bLJP8PouQevBJdU 8/7g3zD795rZT42kWH0PTN+cboQ0Krd/8OqoMurYQXImobweom+wMAqyyctaeKB4 /rx0cTozeSKRa8tQuA4fVsXilKGrE3SbCwDrKzGpKqSmLoQByfxkVGmUQqbeTD06 6LCwFocXcC0kt6zeL/CMsHf/hOm3xN8Ivh3MkHDVyV4LSdGnGqugaCNTUyupvGj3 P8Fg3yQnIPgd3RIzxExrJO3UbIZDmAd3lAYwQebgyr8sTk7iPINlmoTGO9mpzbu4 u7WaMj5rSeTEAFIWfV6eCr10ivrdbQO5/sH4C7Txsh0v3pnGx/D4u9gPl1zlz0/D nFdnIPat26eUo6mNm8oHRdX9onm1Ecv3U+Y8wRMgmX+s3ApL68X/tP1hgo1TfK8r 7nCCH5mp2LGgiQ+aZ82uQV8UBarLsBZg2wi3XHhN8O9fqRFSXVI= =Ns9+ -----END PGP SIGNATURE----- --Apple-Mail=_062439E6-0EE2-4208-BAFC-56CBFB0FFFE5-- From nobody Sun Jul 21 19:21:55 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4A3120096; Sun, 21 Jul 2019 19:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 wRborMlT-EWa; Sun, 21 Jul 2019 19:21:53 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0C7A012003F; Sun, 21 Jul 2019 19:21:53 -0700 (PDT) Received: from dhcp-9817.meeting.ietf.org (dhcp-9817.meeting.ietf.org [31.133.152.23]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6M2LoBq029287 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 21 Jul 2019 21:21:52 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1563762112; bh=9gfWfJOHP+9jqD/D67N3EXP1fW9mCcaLP8+OUJfGq4M=; h=From:Subject:Date:Cc:To; b=wMahyPIXchGDXTNG8ZISI8JzyJnM1ZqTo+TLfT7dztQzLtLQiqheHaCg/GF8fIkqk RPIRM7B4g+blkrLpNWElU9repou5YgKwYOZPoh/udRZV4XwUthMxhEELxyjBJirek+ CHgN//xsQ6IYwnOVIqogsOdmGFu38Ghlg0h8pxcQ= From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_EB3317D7-BA13-4F1C-8470-CB5F9D2512A7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <68FB2C21-CB20-4ABE-A1BF-A597159B0016@nostrum.com> Date: Sun, 21 Jul 2019 22:21:45 -0400 Cc: dispatch chairs To: DISPATCH X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [dispatch] Volunteers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 02:21:55 -0000 --Apple-Mail=_EB3317D7-BA13-4F1C-8470-CB5F9D2512A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Everyone, We will have a tight schedule in Monday=E2=80=99s DISPATCH meeting. = I=E2=80=99d like to get one of our administrative tasks done prior to = the meeting, namely getting volunteers to take meeting notes and act as = Jabber relay. We need one or preferably two note-takers. This doesn=E2=80=99t have to = be a play-by-play (unless you like doing that); we mainly need a record = of decisions, actions items, or similar things of note. We also need a Jabber relay. This mainly means taking comments from the = jabber room to the mike if requested. Remote participants are encouraged = to use MeetEcho to make comments, but we still sometimes get comments = from jabber. Many thanks in advance to our most honored volunteers! Ben. --Apple-Mail=_EB3317D7-BA13-4F1C-8470-CB5F9D2512A7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAl01HbkACgkQgFZKbJXz 1A0xsw//fgxFKFa2zvfiGyyae6sFBCf/b8qvHpyHwGt+88xVyQUpXVA1LBJy3Zp8 gGdqDsKs5v93/T3zUaSu9vpm8kqJRdLiverWWaP4PgIvQYGTWOwMxdcoTF/y51q6 2P6ytive6fdQ1cs7ONm3pjHQUUeD3DpbG0k6j6An+Pdiivbpy+YNsTAO13V5aUA6 eOkQuug893xrFee9XJPQldGr+WfaOH8Haw9uWlPthRgKXcV16Z8j86/64bKkZn0v xoT6D9uZUwxqSoJ+frPECjOS9Bpkdhi1zSvScZ/K10W2UO9/ui7/dD21+gg6jQ/G Wb5SuroVKHr6kfN5CjiJYzrHdZ2w/PzfJmeE6hSP5xkt3gOXDSvHAm/9Ic6Z0VNu bKYrWLqfWZ6uumhOw8hJjDQg5/Tob2e816bVUO/Mgs0Piss+WUEGh1/f7EwpXQFl TmhzHUQyhEEkly/nJaKRaald+JKIaEptzoqT7KLNyBlCVzgKD2Rhth8KmzraaEsX FtgmEFoeKA8XEoN3ZKFqXEeLWcXp8Eg891dTVBYEUe4mFLJ/fmyyJw66GyQZdVAX NKakhYnIvth/NKc8YPuO2A72uv5Ht2rgANjOevE++2QVzF2VGTFoB0G4EmrLy/Xp AyHz8FX39MZVX14MUgacmhqacqYZf19fzNlc0eAlYIaoQxKuvgg= =Q3r+ -----END PGP SIGNATURE----- --Apple-Mail=_EB3317D7-BA13-4F1C-8470-CB5F9D2512A7-- From nobody Mon Jul 22 04:15:42 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDF1120291 for ; Mon, 22 Jul 2019 04:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 h21GWZI9CF0K for ; Mon, 22 Jul 2019 04:15:33 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1E012027D for ; Mon, 22 Jul 2019 04:15:32 -0700 (PDT) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 4E5414226F4A0090481 for ; Mon, 22 Jul 2019 12:15:30 +0100 (IST) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 22 Jul 2019 12:15:29 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.119]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0439.000; Mon, 22 Jul 2019 19:15:22 +0800 From: "Roni Even (A)" To: Eric Burger , "dispatch@ietf.org" Thread-Topic: [dispatch] Thoughts on draft-rosenbergjennings-dispatch-ripp-03 Thread-Index: AQHVQBMf7QubYDkU3Ei8GkiIxgDi+6bWfIHg Date: Mon, 22 Jul 2019 11:15:21 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD23D1F9C0@DGGEMM506-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.124.182.143] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD23D1F9C0DGGEMM506MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [dispatch] Thoughts on draft-rosenbergjennings-dispatch-ripp-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 11:15:40 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD23D1F9C0DGGEMM506MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEVyaWPigJlzIGNvbW1lbnRzLg0KSSB3YXMgYWxzbyB3b25kZXJpbmcgYWJv dXQgdGhlIGNhcGFiaWxpdGllcyBzdXBwb3J0LiBGb3IgZXhhbXBsZSBPUFVTIHN1cHBvcnRzIGlu IGJhbmQgRkVDIHdoaWNoIGFkZHJlc3NlcyBwYWNrZXQgbG9zcyBidXQgaWYgeW91IHVzZSBhIHJl bGlhYmxlIHRyYW5zcG9ydCBpdCB3aWxsIGxvc2UgdGhlIGVmZmVjdGl2ZW5lc3Mgb2YgRkVDLiAg VGhpcyBpcyB3aHkgdGhlcmUgaXMgc29tZSBkaXNjdXNzaW9uIGFib3V0IHVucmVsaWFibGUgc3Ry ZWFtcy4NCkl0IGxvb2sgdG8gbWUgdGhhdCByZXBsYWNpbmcgUlRQIGlzIG5vdCBhcyBzaW1wbGUg YXMgeW91IHByZXNlbnQgaW4gdGhlIGRvY3VtZW50Lg0KUm9uaSBFdmVuDQoNCkZyb206IGRpc3Bh dGNoIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMg QnVyZ2VyDQpTZW50OiBNb25kYXksIEp1bHkgMjIsIDIwMTkgMTI6MTggQU0NClRvOiBkaXNwYXRj aEBpZXRmLm9yZw0KU3ViamVjdDogW2Rpc3BhdGNoXSBUaG91Z2h0cyBvbiBkcmFmdC1yb3NlbmJl cmdqZW5uaW5ncy1kaXNwYXRjaC1yaXBwLTAzDQoNCkdlbmVyYWw6IEZvciB0aGUgbW9zdCBwYXJ0 LCBJIGxpa2UgdGhlIGlkZWEgb2YgYSBkcmFmdCB0aGF0IGJhc2ljYWxseSBzYXlzLCDigJx3ZSB0 cmllZCB0byBiZSBwdXJlIGJ1dCBmYWlsZWQuIFRoaXMgcHJvcG9zYWwgaXMgbm90IHB1cmUgYnV0 IGl0IGZvciB0aGUgbW9zdCBwYXJ0IHJlcHJlc2VudHMgcnVubmluZyBjb2RlLuKAnSBQSEIgd2ls bCBiZSBoYXBweSAocmVmLiB0aGUgTkFUIGRpc2N1c3Npb24gb24gdGhlIElFVEYgbGlzdCkuDQoN Cg0KU2VjdGlvbiAxLjE6IGJhY2tncm91bmQNCldpbGwgbXVjaCBvZiBpdCBiZSBtZWFuaW5nZnVs IHRvIGEgcHJvdG9jb2wgaW1wbGVtZW50ZXIgaW4gYSB5ZWFyLCBubyBsZXNzIGZpdmU/IEkuZS4s IHJlZmVyZW5jaW5nIEt1YmVybmV0ZXMsIElzdGlvLCBDYW5hcnlEZXBsb3lzLCBldGMuLCBtb3Jl IGVzcGVjaWFsbHkgd2l0aG91dCBnb2luZyBpbnRvIGRldGFpbCBhcyB0byB3aGF0IHRoZXkgYXJl PyBTdXJlLCBpZiB5b3UgYXJlIGFuIEFXUyBkZXZlbG9wZXIgeW91IGtub3cgdGhlbSBsaWtlIHRo ZSBiYWNrIG9mIHlvdXIgaGFuZC4gSG93ZXZlciwgbm90IG1hbnkgZm9sa3MgaW4gSUVURi1sYW5k IGFyZS4NCg0KMS4yOg0KV2h5IGlzIGl0IOKAmHVuZm9ydHVuYXRl4oCZIHRoYXQgcGVvcGxlIHdh bnQgdG8gZGVwbG95IGNsb3VkIGFwcGxpY2F0aW9ucyB0aGF0IGludGVyYWN0IHdpdGggdGhlIFBT VE4/IElzIHRoYXQgbm90IGFuIG9wcG9ydHVuaXR5PyBJIHdvdWxkIHRha2Ugb3V0IHRoZSBpbml0 aWFsIOKAnFVuZm9ydHVuYXRlbHku4oCdIEl04oCZcyBqdXN0IGEgc3RhdGVtZW50IG9mIGZhY3Qg dGhhdCBhcHBsaWNhdGlvbnMgbGlrZSB0byBjYWxsIGFuZCBiZSBjYWxsZWQgdG8gbW9zdCBhbnkg cGVyc29uIG9uIHRoZSBwbGFuZXQgb24gYSBmdWxseSBpbnRlcm9wZXJhYmxlIGJhc2lzLg0KDQpU aGVyZSBuZWVkcyB0byBiZSBtb3JlIGp1c3RpZmljYXRpb24gdGhhbiDigJxXZWIgcGVvcGxlIGRv buKAmXQgdW5kZXJzdGFuZCBTSVAu4oCdIFlvdSBtaWdodCB3YW50IHRvIGV4cGxhaW4gaG93IFJJ UFAgaXMgZGlmZmVyZW50IHRoYW4gUGFybGF5WC4gSSB3b3VsZCBvZmZlciB0aGF0IFJJUFA6UGFy bGF5WDo6TERBUDpYLjUwMCwgYnV0IHlvdSBkb27igJl0IHNheSB0aGF0IGFueXdoZXJlLiBBbGwg dGhlIGRyYWZ0IGltcGxpZXMgaXMgV2ViIHBlb3BsZSBjYW5ub3QgZ3JvayBTSVAgYW5kIFNJUCBk b2VzIG5vdCBncm9rIFdlYiBkZXBsb3ltZW50LCB3aGljaCBkb2VzIG5vdCByZWZsZWN0IHdlbGwg b24gZWl0aGVyIGNvbW11bml0eS4NCg0KVGhlIGxhc3QgcGFyYWdyYXBoIG9mIDEuMiBpbXBsaWVz IHRoYXQgU0lQIGlzIHRoZSBzb3VyY2Ugb2Ygcm9ib2NhbGxzIGFuZCBhIG1lY2hhbmlzbSB0aGF0 IHdpbGwgYmUgZXZlbiBlYXNpZXIgdG8gaW5qZWN0IGJvYXRsb2FkcyBvZiBjYWxscyB3aWxsIGJl IGJldHRlci4gUGxlYXNlIGV4cGxhaW4gaG93IHRoaXMgd2lsbCBiZSBzbyAob3IgcmVtb3ZlIHRo ZSBhc3NlcnRpb24pLiBBcyB5b3Uga25vdywgSSBwZXJzb25hbGx5IHdpc2ggaXQgd291bGQgYmUg c28sIHNvIFBMRUFTRSBnaXZlIG1lIGFtbXVuaXRpb24hDQoNCjEuNDoNCkdpdmVuIHRoZSB2aXJ0 dWFsIG1hbmRhdGUgdG8gdXNlIFNJUCBvdmVyIFRDUCwgaXMgc2F5aW5nIOKAnHdlIGNhbiBmaW5h bGx5IHVzZSBIVFRQIG92ZXIgVURQ4oCdIG5vdCBraW5kIG9mIGEgcmV0cm9ncmFkZSBhc3NlcnRp b24/DQoNClJFUSAxMiAoc3VwcG9ydGluZyBvbmx5IGF1ZGlvKSBpcyBhbiBvZGQgcmVxdWlyZW1l bnQuIE1vcmVvdmVyLCBtb3N0IGFwcGxpY2F0aW9ucyBpbiB0aGUgVS5TLiB3b3VsZCByZXF1aXJl IGF0IGxlYXN0IFJUVCBzdXBwb3J0IGlmIG5vdCB2aWRlby4gSSBhbSBub3QgYSBsYXd5ZXIsIGJ1 dCBzaW5jZSB3ZSBhcmUgdGFsa2luZyBpbnRlcm9wZXJhYmlsaXR5IHdpdGggdGhlIFBTVE4sIG9u ZSBpcyBsaWtlbHkgdG8gcnVuIGludG8gU2VjdGlvbiAyNTUgYW5kIDcwNiBpc3N1ZXMgaWYgUlRU IChhbmQgdmlkZW8pIGlzIG5vdCB0aGVyZSBmcm9tIGRheSBvbmUuDQoNClJFUSAxMyBsb29rcyB0 b3RhbGx5IGR1cGxpY2F0aXZlIG9mIFJFUSAxMCAodXNlIHNlY3VyZSBjYWxsZXIgSUQgdGVjaG5v bG9naWVzKS4gSXMgdGhlcmUgYSBkaXN0aW5jdGlvbj8gSWYgc28sIHBsZWFzZSBtYWtlIGl0IGNs ZWFyZXINCg0KU2VjdGlvbiAzLjY6DQpUaGlzIGlzIGEgcGxhY2Ugd2hlcmUgd2UgbmVlZCB0byBk aXN0aW5ndWlzaCBiZXR3ZWVuIHRoZW9yeSBhbmQgcmVhbGl0eS4gSW4gdGhlb3J5LCBTSVAgY291 bGQgcHJvdmlkZSBlbmQtdG8tZW5kIG1lZGlhIHNlY3VyaXR5LiBJbiBwcmFjdGljZSwgbm8gb25l IGZpZ3VyZWQgaXQgb3V0LiBUaGUgZ29vZCBuZXdzIGlzIFJJUFAgaXMgbm8gd29yc2UgdGhhbiBT SVAgYXMgaXQgaXMgZGVwbG95ZWQgdG9kYXkuIE1vcmVvdmVyLCBSSVBQIGlzIG5vIHdvcnNlIHRo YW4gSFRUUC4gTXkgY29uY2VybiBpcyBSSVBQIHN0cnVjdHVyYWxseSB3aWxsIG5ldmVyIGhhdmUg ZW5kLXRvLWVuZCBtZWRpYSBzZWN1cml0eS4gV2hpbGUgdGhhdCBpcyBubyB3b3JzZSB0aGFuIHRv ZGF5LCB3aWxsIHdlIGJlIHJ1bm5pbmcgaW50byBzb21lIHByaXZhY3kgZXhwZWN0YXRpb25zIG9m IHVzZXJzIGFuZCByZWd1bGF0b3JzPyBGb3IgZXhhbXBsZSwgYSBSSVBQIHNlcnZlciBjYW4gcmVj b3JkIGV2ZXJ5dGhpbmcuIFByb2JsZW1zIGhlcmUgYXJlICgxKSBpbiB0aGUgVS5TLiB0aGF0IGlz IGxpa2VseSB0byBiZSBhIHZpb2xhdGlvbiBvZiB0aGUgV2lyZXRhcCBBY3QgYW5kICgyKSBwZW9w bGUgY2FuIHVzZSB0aG9zZSByZWNvcmRpbmdzIGZvciB2ZXJ5IG5lZmFyaW91cyBwdXJwb3NlcyAo c2VlIFJlYWxUYWxrLCBMeXJlYmlyZCwgZXRjLikuDQoNClNlY3Rpb24gOC4yOg0KSnVzdCBjdXJp b3VzOiB3aHkgTVVTVCBOT1QgdGhlIGlkZW50aWZpZXIgaW5jbHVkZWQgdGhlIGF1dGhvcml0eSBj b21wb25lbnQgZm9yIHVuaXF1ZW5lc3M/IElzIHRoYXQgYSBXZWIgYmVzdCBwcmFjdGljZT8gQSBy ZWZlcmVuY2Ugb3IgZXhwbGFuYXRpb24gd291bGQgYmUgaGVscGZ1bC4NCg0KU2VjdGlvbiA4LjM6 DQpXaGF0IGFyZSB0aGUgY2FwYWJpbGl0aWVzICpvZio/IEFyZSB0aGV5IGNvZGVjIHBhcmFtZXRl cnM/IEFyZSB0aGV5IGRlY29kZWQgc3RyZWFtIHBhcmFtZXRlcnM/IEFyZSB0aGV5IGNvZGVjIGRl cGVuZGVudD8gSXMgdGhlcmUgYW55IHZhbHVlIHRvIHRoZXNlIHBhcmFtZXRlcnMsIG91dHNpZGUg cGFyYW1ldGVyaXplZCBjb2RlYyBuZWdvdGlhdGlvbiB0aGF0IEkgYW0gbWlzc2luZz8NCg0KRm9y IGV4YW1wbGUsIGlzIHRoZSBtYXgtYml0cmF0ZSB0aGUgZGVjb2RlZCBtYXhpbXVtIGJpdHJhdGUg b3IgdGhlIGJpdHJhdGUgb2YgdGhlIGNvZGVjPyBXaGF0IGlzIHRoZSBwdXJwb3NlPw0KSWYgSSBj b21lIHVwIHdpdGggYSBjb29sIExQQyB0aGF0IGNhbiBkbyBiZXR0ZXIgdGhhbiBHLjcxMSB3aXRo IDQwMDAgc2FtcGxlcyBwZXIgc2VjdGlvbiwgd2h5IGNhbm5vdCBJIHVzZSBpdD8NCg0KQklHIE9O RTogZm9yY2UtY2JyDQpEbyB3ZSByZXF1aXJlIGEgQ0JSIGNvZGVjIG9yIGRvIHdlIHJlcXVpcmUg dW5pZm9ybSBwYWNrZXQgc2l6ZXMgKGluIGJ5dGVzKT8gSWYgdGhlIGZvcm1lciwgd2h5IG5vdCBq dXN0IGFzayBmb3IgYSBDQlIgY29kZWMgaW4gdGhlIHJlcXVlc3QuIElmIHRoZSBsYXR0ZXIsIGNo YW5nZSB0aGUgcGFyYW1ldGVyIHRvIHNvbWV0aGluZyBsaWtlIOKAnHJlcXVpcmUgcHJpdmFjeS7i gJ0gVGhlcmUgYXJlIG11Y2ggYmV0dGVyIHdheXMgb2YgYWNoaWV2aW5nIHByaXZhY3kgdGhhbiB1 c2luZyBhIENCUiBjb2RlYzsgc2VlIGUuZy4sIGh0dHBzOi8vcmVwb3NpdG9yeS5saWJyYXJ5Lmdl b3JnZXRvd24uZWR1L2hhbmRsZS8xMDgyMi8xMDQwNjk5DQoNClNlY3Rpb24gOC40Og0KSSBhZ3Jl ZSB3aXRoIEN1bGxlbi4gSXQgZ29lcyBhZ2FpbnN0IHRoZSBkZXNpZ24gcHJpbmNpcGxlIG9mIHVz aW5nIEhUVFAvMyBmb3IgdHJhbnNwb3J0IGFuZCB0aGVuIHN0YXJ0IHB1dHRpbmcgYXBwbGljYXRp b24gc2VtYW50aWNzIGludG8gdGhlIHRyYW5zcG9ydCBsYXllci4gSXMgdGhlcmUgYSByZWFzb24g dG8gYnJlYWsgbGF5ZXJzLCBlLmcuLCBmb3IgbG9hZCBiYWxhbmNpbmcgb3Igc29tZXRoaW5nIGVs c2U/DQoNClNlY3Rpb24gOC43DQpXaHkgMjAgZm9yIGZvcndhcmQgYW5kIDEwIGZvciByZXZlcnNl PyBBcmUgdGhlc2UgcnVsZXMgb2YgdGh1bWIsIGNhbGN1bGF0ZWQgb3B0aW1hbCBwbGFjZXMgdG8g c3RhcnQsIFNXQUdzLCBvciBpcnJlbGV2YW50Pw0KQWxzbyAoYW5kIGluIFNlY3Rpb24gOC44KSwg d2hhdCBhYm91dCB0aGUgc3BlZWQgb2YgbGlnaHQgYW5kIHRoZSBhcHBlYXJhbmNlIG9mIGJsb2Nr aW5nPw0KDQpTZWN0aW9uIDguOA0KUGVyaGFwcyBJIG1pc3NlZCBpdCwgYnV0IHdoYXQgaGFwcGVu cyBpZiBhIGJ5d2F5IGFwcGVhcnMgdG8gYmUgYmxvY2tlZCBmb3IgYSDigJh3aGlsZeKAmT8gU2lu Y2UgdGhpcyBpcyB2b2ljZSBhbmQgdGhpcyBpcyBVRFAgYW5kIEkgYW0gdG9sZXJhbnQgb2YgcGFj a2V0IGxvc3MsIGRvIEkgY2FyZSBhIHBhY2tldCB3YXMgbG9zdD8gQWxzbywgSeKAmW0gaGlnaGx5 IHNrZXB0aWNhbCBvZiAxOjEgcGFja2V0OmFjayB0aGlzIHByb3RvY29sIG9mZmVycy4gVGhhdCBz b3VuZHMgbGlrZSBhIGJhZCB0aGluZyBmb3IgTEFOcyBhbmQgYSB0ZXJyaWJsZSB0aGluZyBmb3Ig V0FOcy4gUmVhbGx5Pw0KDQpTZWN0aW9uIDguMTANCkkga2luZCBvZiBhZ3JlZSB3aXRoIEN1bGxl buKAmXMgcG9pbnQsIGJ1dCBoZXJlIGlzIGFuIG9wcG9zaXRlIG9ic2VydmF0aW9uIHRoYXQgSSBj YW1lIHVwIHdpdGggYmVmb3JlIEkgc2F3IEN1bGxlbuKAmXMgcG9pbnQgKHRoYXQgU0lQIHJlc3Vs dCBjb2RlcyBkb27igJl0IGNvdmVyIElTRE4pLiBXaHkgaGF2ZSBhIHNlcGFyYXRlIOKAmHJlamVj dGVk4oCZIHJlc3VsdCBpbiBsaWdodCBvZiDigJhmYWlsZWQu4oCZIFVubGVzcyByZWplY3RlZCBp cyByZWZlcmVuY2luZyB0aGUgU0lQIDYwNyByZXN1bHQgY29kZSwgSSB3b3VsZCB0aGluayBhbGwg dGhlIGNhbGwgY2VudGVyIGNhcmVzIGFib3V0IGlzIHdoZXRoZXIgdGhlIGNhbGwgY29tcGxldGVk IGFuZCBpZiBpdCBkaWQgbm90LCB3aWxsIGEgcmV0cnkgYmUgbGlrZWx5IHRvIHN1Y2NlZWQgb3Ig ZmFpbC4NCg0KDQpUaGVyZSBhcmUgYSB0b24gb2YgdHlwb3MgaW4gdGhlIGRyYWZ0LiBJ4oCZZCBi ZSBoYXBweSB0byBoYW5kIG15IG1hcmstdXAgdG8gd2hvbWV2ZXIgd2FudHMgaXQgaW4gRElTUEFU Q0guDQo= --_000_6E58094ECC8D8344914996DAD28F1CCD23D1F9C0DGGEMM506MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIEVyaWPigJlzIGNvbW1lbnRzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdhcyBhbHNvIHdvbmRlcmluZyBhYm91dCB0 aGUgY2FwYWJpbGl0aWVzIHN1cHBvcnQuIEZvciBleGFtcGxlIE9QVVMgc3VwcG9ydHMgaW4gYmFu ZCBGRUMgd2hpY2ggYWRkcmVzc2VzIHBhY2tldCBsb3NzIGJ1dCBpZiB5b3UgdXNlIGEgcmVsaWFi bGUgdHJhbnNwb3J0IGl0DQogd2lsbCBsb3NlIHRoZSBlZmZlY3RpdmVuZXNzIG9mIEZFQy4mbmJz cDsgVGhpcyBpcyB3aHkgdGhlcmUgaXMgc29tZSBkaXNjdXNzaW9uIGFib3V0IHVucmVsaWFibGUg c3RyZWFtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgbG9vayB0byBtZSB0aGF0 IHJlcGxhY2luZyBSVFAgaXMgbm90IGFzIHNpbXBsZSBhcyB5b3UgcHJlc2VudCBpbiB0aGUgZG9j dW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvbmkgRXZlbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IGRpc3BhdGNoIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBCdXJnZXI8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBK dWx5IDIyLCAyMDE5IDEyOjE4IEFNPGJyPg0KPGI+VG86PC9iPiBkaXNwYXRjaEBpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBbZGlzcGF0Y2hdIFRob3VnaHRzIG9uIGRyYWZ0LXJvc2VuYmVy Z2plbm5pbmdzLWRpc3BhdGNoLXJpcHAtMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2VuZXJhbDogRm9yIHRoZSBtb3N0IHBhcnQsIEkgbGlr ZSB0aGUgaWRlYSBvZiBhIGRyYWZ0IHRoYXQgYmFzaWNhbGx5IHNheXMsIOKAnHdlIHRyaWVkIHRv IGJlIHB1cmUgYnV0IGZhaWxlZC4gVGhpcyBwcm9wb3NhbCBpcyBub3QgcHVyZSBidXQgaXQgZm9y IHRoZSBtb3N0IHBhcnQgcmVwcmVzZW50cyBydW5uaW5nIGNvZGUu4oCdIFBIQiB3aWxsIGJlIGhh cHB5IChyZWYuIHRoZSBOQVQgZGlzY3Vzc2lvbiBvbiB0aGUNCiBJRVRGIGxpc3QpLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNl Y3Rpb24gMS4xOiBiYWNrZ3JvdW5kPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2lsbCBtdWNoIG9mIGl0IGJlIG1lYW5pbmdmdWwgdG8gYSBwcm90b2NvbCBpbXBs ZW1lbnRlciBpbiBhIHllYXIsIG5vIGxlc3MgZml2ZT8gSS5lLiwgcmVmZXJlbmNpbmcgS3ViZXJu ZXRlcywgSXN0aW8sIENhbmFyeURlcGxveXMsIGV0Yy4sIG1vcmUgZXNwZWNpYWxseSB3aXRob3V0 IGdvaW5nIGludG8gZGV0YWlsIGFzIHRvIHdoYXQgdGhleSBhcmU/IFN1cmUsIGlmIHlvdSBhcmUg YW4gQVdTIGRldmVsb3Blcg0KIHlvdSBrbm93IHRoZW0gbGlrZSB0aGUgYmFjayBvZiB5b3VyIGhh bmQuIEhvd2V2ZXIsIG5vdCBtYW55IGZvbGtzIGluIElFVEYtbGFuZCBhcmUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuMjo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoeSBpcyBpdCDigJh1 bmZvcnR1bmF0ZeKAmSB0aGF0IHBlb3BsZSB3YW50IHRvIGRlcGxveSBjbG91ZCBhcHBsaWNhdGlv bnMgdGhhdCBpbnRlcmFjdCB3aXRoIHRoZSBQU1ROPyBJcyB0aGF0IG5vdCBhbiBvcHBvcnR1bml0 eT8gSSB3b3VsZCB0YWtlIG91dCB0aGUgaW5pdGlhbCDigJxVbmZvcnR1bmF0ZWx5LuKAnSBJdOKA mXMganVzdCBhIHN0YXRlbWVudCBvZiBmYWN0IHRoYXQgYXBwbGljYXRpb25zIGxpa2UgdG8gY2Fs bCBhbmQNCiBiZSBjYWxsZWQgdG8gbW9zdCBhbnkgcGVyc29uIG9uIHRoZSBwbGFuZXQgb24gYSBm dWxseSBpbnRlcm9wZXJhYmxlIGJhc2lzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBuZWVkcyB0byBiZSBtb3JlIGp1c3RpZmljYXRp b24gdGhhbiDigJxXZWIgcGVvcGxlIGRvbuKAmXQgdW5kZXJzdGFuZCBTSVAu4oCdIFlvdSBtaWdo dCB3YW50IHRvIGV4cGxhaW4gaG93IFJJUFAgaXMgZGlmZmVyZW50IHRoYW4gUGFybGF5WC4gSSB3 b3VsZCBvZmZlciB0aGF0IFJJUFA6UGFybGF5WDo6TERBUDpYLjUwMCwgYnV0IHlvdSBkb27igJl0 IHNheSB0aGF0IGFueXdoZXJlLiBBbGwgdGhlIGRyYWZ0IGltcGxpZXMNCiBpcyBXZWIgcGVvcGxl IGNhbm5vdCBncm9rIFNJUCBhbmQgU0lQIGRvZXMgbm90IGdyb2sgV2ViIGRlcGxveW1lbnQsIHdo aWNoIGRvZXMgbm90IHJlZmxlY3Qgd2VsbCBvbiBlaXRoZXIgY29tbXVuaXR5LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbGFzdCBwYXJh Z3JhcGggb2YgMS4yIGltcGxpZXMgdGhhdCBTSVAgaXMgdGhlIHNvdXJjZSBvZiByb2JvY2FsbHMg YW5kIGEgbWVjaGFuaXNtIHRoYXQgd2lsbCBiZSBldmVuIGVhc2llciB0byBpbmplY3QgYm9hdGxv YWRzIG9mIGNhbGxzIHdpbGwgYmUgYmV0dGVyLiBQbGVhc2UgZXhwbGFpbiBob3cgdGhpcyB3aWxs IGJlIHNvIChvciByZW1vdmUgdGhlIGFzc2VydGlvbikuIEFzIHlvdSBrbm93LCBJIHBlcnNvbmFs bHkNCiB3aXNoIGl0IHdvdWxkIGJlIHNvLCBzbyBQTEVBU0UgZ2l2ZSBtZSBhbW11bml0aW9uITxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLjQ6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HaXZl biB0aGUgdmlydHVhbCBtYW5kYXRlIHRvIHVzZSBTSVAgb3ZlciBUQ1AsIGlzIHNheWluZyDigJx3 ZSBjYW4gZmluYWxseSB1c2UgSFRUUCBvdmVyIFVEUOKAnSBub3Qga2luZCBvZiBhIHJldHJvZ3Jh ZGUgYXNzZXJ0aW9uPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5SRVEgMTIgKHN1cHBvcnRpbmcgb25seSBhdWRpbykgaXMgYW4gb2RkIHJlcXVp cmVtZW50LiBNb3Jlb3ZlciwgbW9zdCBhcHBsaWNhdGlvbnMgaW4gdGhlIFUuUy4gd291bGQgcmVx dWlyZSBhdCBsZWFzdCBSVFQgc3VwcG9ydCBpZiBub3QgdmlkZW8uIEkgYW0gbm90IGEgbGF3eWVy LCBidXQgc2luY2Ugd2UgYXJlIHRhbGtpbmcgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIHRoZSBQU1RO LCBvbmUgaXMgbGlrZWx5IHRvDQogcnVuIGludG8gU2VjdGlvbiAyNTUgYW5kIDcwNiBpc3N1ZXMg aWYgUlRUIChhbmQgdmlkZW8pIGlzIG5vdCB0aGVyZSBmcm9tIGRheSBvbmUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJFUSAxMyBsb29rcyB0 b3RhbGx5IGR1cGxpY2F0aXZlIG9mIFJFUSAxMCAodXNlIHNlY3VyZSBjYWxsZXIgSUQgdGVjaG5v bG9naWVzKS4gSXMgdGhlcmUgYSBkaXN0aW5jdGlvbj8gSWYgc28sIHBsZWFzZSBtYWtlIGl0IGNs ZWFyZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TZWN0aW9uIDMuNjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgYSBwbGFjZSB3aGVyZSB3ZSBuZWVkIHRvIGRpc3Rp bmd1aXNoIGJldHdlZW4gdGhlb3J5IGFuZCByZWFsaXR5LiBJbiB0aGVvcnksIFNJUCBjb3VsZCBw cm92aWRlIGVuZC10by1lbmQgbWVkaWEgc2VjdXJpdHkuIEluIHByYWN0aWNlLCBubyBvbmUgZmln dXJlZCBpdCBvdXQuIFRoZSBnb29kIG5ld3MgaXMgUklQUCBpcyBubyB3b3JzZSB0aGFuIFNJUCBh cyBpdCBpcyBkZXBsb3llZCB0b2RheS4gTW9yZW92ZXIsDQogUklQUCBpcyBubyB3b3JzZSB0aGFu IEhUVFAuIE15IGNvbmNlcm4gaXMgUklQUCBzdHJ1Y3R1cmFsbHkgd2lsbCBuZXZlciBoYXZlIGVu ZC10by1lbmQgbWVkaWEgc2VjdXJpdHkuIFdoaWxlIHRoYXQgaXMgbm8gd29yc2UgdGhhbiB0b2Rh eSwgd2lsbCB3ZSBiZSBydW5uaW5nIGludG8gc29tZSBwcml2YWN5IGV4cGVjdGF0aW9ucyBvZiB1 c2VycyBhbmQgcmVndWxhdG9ycz8gRm9yIGV4YW1wbGUsIGEgUklQUCBzZXJ2ZXIgY2FuIHJlY29y ZCBldmVyeXRoaW5nLg0KIFByb2JsZW1zIGhlcmUgYXJlICgxKSBpbiB0aGUgVS5TLiB0aGF0IGlz IGxpa2VseSB0byBiZSBhIHZpb2xhdGlvbiBvZiB0aGUgV2lyZXRhcCBBY3QgYW5kICgyKSBwZW9w bGUgY2FuIHVzZSB0aG9zZSByZWNvcmRpbmdzIGZvciB2ZXJ5IG5lZmFyaW91cyBwdXJwb3NlcyAo c2VlIFJlYWxUYWxrLCBMeXJlYmlyZCwgZXRjLikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gOC4yOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBjdXJpb3VzOiB3aHkgTVVT VCBOT1QgdGhlIGlkZW50aWZpZXIgaW5jbHVkZWQgdGhlIGF1dGhvcml0eSBjb21wb25lbnQgZm9y IHVuaXF1ZW5lc3M/IElzIHRoYXQgYSBXZWIgYmVzdCBwcmFjdGljZT8gQSByZWZlcmVuY2Ugb3Ig ZXhwbGFuYXRpb24gd291bGQgYmUgaGVscGZ1bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlvbiA4LjM6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGFyZSB0aGUgY2FwYWJpbGl0 aWVzICpvZio/IEFyZSB0aGV5IGNvZGVjIHBhcmFtZXRlcnM/IEFyZSB0aGV5IGRlY29kZWQgc3Ry ZWFtIHBhcmFtZXRlcnM/IEFyZSB0aGV5IGNvZGVjIGRlcGVuZGVudD8gSXMgdGhlcmUgYW55IHZh bHVlIHRvIHRoZXNlIHBhcmFtZXRlcnMsIG91dHNpZGUgcGFyYW1ldGVyaXplZCBjb2RlYyBuZWdv dGlhdGlvbiB0aGF0IEkgYW0gbWlzc2luZz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGV4YW1wbGUsIGlzIHRoZSBtYXgtYml0cmF0ZSB0 aGUgZGVjb2RlZCBtYXhpbXVtIGJpdHJhdGUgb3IgdGhlIGJpdHJhdGUgb2YgdGhlIGNvZGVjPyBX aGF0IGlzIHRoZSBwdXJwb3NlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SWYgSSBjb21lIHVwIHdpdGggYSBjb29sIExQQyB0aGF0IGNhbiBkbyBi ZXR0ZXIgdGhhbiBHLjcxMSB3aXRoIDQwMDAgc2FtcGxlcyBwZXIgc2VjdGlvbiwgd2h5IGNhbm5v dCBJIHVzZSBpdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QklHIE9ORTogZm9yY2UtY2JyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB3ZSByZXF1aXJlIGEgQ0JSIGNvZGVjIG9yIGRvIHdl IHJlcXVpcmUgdW5pZm9ybSBwYWNrZXQgc2l6ZXMgKGluIGJ5dGVzKT8gSWYgdGhlIGZvcm1lciwg d2h5IG5vdCBqdXN0IGFzayBmb3IgYSBDQlIgY29kZWMgaW4gdGhlIHJlcXVlc3QuIElmIHRoZSBs YXR0ZXIsIGNoYW5nZSB0aGUgcGFyYW1ldGVyIHRvIHNvbWV0aGluZyBsaWtlIOKAnHJlcXVpcmUg cHJpdmFjeS7igJ0gVGhlcmUgYXJlIG11Y2ggYmV0dGVyIHdheXMNCiBvZiBhY2hpZXZpbmcgcHJp dmFjeSB0aGFuIHVzaW5nIGEgQ0JSIGNvZGVjOyBzZWUgZS5nLiwmbmJzcDs8YSBocmVmPSJodHRw czovL3JlcG9zaXRvcnkubGlicmFyeS5nZW9yZ2V0b3duLmVkdS9oYW5kbGUvMTA4MjIvMTA0MDY5 OSI+aHR0cHM6Ly9yZXBvc2l0b3J5LmxpYnJhcnkuZ2VvcmdldG93bi5lZHUvaGFuZGxlLzEwODIy LzEwNDA2OTk8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlNlY3Rpb24gOC40OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB3aXRoIEN1bGxlbi4gSXQgZ29lcyBhZ2FpbnN0IHRo ZSBkZXNpZ24gcHJpbmNpcGxlIG9mIHVzaW5nIEhUVFAvMyBmb3IgdHJhbnNwb3J0IGFuZCB0aGVu IHN0YXJ0IHB1dHRpbmcgYXBwbGljYXRpb24gc2VtYW50aWNzIGludG8gdGhlIHRyYW5zcG9ydCBs YXllci4gSXMgdGhlcmUgYSByZWFzb24gdG8gYnJlYWsgbGF5ZXJzLCBlLmcuLCBmb3IgbG9hZCBi YWxhbmNpbmcgb3Igc29tZXRoaW5nIGVsc2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gOC43PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaHkgMjAgZm9yIGZvcndhcmQgYW5kIDEw IGZvciByZXZlcnNlPyBBcmUgdGhlc2UgcnVsZXMgb2YgdGh1bWIsIGNhbGN1bGF0ZWQgb3B0aW1h bCBwbGFjZXMgdG8gc3RhcnQsIFNXQUdzLCBvciBpcnJlbGV2YW50PzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbyAoYW5kIGluIFNlY3Rpb24g OC44KSwgd2hhdCBhYm91dCB0aGUgc3BlZWQgb2YgbGlnaHQgYW5kIHRoZSBhcHBlYXJhbmNlIG9m IGJsb2NraW5nPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5TZWN0aW9uIDguODxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UGVyaGFwcyBJIG1pc3NlZCBpdCwgYnV0IHdoYXQgaGFwcGVucyBpZiBh IGJ5d2F5IGFwcGVhcnMgdG8gYmUgYmxvY2tlZCBmb3IgYSDigJh3aGlsZeKAmT8gU2luY2UgdGhp cyBpcyB2b2ljZSBhbmQgdGhpcyBpcyBVRFAgYW5kIEkgYW0gdG9sZXJhbnQgb2YgcGFja2V0IGxv c3MsIGRvIEkgY2FyZSBhIHBhY2tldCB3YXMgbG9zdD8gQWxzbywgSeKAmW0gaGlnaGx5IHNrZXB0 aWNhbCBvZiAxOjEgcGFja2V0OmFjayB0aGlzIHByb3RvY29sDQogb2ZmZXJzLiBUaGF0IHNvdW5k cyBsaWtlIGEgYmFkIHRoaW5nIGZvciBMQU5zIGFuZCBhIHRlcnJpYmxlIHRoaW5nIGZvciBXQU5z LiBSZWFsbHk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNlY3Rpb24gOC4xMDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBraW5kIG9mIGFncmVlIHdpdGggQ3VsbGVu4oCZcyBwb2ludCwgYnV0 IGhlcmUgaXMgYW4gb3Bwb3NpdGUgb2JzZXJ2YXRpb24gdGhhdCBJIGNhbWUgdXAgd2l0aCBiZWZv cmUgSSBzYXcgQ3VsbGVu4oCZcyBwb2ludCAodGhhdCBTSVAgcmVzdWx0IGNvZGVzIGRvbuKAmXQg Y292ZXIgSVNETikuIFdoeSBoYXZlIGEgc2VwYXJhdGUg4oCYcmVqZWN0ZWTigJkgcmVzdWx0IGlu IGxpZ2h0IG9mIOKAmGZhaWxlZC7igJkgVW5sZXNzIHJlamVjdGVkDQogaXMgcmVmZXJlbmNpbmcg dGhlIFNJUCA2MDcgcmVzdWx0IGNvZGUsIEkgd291bGQgdGhpbmsgYWxsIHRoZSBjYWxsIGNlbnRl ciBjYXJlcyBhYm91dCBpcyB3aGV0aGVyIHRoZSBjYWxsIGNvbXBsZXRlZCBhbmQgaWYgaXQgZGlk IG5vdCwgd2lsbCBhIHJldHJ5IGJlIGxpa2VseSB0byBzdWNjZWVkIG9yIGZhaWwuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJl IGEgdG9uIG9mIHR5cG9zIGluIHRoZSBkcmFmdC4gSeKAmWQgYmUgaGFwcHkgdG8gaGFuZCBteSBt YXJrLXVwIHRvIHdob21ldmVyIHdhbnRzIGl0IGluIERJU1BBVENILjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6E58094ECC8D8344914996DAD28F1CCD23D1F9C0DGGEMM506MBXchi_-- From nobody Mon Jul 22 05:14:27 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0D8120273 for ; Mon, 22 Jul 2019 05:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 6-C6hCUERqAz for ; Mon, 22 Jul 2019 05:14:21 -0700 (PDT) Received: from ecbiz261.inmotionhosting.com (ecbiz261.inmotionhosting.com [173.231.209.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C625120275 for ; Mon, 22 Jul 2019 05:14:20 -0700 (PDT) Received: from mail-oi1-f173.google.com ([209.85.167.173]:41686) by ecbiz261.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hpXCh-001Ixo-R9 for dispatch@ietf.org; Mon, 22 Jul 2019 08:14:20 -0400 Received: by mail-oi1-f173.google.com with SMTP id g7so29375291oia.8 for ; Mon, 22 Jul 2019 05:14:07 -0700 (PDT) X-Gm-Message-State: APjAAAW6Icmdc5Z/OymWmbIUuv175AusMCk0iwdg12uwxYjPOQnn5VZ3 lCPzKLpIPAWrXI5fxZH+MfAo70UH32bEoJGyS8k= X-Google-Smtp-Source: APXvYqwB7sCdydLluF9TNHh1gKCKE7p7cvQv+uOZynwqel+87eIfH3zUNGTxM/LGPIvYMhQzPvbf0zUwmx8aXReB4+E= X-Received: by 2002:aca:4c6:: with SMTP id 189mr33439123oie.107.1563797647433; Mon, 22 Jul 2019 05:14:07 -0700 (PDT) MIME-Version: 1.0 References: <6E58094ECC8D8344914996DAD28F1CCD23D1F9C0@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD23D1F9C0@DGGEMM506-MBX.china.huawei.com> From: Jonathan Rosenberg Date: Mon, 22 Jul 2019 08:13:56 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Roni Even (A)" Cc: Eric Burger , "dispatch@ietf.org" Content-Type: multipart/alternative; boundary="00000000000046a8b7058e4403ef" X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz261.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net X-Get-Message-Sender-Via: ecbiz261.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed X-Authenticated-Sender: ecbiz261.inmotionhosting.com: jdrosen@jdrosen.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [dispatch] Thoughts on draft-rosenbergjennings-dispatch-ripp-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 12:14:25 -0000 --00000000000046a8b7058e4403ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Roni for the comments! Though quic overall is reliable, the way we=E2=80=99re using it achieves an interesting effect - there is no hol blocking. This means an actual IP loss would result in packet 1 showing up, then 3, then much later, 2. As a result, with hitter buffer, 2 is effectively lost and thus fec would be useful in recovering 2. Thx, Jonathan R. On Mon, Jul 22, 2019 at 7:16 AM Roni Even (A) wrote: > I agree with Eric=E2=80=99s comments. > > I was also wondering about the capabilities support. For example OPUS > supports in band FEC which addresses packet loss but if you use a reliabl= e > transport it will lose the effectiveness of FEC. This is why there is so= me > discussion about unreliable streams. > > It look to me that replacing RTP is not as simple as you present in the > document. > > Roni Even > > > > *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Eric > Burger > *Sent:* Monday, July 22, 2019 12:18 AM > *To:* dispatch@ietf.org > *Subject:* [dispatch] Thoughts on draft-rosenbergjennings-dispatch-ripp-0= 3 > > > > General: For the most part, I like the idea of a draft that basically > says, =E2=80=9Cwe tried to be pure but failed. This proposal is not pure = but it for > the most part represents running code.=E2=80=9D PHB will be happy (ref. t= he NAT > discussion on the IETF list). > > > > > > Section 1.1: background > > Will much of it be meaningful to a protocol implementer in a year, no les= s > five? I.e., referencing Kubernetes, Istio, CanaryDeploys, etc., more > especially without going into detail as to what they are? Sure, if you ar= e > an AWS developer you know them like the back of your hand. However, not > many folks in IETF-land are. > > > > 1.2: > > Why is it =E2=80=98unfortunate=E2=80=99 that people want to deploy cloud = applications that > interact with the PSTN? Is that not an opportunity? I would take out the > initial =E2=80=9CUnfortunately.=E2=80=9D It=E2=80=99s just a statement of= fact that applications > like to call and be called to most any person on the planet on a fully > interoperable basis. > > > > There needs to be more justification than =E2=80=9CWeb people don=E2=80= =99t understand > SIP.=E2=80=9D You might want to explain how RIPP is different than Parlay= X. I would > offer that RIPP:ParlayX::LDAP:X.500, but you don=E2=80=99t say that anywh= ere. All > the draft implies is Web people cannot grok SIP and SIP does not grok Web > deployment, which does not reflect well on either community. > > > > The last paragraph of 1.2 implies that SIP is the source of robocalls and > a mechanism that will be even easier to inject boatloads of calls will be > better. Please explain how this will be so (or remove the assertion). As > you know, I personally wish it would be so, so PLEASE give me ammunition! > > > > 1.4: > > Given the virtual mandate to use SIP over TCP, is saying =E2=80=9Cwe can = finally > use HTTP over UDP=E2=80=9D not kind of a retrograde assertion? > > > > REQ 12 (supporting only audio) is an odd requirement. Moreover, most > applications in the U.S. would require at least RTT support if not video.= I > am not a lawyer, but since we are talking interoperability with the PSTN, > one is likely to run into Section 255 and 706 issues if RTT (and video) i= s > not there from day one. > > > > REQ 13 looks totally duplicative of REQ 10 (use secure caller ID > technologies). Is there a distinction? If so, please make it clearer > > > > Section 3.6: > > This is a place where we need to distinguish between theory and reality. > In theory, SIP could provide end-to-end media security. In practice, no o= ne > figured it out. The good news is RIPP is no worse than SIP as it is > deployed today. Moreover, RIPP is no worse than HTTP. My concern is RIPP > structurally will never have end-to-end media security. While that is no > worse than today, will we be running into some privacy expectations of > users and regulators? For example, a RIPP server can record everything. > Problems here are (1) in the U.S. that is likely to be a violation of the > Wiretap Act and (2) people can use those recordings for very nefarious > purposes (see RealTalk, Lyrebird, etc.). > > > > Section 8.2: > > Just curious: why MUST NOT the identifier included the authority componen= t > for uniqueness? Is that a Web best practice? A reference or explanation > would be helpful. > > > > Section 8.3: > > What are the capabilities *of*? Are they codec parameters? Are they > decoded stream parameters? Are they codec dependent? Is there any value t= o > these parameters, outside parameterized codec negotiation that I am missi= ng? > > > > For example, is the max-bitrate the decoded maximum bitrate or the bitrat= e > of the codec? What is the purpose? > > If I come up with a cool LPC that can do better than G.711 with 4000 > samples per section, why cannot I use it? > > > > BIG ONE: force-cbr > > Do we require a CBR codec or do we require uniform packet sizes (in > bytes)? If the former, why not just ask for a CBR codec in the request. I= f > the latter, change the parameter to something like =E2=80=9Crequire priva= cy.=E2=80=9D There > are much better ways of achieving privacy than using a CBR codec; see e.g= ., > https://repository.library.georgetown.edu/handle/10822/1040699 > > > > Section 8.4: > > I agree with Cullen. It goes against the design principle of using HTTP/3 > for transport and then start putting application semantics into the > transport layer. Is there a reason to break layers, e.g., for load > balancing or something else? > > > > Section 8.7 > > Why 20 for forward and 10 for reverse? Are these rules of thumb, > calculated optimal places to start, SWAGs, or irrelevant? > > Also (and in Section 8.8), what about the speed of light and the > appearance of blocking? > > > > Section 8.8 > > Perhaps I missed it, but what happens if a byway appears to be blocked fo= r > a =E2=80=98while=E2=80=99? Since this is voice and this is UDP and I am t= olerant of packet > loss, do I care a packet was lost? Also, I=E2=80=99m highly skeptical of = 1:1 > packet:ack this protocol offers. That sounds like a bad thing for LANs an= d > a terrible thing for WANs. Really? > > > > Section 8.10 > > I kind of agree with Cullen=E2=80=99s point, but here is an opposite obse= rvation > that I came up with before I saw Cullen=E2=80=99s point (that SIP result = codes > don=E2=80=99t cover ISDN). Why have a separate =E2=80=98rejected=E2=80=99= result in light of > =E2=80=98failed.=E2=80=99 Unless rejected is referencing the SIP 607 resu= lt code, I would > think all the call center cares about is whether the call completed and i= f > it did not, will a retry be likely to succeed or fail. > > > > > > There are a ton of typos in the draft. I=E2=80=99d be happy to hand my ma= rk-up to > whomever wants it in DISPATCH. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net --00000000000046a8b7058e4403ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Roni for the comments!

Though quic overall is reliable, the way= we=E2=80=99re using it achieves an interesting effect - there is no hol bl= ocking. This means an actual IP loss would result in packet 1 showing up, t= hen 3, then much later, 2. As a result, with hitter buffer, 2 is effectivel= y lost and thus fec would be useful in recovering 2.=C2=A0

Thx,
Jonathan R.<= /div>



On Mon, Jul 22,= 2019 at 7:16 AM Roni Even (A) <= roni.even@huawei.com> wrote:

I agree with Eric=E2=80= =99s comments.

I was also wondering abou= t the capabilities support. For example OPUS supports in band FEC which add= resses packet loss but if you use a reliable transport it will lose the effectiveness of FEC.=C2=A0 This is why there is some discus= sion about unreliable streams.

It look to me that replac= ing RTP is not as simple as you present in the document.

Roni Even

=C2=A0

From: dispatch= [mailto:dis= patch-bounces@ietf.org] On Behalf Of Eric Burger
Sent: Monday, July 22, 2019 12:18 AM
To: dispatch@= ietf.org
Subject: [dispatch] Thoughts on draft-rosenbergjennings-dispatch-rip= p-03

=C2=A0

General: For the most part, I like the idea of a dra= ft that basically says, =E2=80=9Cwe tried to be pure but failed. This propo= sal is not pure but it for the most part represents running code.=E2=80=9D = PHB will be happy (ref. the NAT discussion on the IETF list).=C2=A0

=C2=A0

=C2=A0

Section 1.1: background

Will much of it be meaningful to a protocol implemen= ter in a year, no less five? I.e., referencing Kubernetes, Istio, CanaryDep= loys, etc., more especially without going into detail as to what they are? = Sure, if you are an AWS developer you know them like the back of your hand. However, not many folks in IETF-= land are.

=C2=A0

1.2:

Why is it =E2=80=98unfortunate=E2=80=99 that people = want to deploy cloud applications that interact with the PSTN? Is that not = an opportunity? I would take out the initial =E2=80=9CUnfortunately.=E2=80= =9D It=E2=80=99s just a statement of fact that applications like to call an= d be called to most any person on the planet on a fully interoperable basis.=

=C2=A0

There needs to be more justification than =E2=80=9CW= eb people don=E2=80=99t understand SIP.=E2=80=9D You might want to explain = how RIPP is different than ParlayX. I would offer that RIPP:ParlayX::LDAP:X= .500, but you don=E2=80=99t say that anywhere. All the draft implies is Web people cannot grok SIP and SIP does not grok Web deployment, which = does not reflect well on either community.

=C2=A0

The last paragraph of 1.2 implies that SIP is the so= urce of robocalls and a mechanism that will be even easier to inject boatlo= ads of calls will be better. Please explain how this will be so (or remove = the assertion). As you know, I personally wish it would be so, so PLEASE give me ammunition!

=C2=A0

1.4:

Given the virtual mandate to use SIP over TCP, is sa= ying =E2=80=9Cwe can finally use HTTP over UDP=E2=80=9D not kind of a retro= grade assertion?

=C2=A0

REQ 12 (supporting only audio) is an odd requirement= . Moreover, most applications in the U.S. would require at least RTT suppor= t if not video. I am not a lawyer, but since we are talking interoperabilit= y with the PSTN, one is likely to run into Section 255 and 706 issues if RTT (and video) is not there from d= ay one.

=C2=A0

REQ 13 looks totally duplicative of REQ 10 (use secu= re caller ID technologies). Is there a distinction? If so, please make it c= learer

=C2=A0

Section 3.6:

This is a place where we need to distinguish between= theory and reality. In theory, SIP could provide end-to-end media security= . In practice, no one figured it out. The good news is RIPP is no worse tha= n SIP as it is deployed today. Moreover, RIPP is no worse than HTTP. My concern is RIPP structurally will never hav= e end-to-end media security. While that is no worse than today, will we be = running into some privacy expectations of users and regulators? For example= , a RIPP server can record everything. Problems here are (1) in the U.S. that is likely to be a violation of the = Wiretap Act and (2) people can use those recordings for very nefarious purp= oses (see RealTalk, Lyrebird, etc.).

=C2=A0

Section 8.2:

Just curious: why MUST NOT the identifier included t= he authority component for uniqueness? Is that a Web best practice? A refer= ence or explanation would be helpful.

=C2=A0

Section 8.3:

What are the capabilities *of*? Are they codec param= eters? Are they decoded stream parameters? Are they codec dependent? Is the= re any value to these parameters, outside parameterized codec negotiation t= hat I am missing?

=C2=A0

For example, is the max-bitrate the decoded maximum = bitrate or the bitrate of the codec? What is the purpose?

If I come up with a cool LPC that can do better than= G.711 with 4000 samples per section, why cannot I use it?

=C2=A0

BIG ONE: force-cbr

Do we require a CBR codec or do we require uniform p= acket sizes (in bytes)? If the former, why not just ask for a CBR codec in = the request. If the latter, change the parameter to something like =E2=80= =9Crequire privacy.=E2=80=9D There are much better ways of achieving privacy than using a CBR codec; see e.g.,=C2=A0https://repository.library.georgetown.edu/handle/10822/1040699

=C2=A0

Section 8.4:

I agree with Cullen. It goes against the design prin= ciple of using HTTP/3 for transport and then start putting application sema= ntics into the transport layer. Is there a reason to break layers, e.g., fo= r load balancing or something else?

=C2=A0

Section 8.7

Why 20 for forward and 10 for reverse? Are these rul= es of thumb, calculated optimal places to start, SWAGs, or irrelevant?

Also (and in Section 8.8), what about the speed of l= ight and the appearance of blocking?

=C2=A0

Section 8.8

Perhaps I missed it, but what happens if a byway app= ears to be blocked for a =E2=80=98while=E2=80=99? Since this is voice and t= his is UDP and I am tolerant of packet loss, do I care a packet was lost? A= lso, I=E2=80=99m highly skeptical of 1:1 packet:ack this protocol offers. That sounds like a bad thing for LANs and a terrible thing for WAN= s. Really?

=C2=A0

Section 8.10

I kind of agree with Cullen=E2=80=99s point, but her= e is an opposite observation that I came up with before I saw Cullen=E2=80= =99s point (that SIP result codes don=E2=80=99t cover ISDN). Why have a sep= arate =E2=80=98rejected=E2=80=99 result in light of =E2=80=98failed.=E2=80= =99 Unless rejected is referencing the SIP 607 result code, I would think all the call center = cares about is whether the call completed and if it did not, will a retry b= e likely to succeed or fail.

=C2=A0

=C2=A0

There are a ton of typos in the draft. I=E2=80=99d b= e happy to hand my mark-up to whomever wants it in DISPATCH.<= /p>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--
--00000000000046a8b7058e4403ef-- From nobody Mon Jul 22 07:14:24 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BB012017D; Mon, 22 Jul 2019 07:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 t7lEwlSDiOnp; Mon, 22 Jul 2019 07:14:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A67411200B1; Mon, 22 Jul 2019 07:14:20 -0700 (PDT) Received: from dhcp-9817.meeting.ietf.org (dhcp-9817.meeting.ietf.org [31.133.152.23]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6MEEH0L045364 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 22 Jul 2019 09:14:19 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1563804860; bh=lU2RrWFciEhy0TQH8rezgo7mcSMVVKqxfMdNO+KflXU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Xrc5miluoZQvO70z2BH09ZEhovuPkbrsBxFsdXX9ZRDG3yRcK37HqfI0gQRM6KGCv colM6DaYjYfVFei56jcN8+3dH9/qVJsqq8QbZYMujb//xY8p6OWlW6Zcy56+MxL9jc 4AmLcXjuUnJbhbViZNp3L7enjPaotqOBJi4pRYKE= From: Ben Campbell Message-Id: <4AF3C7C6-0091-46BD-A324-B3CE3E6051C0@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_9D447950-FA5C-4B27-9FC2-DD1B7A8A010B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 10:14:14 -0400 In-Reply-To: <68FB2C21-CB20-4ABE-A1BF-A597159B0016@nostrum.com> Cc: dispatch chairs To: DISPATCH References: <68FB2C21-CB20-4ABE-A1BF-A597159B0016@nostrum.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dispatch] Volunteers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 14:14:22 -0000 --Apple-Mail=_9D447950-FA5C-4B27-9FC2-DD1B7A8A010B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 S=E2=80=99il vous pla=C3=AEt ? > On Jul 21, 2019, at 10:21 PM, Ben Campbell wrote: >=20 > Signed PGP part > Hi Everyone, >=20 > We will have a tight schedule in Monday=E2=80=99s DISPATCH meeting. = I=E2=80=99d like to get one of our administrative tasks done prior to = the meeting, namely getting volunteers to take meeting notes and act as = Jabber relay. >=20 > We need one or preferably two note-takers. This doesn=E2=80=99t have = to be a play-by-play (unless you like doing that); we mainly need a = record of decisions, actions items, or similar things of note. >=20 > We also need a Jabber relay. This mainly means taking comments from = the jabber room to the mike if requested. Remote participants are = encouraged to use MeetEcho to make comments, but we still sometimes get = comments from jabber. >=20 > Many thanks in advance to our most honored volunteers! >=20 > Ben. >=20 >=20 --Apple-Mail=_9D447950-FA5C-4B27-9FC2-DD1B7A8A010B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAl01xLYACgkQgFZKbJXz 1A0sIxAAp3PcHKQFqlbDOiybY8DKpIgrEzT5YeuRTPc/XikOu8Onp58+7aNZRVa2 tkaUUDmTT6SC892j1Ugfd+GWWIWCNBD3IxXiyykFxNYFe4kmGyrjjt03yNEgVhlI ACyQcepwKHyhdSBEmr3HyNsQFF4XfioJ4763UOKqe2nMM4JdutGGq6x7AbC9rRdh F/jViiHqcvX6mENtLThlyoTcdOQ9hXHaibpANPMowC7L83HfFPVVXsboV8sru7dW kn3FCAvCGDV3hppzso1x05kIAcKcZQ4TbTHh7/xpD/iufvTGhf788vyoU3TVmcnK gH5jrKu29POkRB4S1KUTGxozIHBv+jDg1UZdOpg3NHR23nG980loUs0334YXfprY BgF68Sf+lTYmcI0dgEvcYQ+fk+WHWwX31WHcCbRhfeLrINwCribQ6Jn97fMafg+6 AqVSybub58uyOAOiOF0tt/onm3EVkbY0/kOB+v+dfwKfgDkNgmj/T9TR4C4nObUB Nl5w+2oN0Cs3oamzkqvXCunVD2u7xwbEo1rxXiBARJZh/D3pwqv/51/d91PcCjpe tuPY1nb+coR1Br8jbP82LlbDeG5rcjcgbTPYjSzGHOFMTCFuC57LONKW5Up+Q7fL 7ROESNKDN68ooxSb2Hncrlakn/RjDwF2QkaIvb3x9jCmC1rqpnM= =wrvv -----END PGP SIGNATURE----- --Apple-Mail=_9D447950-FA5C-4B27-9FC2-DD1B7A8A010B-- From nobody Mon Jul 22 07:52:00 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F389B1201C6; Mon, 22 Jul 2019 07:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 RnThfbyK-un5; Mon, 22 Jul 2019 07:51:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0C8F51202D3; Mon, 22 Jul 2019 07:51:50 -0700 (PDT) Received: from [10.45.11.10] ([194.59.251.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6MEpkoh051748 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 22 Jul 2019 09:51:48 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1563807109; bh=X7mU21b/3uUTeib52rNtfhwE8Gsm5diF9bOaJQJRS+o=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=lHy5HmQNCOn5uwY0pcy8DCVWN0byGfS9QrzsqJO5T9krtVEpH4KFlksotzn2/Mrf/ ncz0VYs681E1wjpo7ElEko4YnQjjA0c8M/0Ta+Uznik47htZYQ244bXVGmXoiuOIKC t3FVdawUljPDGKdiGf50osAizrVYt/MTR74c3y/g= X-Authentication-Warning: raven.nostrum.com: Host [194.59.251.66] claimed to be [10.45.11.10] From: Ben Campbell Message-Id: <9676A69E-F606-4B81-AC60-6B07B1A34F93@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BDCD0184-0A28-4235-9838-76ABF84D7C94"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 10:51:45 -0400 In-Reply-To: <4AF3C7C6-0091-46BD-A324-B3CE3E6051C0@nostrum.com> Cc: dispatch chairs To: DISPATCH References: <68FB2C21-CB20-4ABE-A1BF-A597159B0016@nostrum.com> <4AF3C7C6-0091-46BD-A324-B3CE3E6051C0@nostrum.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dispatch] Volunteers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 14:51:58 -0000 --Apple-Mail=_BDCD0184-0A28-4235-9838-76ABF84D7C94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Update: We have one note taker and a jabber scribe. We still have an = opening for one more note taker. These opportunities are going fast, so = don=E2=80=99t wait to volunteer! Thanks! Ben. > On Jul 22, 2019, at 10:14 AM, Ben Campbell wrote: >=20 > Signed PGP part > S=E2=80=99il vous pla=C3=AEt ? >=20 >> On Jul 21, 2019, at 10:21 PM, Ben Campbell wrote: >>=20 >> Signed PGP part >> Hi Everyone, >>=20 >> We will have a tight schedule in Monday=E2=80=99s DISPATCH meeting. = I=E2=80=99d like to get one of our administrative tasks done prior to = the meeting, namely getting volunteers to take meeting notes and act as = Jabber relay. >>=20 >> We need one or preferably two note-takers. This doesn=E2=80=99t have = to be a play-by-play (unless you like doing that); we mainly need a = record of decisions, actions items, or similar things of note. >>=20 >> We also need a Jabber relay. This mainly means taking comments from = the jabber room to the mike if requested. Remote participants are = encouraged to use MeetEcho to make comments, but we still sometimes get = comments from jabber. >>=20 >> Many thanks in advance to our most honored volunteers! >>=20 >> Ben. >>=20 >>=20 >=20 >=20 --Apple-Mail=_BDCD0184-0A28-4235-9838-76ABF84D7C94 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAl01zYEACgkQgFZKbJXz 1A17OxAAznHxAgmLTDMMoKQyBqNiY/nvsHRveFHpk+bDxGeswrgE0+pIB69ILBpW 3E4eHDPFST7pYZp+LLRL9G6u6xbqzByjrN4BmN4dTrV33Gac3LbJKA3LH6uLzHgI Di7Nnt7jljaD8VaXltSNkck0UpyILavi79XRS7jAdw47SmnRB9yHJKXHL+oT0s+E zI/sBzTTJfFsSJbLSCeF0xswrl4Ov5qDaztsyIzQCTVPDdbjviwaBfk/EX2Jk/CQ s7wrj4ekAby/fNuCin0UcAASNXQALI4oMuBD6NPpXzZTpIfHfPIH2XsbYHfLaVy3 9aBC3C/9xY6g6qmkCRJj7SRyZJl4aaBnFIFSFxfVGv5jLPff+KWyKW01dk9w34ej sYdujnqJ7pE9mtwd9g6lwg0xnciR5z+cBJiZlLjE1TcL3EepAs4InsPJ3zLJhqmX tLMd42j0Sk1uOEF7sCr/Q+tgM087In2sGBd88H9Zj1rnxl6m9dYe8Z+NDRZU+uNY wYF/aOG5TiFKKx5D+E1WHxDBrm8XYN7K25bxdS+JGZL+SOobBunFkXbPa27m8tWA sml8Gt/LKSY7rp862bS5NydWYFuVZK7iz12yYr8eN/alLKezn3UaKFVzxZ+Fb4bz tkYasPhX3J6j527D6ZzYQdh5CgW94xxE9tgCnPHofmlDlIXmrpM= =LMfd -----END PGP SIGNATURE----- --Apple-Mail=_BDCD0184-0A28-4235-9838-76ABF84D7C94-- From nobody Mon Jul 22 09:51:58 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A38F12013B for ; Mon, 22 Jul 2019 09:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 KY8vAnDxJnGR for ; Mon, 22 Jul 2019 09:51:51 -0700 (PDT) Received: from ecbiz261.inmotionhosting.com (ecbiz261.inmotionhosting.com [173.231.209.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D356212008B for ; Mon, 22 Jul 2019 09:51:50 -0700 (PDT) Received: from mail-ot1-f54.google.com ([209.85.210.54]:36679) by ecbiz261.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hpbXC-001fLF-TJ for dispatch@ietf.org; Mon, 22 Jul 2019 12:51:48 -0400 Received: by mail-ot1-f54.google.com with SMTP id r6so40933171oti.3 for ; Mon, 22 Jul 2019 09:51:34 -0700 (PDT) X-Gm-Message-State: APjAAAX9WweKwt54tWZ0bNYZecXTH1lSDdrmd38f/lqCAK8XLKe7I7Cp ykVNDH2NOALPYUd4/fWGDDUn/aUJqfR3OZKtqLA= X-Google-Smtp-Source: APXvYqzMJqRPfLBrgf653BjMSNwanJaRVhLMzW9xRVf89mm4H8IQu1BQTY7LWVm6vZZAQMwxLzL6EVSuuyjPVk+Mgo8= X-Received: by 2002:a9d:6c4a:: with SMTP id g10mr26230557otq.31.1563814294566; Mon, 22 Jul 2019 09:51:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Rosenberg Date: Mon, 22 Jul 2019 12:51:19 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Eric Burger Cc: dispatch@ietf.org Content-Type: multipart/alternative; boundary="00000000000085bc37058e47e3a4" X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz261.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net X-Get-Message-Sender-Via: ecbiz261.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed X-Authenticated-Sender: ecbiz261.inmotionhosting.com: jdrosen@jdrosen.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [dispatch] Thoughts on draft-rosenbergjennings-dispatch-ripp-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 16:51:56 -0000 --00000000000085bc37058e47e3a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eric - thanks for taking the time to read and for the thoughtful comments. Responses inline below - but as a high level response - right now we're less interested in the details of the spec (for which the authors themselves dont all agree...), but rather to see if there is interest in solving this problem. The co-authors will be working on prototyping from here, so if anyone is interested, let us know... goal is working code before next ietf. On Sun, Jul 21, 2019 at 6:24 PM Eric Burger wrote: > General: For the most part, I like the idea of a draft that basically > says, =E2=80=9Cwe tried to be pure but failed. This proposal is not pure = but it for > the most part represents running code.=E2=80=9D PHB will be happy (ref. t= he NAT > discussion on the IETF list). > Yes, this is very much a pragmatic spec, aimed at solving some very real-world problems (ie., i've personally been beating my head against the wall trying to usefully deploy freeswitch within Istio on GKE. Let me know if you figured it out - its all hard due to how different http is from sip.= ) > > > Section 1.1: background > Will much of it be meaningful to a protocol implementer in a year, no les= s > five? I.e., referencing Kubernetes, Istio, CanaryDeploys, etc., more > especially without going into detail as to what they are? Sure, if you ar= e > an AWS developer you know them like the back of your hand. However, not > many folks in IETF-land are. > Happy to remove later on. Right now its just looknig to motivate the problem. > > 1.2: > Why is it =E2=80=98unfortunate=E2=80=99 that people want to deploy cloud = applications that > interact with the PSTN? Is that not an opportunity? I would take out the > initial =E2=80=9CUnfortunately.=E2=80=9D It=E2=80=99s just a statement of= fact that applications > like to call and be called to most any person on the planet on a fully > interoperable basis. > Stray word from a few rounds of edits, will remove thx. > > There needs to be more justification than =E2=80=9CWeb people don=E2=80= =99t understand > SIP.=E2=80=9D You might want to explain how RIPP is different than Parlay= X. I would > offer that RIPP:ParlayX::LDAP:X.500, but you don=E2=80=99t say that anywh= ere. All > the draft implies is Web people cannot grok SIP and SIP does not grok Web > deployment, which does not reflect well on either community. > No - its not about how well people understand anything. Its about how applicable modern cloud paas is to SIP and real-time services (which it really isnt), and how easy it is to build real-time apps which follow established design patterns for scalable and reliable systems (its super hard if not impossible). > > The last paragraph of 1.2 implies that SIP is the source of robocalls and > a mechanism that will be even easier to inject boatloads of calls will be > better. Please explain how this will be so (or remove the assertion). As > you know, I personally wish it would be so, so PLEASE give me ammunition! > It mandates passport as the one and only way to even know the caller ID. COnsequently, the protocol drags stir along for the ride. There is no other special magic or anything. > > 1.4: > Given the virtual mandate to use SIP over TCP, is saying =E2=80=9Cwe can = finally > use HTTP over UDP=E2=80=9D not kind of a retrograde assertion? > I wasn't being specific enough here. "SIP" refers to the whole community of specs needed for it, and this specific sentence is referring to RTP. I'll change to RTP. > > REQ 12 (supporting only audio) is an odd requirement. Moreover, most > applications in the U.S. would require at least RTT support if not video.= I > am not a lawyer, but since we are talking interoperability with the PSTN, > one is likely to run into Section 255 and 706 issues if RTT (and video) i= s > not there from day one. > I dont object - was just trying to start simple and solve one specific problem well. Do current SIP trunking providers support RTT and video? > > REQ 13 looks totally duplicative of REQ 10 (use secure caller ID > technologies). Is there a distinction? If so, please make it clearer > Bug - thx. > > Section 3.6: > This is a place where we need to distinguish between theory and reality. > In theory, SIP could provide end-to-end media security. In practice, no o= ne > figured it out. The good news is RIPP is no worse than SIP as it is > deployed today. Moreover, RIPP is no worse than HTTP. My concern is RIPP > structurally will never have end-to-end media security. While that is no > worse than today, will we be running into some privacy expectations of > users and regulators? For example, a RIPP server can record everything. > Problems here are (1) in the U.S. that is likely to be a violation of the > Wiretap Act and (2) people can use those recordings for very nefarious > purposes (see RealTalk, Lyrebird, etc.). > I would assert that RIPP would be better than SIP today. There is a lot of SIP trunking out there (note RIPP *only* addresses inter-domain trunking cases, so thats the point of comparison). Most SIP trunking interconnection is over private IP with no TLS or SRTP. There is also some over public Internet, I suspect much of it is without SRTP and probably runs over VPN often. So, a peering protocol which requires hop encryption of signaling and media, and actually authenticates both sides, is a big improvement over the current situation. E2E encryption isnt really relevant for the applicability of RIPP, since it is targeted at inter-domain connectivity towards PSTN. PSTN as you well know has no e2e encryption, and there must be decryption at the pstn gateway. I dont follow how having a server at the edge of a provider network might be in violation of the wiretap act, or somehow make recordings worse. THis is no different than the situation today with SBCs, where the vast majority have no SRTP at all, and even those that do, are decrypting so they have access to the media. > > Section 8.2: > Just curious: why MUST NOT the identifier included the authority componen= t > for uniqueness? Is that a Web best practice? A reference or explanation > would be helpful. > THis is the text: "The path component MUST be a globally unique identifier for this trunk, and not depend on the authority component as part of the namespace for purposes of uniqueness." The main motivation is to eliminate the need for wildcard certs to authoriz= e: https://12345abcdef.ripp-provider.com requires one, whereas: https://ripp-provider.com/12345abcdef does not I'll include a mention on that, thanks. > > Section 8.3: > What are the capabilities *of*? Are they codec parameters? Are they > decoded stream parameters? Are they codec dependent? Is there any value t= o > these parameters, outside parameterized codec negotiation that I am missi= ng? > THese are the capabilities of the ripp trunk. These are things normally configured as capabilities/configuration of sip trunks today. Codecs, bitrates, etc. They avoid the need for per-call capabilities exchange. Practically speaking, such exchanges are un-needed since the capabilities are static properties of the configured sip trunks. Again, we're not replacing sip overall - just providing a solution for inter-domain peering for voip to the pstn. > > For example, is the max-bitrate the decoded maximum bitrate or the bitrat= e > of the codec? What is the purpose? > If I come up with a cool LPC that can do better than G.711 with 4000 > samples per section, why cannot I use it? > No this is the max codec bitrate, same as current RTP definition. Meant more for like opus. The protocol of course is extensible to new codecs - each side advertises the codecs they support and their associated max rates. If someone however says they dont want to receive 4000 samples per second, they'd advertise a lower upper bound. This part is really no different than offer/answer. > > BIG ONE: force-cbr > Do we require a CBR codec or do we require uniform packet sizes (in > bytes)? If the former, why not just ask for a CBR codec in the request. I= f > the latter, change the parameter to something like =E2=80=9Crequire priva= cy.=E2=80=9D There > are much better ways of achieving privacy than using a CBR codec; see e.g= ., > https://repository.library.georgetown.edu/handle/10822/1040699 > Cullen was the one who wanted this one - so he's better positioned to speak to it. There was a study that found you could actually figure out what was being said just by looking at patterns of lengths of variable bitrate audio codecs. > > Section 8.4: > I agree with Cullen. It goes against the design principle of using HTTP/3 > for transport and then start putting application semantics into the > transport layer. Is there a reason to break layers, e.g., for load > balancing or something else? > Adding http headers is very common for web apps, so this isnt really different from normal web practice. That said, i dont feel that strongly on this one. Per above, right now its not so much about the specicic details of this proposal, as it is a starting point strawman for working on the problem. > > Section 8.7 > Why 20 for forward and 10 for reverse? Are these rules of thumb, > calculated optimal places to start, SWAGs, or irrelevant? > Also (and in Section 8.8), what about the speed of light and the > appearance of blocking? > TOtal SWAGs right now - we need some implementation experience to make this a more usable spec. Not sure I follow what you mean by speed of light? > > Section 8.8 > Perhaps I missed it, but what happens if a byway appears to be blocked fo= r > a =E2=80=98while=E2=80=99? Since this is voice and this is UDP and I am t= olerant of packet > loss, do I care a packet was lost? Also, I=E2=80=99m highly skeptical of = 1:1 > packet:ack this protocol offers. That sounds like a bad thing for LANs an= d > a terrible thing for WANs. Really? > We didnt spec out yet what happens if its blocked for a while. This would happen under significant packet loss, so things are really bad. Probably drop the call. Do you care if a packet is lost? in normal voip cases, no. There are some use cases where the retransmission would be handy (same reason we have an RTP extension for it..) On the 1-1 packet:ack - thats a good comment. Definitely a drawback. Would be better if its piggybacked on reverse media, but we also currently have reverse media in separate byways. SO thats a tradeoff to be explored. > > Section 8.10 > I kind of agree with Cullen=E2=80=99s point, but here is an opposite obse= rvation > that I came up with before I saw Cullen=E2=80=99s point (that SIP result = codes > don=E2=80=99t cover ISDN). Why have a separate =E2=80=98rejected=E2=80=99= result in light of > =E2=80=98failed.=E2=80=99 Unless rejected is referencing the SIP 607 resu= lt code, I would > think all the call center cares about is whether the call completed and i= f > it did not, will a retry be likely to succeed or fail. > Rejected is meant to handle the case, like mobile, where the end user actually hits the decline button. > > > There are a ton of typos in the draft. I=E2=80=99d be happy to hand my ma= rk-up to > whomever wants it in DISPATCH. > Thanks! Probably not worth fixing till we've gotten more experience under our belt and revised it to reflect that. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net --00000000000085bc37058e47e3a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric - thanks for taking the time to read and for = the thoughtful comments.

Responses inline below - = but as a high level response - right now we're less interested in the d= etails of the spec (for which the authors themselves dont all agree...), bu= t rather to see if there is interest in solving this problem. The co-author= s will be working on prototyping from here, so if anyone is interested, let= us know... goal is working code before next ietf.


=
On Sun, Ju= l 21, 2019 at 6:24 PM Eric Burger <eburger@standardstrack.com> wrote:
=


Section 1.1: background
Will much of= it be meaningful to a protocol implementer in a year, no less five? I.e., = referencing Kubernetes, Istio, CanaryDeploys, etc., more especially without= going into detail as to what they are? Sure, if you are an AWS developer y= ou know them like the back of your hand. However, not many folks in IETF-la= nd are.

Happy to remove l= ater on. Right now its just looknig to motivate the problem.=C2=A0

=C2=A0

1.2:=
Why is it =E2=80=98unfortunate=E2=80=99 that people want to depl= oy cloud applications that interact with the PSTN? Is that not an opportuni= ty? I would take out the initial =E2=80=9CUnfortunately.=E2=80=9D It=E2=80= =99s just a statement of fact that applications like to call and be called = to most any person on the planet on a fully interoperable basis.

Stray word from a few rounds of edi= ts, will remove thx.
=C2=A0

<= /div>
There needs to be more justification than =E2=80=9CWeb people don= =E2=80=99t understand SIP.=E2=80=9D You might want to explain how RIPP is d= ifferent than ParlayX. I would offer that RIPP:ParlayX::LDAP:X.500, but you= don=E2=80=99t say that anywhere. All the draft implies is Web people canno= t grok SIP and SIP does not grok Web deployment, which does not reflect wel= l on either community.

No= - its not about how well people understand anything. Its about how applica= ble modern cloud paas is to SIP and real-time services (which it really isn= t), and how easy it is to build real-time apps which follow established des= ign patterns for scalable and reliable systems (its super hard if not impos= sible).=C2=A0
=C2=A0

The last paragraph of 1.2 implies that SIP is the source of robocalls an= d a mechanism that will be even easier to inject boatloads of calls will be= better. Please explain how this will be so (or remove the assertion). As y= ou know, I personally wish it would be so, so PLEASE give me ammunition!

It mandates passport as the= one and only way to even know the caller ID. COnsequently, the protocol dr= ags stir along for the ride. There is no other special magic or anything.= =C2=A0
=C2=A0

1.4:=
Given the virtual mandate to use SIP over TCP, is saying =E2=80= =9Cwe can finally use HTTP over UDP=E2=80=9D not kind of a retrograde asser= tion?

I wasn't being = specific enough here. "SIP" refers to the whole community of spec= s needed for it, and this specific sentence is referring to RTP. I'll c= hange to RTP.

=C2=A0

REQ 12 (supporting only audio) is an odd requirement. Mor= eover, most applications in the U.S. would require at least RTT support if = not video. I am not a lawyer, but since we are talking interoperability wit= h the PSTN, one is likely to run into Section 255 and 706 issues if RTT (an= d video) is not there from day one.

=
I dont object - was just trying to start simple and solve one sp= ecific problem well. Do current SIP trunking providers support RTT and vide= o?=C2=A0

=C2=A0
REQ 13 looks totally duplicative of REQ 10 (use secure caller = ID technologies). Is there a distinction? If so, please make it clearer

Bug - thx.
=C2=A0<= /div>

Section 3.6:
This is a = place where we need to distinguish between theory and reality. In theory, S= IP could provide end-to-end media security. In practice, no one figured it = out. The good news is RIPP is no worse than SIP as it is deployed today. Mo= reover, RIPP is no worse than HTTP. My concern is RIPP structurally will ne= ver have end-to-end media security. While that is no worse than today, will= we be running into some privacy expectations of users and regulators? For = example, a RIPP server can record everything. Problems here are (1) in the = U.S. that is likely to be a violation of the Wiretap Act and (2) people can= use those recordings for very nefarious purposes (see RealTalk, Lyrebird, = etc.).

I would assert that RIPP= would be better than SIP today. There is a lot of SIP trunking out there (= note RIPP *only* addresses inter-domain trunking cases, so thats the point = of comparison). Most SIP trunking interconnection is over private IP with n= o TLS or SRTP. There is also some over public Internet, I suspect much of i= t is without SRTP and probably runs over VPN often. So, a peering protocol = which requires hop encryption of signaling and media, and actually authenti= cates both sides, is a big improvement over the current situation.

E2E encryption isnt really relevant for the applicability = of RIPP, since it is targeted at inter-domain connectivity towards PSTN. PS= TN as you well know has no e2e encryption, and there must be decryption at = the pstn gateway.=C2=A0

I dont follow how having a= server at the edge of a provider network might be in violation of the wire= tap act, or somehow make recordings worse. THis is no different than the si= tuation today with SBCs, where the vast majority have no SRTP at all, and e= ven those that do, are decrypting so they have access to the media.=C2=A0


=C2=A0
Section 8.2:
Just curious: why MUST NOT the identifi= er included the authority component for uniqueness? Is that a Web best prac= tice? A reference or explanation would be helpful.
=

THis is the text:
"The path component MUST
   be a globally unique identi=
fier for this trunk, and not depend on the
   authority component as part of the namespace for purposes of
   uniqueness."

The main m=
otivation is to eliminate the need for wildcard certs to authorize:
https://12345abcdef.ripp-provider.com requires= one, whereas:
https://ripp-provider.com/12=
345abcdef does not

I'll=
 include a mention on that, thanks.


=C2=A0
=
For example, is the max-bitrate the decoded maximum bitrate = or the bitrate of the codec? What is the purpose?
If I come up wi= th a cool LPC that can do better than G.711 with 4000 samples per section, = why cannot I use it?

No this is= the max codec bitrate, same as current RTP definition. Meant more for like= opus.
The protocol of course is extensible to new codecs - each = side advertises the codecs they support and their associated max rates. If = someone however says they dont want to receive 4000 samples per second, the= y'd advertise a lower upper bound. This part is really no different tha= n offer/answer.
=C2=A0

= BIG ONE: force-cbr
Do we require a CBR codec or do we require uni= form packet sizes (in bytes)? If the former, why not just ask for a CBR cod= ec in the request. If the latter, change the parameter to something like = =E2=80=9Crequire privacy.=E2=80=9D There are much better ways of achieving = privacy than using a CBR codec; see e.g.,=C2=A0https://re= pository.library.georgetown.edu/handle/10822/1040699

Cullen was the one who wanted this one - so he= 9;s better positioned to speak to it. There was a study that found you coul= d actually figure out what was being said just by looking at patterns of le= ngths of variable bitrate audio codecs.
=C2=A0

Section 8.4:
I agree with Cullen. It goes= against the design principle of using HTTP/3 for transport and then start = putting application semantics into the transport layer. Is there a reason t= o break layers, e.g., for load balancing or something else?

Adding http headers is very common for web app= s, so this isnt really different from normal web practice. That said, i don= t feel that strongly on this one. Per above, right now its not so much abou= t the specicic details of this proposal, as it is a starting point strawman= for working on the problem.

=C2=A0

Section 8.7
Why 20 for forward and 10= for reverse? Are these rules of thumb, calculated optimal places to start,= SWAGs, or irrelevant?
Also (and in Section 8.8), what about the = speed of light and the appearance of blocking?

TOtal SWAGs right now - we need some implementation experie= nce to make this a more usable spec.

Not sure I fo= llow what you mean by speed of light?
=C2=A0

Section= 8.10
I kind of agree with Cullen=E2=80=99s point, but here is an= opposite observation that I came up with before I saw Cullen=E2=80=99s poi= nt (that SIP result codes don=E2=80=99t cover ISDN). Why have a separate = =E2=80=98rejected=E2=80=99 result in light of =E2=80=98failed.=E2=80=99 Unl= ess rejected is referencing the SIP 607 result code, I would think all the = call center cares about is whether the call completed and if it did not, wi= ll a retry be likely to succeed or fail.

<= /div>

Rejected is meant to handle the case, like mobile,= where the end user actually hits the decline button.

<= div>=C2=A0


There a= re a ton of typos in the draft. I=E2=80=99d be happy to hand my mark-up to = whomever wants it in DISPATCH.

= Thanks! Probably not worth fixing till we've gotten more experience und= er our belt and revised it to reflect that.


=C2=A0
____= ___________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net<= /a>
http://www.jdro= sen.net
--00000000000085bc37058e47e3a4-- From nobody Mon Jul 22 13:36:49 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645651200A3 for ; Mon, 22 Jul 2019 13:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 pA95NDs67HFj for ; Mon, 22 Jul 2019 13:36:34 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 B2BB01200FD for ; Mon, 22 Jul 2019 13:36:32 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id c9so27597066lfh.4 for ; Mon, 22 Jul 2019 13:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=WE5v5GQDtvmu+HJ52A3thcKZ6q79BY8L24gjsBMttSY=; b=v9pX59Fg3ZVNVUkggLIPp8TettOlqAhg/Ho+i0YEFnYgtcbboMBnIfxPxHN2CIdj13 hCvm22HzmaMsdEC0S7RuLVzKWDmBKe3Cjs+c9DIweqfIgjiw3jlYRHAcdkZ5g4bqMqhv 8veL1jiKSUcov/omQoK+GXgf0Ffj+ui8RKMhC0JNWhqoSlUsUwVapFOPYov5118BxHik 6NduFNgHvc1x7queoaujP4agCxr7M/fvvILfxRJGK3bTx9kOHJ5Whq/ty8kpzPdUOmIM rn0MY5dlPGX7its1je8sDolfpdRGt/lKx8mHOJlgViK9sCrPPpzwwsL5X4asyof8egpa fTZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=WE5v5GQDtvmu+HJ52A3thcKZ6q79BY8L24gjsBMttSY=; b=dWqr/4/XEtr0UHcbtObtYs1R8iPTatzIqAKaw/tnyBtegYeITgiF3ylUTRN0NvMSNZ s7ML1FfwiYvcYGcISpceAz85QW+7pEy8r97ekm5tNEMKoLEBEdgz72i8cuLGfxg0xaQJ vg36m/O7P0BHsq0Yh+9XCCbOTvCAWxzxgQzmHvrIL7YH+r3HHAmTScBKXkeWSl24leeQ HhF+5i02vorlPN1FoG/9NSEnwOV9HQmXr7DU3b2NdvSI4g9jb509rFL0SOhnd9Ojtmyr yA6iNJqD08SOdEaj8dOFnnRN2WLV52/YD3l09FRbYUABnVlZHGx+6BLE7ttRl2EhK6SE eBhQ== X-Gm-Message-State: APjAAAXC8Z9ijdIB0ldolABRg9M3HXsFj9fyzi9vYWvtyv4ZNZwGhzhP TBc9TBcceQutemo+bMZAXTvnDt/exFwDQwto0YV+VxwMBI6EorqH X-Google-Smtp-Source: APXvYqwUFPGe+8AF/WfWXs15m/AVkEVfqouzUCnyaOjvNAi+Bps3509CZ6HTsQYdin5F4pLJpfg80JjUiQVCg7Hu45w= X-Received: by 2002:a19:48d1:: with SMTP id v200mr31728919lfa.190.1563827790444; Mon, 22 Jul 2019 13:36:30 -0700 (PDT) MIME-Version: 1.0 From: Victor Vasiliev Date: Mon, 22 Jul 2019 16:36:19 -0400 Message-ID: To: dispatch@ietf.org, David Schinazi Cc: IETF QUIC WG , HTTP Working Group , hybi@ietf.org Content-Type: multipart/alternative; boundary="000000000000f0ea9e058e4b0703" Archived-At: Subject: [dispatch] WebTransport Side Meeting (Tuesday, 15:20) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 20:36:36 -0000 --000000000000f0ea9e058e4b0703 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, Today, at the dispatch working group meeting (18:10), I am going to present WebTransport. WebTransport is a protocol framework that allows multiplexed and datagram-oriented transport protocols to be used by the web applications (think =E2=80=9CWebSocket for UDP=E2=80=9D). Since it=E2=80=99s quite likely we will run out of time during dispatch, I scheduled a side-meeting to discuss this in more depth. Below are the side meeting details. *Time:* Tuesday, 15:20 ~ 16:50 *Place:* Room C2 (21st floor) *Organizers:* Victor Vasiliev, David Schinazi *Agenda:* 1. A more in-depth overview of WebTransport. 2. Discussion of the overall design and the use cases. 3. As time permits, some of the major outstanding design issues in Web transport, e.g.: - What fallback protocol to use? - How to multiplex streams and datagrams within a single connection? - Can we let web applications do their own congestion control? - Should WebTransport sessions have URLs associated with them? As usual, here are some helpful links: - WebTransport overview: https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 - QuicTransport: https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 - Http3Transport: https://tools.ietf.org/html/draft-vvv-webtransport-http3-00 - Web API Spec draft: https://wicg.github.io/web-transport/ - Discussion on use cases: https://discourse.wicg.io/t/webtransport-proposal/3508 Cheers, Victor. --000000000000f0ea9e058e4b0703 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

Today, at the dispatch working grou= p meeting (18:10), I am going to present WebTransport. WebTransport is a pr= otocol framework that allows multiplexed and datagram-oriented transport pr= otocols to be used by the web applications (think =E2=80=9CWebSocket for UD= P=E2=80=9D).

Since it=E2=80=99s quite likely we will run out of time= during dispatch, I scheduled a side-meeting to discuss this in more depth.= Below are the side meeting details.

Time: Tuesday, 15:20 ~ 1= 6:50
Place: Room C2 (21st floor)
Organizers: Victor Vas= iliev, David Schinazi
Agenda:
  1. A more in-depth overview= of WebTransport.
  2. Discussion of the overall design and the use case= s.
  3. As time permits, some of the major outstanding design issues in = Web transport, e.g.:
    • What fallback protocol to use?
    • How= to multiplex streams and datagrams within a single connection?
    • Can= we let web applications do their own congestion control?
    • Should We= bTransport sessions have URLs associated with them?
As usual,= here are some helpful links:
Cheers,
=C2= =A0 Victor.
--000000000000f0ea9e058e4b0703-- From nobody Mon Jul 22 14:00:14 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E280120120; Mon, 22 Jul 2019 14:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 sjEAunKIUEID; Mon, 22 Jul 2019 14:00:09 -0700 (PDT) Received: from warmcat.com (warmcat.com [46.105.127.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9268812008C; Mon, 22 Jul 2019 14:00:08 -0700 (PDT) To: Victor Vasiliev , dispatch@ietf.org, David Schinazi Cc: hybi@ietf.org, IETF QUIC WG , HTTP Working Group References: From: Andy Green Message-ID: <5c631764-25e2-ce37-3f84-8eca5a8378eb@warmcat.com> Date: Mon, 22 Jul 2019 13:59:57 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] [hybi] WebTransport Side Meeting (Tuesday, 15:20) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 21:00:13 -0000 On 7/22/19 1:36 PM, Victor Vasiliev wrote: > Hello everyone, > > Today, at the dispatch working group meeting (18:10), I am going to > present WebTransport. WebTransport is a protocol framework that allows > multiplexed and datagram-oriented transport protocols to be used by the > web applications (think “WebSocket for UDP”). "Historically, web applications that needed bidirectional data stream between a client and a server could rely on WebSockets [RFC6455], a message-based protocol compatible with Web security model. However, since the abstraction it provides is a single ordered stream of messages, it suffers from head-of-line blocking (HOLB), meaning that all messages must be sent and received in order even if they are independent and some of them are no longer needed. This makes it a poor fit for latency sensitive applications which rely on partial reliability and stream independence for performance." The HOLB isn't really entirely the case... RFC6455 ws allows arbitrary fragmentation of messages allowing interleaving with control frames. ws-over-h2 allows you to can the h2 stream when you want as well. " Each new stream would require a WebSocket handshake to agree on application protocol used, meaning that it would take at least one RTT for each new stream before the client can write to it." Yes it was knowingly done as a hack to try to encourage uptake from browser vendors... it's not really integrated into the encapsulating protocol. > * WebTransport overview: > https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 > * QuicTransport: > https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 > * Http3Transport: > https://tools.ietf.org/html/draft-vvv-webtransport-http3-00 There's no h2 transport implementation? Not everything that might want to use this will get h3 capability in a reasonable timeframe. If there's more momentum behind it than RFC8441 there's probably room for a generic long-lived bidirectional extension to h2 either reusing DATA or a new frame type. It's a good idea to have it ride on other protocols. Not doing this really hurt RFC6455 ws since deploying it usually needed extra, different servers with the attendant difficulties interoperating with other protocols. I really suggest thinking through the effects of not having an RFC6455 type subprotocol (unless I failed to spot it). It really makes an implicit assumption about what the stream will carry that doesn't scale beyond one server carrying one thing. That's not how things tend to pan out if the protocol is useful. The url path could be hacked to imply the subprotocol but if that's not standardized it's still a mess. And the subprotocol binding may be orthogonal to the url layout complicating things needlessly. -Andy > * Web API Spec draft: https://wicg.github.io/web-transport/ > * Discussion on use cases: > https://discourse.wicg.io/t/webtransport-proposal/3508 > > Cheers, >   Victor. > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From nobody Mon Jul 22 14:29:27 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356C512001B; Mon, 22 Jul 2019 14:29:20 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=apple.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 c6j6GSy2js4I; Mon, 22 Jul 2019 14:29:18 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FECB1200B9; Mon, 22 Jul 2019 14:29:18 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6MLM69N062761; Mon, 22 Jul 2019 14:29:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=Mjp+2BlrZ2RjXqmOsoC9wmr6feKbPVzKF5onqcpmZqQ=; b=SSUjTpiePl98fdqT/fXYJCj9LCZJVpF+JZAATCtw6the8n9jJ2S7b455Rb81pAffVeZP oT6nWsN/4TWUcf+OflhbsgVbt0gCZchayfItP748m/KRgewtMxEo8jOlQgdx3ysWNLc3 qtvddUQ/QJIUr1xRGA1Zeo0chKUs5Ftn4Z9P0NeM7R1f0B+vYlNiAIWsyCD7FIts0ngl Pi5TF+xjouvrEhx/KFpLpWdydtvuuiX//ayo6ftd2K3WWIjFprPIBG1dMBFq3sdKBT8/ VngibxOhAM1RUNVlgkdYZOd+ntnXLxsxgKySV2H5sfzapk0dzb6IOwf+OfL19zLNgR/r OQ== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2tv1xymqf4-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 22 Jul 2019 14:29:13 -0700 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PV200BQ4BOOYL60@ma1-mtap-s02.corp.apple.com>; Mon, 22 Jul 2019 14:29:13 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PV200K00AP1BB00@nwk-mmpp-sz10.apple.com>; Mon, 22 Jul 2019 14:29:12 -0700 (PDT) X-Va-A: X-Va-T-CD: 68f2109845201c7217a51c1ddd85d479 X-Va-E-CD: 0d3c3e2cca636b8155b399dd19473f9c X-Va-R-CD: 8aa891bccd01e26013fb581b8aa95994 X-Va-CD: 0 X-Va-ID: 4910b7c8-b14a-406b-9e46-9a1e7d5a72cc X-V-A: X-V-T-CD: 68f2109845201c7217a51c1ddd85d479 X-V-E-CD: 0d3c3e2cca636b8155b399dd19473f9c X-V-R-CD: 8aa891bccd01e26013fb581b8aa95994 X-V-CD: 0 X-V-ID: be48a199-b79c-4fa2-96ab-7383782d1cc7 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-22_15:,, signatures=0 Received: from [17.235.124.103] (unknown [17.235.124.103]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PV2006FQBOM7410@nwk-mmpp-sz10.apple.com>; Mon, 22 Jul 2019 14:29:12 -0700 (PDT) Sender: ekinnear@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Eric Kinnear In-reply-to: <5c631764-25e2-ce37-3f84-8eca5a8378eb@warmcat.com> Date: Mon, 22 Jul 2019 17:29:09 -0400 Cc: Victor Vasiliev , dispatch@ietf.org, David Schinazi , hybi@ietf.org, IETF QUIC WG , HTTP Working Group Content-transfer-encoding: quoted-printable Message-id: References: <5c631764-25e2-ce37-3f84-8eca5a8378eb@warmcat.com> To: Andy Green X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-22_15:, , signatures=0 Archived-At: Subject: Re: [dispatch] [hybi] WebTransport Side Meeting (Tuesday, 15:20) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 21:29:20 -0000 > On Jul 22, 2019, at 4:59 PM, Andy Green wrote: >=20 >=20 >=20 > On 7/22/19 1:36 PM, Victor Vasiliev wrote: >> Hello everyone, >> Today, at the dispatch working group meeting (18:10), I am going to = present WebTransport. WebTransport is a protocol framework that allows = multiplexed and datagram-oriented transport protocols to be used by the = web applications (think =E2=80=9CWebSocket for UDP=E2=80=9D). >=20 > "Historically, web applications that needed bidirectional data stream > between a client and a server could rely on WebSockets [RFC6455], a > message-based protocol compatible with Web security model. However, > since the abstraction it provides is a single ordered stream of > messages, it suffers from head-of-line blocking (HOLB), meaning that > all messages must be sent and received in order even if they are > independent and some of them are no longer needed. This makes it a > poor fit for latency sensitive applications which rely on partial > reliability and stream independence for performance." >=20 > The HOLB isn't really entirely the case... RFC6455 ws allows arbitrary = fragmentation of messages allowing interleaving with control frames. >=20 > ws-over-h2 allows you to can the h2 stream when you want as well. >=20 > " Each new stream would require a WebSocket handshake to agree on > application protocol used, meaning that it would take at least = one > RTT for each new stream before the client can write to it." >=20 > Yes it was knowingly done as a hack to try to encourage uptake from = browser vendors... it's not really integrated into the encapsulating = protocol. >=20 >> * WebTransport overview: >> https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 >> * QuicTransport: >> https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 >> * Http3Transport: >> https://tools.ietf.org/html/draft-vvv-webtransport-http3-00 >=20 > There's no h2 transport implementation? >=20 > Not everything that might want to use this will get h3 capability in a = reasonable timeframe. If there's more momentum behind it than RFC8441 = there's probably room for a generic long-lived bidirectional extension = to h2 either reusing DATA or a new frame type. Definitely agree! I know that we=E2=80=99ve been chatting a bit with = Victor about = https://datatracker.ietf.org/doc/draft-kinnear-httpbis-http2-transport/ = which aims to provide this, and I think it would be worth making sure = that this works nicely with WebTransport.=20 -00 for that document covers effectively what you=E2=80=99d get with a = new frame type, and -01 extends 8441 to cover more than just WebSockets = with the extended CONNECT handshake. I don=E2=80=99t have a particularly strong preference for the mechanism = used, but rather care more about the outcome =E2=80=94 very much agree = that this is a useful component. Thanks, Eric >=20 > It's a good idea to have it ride on other protocols. Not doing this = really hurt RFC6455 ws since deploying it usually needed extra, = different servers with the attendant difficulties interoperating with = other protocols. >=20 > I really suggest thinking through the effects of not having an RFC6455 = type subprotocol (unless I failed to spot it). It really makes an = implicit assumption about what the stream will carry that doesn't scale = beyond one server carrying one thing. That's not how things tend to pan = out if the protocol is useful. The url path could be hacked to imply = the subprotocol but if that's not standardized it's still a mess. And = the subprotocol binding may be orthogonal to the url layout complicating = things needlessly. >=20 > -Andy >=20 >> * Web API Spec draft: https://wicg.github.io/web-transport/ >> * Discussion on use cases: >> https://discourse.wicg.io/t/webtransport-proposal/3508 >> Cheers, >> Victor. >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >=20 From nobody Mon Jul 22 16:03:06 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD721200B9 for ; Mon, 22 Jul 2019 16:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 O6BJlVYenJHa for ; Mon, 22 Jul 2019 16:03:01 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 D4A70120045 for ; Mon, 22 Jul 2019 16:03:00 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1hphKc-0003gF-FV for dispatch@ietf.org; Tue, 23 Jul 2019 01:02:58 +0200 Date: Tue, 23 Jul 2019 01:02:58 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: IETF DISPATCH list In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="37663318-251774225-1563836578=:12363" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: [dispatch] Side-Meeting MEDUP (incl. Private Key Synchronization) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 23:03:04 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --37663318-251774225-1563836578=:12363 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT As just instructed by the chair, I am sending the side meeting information for MEDUP (Missing Elemments for Decentralized and Usable Privacy) to the list. Please find more information below. The most insteresting topic appears to be the protocol to synchronize Private Keys among different devices belonging to the same user. For a few weeks we have runing code and there is an early Internet Draft to specify the KeySync protocol: https://tools.ietf.org/html/draft-hoeneisen-pep-keysync-00 Discussions will be on the MEDUP Mailing list: https://www.ietf.org/mailman/listinfo/MEDUP Looking forward to see you on Wed, 14:50-16:50 in room C2 (21st floor)! All the best, Bernie > On Mon, 22 Jul 2019, Hernâni Marques (p≡p foundation) wrote: > >> Dear folks >> >> >> Following our meeting @ IETF-104 in Prague [1][2], we will have our second >> non-WG meeting @ IETF-105 in Montreal, taking place Wed, 24 July, from >> 14:50-16:50 EDT in room C2 (21st floor). >> >> To know how many people to expect, it would be nice you could sign up >> here (with some name): >> >> https://du7f.koalatux.ch/SrtXRHemfNY-xM3k-QWGKA >> >> Please note that this time we will also provide a Jitsi/WebRTC remote >> participation channel (by best effort): >> >> https://meet.digitale-gesellschaft.ch/medup >> >> The current agenda is here: >> >> >> https://pep.foundation/dev/repos/internet-drafts/file/tip/medup/ietf-105/agenda.txt >> >> In that respect, if you want to present an approach / a missing piece in >> scope of MEDUP or suggest other changes to the agenda, please reach out! >> >> >> Cu soon & thanks! >> >> Greets >> >> Hernani >> >> >> [1] Minutes from IETF-104: >> https://pep.foundation/dev/repos/internet-drafts/file/tip/medup/ietf-104/notes-ietf-104-medup-00.txt >> >> [2] Meeting materials and video podcast: >> https://pep.foundation/docs/ietf/104/medup/ >> >> -- >> p≡p foundation: https://pep.foundation/ > --37663318-251774225-1563836578=:12363-- From nobody Mon Jul 22 16:05:27 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145981200DE for ; Mon, 22 Jul 2019 16:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 I0Rwdpxt0m_b for ; Mon, 22 Jul 2019 16:05:20 -0700 (PDT) Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [198.46.93.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7386A120045 for ; Mon, 22 Jul 2019 16:05:20 -0700 (PDT) Received: from [207.115.96.130] (port=60768 helo=[172.16.142.251]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hphMj-000QmR-3L; Mon, 22 Jul 2019 16:05:20 -0700 SavedFromEmail: eburger@standardstrack.com Date: Mon, 22 Jul 2019 19:05:05 -0400 In-Reply-To: Importance: normal From: Eric Burger To: Jonathan Rosenberg Cc: dispatch@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_104145449745110" X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20190722230520.7386A120045@ietfa.amsl.com> Archived-At: Subject: Re: [dispatch] Thoughts on draft-rosenbergjennings-dispatch-ripp-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 23:05:25 -0000 ----_com.samsung.android.email_104145449745110 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QWggLSBhZnRlciBzZWVpbmcgdGhpcyBhbmQgQ3VsbGVuJ3MgcHJlc2VudGF0aW9uIEkganVzdCBm aWd1cmVkIG91dCB0aGVyZSBpcyBubyBhc2sgb2YgdGhlIElFVEYgb3RoZXIgdGhhbiB0byBwbGVh c2UgY29udHJpYnV0ZSB0byB0aGUgcmVzZWFyY2ggdG8gc29sdmUgdGhlIHByb2JsZW0gc3VjaCB0 aGF0IHNvbWVkYXkgd2UgV0lMTCBoYXZlIGEgcmVwbGFjZW1lbnQgZm9yIHRoYXQgMjAteWVhci1v bGQgbGVnYWN5IHByb3RvY29sIGFuZCBpbiBhIGZldyBjeWNsZXMgaGF2ZSBhIGNvbmNyZXRlIHBy b3Bvc2FsIHRoYXQgd2UgY291bGQgZm9ybSBhIERpc3BhdGNoIG9yIHdvcmsgZ3JvdXAuwqBJJ20g YWxsIGZvciB0aGF0IQotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJvbTogSm9u YXRoYW4gUm9zZW5iZXJnIDxqZHJvc2VuQGpkcm9zZW4ubmV0PiBEYXRlOiA3LzIyLzE5ICAxMjo1 MSBQTSAgKEdNVC0wNTowMCkgVG86IEVyaWMgQnVyZ2VyIDxlYnVyZ2VyQHN0YW5kYXJkc3RyYWNr LmNvbT4gQ2M6IGRpc3BhdGNoQGlldGYub3JnIFN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIFRob3Vn aHRzIG9uIGRyYWZ0LXJvc2VuYmVyZ2plbm5pbmdzLWRpc3BhdGNoLXJpcHAtMDMgSGkgRXJpYyAt IHRoYW5rcyBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIHJlYWQgYW5kIGZvciB0aGUgdGhvdWdodGZ1 bCBjb21tZW50cy5SZXNwb25zZXMgaW5saW5lIGJlbG93IC0gYnV0IGFzIGEgaGlnaCBsZXZlbCBy ZXNwb25zZSAtIHJpZ2h0IG5vdyB3ZSdyZSBsZXNzIGludGVyZXN0ZWQgaW4gdGhlIGRldGFpbHMg b2YgdGhlIHNwZWMgKGZvciB3aGljaCB0aGUgYXV0aG9ycyB0aGVtc2VsdmVzIGRvbnQgYWxsIGFn cmVlLi4uKSwgYnV0IHJhdGhlciB0byBzZWUgaWYgdGhlcmUgaXMgaW50ZXJlc3QgaW4gc29sdmlu ZyB0aGlzIHByb2JsZW0uIFRoZSBjby1hdXRob3JzIHdpbGwgYmUgd29ya2luZyBvbiBwcm90b3R5 cGluZyBmcm9tIGhlcmUsIHNvIGlmIGFueW9uZSBpcyBpbnRlcmVzdGVkLCBsZXQgdXMga25vdy4u LiBnb2FsIGlzIHdvcmtpbmcgY29kZSBiZWZvcmUgbmV4dCBpZXRmLk9uIFN1biwgSnVsIDIxLCAy MDE5IGF0IDY6MjQgUE0gRXJpYyBCdXJnZXIgPGVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tPiB3 cm90ZTpHZW5lcmFsOiBGb3IgdGhlIG1vc3QgcGFydCwgSSBsaWtlIHRoZSBpZGVhIG9mIGEgZHJh ZnQgdGhhdCBiYXNpY2FsbHkgc2F5cywg4oCcd2UgdHJpZWQgdG8gYmUgcHVyZSBidXQgZmFpbGVk LiBUaGlzIHByb3Bvc2FsIGlzIG5vdCBwdXJlIGJ1dCBpdCBmb3IgdGhlIG1vc3QgcGFydCByZXBy ZXNlbnRzIHJ1bm5pbmcgY29kZS7igJ0gUEhCIHdpbGwgYmUgaGFwcHkgKHJlZi4gdGhlIE5BVCBk aXNjdXNzaW9uIG9uIHRoZSBJRVRGIGxpc3QpLsKgWWVzLCB0aGlzIGlzIHZlcnkgbXVjaCBhIHBy YWdtYXRpYyBzcGVjLCBhaW1lZCBhdCBzb2x2aW5nIHNvbWUgdmVyeSByZWFsLXdvcmxkIHByb2Js ZW1zIChpZS4sIGkndmUgcGVyc29uYWxseSBiZWVuIGJlYXRpbmcgbXkgaGVhZCBhZ2FpbnN0IHRo ZSB3YWxsIHRyeWluZyB0byB1c2VmdWxseSBkZXBsb3kgZnJlZXN3aXRjaCB3aXRoaW4gSXN0aW8g b24gR0tFLiBMZXQgbWUga25vdyBpZiB5b3UgZmlndXJlZCBpdCBvdXQgLSBpdHMgYWxsIGhhcmQg ZHVlIHRvIGhvdyBkaWZmZXJlbnQgaHR0cCBpcyBmcm9tIHNpcC4pwqBTZWN0aW9uIDEuMTogYmFj a2dyb3VuZFdpbGwgbXVjaCBvZiBpdCBiZSBtZWFuaW5nZnVsIHRvIGEgcHJvdG9jb2wgaW1wbGVt ZW50ZXIgaW4gYSB5ZWFyLCBubyBsZXNzIGZpdmU/IEkuZS4sIHJlZmVyZW5jaW5nIEt1YmVybmV0 ZXMsIElzdGlvLCBDYW5hcnlEZXBsb3lzLCBldGMuLCBtb3JlIGVzcGVjaWFsbHkgd2l0aG91dCBn b2luZyBpbnRvIGRldGFpbCBhcyB0byB3aGF0IHRoZXkgYXJlPyBTdXJlLCBpZiB5b3UgYXJlIGFu IEFXUyBkZXZlbG9wZXIgeW91IGtub3cgdGhlbSBsaWtlIHRoZSBiYWNrIG9mIHlvdXIgaGFuZC4g SG93ZXZlciwgbm90IG1hbnkgZm9sa3MgaW4gSUVURi1sYW5kIGFyZS5IYXBweSB0byByZW1vdmUg bGF0ZXIgb24uIFJpZ2h0IG5vdyBpdHMganVzdCBsb29rbmlnIHRvIG1vdGl2YXRlIHRoZSBwcm9i bGVtLsKgwqAxLjI6V2h5IGlzIGl0IOKAmHVuZm9ydHVuYXRl4oCZIHRoYXQgcGVvcGxlIHdhbnQg dG8gZGVwbG95IGNsb3VkIGFwcGxpY2F0aW9ucyB0aGF0IGludGVyYWN0IHdpdGggdGhlIFBTVE4/ IElzIHRoYXQgbm90IGFuIG9wcG9ydHVuaXR5PyBJIHdvdWxkIHRha2Ugb3V0IHRoZSBpbml0aWFs IOKAnFVuZm9ydHVuYXRlbHku4oCdIEl04oCZcyBqdXN0IGEgc3RhdGVtZW50IG9mIGZhY3QgdGhh dCBhcHBsaWNhdGlvbnMgbGlrZSB0byBjYWxsIGFuZCBiZSBjYWxsZWQgdG8gbW9zdCBhbnkgcGVy c29uIG9uIHRoZSBwbGFuZXQgb24gYSBmdWxseSBpbnRlcm9wZXJhYmxlIGJhc2lzLlN0cmF5IHdv cmQgZnJvbSBhIGZldyByb3VuZHMgb2YgZWRpdHMsIHdpbGwgcmVtb3ZlIHRoeC7CoFRoZXJlIG5l ZWRzIHRvIGJlIG1vcmUganVzdGlmaWNhdGlvbiB0aGFuIOKAnFdlYiBwZW9wbGUgZG9u4oCZdCB1 bmRlcnN0YW5kIFNJUC7igJ0gWW91IG1pZ2h0IHdhbnQgdG8gZXhwbGFpbiBob3cgUklQUCBpcyBk aWZmZXJlbnQgdGhhbiBQYXJsYXlYLiBJIHdvdWxkIG9mZmVyIHRoYXQgUklQUDpQYXJsYXlYOjpM REFQOlguNTAwLCBidXQgeW91IGRvbuKAmXQgc2F5IHRoYXQgYW55d2hlcmUuIEFsbCB0aGUgZHJh ZnQgaW1wbGllcyBpcyBXZWIgcGVvcGxlIGNhbm5vdCBncm9rIFNJUCBhbmQgU0lQIGRvZXMgbm90 IGdyb2sgV2ViIGRlcGxveW1lbnQsIHdoaWNoIGRvZXMgbm90IHJlZmxlY3Qgd2VsbCBvbiBlaXRo ZXIgY29tbXVuaXR5Lk5vIC0gaXRzIG5vdCBhYm91dCBob3cgd2VsbCBwZW9wbGUgdW5kZXJzdGFu ZCBhbnl0aGluZy4gSXRzIGFib3V0IGhvdyBhcHBsaWNhYmxlIG1vZGVybiBjbG91ZCBwYWFzIGlz IHRvIFNJUCBhbmQgcmVhbC10aW1lIHNlcnZpY2VzICh3aGljaCBpdCByZWFsbHkgaXNudCksIGFu ZCBob3cgZWFzeSBpdCBpcyB0byBidWlsZCByZWFsLXRpbWUgYXBwcyB3aGljaCBmb2xsb3cgZXN0 YWJsaXNoZWQgZGVzaWduIHBhdHRlcm5zIGZvciBzY2FsYWJsZSBhbmQgcmVsaWFibGUgc3lzdGVt cyAoaXRzIHN1cGVyIGhhcmQgaWYgbm90IGltcG9zc2libGUpLsKgwqBUaGUgbGFzdCBwYXJhZ3Jh cGggb2YgMS4yIGltcGxpZXMgdGhhdCBTSVAgaXMgdGhlIHNvdXJjZSBvZiByb2JvY2FsbHMgYW5k IGEgbWVjaGFuaXNtIHRoYXQgd2lsbCBiZSBldmVuIGVhc2llciB0byBpbmplY3QgYm9hdGxvYWRz IG9mIGNhbGxzIHdpbGwgYmUgYmV0dGVyLiBQbGVhc2UgZXhwbGFpbiBob3cgdGhpcyB3aWxsIGJl IHNvIChvciByZW1vdmUgdGhlIGFzc2VydGlvbikuIEFzIHlvdSBrbm93LCBJIHBlcnNvbmFsbHkg d2lzaCBpdCB3b3VsZCBiZSBzbywgc28gUExFQVNFIGdpdmUgbWUgYW1tdW5pdGlvbiFJdCBtYW5k YXRlcyBwYXNzcG9ydCBhcyB0aGUgb25lIGFuZCBvbmx5IHdheSB0byBldmVuIGtub3cgdGhlIGNh bGxlciBJRC4gQ09uc2VxdWVudGx5LCB0aGUgcHJvdG9jb2wgZHJhZ3Mgc3RpciBhbG9uZyBmb3Ig dGhlIHJpZGUuIFRoZXJlIGlzIG5vIG90aGVyIHNwZWNpYWwgbWFnaWMgb3IgYW55dGhpbmcuwqDC oDEuNDpHaXZlbiB0aGUgdmlydHVhbCBtYW5kYXRlIHRvIHVzZSBTSVAgb3ZlciBUQ1AsIGlzIHNh eWluZyDigJx3ZSBjYW4gZmluYWxseSB1c2UgSFRUUCBvdmVyIFVEUOKAnSBub3Qga2luZCBvZiBh IHJldHJvZ3JhZGUgYXNzZXJ0aW9uP0kgd2Fzbid0IGJlaW5nIHNwZWNpZmljIGVub3VnaCBoZXJl LiAiU0lQIiByZWZlcnMgdG8gdGhlIHdob2xlIGNvbW11bml0eSBvZiBzcGVjcyBuZWVkZWQgZm9y IGl0LCBhbmQgdGhpcyBzcGVjaWZpYyBzZW50ZW5jZSBpcyByZWZlcnJpbmcgdG8gUlRQLiBJJ2xs IGNoYW5nZSB0byBSVFAuwqBSRVEgMTIgKHN1cHBvcnRpbmcgb25seSBhdWRpbykgaXMgYW4gb2Rk IHJlcXVpcmVtZW50LiBNb3Jlb3ZlciwgbW9zdCBhcHBsaWNhdGlvbnMgaW4gdGhlIFUuUy4gd291 bGQgcmVxdWlyZSBhdCBsZWFzdCBSVFQgc3VwcG9ydCBpZiBub3QgdmlkZW8uIEkgYW0gbm90IGEg bGF3eWVyLCBidXQgc2luY2Ugd2UgYXJlIHRhbGtpbmcgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIHRo ZSBQU1ROLCBvbmUgaXMgbGlrZWx5IHRvIHJ1biBpbnRvIFNlY3Rpb24gMjU1IGFuZCA3MDYgaXNz dWVzIGlmIFJUVCAoYW5kIHZpZGVvKSBpcyBub3QgdGhlcmUgZnJvbSBkYXkgb25lLkkgZG9udCBv YmplY3QgLSB3YXMganVzdCB0cnlpbmcgdG8gc3RhcnQgc2ltcGxlIGFuZCBzb2x2ZSBvbmUgc3Bl Y2lmaWMgcHJvYmxlbSB3ZWxsLiBEbyBjdXJyZW50IFNJUCB0cnVua2luZyBwcm92aWRlcnMgc3Vw cG9ydCBSVFQgYW5kIHZpZGVvP8KgwqBSRVEgMTMgbG9va3MgdG90YWxseSBkdXBsaWNhdGl2ZSBv ZiBSRVEgMTAgKHVzZSBzZWN1cmUgY2FsbGVyIElEIHRlY2hub2xvZ2llcykuIElzIHRoZXJlIGEg ZGlzdGluY3Rpb24/IElmIHNvLCBwbGVhc2UgbWFrZSBpdCBjbGVhcmVyQnVnIC0gdGh4LsKgU2Vj dGlvbiAzLjY6VGhpcyBpcyBhIHBsYWNlIHdoZXJlIHdlIG5lZWQgdG8gZGlzdGluZ3Vpc2ggYmV0 d2VlbiB0aGVvcnkgYW5kIHJlYWxpdHkuIEluIHRoZW9yeSwgU0lQIGNvdWxkIHByb3ZpZGUgZW5k LXRvLWVuZCBtZWRpYSBzZWN1cml0eS4gSW4gcHJhY3RpY2UsIG5vIG9uZSBmaWd1cmVkIGl0IG91 dC4gVGhlIGdvb2QgbmV3cyBpcyBSSVBQIGlzIG5vIHdvcnNlIHRoYW4gU0lQIGFzIGl0IGlzIGRl cGxveWVkIHRvZGF5LiBNb3Jlb3ZlciwgUklQUCBpcyBubyB3b3JzZSB0aGFuIEhUVFAuIE15IGNv bmNlcm4gaXMgUklQUCBzdHJ1Y3R1cmFsbHkgd2lsbCBuZXZlciBoYXZlIGVuZC10by1lbmQgbWVk aWEgc2VjdXJpdHkuIFdoaWxlIHRoYXQgaXMgbm8gd29yc2UgdGhhbiB0b2RheSwgd2lsbCB3ZSBi ZSBydW5uaW5nIGludG8gc29tZSBwcml2YWN5IGV4cGVjdGF0aW9ucyBvZiB1c2VycyBhbmQgcmVn dWxhdG9ycz8gRm9yIGV4YW1wbGUsIGEgUklQUCBzZXJ2ZXIgY2FuIHJlY29yZCBldmVyeXRoaW5n LiBQcm9ibGVtcyBoZXJlIGFyZSAoMSkgaW4gdGhlIFUuUy4gdGhhdCBpcyBsaWtlbHkgdG8gYmUg YSB2aW9sYXRpb24gb2YgdGhlIFdpcmV0YXAgQWN0IGFuZCAoMikgcGVvcGxlIGNhbiB1c2UgdGhv c2UgcmVjb3JkaW5ncyBmb3IgdmVyeSBuZWZhcmlvdXMgcHVycG9zZXMgKHNlZSBSZWFsVGFsaywg THlyZWJpcmQsIGV0Yy4pLkkgd291bGQgYXNzZXJ0IHRoYXQgUklQUCB3b3VsZCBiZSBiZXR0ZXIg dGhhbiBTSVAgdG9kYXkuIFRoZXJlIGlzIGEgbG90IG9mIFNJUCB0cnVua2luZyBvdXQgdGhlcmUg KG5vdGUgUklQUCAqb25seSogYWRkcmVzc2VzIGludGVyLWRvbWFpbiB0cnVua2luZyBjYXNlcywg c28gdGhhdHMgdGhlIHBvaW50IG9mIGNvbXBhcmlzb24pLiBNb3N0IFNJUCB0cnVua2luZyBpbnRl cmNvbm5lY3Rpb24gaXMgb3ZlciBwcml2YXRlIElQIHdpdGggbm8gVExTIG9yIFNSVFAuIFRoZXJl IGlzIGFsc28gc29tZSBvdmVyIHB1YmxpYyBJbnRlcm5ldCwgSSBzdXNwZWN0IG11Y2ggb2YgaXQg aXMgd2l0aG91dCBTUlRQIGFuZCBwcm9iYWJseSBydW5zIG92ZXIgVlBOIG9mdGVuLiBTbywgYSBw ZWVyaW5nIHByb3RvY29sIHdoaWNoIHJlcXVpcmVzIGhvcCBlbmNyeXB0aW9uIG9mIHNpZ25hbGlu ZyBhbmQgbWVkaWEsIGFuZCBhY3R1YWxseSBhdXRoZW50aWNhdGVzIGJvdGggc2lkZXMsIGlzIGEg YmlnIGltcHJvdmVtZW50IG92ZXIgdGhlIGN1cnJlbnQgc2l0dWF0aW9uLkUyRSBlbmNyeXB0aW9u IGlzbnQgcmVhbGx5IHJlbGV2YW50IGZvciB0aGUgYXBwbGljYWJpbGl0eSBvZiBSSVBQLCBzaW5j ZSBpdCBpcyB0YXJnZXRlZCBhdCBpbnRlci1kb21haW4gY29ubmVjdGl2aXR5IHRvd2FyZHMgUFNU Ti4gUFNUTiBhcyB5b3Ugd2VsbCBrbm93IGhhcyBubyBlMmUgZW5jcnlwdGlvbiwgYW5kIHRoZXJl IG11c3QgYmUgZGVjcnlwdGlvbiBhdCB0aGUgcHN0biBnYXRld2F5LsKgSSBkb250IGZvbGxvdyBo b3cgaGF2aW5nIGEgc2VydmVyIGF0IHRoZSBlZGdlIG9mIGEgcHJvdmlkZXIgbmV0d29yayBtaWdo dCBiZSBpbiB2aW9sYXRpb24gb2YgdGhlIHdpcmV0YXAgYWN0LCBvciBzb21laG93IG1ha2UgcmVj b3JkaW5ncyB3b3JzZS4gVEhpcyBpcyBubyBkaWZmZXJlbnQgdGhhbiB0aGUgc2l0dWF0aW9uIHRv ZGF5IHdpdGggU0JDcywgd2hlcmUgdGhlIHZhc3QgbWFqb3JpdHkgaGF2ZSBubyBTUlRQIGF0IGFs bCwgYW5kIGV2ZW4gdGhvc2UgdGhhdCBkbywgYXJlIGRlY3J5cHRpbmcgc28gdGhleSBoYXZlIGFj Y2VzcyB0byB0aGUgbWVkaWEuwqDCoFNlY3Rpb24gOC4yOkp1c3QgY3VyaW91czogd2h5IE1VU1Qg Tk9UIHRoZSBpZGVudGlmaWVyIGluY2x1ZGVkIHRoZSBhdXRob3JpdHkgY29tcG9uZW50IGZvciB1 bmlxdWVuZXNzPyBJcyB0aGF0IGEgV2ViIGJlc3QgcHJhY3RpY2U/IEEgcmVmZXJlbmNlIG9yIGV4 cGxhbmF0aW9uIHdvdWxkIGJlIGhlbHBmdWwuVEhpcyBpcyB0aGUgdGV4dDoiVGhlIHBhdGggY29t cG9uZW50IE1VU1QgICBiZSBhIGdsb2JhbGx5IHVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGlzIHRy dW5rLCBhbmQgbm90IGRlcGVuZCBvbiB0aGUKICAgYXV0aG9yaXR5IGNvbXBvbmVudCBhcyBwYXJ0 IG9mIHRoZSBuYW1lc3BhY2UgZm9yIHB1cnBvc2VzIG9mCiAgIHVuaXF1ZW5lc3MuIlRoZSBtYWlu IG1vdGl2YXRpb24gaXMgdG8gZWxpbWluYXRlIHRoZSBuZWVkIGZvciB3aWxkY2FyZCBjZXJ0cyB0 byBhdXRob3JpemU6aHR0cHM6Ly8xMjM0NWFiY2RlZi5yaXBwLXByb3ZpZGVyLmNvbSByZXF1aXJl cyBvbmUsIHdoZXJlYXM6aHR0cHM6Ly9yaXBwLXByb3ZpZGVyLmNvbS8xMjM0NWFiY2RlZiBkb2Vz IG5vdEknbGwgaW5jbHVkZSBhIG1lbnRpb24gb24gdGhhdCwgdGhhbmtzLsKgU2VjdGlvbiA4LjM6 V2hhdCBhcmUgdGhlIGNhcGFiaWxpdGllcyAqb2YqPyBBcmUgdGhleSBjb2RlYyBwYXJhbWV0ZXJz PyBBcmUgdGhleSBkZWNvZGVkIHN0cmVhbSBwYXJhbWV0ZXJzPyBBcmUgdGhleSBjb2RlYyBkZXBl bmRlbnQ/IElzIHRoZXJlIGFueSB2YWx1ZSB0byB0aGVzZSBwYXJhbWV0ZXJzLCBvdXRzaWRlIHBh cmFtZXRlcml6ZWQgY29kZWMgbmVnb3RpYXRpb24gdGhhdCBJIGFtIG1pc3Npbmc/VEhlc2UgYXJl IHRoZSBjYXBhYmlsaXRpZXMgb2YgdGhlIHJpcHAgdHJ1bmsuIFRoZXNlIGFyZSB0aGluZ3Mgbm9y bWFsbHkgY29uZmlndXJlZCBhcyBjYXBhYmlsaXRpZXMvY29uZmlndXJhdGlvbiBvZiBzaXAgdHJ1 bmtzIHRvZGF5LiBDb2RlY3MsIGJpdHJhdGVzLCBldGMuIFRoZXkgYXZvaWQgdGhlIG5lZWQgZm9y IHBlci1jYWxsIGNhcGFiaWxpdGllcyBleGNoYW5nZS4gUHJhY3RpY2FsbHkgc3BlYWtpbmcsIHN1 Y2ggZXhjaGFuZ2VzIGFyZSB1bi1uZWVkZWQgc2luY2UgdGhlIGNhcGFiaWxpdGllcyBhcmUgc3Rh dGljIHByb3BlcnRpZXMgb2YgdGhlIGNvbmZpZ3VyZWQgc2lwIHRydW5rcy4gQWdhaW4sIHdlJ3Jl IG5vdCByZXBsYWNpbmcgc2lwIG92ZXJhbGwgLSBqdXN0IHByb3ZpZGluZyBhIHNvbHV0aW9uIGZv ciBpbnRlci1kb21haW4gcGVlcmluZyBmb3Igdm9pcCB0byB0aGUgcHN0bi7CoEZvciBleGFtcGxl LCBpcyB0aGUgbWF4LWJpdHJhdGUgdGhlIGRlY29kZWQgbWF4aW11bSBiaXRyYXRlIG9yIHRoZSBi aXRyYXRlIG9mIHRoZSBjb2RlYz8gV2hhdCBpcyB0aGUgcHVycG9zZT9JZiBJIGNvbWUgdXAgd2l0 aCBhIGNvb2wgTFBDIHRoYXQgY2FuIGRvIGJldHRlciB0aGFuIEcuNzExIHdpdGggNDAwMCBzYW1w bGVzIHBlciBzZWN0aW9uLCB3aHkgY2Fubm90IEkgdXNlIGl0P05vIHRoaXMgaXMgdGhlIG1heCBj b2RlYyBiaXRyYXRlLCBzYW1lIGFzIGN1cnJlbnQgUlRQIGRlZmluaXRpb24uIE1lYW50IG1vcmUg Zm9yIGxpa2Ugb3B1cy5UaGUgcHJvdG9jb2wgb2YgY291cnNlIGlzIGV4dGVuc2libGUgdG8gbmV3 IGNvZGVjcyAtIGVhY2ggc2lkZSBhZHZlcnRpc2VzIHRoZSBjb2RlY3MgdGhleSBzdXBwb3J0IGFu ZCB0aGVpciBhc3NvY2lhdGVkIG1heCByYXRlcy4gSWYgc29tZW9uZSBob3dldmVyIHNheXMgdGhl eSBkb250IHdhbnQgdG8gcmVjZWl2ZSA0MDAwIHNhbXBsZXMgcGVyIHNlY29uZCwgdGhleSdkIGFk dmVydGlzZSBhIGxvd2VyIHVwcGVyIGJvdW5kLiBUaGlzIHBhcnQgaXMgcmVhbGx5IG5vIGRpZmZl cmVudCB0aGFuIG9mZmVyL2Fuc3dlci7CoEJJRyBPTkU6IGZvcmNlLWNickRvIHdlIHJlcXVpcmUg YSBDQlIgY29kZWMgb3IgZG8gd2UgcmVxdWlyZSB1bmlmb3JtIHBhY2tldCBzaXplcyAoaW4gYnl0 ZXMpPyBJZiB0aGUgZm9ybWVyLCB3aHkgbm90IGp1c3QgYXNrIGZvciBhIENCUiBjb2RlYyBpbiB0 aGUgcmVxdWVzdC4gSWYgdGhlIGxhdHRlciwgY2hhbmdlIHRoZSBwYXJhbWV0ZXIgdG8gc29tZXRo aW5nIGxpa2Ug4oCccmVxdWlyZSBwcml2YWN5LuKAnSBUaGVyZSBhcmUgbXVjaCBiZXR0ZXIgd2F5 cyBvZiBhY2hpZXZpbmcgcHJpdmFjeSB0aGFuIHVzaW5nIGEgQ0JSIGNvZGVjOyBzZWUgZS5nLizC oGh0dHBzOi8vcmVwb3NpdG9yeS5saWJyYXJ5Lmdlb3JnZXRvd24uZWR1L2hhbmRsZS8xMDgyMi8x MDQwNjk5Q3VsbGVuIHdhcyB0aGUgb25lIHdobyB3YW50ZWQgdGhpcyBvbmUgLSBzbyBoZSdzIGJl dHRlciBwb3NpdGlvbmVkIHRvIHNwZWFrIHRvIGl0LiBUaGVyZSB3YXMgYSBzdHVkeSB0aGF0IGZv dW5kIHlvdSBjb3VsZCBhY3R1YWxseSBmaWd1cmUgb3V0IHdoYXQgd2FzIGJlaW5nIHNhaWQganVz dCBieSBsb29raW5nIGF0IHBhdHRlcm5zIG9mIGxlbmd0aHMgb2YgdmFyaWFibGUgYml0cmF0ZSBh dWRpbyBjb2RlY3MuwqBTZWN0aW9uIDguNDpJIGFncmVlIHdpdGggQ3VsbGVuLiBJdCBnb2VzIGFn YWluc3QgdGhlIGRlc2lnbiBwcmluY2lwbGUgb2YgdXNpbmcgSFRUUC8zIGZvciB0cmFuc3BvcnQg YW5kIHRoZW4gc3RhcnQgcHV0dGluZyBhcHBsaWNhdGlvbiBzZW1hbnRpY3MgaW50byB0aGUgdHJh bnNwb3J0IGxheWVyLiBJcyB0aGVyZSBhIHJlYXNvbiB0byBicmVhayBsYXllcnMsIGUuZy4sIGZv ciBsb2FkIGJhbGFuY2luZyBvciBzb21ldGhpbmcgZWxzZT9BZGRpbmcgaHR0cCBoZWFkZXJzIGlz IHZlcnkgY29tbW9uIGZvciB3ZWIgYXBwcywgc28gdGhpcyBpc250IHJlYWxseSBkaWZmZXJlbnQg ZnJvbSBub3JtYWwgd2ViIHByYWN0aWNlLiBUaGF0IHNhaWQsIGkgZG9udCBmZWVsIHRoYXQgc3Ry b25nbHkgb24gdGhpcyBvbmUuIFBlciBhYm92ZSwgcmlnaHQgbm93IGl0cyBub3Qgc28gbXVjaCBh Ym91dCB0aGUgc3BlY2ljaWMgZGV0YWlscyBvZiB0aGlzIHByb3Bvc2FsLCBhcyBpdCBpcyBhIHN0 YXJ0aW5nIHBvaW50IHN0cmF3bWFuIGZvciB3b3JraW5nIG9uIHRoZSBwcm9ibGVtLsKgU2VjdGlv biA4LjdXaHkgMjAgZm9yIGZvcndhcmQgYW5kIDEwIGZvciByZXZlcnNlPyBBcmUgdGhlc2UgcnVs ZXMgb2YgdGh1bWIsIGNhbGN1bGF0ZWQgb3B0aW1hbCBwbGFjZXMgdG8gc3RhcnQsIFNXQUdzLCBv ciBpcnJlbGV2YW50P0Fsc28gKGFuZCBpbiBTZWN0aW9uIDguOCksIHdoYXQgYWJvdXQgdGhlIHNw ZWVkIG9mIGxpZ2h0IGFuZCB0aGUgYXBwZWFyYW5jZSBvZiBibG9ja2luZz9UT3RhbCBTV0FHcyBy aWdodCBub3cgLSB3ZSBuZWVkIHNvbWUgaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSB0byBtYWtl IHRoaXMgYSBtb3JlIHVzYWJsZSBzcGVjLk5vdCBzdXJlIEkgZm9sbG93IHdoYXQgeW91IG1lYW4g Ynkgc3BlZWQgb2YgbGlnaHQ/wqBTZWN0aW9uIDguOFBlcmhhcHMgSSBtaXNzZWQgaXQsIGJ1dCB3 aGF0IGhhcHBlbnMgaWYgYSBieXdheSBhcHBlYXJzIHRvIGJlIGJsb2NrZWQgZm9yIGEg4oCYd2hp bGXigJk/IFNpbmNlIHRoaXMgaXMgdm9pY2UgYW5kIHRoaXMgaXMgVURQIGFuZCBJIGFtIHRvbGVy YW50IG9mIHBhY2tldCBsb3NzLCBkbyBJIGNhcmUgYSBwYWNrZXQgd2FzIGxvc3Q/IEFsc28sIEni gJltIGhpZ2hseSBza2VwdGljYWwgb2YgMToxIHBhY2tldDphY2sgdGhpcyBwcm90b2NvbCBvZmZl cnMuIFRoYXQgc291bmRzIGxpa2UgYSBiYWQgdGhpbmcgZm9yIExBTnMgYW5kIGEgdGVycmlibGUg dGhpbmcgZm9yIFdBTnMuIFJlYWxseT9XZSBkaWRudCBzcGVjIG91dCB5ZXQgd2hhdCBoYXBwZW5z IGlmIGl0cyBibG9ja2VkIGZvciBhIHdoaWxlLiBUaGlzIHdvdWxkIGhhcHBlbiB1bmRlciBzaWdu aWZpY2FudCBwYWNrZXQgbG9zcywgc28gdGhpbmdzIGFyZSByZWFsbHkgYmFkLiBQcm9iYWJseSBk cm9wIHRoZSBjYWxsLkRvIHlvdSBjYXJlIGlmIGEgcGFja2V0IGlzIGxvc3Q/IGluIG5vcm1hbCB2 b2lwIGNhc2VzLCBuby4gVGhlcmUgYXJlIHNvbWUgdXNlIGNhc2VzIHdoZXJlIHRoZSByZXRyYW5z bWlzc2lvbiB3b3VsZCBiZSBoYW5keSAoc2FtZSByZWFzb24gd2UgaGF2ZSBhbiBSVFAgZXh0ZW5z aW9uIGZvciBpdC4uKU9uIHRoZSAxLTEgcGFja2V0OmFjayAtIHRoYXRzIGEgZ29vZCBjb21tZW50 LiBEZWZpbml0ZWx5IGEgZHJhd2JhY2suIFdvdWxkIGJlIGJldHRlciBpZiBpdHMgcGlnZ3liYWNr ZWQgb24gcmV2ZXJzZSBtZWRpYSwgYnV0IHdlIGFsc28gY3VycmVudGx5IGhhdmUgcmV2ZXJzZSBt ZWRpYSBpbiBzZXBhcmF0ZSBieXdheXMuIFNPIHRoYXRzIGEgdHJhZGVvZmYgdG8gYmUgZXhwbG9y ZWQuwqBTZWN0aW9uIDguMTBJIGtpbmQgb2YgYWdyZWUgd2l0aCBDdWxsZW7igJlzIHBvaW50LCBi dXQgaGVyZSBpcyBhbiBvcHBvc2l0ZSBvYnNlcnZhdGlvbiB0aGF0IEkgY2FtZSB1cCB3aXRoIGJl Zm9yZSBJIHNhdyBDdWxsZW7igJlzIHBvaW50ICh0aGF0IFNJUCByZXN1bHQgY29kZXMgZG9u4oCZ dCBjb3ZlciBJU0ROKS4gV2h5IGhhdmUgYSBzZXBhcmF0ZSDigJhyZWplY3RlZOKAmSByZXN1bHQg aW4gbGlnaHQgb2Yg4oCYZmFpbGVkLuKAmSBVbmxlc3MgcmVqZWN0ZWQgaXMgcmVmZXJlbmNpbmcg dGhlIFNJUCA2MDcgcmVzdWx0IGNvZGUsIEkgd291bGQgdGhpbmsgYWxsIHRoZSBjYWxsIGNlbnRl ciBjYXJlcyBhYm91dCBpcyB3aGV0aGVyIHRoZSBjYWxsIGNvbXBsZXRlZCBhbmQgaWYgaXQgZGlk IG5vdCwgd2lsbCBhIHJldHJ5IGJlIGxpa2VseSB0byBzdWNjZWVkIG9yIGZhaWwuUmVqZWN0ZWQg aXMgbWVhbnQgdG8gaGFuZGxlIHRoZSBjYXNlLCBsaWtlIG1vYmlsZSwgd2hlcmUgdGhlIGVuZCB1 c2VyIGFjdHVhbGx5IGhpdHMgdGhlIGRlY2xpbmUgYnV0dG9uLsKgVGhlcmUgYXJlIGEgdG9uIG9m IHR5cG9zIGluIHRoZSBkcmFmdC4gSeKAmWQgYmUgaGFwcHkgdG8gaGFuZCBteSBtYXJrLXVwIHRv IHdob21ldmVyIHdhbnRzIGl0IGluIERJU1BBVENILlRoYW5rcyEgUHJvYmFibHkgbm90IHdvcnRo IGZpeGluZyB0aWxsIHdlJ3ZlIGdvdHRlbiBtb3JlIGV4cGVyaWVuY2UgdW5kZXIgb3VyIGJlbHQg YW5kIHJldmlzZWQgaXQgdG8gcmVmbGVjdCB0aGF0LsKgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KZGlzcGF0Y2ggbWFpbGluZyBsaXN0CmRpc3BhdGNoQGll dGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gKLS0g Sm9uYXRoYW4gUm9zZW5iZXJnLCBQaC5ELmpkcm9zZW5AamRyb3Nlbi5uZXRodHRwOi8vd3d3Lmpk cm9zZW4ubmV0Cg== ----_com.samsung.android.email_104145449745110 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJh dXRvIj5BaCAtIGFmdGVyIHNlZWluZyB0aGlzIGFuZCBDdWxsZW4ncyBwcmVzZW50YXRpb24gSSBq dXN0IGZpZ3VyZWQgb3V0IHRoZXJlIGlzIG5vIGFzayBvZiB0aGUgSUVURiBvdGhlciB0aGFuIHRv IHBsZWFzZSBjb250cmlidXRlIHRvIHRoZSByZXNlYXJjaCB0byBzb2x2ZSB0aGUgcHJvYmxlbSBz dWNoIHRoYXQgc29tZWRheSB3ZSBXSUxMIGhhdmUgYSByZXBsYWNlbWVudCBmb3IgdGhhdCAyMC15 ZWFyLW9sZCBsZWdhY3kgcHJvdG9jb2wgYW5kIGluIGEgZmV3IGN5Y2xlcyBoYXZlIGEgY29uY3Jl dGUgcHJvcG9zYWwgdGhhdCB3ZSBjb3VsZCBmb3JtIGEgRGlzcGF0Y2ggb3Igd29yayBncm91cC4m bmJzcDs8L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5JJ20g YWxsIGZvciB0aGF0ITwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTox MDAlO2NvbG9yOiMwMDAwMDAiIGRpcj0iYXV0byI+PCEtLSBvcmlnaW5hbE1lc3NhZ2UgLS0+PGRp dj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBKb25h dGhhbiBSb3NlbmJlcmcgJmx0O2pkcm9zZW5AamRyb3Nlbi5uZXQmZ3Q7IDwvZGl2PjxkaXY+RGF0 ZTogNy8yMi8xOSAgMTI6NTEgUE0gIChHTVQtMDU6MDApIDwvZGl2PjxkaXY+VG86IEVyaWMgQnVy Z2VyICZsdDtlYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbSZndDsgPC9kaXY+PGRpdj5DYzogZGlz cGF0Y2hAaWV0Zi5vcmcgPC9kaXY+PGRpdj5TdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBUaG91Z2h0 cyBvbiBkcmFmdC1yb3NlbmJlcmdqZW5uaW5ncy1kaXNwYXRjaC1yaXBwLTAzIDwvZGl2PjxkaXY+ PGJyPjwvZGl2PjwvZGl2PjxkaXYgZGlyPSJsdHIiPjxkaXY+SGkgRXJpYyAtIHRoYW5rcyBmb3Ig dGFraW5nIHRoZSB0aW1lIHRvIHJlYWQgYW5kIGZvciB0aGUgdGhvdWdodGZ1bCBjb21tZW50cy48 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlJlc3BvbnNlcyBpbmxpbmUgYmVsb3cgLSBidXQgYXMg YSBoaWdoIGxldmVsIHJlc3BvbnNlIC0gcmlnaHQgbm93IHdlJ3JlIGxlc3MgaW50ZXJlc3RlZCBp biB0aGUgZGV0YWlscyBvZiB0aGUgc3BlYyAoZm9yIHdoaWNoIHRoZSBhdXRob3JzIHRoZW1zZWx2 ZXMgZG9udCBhbGwgYWdyZWUuLi4pLCBidXQgcmF0aGVyIHRvIHNlZSBpZiB0aGVyZSBpcyBpbnRl cmVzdCBpbiBzb2x2aW5nIHRoaXMgcHJvYmxlbS4gVGhlIGNvLWF1dGhvcnMgd2lsbCBiZSB3b3Jr aW5nIG9uIHByb3RvdHlwaW5nIGZyb20gaGVyZSwgc28gaWYgYW55b25lIGlzIGludGVyZXN0ZWQs IGxldCB1cyBrbm93Li4uIGdvYWwgaXMgd29ya2luZyBjb2RlIGJlZm9yZSBuZXh0IGlldGYuPC9k aXY+PGRpdj48YnI+PC9kaXY+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2IGRpcj0i bHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gU3VuLCBKdWwgMjEsIDIwMTkgYXQgNjoyNCBQTSBF cmljIEJ1cmdlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29t Ij5lYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48L2Rpdj48Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFl eCI+PGRpdiBzdHlsZT0ib3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZDsiPjxkaXY+R2VuZXJhbDog Rm9yIHRoZSBtb3N0IHBhcnQsIEkgbGlrZSB0aGUgaWRlYSBvZiBhIGRyYWZ0IHRoYXQgYmFzaWNh bGx5IHNheXMsIOKAnHdlIHRyaWVkIHRvIGJlIHB1cmUgYnV0IGZhaWxlZC4gVGhpcyBwcm9wb3Nh bCBpcyBub3QgcHVyZSBidXQgaXQgZm9yIHRoZSBtb3N0IHBhcnQgcmVwcmVzZW50cyBydW5uaW5n IGNvZGUu4oCdIFBIQiB3aWxsIGJlIGhhcHB5IChyZWYuIHRoZSBOQVQgZGlzY3Vzc2lvbiBvbiB0 aGUgSUVURiBsaXN0KS4mbmJzcDs8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9k aXY+PGRpdj5ZZXMsIHRoaXMgaXMgdmVyeSBtdWNoIGEgcHJhZ21hdGljIHNwZWMsIGFpbWVkIGF0 IHNvbHZpbmcgc29tZSB2ZXJ5IHJlYWwtd29ybGQgcHJvYmxlbXMgKGllLiwgaSd2ZSBwZXJzb25h bGx5IGJlZW4gYmVhdGluZyBteSBoZWFkIGFnYWluc3QgdGhlIHdhbGwgdHJ5aW5nIHRvIHVzZWZ1 bGx5IGRlcGxveSBmcmVlc3dpdGNoIHdpdGhpbiBJc3RpbyBvbiBHS0UuIExldCBtZSBrbm93IGlm IHlvdSBmaWd1cmVkIGl0IG91dCAtIGl0cyBhbGwgaGFyZCBkdWUgdG8gaG93IGRpZmZlcmVudCBo dHRwIGlzIGZyb20gc2lwLik8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PiZuYnNwOzwvZGl2Pjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAw LjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6 MWV4Ij48ZGl2IHN0eWxlPSJvdmVyZmxvdy13cmFwOiBicmVhay13b3JkOyI+PGRpdj48YnI+PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj5TZWN0aW9uIDEuMTogYmFja2dyb3VuZDxkaXY+V2lsbCBt dWNoIG9mIGl0IGJlIG1lYW5pbmdmdWwgdG8gYSBwcm90b2NvbCBpbXBsZW1lbnRlciBpbiBhIHll YXIsIG5vIGxlc3MgZml2ZT8gSS5lLiwgcmVmZXJlbmNpbmcgS3ViZXJuZXRlcywgSXN0aW8sIENh bmFyeURlcGxveXMsIGV0Yy4sIG1vcmUgZXNwZWNpYWxseSB3aXRob3V0IGdvaW5nIGludG8gZGV0 YWlsIGFzIHRvIHdoYXQgdGhleSBhcmU/IFN1cmUsIGlmIHlvdSBhcmUgYW4gQVdTIGRldmVsb3Bl ciB5b3Uga25vdyB0aGVtIGxpa2UgdGhlIGJhY2sgb2YgeW91ciBoYW5kLiBIb3dldmVyLCBub3Qg bWFueSBmb2xrcyBpbiBJRVRGLWxhbmQgYXJlLjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90 ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PkhhcHB5IHRvIHJlbW92ZSBsYXRlciBvbi4gUmlnaHQgbm93 IGl0cyBqdXN0IGxvb2tuaWcgdG8gbW90aXZhdGUgdGhlIHByb2JsZW0uJm5ic3A7PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlk IHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBzdHlsZT0ib3ZlcmZsb3ct d3JhcDogYnJlYWstd29yZDsiPjxkaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4xLjI6PC9kaXY+PGRp dj5XaHkgaXMgaXQg4oCYdW5mb3J0dW5hdGXigJkgdGhhdCBwZW9wbGUgd2FudCB0byBkZXBsb3kg Y2xvdWQgYXBwbGljYXRpb25zIHRoYXQgaW50ZXJhY3Qgd2l0aCB0aGUgUFNUTj8gSXMgdGhhdCBu b3QgYW4gb3Bwb3J0dW5pdHk/IEkgd291bGQgdGFrZSBvdXQgdGhlIGluaXRpYWwg4oCcVW5mb3J0 dW5hdGVseS7igJ0gSXTigJlzIGp1c3QgYSBzdGF0ZW1lbnQgb2YgZmFjdCB0aGF0IGFwcGxpY2F0 aW9ucyBsaWtlIHRvIGNhbGwgYW5kIGJlIGNhbGxlZCB0byBtb3N0IGFueSBwZXJzb24gb24gdGhl IHBsYW5ldCBvbiBhIGZ1bGx5IGludGVyb3BlcmFibGUgYmFzaXMuPC9kaXY+PC9kaXY+PC9kaXY+ PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+U3RyYXkgd29yZCBmcm9tIGEgZmV3IHJv dW5kcyBvZiBlZGl0cywgd2lsbCByZW1vdmUgdGh4LjwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAu OGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDox ZXgiPjxkaXYgc3R5bGU9Im92ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQ7Ij48ZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+VGhlcmUgbmVlZHMgdG8gYmUgbW9yZSBqdXN0aWZpY2F0aW9uIHRoYW4g4oCc V2ViIHBlb3BsZSBkb27igJl0IHVuZGVyc3RhbmQgU0lQLuKAnSBZb3UgbWlnaHQgd2FudCB0byBl eHBsYWluIGhvdyBSSVBQIGlzIGRpZmZlcmVudCB0aGFuIFBhcmxheVguIEkgd291bGQgb2ZmZXIg dGhhdCBSSVBQOlBhcmxheVg6OkxEQVA6WC41MDAsIGJ1dCB5b3UgZG9u4oCZdCBzYXkgdGhhdCBh bnl3aGVyZS4gQWxsIHRoZSBkcmFmdCBpbXBsaWVzIGlzIFdlYiBwZW9wbGUgY2Fubm90IGdyb2sg U0lQIGFuZCBTSVAgZG9lcyBub3QgZ3JvayBXZWIgZGVwbG95bWVudCwgd2hpY2ggZG9lcyBub3Qg cmVmbGVjdCB3ZWxsIG9uIGVpdGhlciBjb21tdW5pdHkuPC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9j a3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+Tm8gLSBpdHMgbm90IGFib3V0IGhvdyB3ZWxsIHBl b3BsZSB1bmRlcnN0YW5kIGFueXRoaW5nLiBJdHMgYWJvdXQgaG93IGFwcGxpY2FibGUgbW9kZXJu IGNsb3VkIHBhYXMgaXMgdG8gU0lQIGFuZCByZWFsLXRpbWUgc2VydmljZXMgKHdoaWNoIGl0IHJl YWxseSBpc250KSwgYW5kIGhvdyBlYXN5IGl0IGlzIHRvIGJ1aWxkIHJlYWwtdGltZSBhcHBzIHdo aWNoIGZvbGxvdyBlc3RhYmxpc2hlZCBkZXNpZ24gcGF0dGVybnMgZm9yIHNjYWxhYmxlIGFuZCBy ZWxpYWJsZSBzeXN0ZW1zIChpdHMgc3VwZXIgaGFyZCBpZiBub3QgaW1wb3NzaWJsZSkuJm5ic3A7 PC9kaXY+PGRpdj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigy MDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBzdHlsZT0ib3ZlcmZsb3ctd3JhcDog YnJlYWstd29yZDsiPjxkaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgbGFzdCBwYXJhZ3JhcGgg b2YgMS4yIGltcGxpZXMgdGhhdCBTSVAgaXMgdGhlIHNvdXJjZSBvZiByb2JvY2FsbHMgYW5kIGEg bWVjaGFuaXNtIHRoYXQgd2lsbCBiZSBldmVuIGVhc2llciB0byBpbmplY3QgYm9hdGxvYWRzIG9m IGNhbGxzIHdpbGwgYmUgYmV0dGVyLiBQbGVhc2UgZXhwbGFpbiBob3cgdGhpcyB3aWxsIGJlIHNv IChvciByZW1vdmUgdGhlIGFzc2VydGlvbikuIEFzIHlvdSBrbm93LCBJIHBlcnNvbmFsbHkgd2lz aCBpdCB3b3VsZCBiZSBzbywgc28gUExFQVNFIGdpdmUgbWUgYW1tdW5pdGlvbiE8L2Rpdj48L2Rp dj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5JdCBtYW5kYXRlcyBwYXNz cG9ydCBhcyB0aGUgb25lIGFuZCBvbmx5IHdheSB0byBldmVuIGtub3cgdGhlIGNhbGxlciBJRC4g Q09uc2VxdWVudGx5LCB0aGUgcHJvdG9jb2wgZHJhZ3Mgc3RpciBhbG9uZyBmb3IgdGhlIHJpZGUu IFRoZXJlIGlzIG5vIG90aGVyIHNwZWNpYWwgbWFnaWMgb3IgYW55dGhpbmcuJm5ic3A7PC9kaXY+ PGRpdj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJt YXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0 LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBzdHlsZT0ib3ZlcmZsb3ctd3JhcDogYnJlYWst d29yZDsiPjxkaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4xLjQ6PC9kaXY+PGRpdj5HaXZlbiB0aGUg dmlydHVhbCBtYW5kYXRlIHRvIHVzZSBTSVAgb3ZlciBUQ1AsIGlzIHNheWluZyDigJx3ZSBjYW4g ZmluYWxseSB1c2UgSFRUUCBvdmVyIFVEUOKAnSBub3Qga2luZCBvZiBhIHJldHJvZ3JhZGUgYXNz ZXJ0aW9uPzwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2 Pkkgd2Fzbid0IGJlaW5nIHNwZWNpZmljIGVub3VnaCBoZXJlLiAiU0lQIiByZWZlcnMgdG8gdGhl IHdob2xlIGNvbW11bml0eSBvZiBzcGVjcyBuZWVkZWQgZm9yIGl0LCBhbmQgdGhpcyBzcGVjaWZp YyBzZW50ZW5jZSBpcyByZWZlcnJpbmcgdG8gUlRQLiBJJ2xsIGNoYW5nZSB0byBSVFAuPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNv bGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBzdHlsZT0ib3ZlcmZs b3ctd3JhcDogYnJlYWstd29yZDsiPjxkaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5SRVEgMTIgKHN1 cHBvcnRpbmcgb25seSBhdWRpbykgaXMgYW4gb2RkIHJlcXVpcmVtZW50LiBNb3Jlb3ZlciwgbW9z dCBhcHBsaWNhdGlvbnMgaW4gdGhlIFUuUy4gd291bGQgcmVxdWlyZSBhdCBsZWFzdCBSVFQgc3Vw cG9ydCBpZiBub3QgdmlkZW8uIEkgYW0gbm90IGEgbGF3eWVyLCBidXQgc2luY2Ugd2UgYXJlIHRh bGtpbmcgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIHRoZSBQU1ROLCBvbmUgaXMgbGlrZWx5IHRvIHJ1 biBpbnRvIFNlY3Rpb24gMjU1IGFuZCA3MDYgaXNzdWVzIGlmIFJUVCAoYW5kIHZpZGVvKSBpcyBu b3QgdGhlcmUgZnJvbSBkYXkgb25lLjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2 Pjxicj48L2Rpdj48ZGl2PkkgZG9udCBvYmplY3QgLSB3YXMganVzdCB0cnlpbmcgdG8gc3RhcnQg c2ltcGxlIGFuZCBzb2x2ZSBvbmUgc3BlY2lmaWMgcHJvYmxlbSB3ZWxsLiBEbyBjdXJyZW50IFNJ UCB0cnVua2luZyBwcm92aWRlcnMgc3VwcG9ydCBSVFQgYW5kIHZpZGVvPyZuYnNwOzwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xp ZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgc3R5bGU9Im92ZXJmbG93 LXdyYXA6IGJyZWFrLXdvcmQ7Ij48ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+UkVRIDEzIGxvb2tz IHRvdGFsbHkgZHVwbGljYXRpdmUgb2YgUkVRIDEwICh1c2Ugc2VjdXJlIGNhbGxlciBJRCB0ZWNo bm9sb2dpZXMpLiBJcyB0aGVyZSBhIGRpc3RpbmN0aW9uPyBJZiBzbywgcGxlYXNlIG1ha2UgaXQg Y2xlYXJlcjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2 PkJ1ZyAtIHRoeC48L2Rpdj48ZGl2PiZuYnNwOzwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHgg c29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IHN0eWxlPSJvdmVy Zmxvdy13cmFwOiBicmVhay13b3JkOyI+PGRpdj48YnI+PC9kaXY+PGRpdj5TZWN0aW9uIDMuNjo8 L2Rpdj48ZGl2PlRoaXMgaXMgYSBwbGFjZSB3aGVyZSB3ZSBuZWVkIHRvIGRpc3Rpbmd1aXNoIGJl dHdlZW4gdGhlb3J5IGFuZCByZWFsaXR5LiBJbiB0aGVvcnksIFNJUCBjb3VsZCBwcm92aWRlIGVu ZC10by1lbmQgbWVkaWEgc2VjdXJpdHkuIEluIHByYWN0aWNlLCBubyBvbmUgZmlndXJlZCBpdCBv dXQuIFRoZSBnb29kIG5ld3MgaXMgUklQUCBpcyBubyB3b3JzZSB0aGFuIFNJUCBhcyBpdCBpcyBk ZXBsb3llZCB0b2RheS4gTW9yZW92ZXIsIFJJUFAgaXMgbm8gd29yc2UgdGhhbiBIVFRQLiBNeSBj b25jZXJuIGlzIFJJUFAgc3RydWN0dXJhbGx5IHdpbGwgbmV2ZXIgaGF2ZSBlbmQtdG8tZW5kIG1l ZGlhIHNlY3VyaXR5LiBXaGlsZSB0aGF0IGlzIG5vIHdvcnNlIHRoYW4gdG9kYXksIHdpbGwgd2Ug YmUgcnVubmluZyBpbnRvIHNvbWUgcHJpdmFjeSBleHBlY3RhdGlvbnMgb2YgdXNlcnMgYW5kIHJl Z3VsYXRvcnM/IEZvciBleGFtcGxlLCBhIFJJUFAgc2VydmVyIGNhbiByZWNvcmQgZXZlcnl0aGlu Zy4gUHJvYmxlbXMgaGVyZSBhcmUgKDEpIGluIHRoZSBVLlMuIHRoYXQgaXMgbGlrZWx5IHRvIGJl IGEgdmlvbGF0aW9uIG9mIHRoZSBXaXJldGFwIEFjdCBhbmQgKDIpIHBlb3BsZSBjYW4gdXNlIHRo b3NlIHJlY29yZGluZ3MgZm9yIHZlcnkgbmVmYXJpb3VzIHB1cnBvc2VzIChzZWUgUmVhbFRhbGss IEx5cmViaXJkLCBldGMuKS48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+ PGRpdj5JIHdvdWxkIGFzc2VydCB0aGF0IFJJUFAgd291bGQgYmUgYmV0dGVyIHRoYW4gU0lQIHRv ZGF5LiBUaGVyZSBpcyBhIGxvdCBvZiBTSVAgdHJ1bmtpbmcgb3V0IHRoZXJlIChub3RlIFJJUFAg Km9ubHkqIGFkZHJlc3NlcyBpbnRlci1kb21haW4gdHJ1bmtpbmcgY2FzZXMsIHNvIHRoYXRzIHRo ZSBwb2ludCBvZiBjb21wYXJpc29uKS4gTW9zdCBTSVAgdHJ1bmtpbmcgaW50ZXJjb25uZWN0aW9u IGlzIG92ZXIgcHJpdmF0ZSBJUCB3aXRoIG5vIFRMUyBvciBTUlRQLiBUaGVyZSBpcyBhbHNvIHNv bWUgb3ZlciBwdWJsaWMgSW50ZXJuZXQsIEkgc3VzcGVjdCBtdWNoIG9mIGl0IGlzIHdpdGhvdXQg U1JUUCBhbmQgcHJvYmFibHkgcnVucyBvdmVyIFZQTiBvZnRlbi4gU28sIGEgcGVlcmluZyBwcm90 b2NvbCB3aGljaCByZXF1aXJlcyBob3AgZW5jcnlwdGlvbiBvZiBzaWduYWxpbmcgYW5kIG1lZGlh LCBhbmQgYWN0dWFsbHkgYXV0aGVudGljYXRlcyBib3RoIHNpZGVzLCBpcyBhIGJpZyBpbXByb3Zl bWVudCBvdmVyIHRoZSBjdXJyZW50IHNpdHVhdGlvbi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 PkUyRSBlbmNyeXB0aW9uIGlzbnQgcmVhbGx5IHJlbGV2YW50IGZvciB0aGUgYXBwbGljYWJpbGl0 eSBvZiBSSVBQLCBzaW5jZSBpdCBpcyB0YXJnZXRlZCBhdCBpbnRlci1kb21haW4gY29ubmVjdGl2 aXR5IHRvd2FyZHMgUFNUTi4gUFNUTiBhcyB5b3Ugd2VsbCBrbm93IGhhcyBubyBlMmUgZW5jcnlw dGlvbiwgYW5kIHRoZXJlIG11c3QgYmUgZGVjcnlwdGlvbiBhdCB0aGUgcHN0biBnYXRld2F5LiZu YnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBkb250IGZvbGxvdyBob3cgaGF2aW5nIGEg c2VydmVyIGF0IHRoZSBlZGdlIG9mIGEgcHJvdmlkZXIgbmV0d29yayBtaWdodCBiZSBpbiB2aW9s YXRpb24gb2YgdGhlIHdpcmV0YXAgYWN0LCBvciBzb21laG93IG1ha2UgcmVjb3JkaW5ncyB3b3Jz ZS4gVEhpcyBpcyBubyBkaWZmZXJlbnQgdGhhbiB0aGUgc2l0dWF0aW9uIHRvZGF5IHdpdGggU0JD cywgd2hlcmUgdGhlIHZhc3QgbWFqb3JpdHkgaGF2ZSBubyBTUlRQIGF0IGFsbCwgYW5kIGV2ZW4g dGhvc2UgdGhhdCBkbywgYXJlIGRlY3J5cHRpbmcgc28gdGhleSBoYXZlIGFjY2VzcyB0byB0aGUg bWVkaWEuJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4mbmJz cDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4 IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFk ZGluZy1sZWZ0OjFleCI+PGRpdiBzdHlsZT0ib3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZDsiPjxk aXY+PGJyPjwvZGl2PjxkaXY+U2VjdGlvbiA4LjI6PC9kaXY+PGRpdj5KdXN0IGN1cmlvdXM6IHdo eSBNVVNUIE5PVCB0aGUgaWRlbnRpZmllciBpbmNsdWRlZCB0aGUgYXV0aG9yaXR5IGNvbXBvbmVu dCBmb3IgdW5pcXVlbmVzcz8gSXMgdGhhdCBhIFdlYiBiZXN0IHByYWN0aWNlPyBBIHJlZmVyZW5j ZSBvciBleHBsYW5hdGlvbiB3b3VsZCBiZSBoZWxwZnVsLjwvZGl2PjwvZGl2PjwvYmxvY2txdW90 ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PlRIaXMgaXMgdGhlIHRleHQ6PC9kaXY+PGRpdj4iPHNwYW4g c3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOjEzLjMzMzNweCI+VGhlIHBhdGggY29t cG9uZW50IE1VU1Q8L3NwYW4+PC9kaXY+PHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9 ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7YnJl YWstYmVmb3JlOnBhZ2U7Y29sb3I6cmdiKDAsMCwwKSI+ICAgYmUgYSBnbG9iYWxseSB1bmlxdWUg aWRlbnRpZmllciBmb3IgdGhpcyB0cnVuaywgYW5kIG5vdCBkZXBlbmQgb24gdGhlCiAgIGF1dGhv cml0eSBjb21wb25lbnQgYXMgcGFydCBvZiB0aGUgbmFtZXNwYWNlIGZvciBwdXJwb3NlcyBvZgog ICB1bmlxdWVuZXNzLiI8L3ByZT48cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9u dC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDticmVhay1i ZWZvcmU6cGFnZTtjb2xvcjpyZ2IoMCwwLDApIj48YnI+PC9wcmU+PHByZSBjbGFzcz0iZ21haWwt bmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2lu LWJvdHRvbTowcHg7YnJlYWstYmVmb3JlOnBhZ2U7Y29sb3I6cmdiKDAsMCwwKSI+VGhlIG1haW4g bW90aXZhdGlvbiBpcyB0byBlbGltaW5hdGUgdGhlIG5lZWQgZm9yIHdpbGRjYXJkIGNlcnRzIHRv IGF1dGhvcml6ZTo8L3ByZT48cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1z aXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDticmVhay1iZWZv cmU6cGFnZTtjb2xvcjpyZ2IoMCwwLDApIj48YSBocmVmPSJodHRwczovLzEyMzQ1YWJjZGVmLnJp cHAtcHJvdmlkZXIuY29tIj5odHRwczovLzEyMzQ1YWJjZGVmLnJpcHAtcHJvdmlkZXIuY29tPC9h PiByZXF1aXJlcyBvbmUsIHdoZXJlYXM6PC9wcmU+PHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIg c3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTow cHg7YnJlYWstYmVmb3JlOnBhZ2U7Y29sb3I6cmdiKDAsMCwwKSI+PGEgaHJlZj0iaHR0cHM6Ly9y aXBwLXByb3ZpZGVyLmNvbS8xMjM0NWFiY2RlZiI+aHR0cHM6Ly9yaXBwLXByb3ZpZGVyLmNvbS8x MjM0NWFiY2RlZjwvYT4gZG9lcyBub3Q8L3ByZT48cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBz dHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBw eDticmVhay1iZWZvcmU6cGFnZTtjb2xvcjpyZ2IoMCwwLDApIj48YnI+PC9wcmU+PHByZSBjbGFz cz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDow cHg7bWFyZ2luLWJvdHRvbTowcHg7YnJlYWstYmVmb3JlOnBhZ2U7Y29sb3I6cmdiKDAsMCwwKSI+ SSdsbCBpbmNsdWRlIGEgbWVudGlvbiBvbiB0aGF0LCB0aGFua3MuPC9wcmU+PHByZSBjbGFzcz0i Z21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7 bWFyZ2luLWJvdHRvbTowcHg7YnJlYWstYmVmb3JlOnBhZ2U7Y29sb3I6cmdiKDAsMCwwKSI+PGJy PjwvcHJlPjxkaXY+PGJyPjwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0 OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgc3R5bGU9 Im92ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQ7Ij48ZGl2Pjxicj48L2Rpdj48ZGl2PlNlY3Rpb24g OC4zOjwvZGl2PjxkaXY+V2hhdCBhcmUgdGhlIGNhcGFiaWxpdGllcyAqb2YqPyBBcmUgdGhleSBj b2RlYyBwYXJhbWV0ZXJzPyBBcmUgdGhleSBkZWNvZGVkIHN0cmVhbSBwYXJhbWV0ZXJzPyBBcmUg dGhleSBjb2RlYyBkZXBlbmRlbnQ/IElzIHRoZXJlIGFueSB2YWx1ZSB0byB0aGVzZSBwYXJhbWV0 ZXJzLCBvdXRzaWRlIHBhcmFtZXRlcml6ZWQgY29kZWMgbmVnb3RpYXRpb24gdGhhdCBJIGFtIG1p c3Npbmc/PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+VEhlc2Ug YXJlIHRoZSBjYXBhYmlsaXRpZXMgb2YgdGhlIHJpcHAgdHJ1bmsuIFRoZXNlIGFyZSB0aGluZ3Mg bm9ybWFsbHkgY29uZmlndXJlZCBhcyBjYXBhYmlsaXRpZXMvY29uZmlndXJhdGlvbiBvZiBzaXAg dHJ1bmtzIHRvZGF5LiBDb2RlY3MsIGJpdHJhdGVzLCBldGMuIFRoZXkgYXZvaWQgdGhlIG5lZWQg Zm9yIHBlci1jYWxsIGNhcGFiaWxpdGllcyBleGNoYW5nZS4gUHJhY3RpY2FsbHkgc3BlYWtpbmcs IHN1Y2ggZXhjaGFuZ2VzIGFyZSB1bi1uZWVkZWQgc2luY2UgdGhlIGNhcGFiaWxpdGllcyBhcmUg c3RhdGljIHByb3BlcnRpZXMgb2YgdGhlIGNvbmZpZ3VyZWQgc2lwIHRydW5rcy4gQWdhaW4sIHdl J3JlIG5vdCByZXBsYWNpbmcgc2lwIG92ZXJhbGwgLSBqdXN0IHByb3ZpZGluZyBhIHNvbHV0aW9u IGZvciBpbnRlci1kb21haW4gcGVlcmluZyBmb3Igdm9pcCB0byB0aGUgcHN0bi48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PiZuYnNwOzwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQg cmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IHN0eWxlPSJvdmVyZmxvdy13 cmFwOiBicmVhay13b3JkOyI+PGRpdj48YnI+PC9kaXY+PGRpdj5Gb3IgZXhhbXBsZSwgaXMgdGhl IG1heC1iaXRyYXRlIHRoZSBkZWNvZGVkIG1heGltdW0gYml0cmF0ZSBvciB0aGUgYml0cmF0ZSBv ZiB0aGUgY29kZWM/IFdoYXQgaXMgdGhlIHB1cnBvc2U/PC9kaXY+PGRpdj5JZiBJIGNvbWUgdXAg d2l0aCBhIGNvb2wgTFBDIHRoYXQgY2FuIGRvIGJldHRlciB0aGFuIEcuNzExIHdpdGggNDAwMCBz YW1wbGVzIHBlciBzZWN0aW9uLCB3aHkgY2Fubm90IEkgdXNlIGl0PzwvZGl2PjwvZGl2PjwvYmxv Y2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pk5vIHRoaXMgaXMgdGhlIG1heCBjb2RlYyBiaXRy YXRlLCBzYW1lIGFzIGN1cnJlbnQgUlRQIGRlZmluaXRpb24uIE1lYW50IG1vcmUgZm9yIGxpa2Ug b3B1cy48L2Rpdj48ZGl2PlRoZSBwcm90b2NvbCBvZiBjb3Vyc2UgaXMgZXh0ZW5zaWJsZSB0byBu ZXcgY29kZWNzIC0gZWFjaCBzaWRlIGFkdmVydGlzZXMgdGhlIGNvZGVjcyB0aGV5IHN1cHBvcnQg YW5kIHRoZWlyIGFzc29jaWF0ZWQgbWF4IHJhdGVzLiBJZiBzb21lb25lIGhvd2V2ZXIgc2F5cyB0 aGV5IGRvbnQgd2FudCB0byByZWNlaXZlIDQwMDAgc2FtcGxlcyBwZXIgc2Vjb25kLCB0aGV5J2Qg YWR2ZXJ0aXNlIGEgbG93ZXIgdXBwZXIgYm91bmQuIFRoaXMgcGFydCBpcyByZWFsbHkgbm8gZGlm ZmVyZW50IHRoYW4gb2ZmZXIvYW5zd2VyLjwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2Jv cmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPjxk aXYgc3R5bGU9Im92ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQ7Ij48ZGl2Pjxicj48L2Rpdj48ZGl2 PkJJRyBPTkU6IGZvcmNlLWNicjwvZGl2PjxkaXY+RG8gd2UgcmVxdWlyZSBhIENCUiBjb2RlYyBv ciBkbyB3ZSByZXF1aXJlIHVuaWZvcm0gcGFja2V0IHNpemVzIChpbiBieXRlcyk/IElmIHRoZSBm b3JtZXIsIHdoeSBub3QganVzdCBhc2sgZm9yIGEgQ0JSIGNvZGVjIGluIHRoZSByZXF1ZXN0LiBJ ZiB0aGUgbGF0dGVyLCBjaGFuZ2UgdGhlIHBhcmFtZXRlciB0byBzb21ldGhpbmcgbGlrZSDigJxy ZXF1aXJlIHByaXZhY3ku4oCdIFRoZXJlIGFyZSBtdWNoIGJldHRlciB3YXlzIG9mIGFjaGlldmlu ZyBwcml2YWN5IHRoYW4gdXNpbmcgYSBDQlIgY29kZWM7IHNlZSBlLmcuLCZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vcmVwb3NpdG9yeS5saWJyYXJ5Lmdlb3JnZXRvd24uZWR1L2hhbmRsZS8xMDgyMi8x MDQwNjk5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9yZXBvc2l0b3J5LmxpYnJhcnkuZ2Vvcmdl dG93bi5lZHUvaGFuZGxlLzEwODIyLzEwNDA2OTk8L2E+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3Rl PjxkaXY+PGJyPjwvZGl2PjxkaXY+Q3VsbGVuIHdhcyB0aGUgb25lIHdobyB3YW50ZWQgdGhpcyBv bmUgLSBzbyBoZSdzIGJldHRlciBwb3NpdGlvbmVkIHRvIHNwZWFrIHRvIGl0LiBUaGVyZSB3YXMg YSBzdHVkeSB0aGF0IGZvdW5kIHlvdSBjb3VsZCBhY3R1YWxseSBmaWd1cmUgb3V0IHdoYXQgd2Fz IGJlaW5nIHNhaWQganVzdCBieSBsb29raW5nIGF0IHBhdHRlcm5zIG9mIGxlbmd0aHMgb2YgdmFy aWFibGUgYml0cmF0ZSBhdWRpbyBjb2RlY3MuPC9kaXY+PGRpdj4mbmJzcDs8L2Rpdj48YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+ PGRpdiBzdHlsZT0ib3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZDsiPjxkaXY+PGJyPjwvZGl2Pjxk aXY+U2VjdGlvbiA4LjQ6PC9kaXY+PGRpdj5JIGFncmVlIHdpdGggQ3VsbGVuLiBJdCBnb2VzIGFn YWluc3QgdGhlIGRlc2lnbiBwcmluY2lwbGUgb2YgdXNpbmcgSFRUUC8zIGZvciB0cmFuc3BvcnQg YW5kIHRoZW4gc3RhcnQgcHV0dGluZyBhcHBsaWNhdGlvbiBzZW1hbnRpY3MgaW50byB0aGUgdHJh bnNwb3J0IGxheWVyLiBJcyB0aGVyZSBhIHJlYXNvbiB0byBicmVhayBsYXllcnMsIGUuZy4sIGZv ciBsb2FkIGJhbGFuY2luZyBvciBzb21ldGhpbmcgZWxzZT88L2Rpdj48L2Rpdj48L2Jsb2NrcXVv dGU+PGRpdj48YnI+PC9kaXY+PGRpdj5BZGRpbmcgaHR0cCBoZWFkZXJzIGlzIHZlcnkgY29tbW9u IGZvciB3ZWIgYXBwcywgc28gdGhpcyBpc250IHJlYWxseSBkaWZmZXJlbnQgZnJvbSBub3JtYWwg d2ViIHByYWN0aWNlLiBUaGF0IHNhaWQsIGkgZG9udCBmZWVsIHRoYXQgc3Ryb25nbHkgb24gdGhp cyBvbmUuIFBlciBhYm92ZSwgcmlnaHQgbm93IGl0cyBub3Qgc28gbXVjaCBhYm91dCB0aGUgc3Bl Y2ljaWMgZGV0YWlscyBvZiB0aGlzIHByb3Bvc2FsLCBhcyBpdCBpcyBhIHN0YXJ0aW5nIHBvaW50 IHN0cmF3bWFuIGZvciB3b3JraW5nIG9uIHRoZSBwcm9ibGVtLjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+Jm5ic3A7PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i bWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIw NCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgc3R5bGU9Im92ZXJmbG93LXdyYXA6IGJyZWFr LXdvcmQ7Ij48ZGl2Pjxicj48L2Rpdj48ZGl2PlNlY3Rpb24gOC43PC9kaXY+PGRpdj5XaHkgMjAg Zm9yIGZvcndhcmQgYW5kIDEwIGZvciByZXZlcnNlPyBBcmUgdGhlc2UgcnVsZXMgb2YgdGh1bWIs IGNhbGN1bGF0ZWQgb3B0aW1hbCBwbGFjZXMgdG8gc3RhcnQsIFNXQUdzLCBvciBpcnJlbGV2YW50 PzwvZGl2PjxkaXY+QWxzbyAoYW5kIGluIFNlY3Rpb24gOC44KSwgd2hhdCBhYm91dCB0aGUgc3Bl ZWQgb2YgbGlnaHQgYW5kIHRoZSBhcHBlYXJhbmNlIG9mIGJsb2NraW5nPzwvZGl2PjwvZGl2Pjwv YmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PlRPdGFsIFNXQUdzIHJpZ2h0IG5vdyAtIHdl IG5lZWQgc29tZSBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlIHRvIG1ha2UgdGhpcyBhIG1vcmUg dXNhYmxlIHNwZWMuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Ob3Qgc3VyZSBJIGZvbGxvdyB3 aGF0IHlvdSBtZWFuIGJ5IHNwZWVkIG9mIGxpZ2h0PzwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAu OGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDox ZXgiPjxkaXYgc3R5bGU9Im92ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQ7Ij48ZGl2Pjxicj48L2Rp dj48ZGl2PlNlY3Rpb24gOC44PC9kaXY+PGRpdj5QZXJoYXBzIEkgbWlzc2VkIGl0LCBidXQgd2hh dCBoYXBwZW5zIGlmIGEgYnl3YXkgYXBwZWFycyB0byBiZSBibG9ja2VkIGZvciBhIOKAmHdoaWxl 4oCZPyBTaW5jZSB0aGlzIGlzIHZvaWNlIGFuZCB0aGlzIGlzIFVEUCBhbmQgSSBhbSB0b2xlcmFu dCBvZiBwYWNrZXQgbG9zcywgZG8gSSBjYXJlIGEgcGFja2V0IHdhcyBsb3N0PyBBbHNvLCBJ4oCZ bSBoaWdobHkgc2tlcHRpY2FsIG9mIDE6MSBwYWNrZXQ6YWNrIHRoaXMgcHJvdG9jb2wgb2ZmZXJz LiBUaGF0IHNvdW5kcyBsaWtlIGEgYmFkIHRoaW5nIGZvciBMQU5zIGFuZCBhIHRlcnJpYmxlIHRo aW5nIGZvciBXQU5zLiBSZWFsbHk/PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwv ZGl2PjxkaXY+V2UgZGlkbnQgc3BlYyBvdXQgeWV0IHdoYXQgaGFwcGVucyBpZiBpdHMgYmxvY2tl ZCBmb3IgYSB3aGlsZS4gVGhpcyB3b3VsZCBoYXBwZW4gdW5kZXIgc2lnbmlmaWNhbnQgcGFja2V0 IGxvc3MsIHNvIHRoaW5ncyBhcmUgcmVhbGx5IGJhZC4gUHJvYmFibHkgZHJvcCB0aGUgY2FsbC48 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkRvIHlvdSBjYXJlIGlmIGEgcGFja2V0IGlzIGxvc3Q/ IGluIG5vcm1hbCB2b2lwIGNhc2VzLCBuby4gVGhlcmUgYXJlIHNvbWUgdXNlIGNhc2VzIHdoZXJl IHRoZSByZXRyYW5zbWlzc2lvbiB3b3VsZCBiZSBoYW5keSAoc2FtZSByZWFzb24gd2UgaGF2ZSBh biBSVFAgZXh0ZW5zaW9uIGZvciBpdC4uKTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+T24gdGhl IDEtMSBwYWNrZXQ6YWNrIC0gdGhhdHMgYSBnb29kIGNvbW1lbnQuIERlZmluaXRlbHkgYSBkcmF3 YmFjay4gV291bGQgYmUgYmV0dGVyIGlmIGl0cyBwaWdneWJhY2tlZCBvbiByZXZlcnNlIG1lZGlh LCBidXQgd2UgYWxzbyBjdXJyZW50bHkgaGF2ZSByZXZlcnNlIG1lZGlhIGluIHNlcGFyYXRlIGJ5 d2F5cy4gU08gdGhhdHMgYSB0cmFkZW9mZiB0byBiZSBleHBsb3JlZC48L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PiZuYnNwOzwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIw NCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IHN0eWxlPSJvdmVyZmxvdy13cmFwOiBi cmVhay13b3JkOyI+PGRpdj48YnI+PC9kaXY+PGRpdj5TZWN0aW9uIDguMTA8L2Rpdj48ZGl2Pkkg a2luZCBvZiBhZ3JlZSB3aXRoIEN1bGxlbuKAmXMgcG9pbnQsIGJ1dCBoZXJlIGlzIGFuIG9wcG9z aXRlIG9ic2VydmF0aW9uIHRoYXQgSSBjYW1lIHVwIHdpdGggYmVmb3JlIEkgc2F3IEN1bGxlbuKA mXMgcG9pbnQgKHRoYXQgU0lQIHJlc3VsdCBjb2RlcyBkb27igJl0IGNvdmVyIElTRE4pLiBXaHkg aGF2ZSBhIHNlcGFyYXRlIOKAmHJlamVjdGVk4oCZIHJlc3VsdCBpbiBsaWdodCBvZiDigJhmYWls ZWQu4oCZIFVubGVzcyByZWplY3RlZCBpcyByZWZlcmVuY2luZyB0aGUgU0lQIDYwNyByZXN1bHQg Y29kZSwgSSB3b3VsZCB0aGluayBhbGwgdGhlIGNhbGwgY2VudGVyIGNhcmVzIGFib3V0IGlzIHdo ZXRoZXIgdGhlIGNhbGwgY29tcGxldGVkIGFuZCBpZiBpdCBkaWQgbm90LCB3aWxsIGEgcmV0cnkg YmUgbGlrZWx5IHRvIHN1Y2NlZWQgb3IgZmFpbC48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRp dj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5SZWplY3RlZCBpcyBtZWFudCB0byBoYW5k bGUgdGhlIGNhc2UsIGxpa2UgbW9iaWxlLCB3aGVyZSB0aGUgZW5kIHVzZXIgYWN0dWFsbHkgaGl0 cyB0aGUgZGVjbGluZSBidXR0b24uPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4mbmJzcDs8L2Rp dj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAw cHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1s ZWZ0OjFleCI+PGRpdiBzdHlsZT0ib3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZDsiPjxkaXY+PGJy PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhlcmUgYXJlIGEgdG9uIG9mIHR5cG9zIGluIHRo ZSBkcmFmdC4gSeKAmWQgYmUgaGFwcHkgdG8gaGFuZCBteSBtYXJrLXVwIHRvIHdob21ldmVyIHdh bnRzIGl0IGluIERJU1BBVENILjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rp dj48ZGl2PlRoYW5rcyEgUHJvYmFibHkgbm90IHdvcnRoIGZpeGluZyB0aWxsIHdlJ3ZlIGdvdHRl biBtb3JlIGV4cGVyaWVuY2UgdW5kZXIgb3VyIGJlbHQgYW5kIHJldmlzZWQgaXQgdG8gcmVmbGVj dCB0aGF0LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Jm5ic3A7PC9k aXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgg MHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmct bGVmdDoxZXgiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPgpkaXNwYXRjaCBtYWlsaW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0bzpkaXNwYXRjaEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRpc3BhdGNoQGlldGYub3JnPC9hPjxicj4KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaCIgcmVsPSJu b3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kaXNwYXRjaDwvYT48YnI+CjwvYmxvY2txdW90ZT48L2Rpdj48YnIgY2xlYXI9ImFs bCI+PGRpdj48YnI+PC9kaXY+LS0gPGJyPjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9zaWdu YXR1cmUiPjxkaXYgZGlyPSJsdHIiPkpvbmF0aGFuIFJvc2VuYmVyZywgUGguRC48YnI+PGEgaHJl Zj0ibWFpbHRvOmpkcm9zZW5AamRyb3Nlbi5uZXQiIHRhcmdldD0iX2JsYW5rIj5qZHJvc2VuQGpk cm9zZW4ubmV0PC9hPjxicj48YSBocmVmPSJodHRwOi8vd3d3Lmpkcm9zZW4ubmV0IiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL3d3dy5qZHJvc2VuLm5ldDwvYT48L2Rpdj48L2Rpdj48L2Rpdj4KPC9i b2R5PjwvaHRtbD4= ----_com.samsung.android.email_104145449745110-- From nobody Tue Jul 23 08:38:08 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC10120112 for ; Tue, 23 Jul 2019 08:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 YX4N9aOeFUcd for ; Tue, 23 Jul 2019 08:37:44 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 3BCE91203C9 for ; Tue, 23 Jul 2019 08:37:41 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id k9so29063657vso.5 for ; Tue, 23 Jul 2019 08:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KjFcZbFOXA/3xLyOLWBZeTKs+2je2pU6jKp0rUuAZSk=; b=v8bVtu+ksIn4kO98yh1XYwHvJuJBKtS5YkFfkAlAcduEe6sVZVfLMg86uSAqMrnYsf RLf8wGrUoYZ713s4t+x70W8rOrYERX/Jb2AY5VB9OzM0V294M9xsvF61hcbeFCRRuSfs HgN54dNVjbVWpk0WAzI+nknKLVbuO6bv01JiskhHSFWLJ0xzjMP5Q6YStL5zu8JXSz/8 H8S6YOlBYh7fr4OXtOnaWLVOnDHYtTBLbTiQO7Mg+o+QQBHrbgu+X0YmrxUPp7IFEA17 /Mh7ZVuflNLZYVpWdpYjhoYpq8ANUQ3n74GQS9mHloiO+6XZ+AmLLfbE4KoUgBKf4xB6 Icmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KjFcZbFOXA/3xLyOLWBZeTKs+2je2pU6jKp0rUuAZSk=; b=g7VbZy4MM6gyZpRddXtCnX3LecNgak2Uoq+qIKESJPsksKLBHHwZ6W+v36zS7PWU18 KBDW6YXZNdBE76dMRk9sl+EZjgKAneVOszK8vUFMDNisRJBkEUYyMozCwln5endp2KE6 Ioj/D90SxpnRcZU8uRQoaH1sLEflq86DA2nU7vMfZkLXBg+loTlSN/CtQq6bENjL9XbW +LmoIwK59E6+mnel3B3ax+I9CKxwKQJMczesL4T8GUxadVMvfBp+WPoHCNjp7v0zFFib YgqQ+PcgfqJuZgY6QyVmQ60bngR15pCM3CcCxeVTp+X7rlMzVv4tH92WARFaKB5zUMqQ JsYQ== X-Gm-Message-State: APjAAAXI66Z35A1twnSBOiYWMUR/U1fLsy/Bhcq0Jr6Cp5ed6PUWSmuJ 5/hWOzKbTc2k7ZdMqk2WzTWuQ99IFpGmIFv8S1hsWA== X-Google-Smtp-Source: APXvYqw7328LdDEQuf8TIIo3b4QPI68nnE4n3lb6TUzHIjictqDKuBR6RAkmD3724k5hN1P4PH4rVaJUM0lOrsacsc0= X-Received: by 2002:a67:e41a:: with SMTP id d26mr47807623vsf.71.1563896259834; Tue, 23 Jul 2019 08:37:39 -0700 (PDT) MIME-Version: 1.0 References: <5c631764-25e2-ce37-3f84-8eca5a8378eb@warmcat.com> In-Reply-To: From: Peter Thatcher Date: Tue, 23 Jul 2019 11:37:04 -0400 Message-ID: To: Eric Kinnear Cc: Andy Green , Victor Vasiliev , hybi@ietf.org, David Schinazi , dispatch@ietf.org, HTTP Working Group , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000008df14058e5af90e" Archived-At: Subject: Re: [dispatch] [hybi] WebTransport Side Meeting (Tuesday, 15:20) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 15:37:56 -0000 --00000000000008df14058e5af90e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable At a quick glance, https://datatracker.ietf.org/doc/draft-kinnear-httpbis-http2-transport/?inc= lude_text=3D1 seems like a decent fit for the WebTransport API. It seems better than trying to fit the WebSocket API. But do we expect people to implement it on servers before they implement QUIC? I suppose even if it takes longer, it may have the advantage of working on more networks than QUIC and HTTP/3 potentially (for networks that still block UDP, for example). On Mon, Jul 22, 2019 at 5:29 PM Eric Kinnear wrote: > > > > On Jul 22, 2019, at 4:59 PM, Andy Green wrote: > > > > > > > > On 7/22/19 1:36 PM, Victor Vasiliev wrote: > >> Hello everyone, > >> Today, at the dispatch working group meeting (18:10), I am going to > present WebTransport. WebTransport is a protocol framework that allows > multiplexed and datagram-oriented transport protocols to be used by the w= eb > applications (think =E2=80=9CWebSocket for UDP=E2=80=9D). > > > > "Historically, web applications that needed bidirectional data stream > > between a client and a server could rely on WebSockets [RFC6455], a > > message-based protocol compatible with Web security model. However, > > since the abstraction it provides is a single ordered stream of > > messages, it suffers from head-of-line blocking (HOLB), meaning that > > all messages must be sent and received in order even if they are > > independent and some of them are no longer needed. This makes it a > > poor fit for latency sensitive applications which rely on partial > > reliability and stream independence for performance." > > > > The HOLB isn't really entirely the case... RFC6455 ws allows arbitrary > fragmentation of messages allowing interleaving with control frames. > > > > ws-over-h2 allows you to can the h2 stream when you want as well. > > > > " Each new stream would require a WebSocket handshake to agree on > > application protocol used, meaning that it would take at least one > > RTT for each new stream before the client can write to it." > > > > Yes it was knowingly done as a hack to try to encourage uptake from > browser vendors... it's not really integrated into the encapsulating > protocol. > > > >> * WebTransport overview: > >> https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 > >> * QuicTransport: > >> https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 > >> * Http3Transport: > >> https://tools.ietf.org/html/draft-vvv-webtransport-http3-00 > > > > There's no h2 transport implementation? > > > > Not everything that might want to use this will get h3 capability in a > reasonable timeframe. If there's more momentum behind it than RFC8441 > there's probably room for a generic long-lived bidirectional extension to > h2 either reusing DATA or a new frame type. > > Definitely agree! I know that we=E2=80=99ve been chatting a bit with Vict= or about > https://datatracker.ietf.org/doc/draft-kinnear-httpbis-http2-transport/ > which aims to provide this, and I think it would be worth making sure tha= t > this works nicely with WebTransport. > -00 for that document covers effectively what you=E2=80=99d get with a ne= w frame > type, and -01 extends 8441 to cover more than just WebSockets with the > extended CONNECT handshake. > I don=E2=80=99t have a particularly strong preference for the mechanism u= sed, but > rather care more about the outcome =E2=80=94 very much agree that this is= a useful > component. > > Thanks, > Eric > > > > > It's a good idea to have it ride on other protocols. Not doing this > really hurt RFC6455 ws since deploying it usually needed extra, different > servers with the attendant difficulties interoperating with other protoco= ls. > > > > I really suggest thinking through the effects of not having an RFC6455 > type subprotocol (unless I failed to spot it). It really makes an implic= it > assumption about what the stream will carry that doesn't scale beyond one > server carrying one thing. That's not how things tend to pan out if the > protocol is useful. The url path could be hacked to imply the subprotoco= l > but if that's not standardized it's still a mess. And the subprotocol > binding may be orthogonal to the url layout complicating things needlessl= y. > > > > -Andy > > > >> * Web API Spec draft: https://wicg.github.io/web-transport/ > >> * Discussion on use cases: > >> https://discourse.wicg.io/t/webtransport-proposal/3508 > >> Cheers, > >> Victor. > >> _______________________________________________ > >> hybi mailing list > >> hybi@ietf.org > >> https://www.ietf.org/mailman/listinfo/hybi > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000008df14058e5af90e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

At a quick glance,=C2=A0https://datatracker.ietf.org/doc/draft-kinnear-httpbis-http2-transpo= rt/?include_text=3D1=C2=A0seems like a decent fit for the WebTransport= =C2=A0=C2=A0API.=C2=A0 It seems better than trying to fit the WebSocket API= .=C2=A0 But do we expect people to implement it on servers before they impl= ement QUIC?=C2=A0 I suppose even if it takes longer, it may have the advant= age of working on more networks than QUIC and HTTP/3 potentially (for netwo= rks that still block UDP, for example).=C2=A0


=

= On Mon, Jul 22, 2019 at 5:29 PM Eric Kinnear <ekinnear=3D40apple.com@dmarc.ietf.org> wrote:


> On Jul 22, 2019, at 4:59 PM, Andy Green <andy@warmcat.com> wrote:
>
>
>
> On 7/22/19 1:36 PM, Victor Vasiliev wrote:
>> Hello everyone,
>> Today, at the dispatch working group meeting (18:10), I am going t= o present WebTransport. WebTransport is a protocol framework that allows mu= ltiplexed and datagram-oriented transport protocols to be used by the web a= pplications (think =E2=80=9CWebSocket for UDP=E2=80=9D).
>
> "Historically, web applications that needed bidirectional data st= ream
>=C2=A0 =C2=A0between a client and a server could rely on WebSockets [RF= C6455], a
>=C2=A0 =C2=A0message-based protocol compatible with Web security model.= =C2=A0 However,
>=C2=A0 =C2=A0since the abstraction it provides is a single ordered stre= am of
>=C2=A0 =C2=A0messages, it suffers from head-of-line blocking (HOLB), me= aning that
>=C2=A0 =C2=A0all messages must be sent and received in order even if th= ey are
>=C2=A0 =C2=A0independent and some of them are no longer needed.=C2=A0 T= his makes it a
>=C2=A0 =C2=A0poor fit for latency sensitive applications which rely on = partial
>=C2=A0 =C2=A0reliability and stream independence for performance."=
>
> The HOLB isn't really entirely the case... RFC6455 ws allows arbit= rary fragmentation of messages allowing interleaving with control frames. >
> ws-over-h2 allows you to can the h2 stream when you want as well.
>
> " Each new stream would require a WebSocket handshake to agree on=
>=C2=A0 =C2=A0 =C2=A0 application protocol used, meaning that it would t= ake at least one
>=C2=A0 =C2=A0 =C2=A0 RTT for each new stream before the client can writ= e to it."
>
> Yes it was knowingly done as a hack to try to encourage uptake from br= owser vendors... it's not really integrated into the encapsulating prot= ocol.
>
>>=C2=A0 * WebTransport overview:
>>=C2=A0 =C2=A0 https://tools.ie= tf.org/html/draft-vvv-webtransport-overview-00
>>=C2=A0 * QuicTransport:
>>=C2=A0 =C2=A0 https://tools.ietf.o= rg/html/draft-vvv-webtransport-quic-00
>>=C2=A0 * Http3Transport:
>>=C2=A0 =C2=A0 https://tools.ietf.= org/html/draft-vvv-webtransport-http3-00
>
> There's no h2 transport implementation?
>
> Not everything that might want to use this will get h3 capability in a= reasonable timeframe.=C2=A0 If there's more momentum behind it than RF= C8441 there's probably room for a generic long-lived bidirectional exte= nsion to h2 either reusing DATA or a new frame type.

Definitely agree! I know that we=E2=80=99ve been chatting a bit with Victor= about https://datatracker.ie= tf.org/doc/draft-kinnear-httpbis-http2-transport/ which aims to provide= this, and I think it would be worth making sure that this works nicely wit= h WebTransport.
-00 for that document covers effectively what you=E2=80=99d get with a new = frame type, and -01 extends 8441 to cover more than just WebSockets with th= e extended CONNECT handshake.
I don=E2=80=99t have a particularly strong preference for the mechanism use= d, but rather care more about the outcome =E2=80=94 very much agree that th= is is a useful component.

Thanks,
Eric

>
> It's a good idea to have it ride on other protocols.=C2=A0 Not doi= ng this really hurt RFC6455 ws since deploying it usually needed extra, dif= ferent servers with the attendant difficulties interoperating with other pr= otocols.
>
> I really suggest thinking through the effects of not having an RFC6455= type subprotocol (unless I failed to spot it).=C2=A0 It really makes an im= plicit assumption about what the stream will carry that doesn't scale b= eyond one server carrying one thing.=C2=A0 That's not how things tend t= o pan out if the protocol is useful.=C2=A0 The url path could be hacked to = imply the subprotocol but if that's not standardized it's still a m= ess.=C2=A0 And the subprotocol binding may be orthogonal to the url layout = complicating things needlessly.
>
> -Andy
>
>>=C2=A0 * Web API Spec draft: https://wicg.github.io/web= -transport/
>>=C2=A0 * Discussion on use cases:
>>=C2=A0 =C2=A0 https://discourse.wicg.i= o/t/webtransport-proposal/3508
>> Cheers,
>>=C2=A0 =C2=A0Victor.
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi >

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000008df14058e5af90e-- From nobody Tue Jul 23 14:35:41 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7C41209A4; Tue, 23 Jul 2019 14:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=gmail.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 sh2GnKW_UmCA; Tue, 23 Jul 2019 14:35:21 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 5FDD61209A8; Tue, 23 Jul 2019 14:35:19 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id b29so23160277lfq.1; Tue, 23 Jul 2019 14:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x3A94tRpsxJqiVWbazIcBPq8Ii4pxMTWmsJBEWrrTd4=; b=IXYTAEA+gJhGti7FYN84p4MKxZRtMfP/dsMXZlG4YTz0YEEKvdmoY0VswHUs7T5OoE hPQrplt7wzCl7yTPyfckN4IKHN5pbRUZC/mAuzOPGsxaWH9veNB1GKZ5pqa8lsnxPfJN QF6EHMNfUUXJTUhdCcAnd394xhW9UMWnxkamgb9X6e3Ki2T+BDKt4KyO/MzTzfjKZv0/ eZVe/Wt+pO/s/SLEKE8uC9WNOMTXl53YlRV73RG9o6IIw6YMBnxqLQEQKsL5oOcp8pqo 7jcD8Mu9c3Eul/7QdC17fUSbHCMWdPrS/Llrw8JrlMftvOEr1fXCMLCnYD6L8WgCIVA2 NuGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x3A94tRpsxJqiVWbazIcBPq8Ii4pxMTWmsJBEWrrTd4=; b=GEr4xo8pA3w25cruHNRV5IR4VJ6IxOjujjVSsUj4Ule6mLmTrhaBssn4R7vjNz0sk9 Fy81gAGsXb9ADdlJUXQEnxuh2KmYp4njnfRi1HQXIfaE/SPToITHnMhYxLkgyZPRrCws 4hbbDiaIo69EWlmzsum3K6Rdk/lequCUpEyrvWhEc9Ti72Y1kTyV7P00MkSjNe7e9/tF iT60HqQxpa9+VEkbBYIXJ8PUXN6EWfLu9S+q/Hx2YBrA6m9V34bR4bDeVmYBTmM19BEq EJzI2ZdvB85h8Rdgo/oxdEVr7oV7E4ZFu2afJgaHZOCHBmwpduwJc5Q01bWTI8U/WDMX WgtA== X-Gm-Message-State: APjAAAXXj+bxkj3gDQR5TDaW+6+Dni4grxCA1OZZ6uERQ9JtXeJnWwQu rMuvtII6Dj56kVg2S0JXVjfKWCeeFTytZbWYDNk= X-Google-Smtp-Source: APXvYqzItvzfMFoYnVjcLV9pHsCmzz4yQHNV03TCNsbLMddmcQeg8frISmrbm+1KdE1a56QZSWVK8OwpJeph0b3rL74= X-Received: by 2002:a05:6512:51c:: with SMTP id o28mr37606034lfb.67.1563917717582; Tue, 23 Jul 2019 14:35:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Tue, 23 Jul 2019 17:35:06 -0400 Message-ID: To: Victor Vasiliev Cc: dispatch@ietf.org, hybi@ietf.org, IETF QUIC WG , HTTP Working Group Content-Type: multipart/alternative; boundary="00000000000003b8ff058e5ff839" Archived-At: Subject: Re: [dispatch] WebTransport Side Meeting (Tuesday, 15:20) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 21:35:33 -0000 --00000000000003b8ff058e5ff839 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks to everyone who came to the side-meeting today. We had 27 people in the room and strong interest in the topic. In terms of next steps: this work will proceed in parallel at the W3C, and we will seek to open an IETF mailing list to discuss WebTransport (we'll report the list here when it exists). Thanks in particular to Steve Anton for recording the following minutes: Roberto Peon: best to share connection even for data with different congestion controllers Seth Blank: many games open many TCP connections for reliable data, in addition to UDP Seth: others will layer a reliable layer on top of UDP Jana Iyengar: having all types of data under the same cc is very useful, but needs a way to prioritize traffic. Another issue with existing approaches: some connections (if multiple TCP/UDP/etc) may fail which is awkward (e.g., TCP may work but UDP not). Is connection setup latency important? Yes, RTC use cases find call setup very important QUIC should help a lot here Use case: for legacy apps, map UDP sockets to QUIC datagrams, TCP sockets to QUIC streams Brian Trammell: but these legacy apps want to interop with things that speak TCP and UDP, not QUIC Solution: host a shim proxy Roberto: a L7 proxy wants very low level APIs to forward data avoid compounding delays. Partial reliability models Jana: agree that datagrams are too low level for from-scratch applications. SCTP made this mistake. What is the API for sending application-sized messages? (streams?) Roberto: QUIC is missing the concept of =E2=80=9Csession=E2=80=9D (bundling= streams together to the same endpoint). Use case: L7 proxies that route at the session level. Roberto: protocol needs to know about framing and ordering (for flow control) Martin Thomson: don=E2=80=99t invent partial reliability here, or else it c= ould be the hill to die on. Victor Vasiliev: want to just expose APIs for QUIC primitives that are already defined (imagine streams are a useful abstraction, datagrams are the most minimal abstraction) Target application: real-time client-server streaming Not going to solve this in WebTransport, instead offer primitives to build on. TAPS Brian: Underlying transport depends on application and deployment. Will likely need a transport selection algorithm. Victor: want to do transport selection as a higher level layer, not in WebTransport. Victor: some of the data API will use Web primitives (like WHATWG Streams). Don=E2=80=99t want to over abstract. Brian: take a close look at the TAPS architecture document. QuicTransport vs. Http3Transport Roberto: things we implement in HTTP: redirection, shut down state, caching, multiplexing. These are very valuable, let=E2=80=99s not forget. Important to ship an API which performs and is what people want to use. Eric Kinnear: HTTP has a few downsides, e.g. bidirectionality. There=E2=80= =99s a use case for just a QUIC transport. Peter Thatcher: HTTP doesn=E2=80=99t make sense for P2P. Martin: How does this spec handle fallback if e.g. QUIC can=E2=80=99t conne= ct? There should be a transparent fallback. Victor: WebSocket fallback (can even implement as a polyfill). Jana: may need to break down spec into pieces before bringing it into the IETF. Victor: wire format changes are clearly IETF. API design is clearly W3C. Framework definition could go either way, not sure which venue right now. Martin: kind of weird but seems to work to have the same people wear IETF and W3C hats David Schinazi: seems to be interest: in terms of process, should a new IETF mailing list be formed? Martin: get an AD to form a mailing list. IETF should do work for W3C, not the other way around. Roberto: implementations of WebTransport could be useful without it necessarily being a Web API. Mark Nottingham/Martin/Peter: W3C work is in WICG right now. Needs to be a working group before IETF would form a working group. Can still make a mailing list, have a BOF before the working group was formed. Jana: Other way of doing it: W3C driving requirements for IETF protocol, creates API. Roberto: some use cases for L7 proxies even if this doesn=E2=80=99t end up = in the browser. Jana: Is the RTCDataChannel a first application for WebTransport? Harald Alvestrand: desire in WebRTC to redesign the RTCDataChannel API. Roberto: a major application that wants this is low latency broadcast video= . Bandwidth prediction APIs Roberto: value for this, very complicated though. Today the server which has lower level control can send the browser cc info. Harald: started with receiver cc, went back to sender cc later Brian: should take this out of scope for a BOF Roberto: defer this or else it will fail (e.g., HTTP2 started without QUIC even though they knew QUIC was needed). Jana: don=E2=80=99t bring bandwidth prediction up or else it will be front = and center and kill the effort On Mon, Jul 22, 2019 at 4:36 PM Victor Vasiliev wrote: > Hello everyone, > > Today, at the dispatch working group meeting (18:10), I am going to > present WebTransport. WebTransport is a protocol framework that allows > multiplexed and datagram-oriented transport protocols to be used by the w= eb > applications (think =E2=80=9CWebSocket for UDP=E2=80=9D). > > Since it=E2=80=99s quite likely we will run out of time during dispatch, = I > scheduled a side-meeting to discuss this in more depth. Below are the sid= e > meeting details. > > *Time:* Tuesday, 15:20 ~ 16:50 > *Place:* Room C2 (21st floor) > *Organizers:* Victor Vasiliev, David Schinazi > *Agenda:* > > 1. A more in-depth overview of WebTransport. > 2. Discussion of the overall design and the use cases. > 3. As time permits, some of the major outstanding design issues in Web > transport, e.g.: > - What fallback protocol to use? > - How to multiplex streams and datagrams within a single connection= ? > - Can we let web applications do their own congestion control? > - Should WebTransport sessions have URLs associated with them? > > As usual, here are some helpful links: > > - WebTransport overview: > https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 > - QuicTransport: > https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 > - Http3Transport: > https://tools.ietf.org/html/draft-vvv-webtransport-http3-00 > - Web API Spec draft: https://wicg.github.io/web-transport/ > - Discussion on use cases: > https://discourse.wicg.io/t/webtransport-proposal/3508 > > Cheers, > Victor. > --00000000000003b8ff058e5ff839 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks to everyone who came to the side-meeting today. We = had 27 people in the room and strong interest in the topic.

<= div>In terms of next steps: this work will proceed in parallel at the W3C, = and we will seek to open an IETF mailing list to discuss WebTransport (we&#= 39;ll report the list here when it exists).

Thanks i= n particular to Steve Anton for recording the following minutes:
=
Roberto Peon: best to share connection even for data with different con= gestion controllers
Seth Blank: many games open many TCP connections for= reliable data, in addition to UDP
Seth: others will layer a reliable la= yer on top of UDP
Jana Iyengar: having all types of data under the same = cc is very useful, but needs a way to prioritize traffic. Another issue wit= h existing approaches: some connections (if multiple TCP/UDP/etc) may fail = which is awkward (e.g., TCP may work but UDP not).
Is connection setup l= atency important?
Yes, RTC use cases find call setup very important
Q= UIC should help a lot here
Use case: for legacy apps, map UDP sockets to= QUIC datagrams, TCP sockets to QUIC streams
Brian Trammell: but these l= egacy apps want to interop with things that speak TCP and UDP, not QUIC
= Solution: host a shim proxy
Roberto: a L7 proxy wants very low level API= s to forward data avoid compounding delays.
Partial reliability modelsJana: agree that datagrams are too low level for from-scratch application= s. SCTP made this mistake. What is the API for sending application-sized me= ssages? (streams?)
Roberto: QUIC is missing the concept of =E2=80=9Csess= ion=E2=80=9D (bundling streams together to the same endpoint). Use case: L7= proxies that route at the session level.
Roberto: protocol needs to kno= w about framing and ordering (for flow control)
Martin Thomson: don=E2= =80=99t invent partial reliability here, or else it could be the hill to di= e on.
Victor Vasiliev: want to just expose APIs for QUIC primitives that= are already defined (imagine streams are a useful abstraction, datagrams a= re the most minimal abstraction)
Target application: real-time client-se= rver streaming
Not going to solve this in WebTransport, instead offer pr= imitives to build on.
TAPS
Brian: Underlying transport depends on app= lication and deployment. Will likely need a transport selection algorithm.<= br>Victor: want to do transport selection as a higher level layer, not in W= ebTransport.
Victor: some of the data API will use Web primitives (like = WHATWG Streams). Don=E2=80=99t want to over abstract.
Brian: take a clos= e look at the TAPS architecture document.
QuicTransport vs. Http3Transpo= rt
Roberto: things we implement in HTTP: redirection, shut down state, c= aching, multiplexing. These are very valuable, let=E2=80=99s not forget.Important to ship an API which performs and is what people want to use.Eric Kinnear: HTTP has a few downsides, e.g. bidirectionality. There=E2=80= =99s a use case for just a QUIC transport.
Peter Thatcher: HTTP doesn=E2= =80=99t make sense for P2P.
Martin: How does this spec handle fallback i= f e.g. QUIC can=E2=80=99t connect? There should be a transparent fallback.<= br>Victor: WebSocket fallback (can even implement as a polyfill).
Jana: = may need to break down spec into pieces before bringing it into the IETF.Victor: wire format changes are clearly IETF. API design is clearly W3C. = Framework definition could go either way, not sure which venue right now.Martin: kind of weird but seems to work to have the same people wear IETF= and W3C hats
David Schinazi: seems to be interest: in terms of process,= should a new IETF mailing list be formed?
Martin: get an AD to form a m= ailing list. IETF should do work for W3C, not the other way around.
Robe= rto: implementations of WebTransport could be useful without it necessarily= being a Web API.
Mark Nottingham/Martin/Peter: W3C work is in WICG righ= t now. Needs to be a working group before IETF would form a working group.<= br>Can still make a mailing list, have a BOF before the working group was f= ormed.
Jana: Other way of doing it: W3C driving requirements for IETF pr= otocol, creates API.
Roberto: some use cases for L7 proxies even if this= doesn=E2=80=99t end up in the browser.
Jana: Is the RTCDataChannel a fi= rst application for WebTransport?
Harald Alvestrand: desire in WebRTC to= redesign the RTCDataChannel API.
Roberto: a major application that want= s this is low latency broadcast video.
Bandwidth prediction APIs
Robe= rto: value for this, very complicated though. Today the server which has lo= wer level control can send the browser cc info.
Harald: started with rec= eiver cc, went back to sender cc later
Brian: should take this out of sc= ope for a BOF
Roberto: defer this or else it will fail (e.g., HTTP2 star= ted without QUIC even though they knew QUIC was needed).
Jana: don=E2=80= =99t bring bandwidth prediction up or else it will be front and center and = kill the effort

On Mon, Jul 22, 2019 at 4:36 PM Victor Vasil= iev <vasilvv=3D40google.c= om@dmarc.ietf.org> wrote:
Hello everyone,

Today, at the disp= atch working group meeting (18:10), I am going to present WebTransport. Web= Transport is a protocol framework that allows multiplexed and datagram-orie= nted transport protocols to be used by the web applications (think =E2=80= =9CWebSocket for UDP=E2=80=9D).

Since it=E2=80=99s quite likely we w= ill run out of time during dispatch, I scheduled a side-meeting to discuss = this in more depth. Below are the side meeting details.

Time:= Tuesday, 15:20 ~ 16:50
Place: Room C2 (21st floor)
Organiz= ers: Victor Vasiliev, David Schinazi
Agenda:
  1. A mor= e in-depth overview of WebTransport.
  2. Discussion of the overall desi= gn and the use cases.
  3. As time permits, some of the major outstandin= g design issues in Web transport, e.g.:
    • What fallback protocol = to use?
    • How to multiplex streams and datagrams within a single conn= ection?
    • Can we let web applications do their own congestion control= ?
    • Should WebTransport sessions have URLs associated with them?
      • =
As usual, here are some helpful links:
Cheers,
=C2=A0 Victor.
--00000000000003b8ff058e5ff839-- From nobody Thu Jul 25 13:04:05 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99741201DB; Thu, 25 Jul 2019 13:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 2PUaHO0N6T8J; Thu, 25 Jul 2019 13:04:02 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8C9191201C6; Thu, 25 Jul 2019 13:04:02 -0700 (PDT) Received: from dhcp-9817.meeting.ietf.org (dhcp-9817.meeting.ietf.org [31.133.152.23]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6PK3xZd008528 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 25 Jul 2019 15:04:00 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1564085041; bh=il96rXS38018zAv8gKsjxsnEYOmRlSvZEQsQHYwzAaU=; h=From:Subject:Date:Cc:To; b=K091CBTc1fVGQrAq90lB7YQWQxc90JUXHzN5RBFEAn3PxnwI3l6Q6kIq+HHrZcBV9 PZjKhyTWtoQbJafmRJFS5XBwWeYdXc940izZ2K4gs7BXanu2KlLpOFlbLR74LiRCx7 omQ+2pI47MXPKFznYRvrWY8WkHZ6Gblb8WK3JCU8= From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_F44263AC-BC12-43E6-BB58-63146BC77C25"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <884225B0-88B2-4401-AF3F-955DFC424314@nostrum.com> Date: Thu, 25 Jul 2019 16:03:52 -0400 Cc: dispatch chairs To: DISPATCH X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [dispatch] Draft Minutes from IETF 105 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 20:04:04 -0000 --Apple-Mail=_F44263AC-BC12-43E6-BB58-63146BC77C25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, The draft minutes from this week=E2=80=99s session are up on the = materials page[1]. Please send any comments or corrections to the = DISPATCH list as soon as possible. [1] = https://datatracker.ietf.org/meeting/105/materials/minutes-105-dispatch-01= Thanks! Ben. --Apple-Mail=_F44263AC-BC12-43E6-BB58-63146BC77C25 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAl06CygACgkQgFZKbJXz 1A2x1xAApnxljF6PNJSy8189Phc41QIrpOC3Tt3zmEdYMXpzc5/Z4aki+vlmFATx T9tAI94Wtq1iPKqrYdK6DtTy7FauXK7mChtUdl5fSubB6K3CiKJ6yVcF/RPdWMts NA9IonesMN9IOI6pU99aH0gm1n4Uo3R54KuFDhgYmbx1DuRCjfmNq42fF0uHOoKy 5MaX/0q4Tp7YpHzemWnqacF8fUy/wneAtPaKj0n3T4t5xPwacfqIebhzfLXPs7ha EcF7B8KsgbQ5iAE47fUH/Ds8qZ1vrur7AAtMeUvhckr2VyaqTAmW/1FFfe2embdG peKqKnztblGzq2We0v+6VH1kT4mPg913lyRJ/AsJZfwOT/tGWgAylkcqAh0CFyuw zhwFlzM9gz19yzHGnVZoODgFjVrSZlC+5NzGWUSp99mZ4hwy1Wjrpd2KaauzmzGR UEV9ftsEFlLg32Fg/7UhbRE82/FRwt1fqN1IwE/nP0hb+G2gZinyARwIBA2O57Fy 9SVFjsFlzqh8QtwURc/3uJspHn9yCNYbKaz4R3XgMIqsNtZ0pvygIjaTVVwFwjnu 5FEC7aILZE7yTTaSo3Y4P/ZKVfo4PUZ7HpmgkbcXLKSy8cLgYP2VqBJrdEcEVCx7 uqXer5p66uVbzA3Kaufaz1BXAyaEhIiWvMqkEGjpM5aoWoGnz/k= =GoSl -----END PGP SIGNATURE----- --Apple-Mail=_F44263AC-BC12-43E6-BB58-63146BC77C25-- From nobody Sun Jul 28 14:04:06 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854A6120044 for ; Sun, 28 Jul 2019 14:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 8M3bClqXa5fv for ; Sun, 28 Jul 2019 14:04:04 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0623C120041 for ; Sun, 28 Jul 2019 14:04:03 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-07v.sys.comcast.net with ESMTP id rppTheM7A544SrqKohEeCH; Sun, 28 Jul 2019 21:04:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1564347842; bh=HzI5UwMRobBKgaF+PuOmhIeIORlo6IG0hscZW3pZ340=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=mF42PUoz0F4JWsmi0M3JJBAH0QZKUSFYBHZWF1vsdc+ec3qdraU6PMTvf40+PfBV1 sensAv/hahVbcjVvPUnnjhiwnERxsdKP90VwLNFJ6MELPw34cXsYnqlD5AP/DamZYm k+0LVZwg/1BYcnUqmS68qFiQZu3QLEP0ZMai32c+M+g6BEgm8hTPLdqVn+oljL41G5 YC4VtX8j7aIUIYGcoORJczoJ4Qxa182SKKpRFn6I5LRcTo7DswojIBwRZC7EnkdJ7H EMMUl2cBr7odbBWrLgeAz0CuACujp3G5Dg+T0bQi9l6CmDJ/wH+42/UaS2VTq6moo4 x1pt+P4+AUJ0g== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-04v.sys.comcast.net with ESMTPA id rqKnhf9b2SfLWrqKohTjID; Sun, 28 Jul 2019 21:04:02 +0000 X-Xfinity-VMeta: sc=0;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id x6SL40K5020659 for ; Sun, 28 Jul 2019 17:04:00 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id x6SL3xcb020643; Sun, 28 Jul 2019 17:03:59 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-Reply-To: <884225B0-88B2-4401-AF3F-955DFC424314@nostrum.com> (ben@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 28 Jul 2019 17:03:58 -0400 Message-ID: <87y30hg9c1.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [dispatch] Draft Minutes from IETF 105 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2019 21:04:05 -0000 A complete nit, but it was hard to read: Why replace SIP is it is 60% of interconnected VoIP? I think should be Why replace SIP as it is 60% of interconnected VoIP? ^^ (maybe "if") but I'm not sure. Dale From nobody Mon Jul 29 07:25:17 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A8F1200C4 for ; Mon, 29 Jul 2019 07:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 DWlovtS1wJ5W for ; Mon, 29 Jul 2019 07:25:14 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 E89F01200B5 for ; Mon, 29 Jul 2019 07:25:13 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id m24so120438683ioo.2 for ; Mon, 29 Jul 2019 07:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=epEI4XTqDrmt58SovaVhywuzmlL3AcXA/eZQQuNpZF0=; b=ThqqYzaNJVhaSlgtjVwAOCEy1xWGiBdWraSWJZBaiyCOPL92XCnpBNqqbQ46qE/cby gDujiJRqZeFy87bKGOyFrFbdQxSiaMp1Wu0Djrgc4vnCiYUXmljuZdmB/OBIxIy15Lvt vbBKM8CEgffseDN2dXs2T7d2Ys83OyKoQibXPY2ey10+DWQhLO0V5CzC4+Ygss/gNeuf SRusqbS5kNH2/iFGegM51fba+MqiOpRPC8T6E6xy0WI/iQv615vSJWAVJtOA+3+551cG H6CSKHQ2zuE/iQbKydE7viiMInN4palgVG5IUd/anOr5sJdlhjTeFvrb3KYCFhl7TOIW m1Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=epEI4XTqDrmt58SovaVhywuzmlL3AcXA/eZQQuNpZF0=; b=iFfys9u1tH4FFMy4srXJQzd4L2bN1xN1wJoMl1IFlouSK3r/b0398juA6RHLK7Al7x IjrAPpZBcxCDE8K8fKGwH564AEZYurdMYWXj+vqxS/hrS/DXPoQwNcMW4mDdkAg+mXyb Z3eHbcmAEXgRKheSshziSy/7uBU4bYRfl73wgubZmsm6YHCmMwS2bjIphAUXlFil+lrz t2lXl5m/5OZD77AaOO0lW7phT5LxfJSFrUR6a1cnzeUj4Va2H80nElRrqatcupMi8tlc kCs5E0z1jZss53TOU29HoyPTVF2tZfhWXKJjmcQS/ig/MLJTNsxoB9WzrXkrgVccb9GS 8Q2A== X-Gm-Message-State: APjAAAUw7QL4oxLzJr9HuOE3xcZy9Hkr4ZB8quBsvveTnZ1jjWx1waxE Gtu9+v8ol8eu50Chegy/+2tYIF2BnJ/ZDU0DzHSLUA== X-Google-Smtp-Source: APXvYqyqn317Dqp/vmvzyi2kI1Gl5a/+mrcxvHEgAJQiP4qoe9vwgI8luD/92Gtg7U34XerqxrkHxIY92O2am+AMHGs= X-Received: by 2002:a5d:9681:: with SMTP id m1mr24979339ion.291.1564410313174; Mon, 29 Jul 2019 07:25:13 -0700 (PDT) MIME-Version: 1.0 References: <884225B0-88B2-4401-AF3F-955DFC424314@nostrum.com> <87y30hg9c1.fsf@hobgoblin.ariadne.com> In-Reply-To: <87y30hg9c1.fsf@hobgoblin.ariadne.com> From: Vijay Gurbani Date: Mon, 29 Jul 2019 09:26:01 -0500 Message-ID: To: "Dale R. Worley" Cc: dispatch@ietf.org Content-Type: multipart/alternative; boundary="000000000000fff5fc058ed2a8eb" Archived-At: Subject: Re: [dispatch] Draft Minutes from IETF 105 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2019 14:25:16 -0000 --000000000000fff5fc058ed2a8eb Content-Type: text/plain; charset="UTF-8" Dale: Hi. Indeed, s/SIP is is is/SIP if it is/ My (typo) bad. Cheers, - vijay On Sun, Jul 28, 2019 at 4:04 PM Dale R. Worley wrote: > A complete nit, but it was hard to read: > > Why replace SIP is it is 60% of interconnected VoIP? > > I think should be > > Why replace SIP as it is 60% of interconnected VoIP? > ^^ > (maybe "if") but I'm not sure. > > Dale > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000fff5fc058ed2a8eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dale: Hi.=C2=A0 Indeed, s/SIP is is is/SIP if it is/<= /div>

My (typo) bad.

Cheers,

- vijay

On Sun, Jul 28, 2019 at 4:04 PM Dal= e R. Worley <worley@ariadne.com> wrote:
A c= omplete nit, but it was hard to read:

=C2=A0 =C2=A0 Why replace SIP is it is 60% of interconnected VoIP?

I think should be

=C2=A0 =C2=A0 Why replace SIP as it is 60% of interconnected VoIP?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^ (maybe "if") but I'm not sure.

Dale

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000fff5fc058ed2a8eb-- From nobody Mon Jul 29 13:58:48 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711CA12011F for ; Mon, 29 Jul 2019 13:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 3HKyFhcRhWWC for ; Mon, 29 Jul 2019 13:58:38 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 8760E12015F for ; Mon, 29 Jul 2019 13:58:36 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id z28so5684888ljn.4 for ; Mon, 29 Jul 2019 13:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1EoFQvazXzslyc73L+Ce7bt3a4TGCcPL3inrluKfP9A=; b=a1V3uMum61G/drTUgzaCbRCR1Hv+b3UJdyk8TC19z3w3zCdgh2YcIVjBRJ6tZ3XSB4 BhUKgh4iaDPpXsPLCVpmfWbAWxpjQobHbKOqAWkMEgecAvWaHiQSBgoUg7V5W4tqPuIV 2f/l3M0Asn9LIHQN6ikA8yEJ49UlcWArtjLH479i8EXRX0hAIJ2JTq6yGEcldJsFxtuu SjWYeEtICaGYpT5ivLzhBi8ub+aFlSQJA3vhHWnSg1nSfIqUgNEy9SKKCBf0FKXTXgTH NS2MMoOeT63doeilysnJv5kAGkUwCpqdgBxdjNGlRZ4cgVr1GUmIQ1bYsBPzWnq+DzJx Il5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1EoFQvazXzslyc73L+Ce7bt3a4TGCcPL3inrluKfP9A=; b=L/igOEfmVtQ4nGxlZavSlZNB9uqOPNi7KLRjPE9bCGGoLEJvek3ISQEuJ6v868qa+A WZbBeyyBTuLFfyyKzGn3/Ejrilkun7YZ5jhHSH22o2SZazpF0IQT4JiTHRU9Xky9A/o3 HYzn9Z/0wntZoeG6cPqaaDNGgTc6c4lnHYvmUdEDlGHi3NaQIGj6mucscO8/Krc3kKH/ vnBpNkSMMdi2rgFD7CK4WxX5xxN5oe2gvFYFwd7vN5VZVevJkR9Zt7Q5jidxJM3L++m3 ofAVVwKynYce2bD0mnOa3RXH2IqUn2vfWXtch1Xx0fQaYkgrimY1CTNSws+jpy3YKv6x u+Zg== X-Gm-Message-State: APjAAAU/K5ocCYFDFpiVQYfTrRaZQlM5UnkW6J1li2UdMZdn2Rs90mIh 0q49mru66zUozEgOpuOFBx877H/E6t3/MgbCv4JKZfb71lQ+jw== X-Google-Smtp-Source: APXvYqxvULbZgMc/AvD1IrpTYnHx/Yxri7HPRoyiWsbfxEkUb/KKsIOFeX83Xi2phsn/VjoMdRB510Gkb9g7EUtP2AY= X-Received: by 2002:a2e:9788:: with SMTP id y8mr58288270lji.41.1564433914281; Mon, 29 Jul 2019 13:58:34 -0700 (PDT) MIME-Version: 1.0 From: Victor Vasiliev Date: Mon, 29 Jul 2019 16:58:23 -0400 Message-ID: To: dispatch@ietf.org, IETF QUIC WG , HTTP Working Group , hybi@ietf.org, webtransport@ietf.org Content-Type: multipart/alternative; boundary="000000000000bc9794058ed827c0" Archived-At: Subject: [dispatch] WebTransport Mailing List X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2019 20:58:39 -0000 --000000000000bc9794058ed827c0 Content-Type: text/plain; charset="UTF-8" Hello everyone, Judging from the in-person discussions in Montreal, there appears to be a decent amount of interest in the WebTransport work. Everyone interested is invited to join our mailing list: https://www.ietf.org/mailman/listinfo/webtransport Cheers, Victor. --000000000000bc9794058ed827c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

Judging from= the in-person discussions in Montreal, there appears to be a decent amount= of interest in the WebTransport work.=C2=A0 Everyone interested is invited= to join our mailing list:


Cheers,
<= div>=C2=A0 Victor.
--000000000000bc9794058ed827c0-- From nobody Mon Jul 29 14:29:05 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6E0120043; Mon, 29 Jul 2019 14:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 UI0beln4imX4; Mon, 29 Jul 2019 14:29:03 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB2612006B; Mon, 29 Jul 2019 14:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3594; q=dns/txt; s=iport; t=1564435742; x=1565645342; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=NO01rd8nvI8MgfjjqMPBao3ez9OekUlo4P9Gg6KJcoA=; b=AWLBL0JOFzIdn0MOe3HcRnfhJIFOMAvBWzfdnAKo9kwA527Z4kjMuvrM rq+1SkxzHxL6I8N2Zazw+3KbVD0VCC3DvICZab6z2wrVrx9teaxNuyRr3 WVrgNI4UAXNmUReBRUgD3JcUYxkJEsYzoDB05uuCH5KNqQKRncUv0+nyr U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAD0Yz9d/xbLJq0WBUsZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBAYFTBAEBAQEBCwEBgwJRASASKow6YIosknyGBYF7Agc?= =?us-ascii?q?BAQEJAwEBGAEKDAEBg3pGAoMPNAkOAQMBAQQBAQIBBm2FHgyFSgEBAQECAQE?= =?us-ascii?q?BbAsFCwsEFC4nMAYTgyIBgXsPD4hPpUaFSIRqCgaBNAGBUIMhhwWBf4E4H4J?= =?us-ascii?q?MPoJhAQEChRyCJgSUeIdvjhAJghyCH4ENkGgbmA6iBoMLAgQGBQIVgVA4gVg?= =?us-ascii?q?zGggbFTsqAYJBPosJhUE9AzABjmMBAQ?= X-IronPort-AV: E=Sophos;i="5.64,324,1559520000"; d="asc'?scan'208,217";a="14839562" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jul 2019 21:28:59 +0000 Received: from ams3-vpn-dhcp114.cisco.com (ams3-vpn-dhcp114.cisco.com [10.61.64.114]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x6TLSwVK015940 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 29 Jul 2019 21:28:59 GMT From: Eliot Lear Message-Id: <85E74088-6D84-47CB-97CC-C637167959B0@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_CBCF54D4-C02E-456E-9792-6851BF941040"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 29 Jul 2019 23:28:57 +0200 In-Reply-To: Cc: dispatch@ietf.org, IETF QUIC WG , HTTP Working Group , hybi@ietf.org, webtransport@ietf.org To: Victor Vasiliev References: X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.64.114, ams3-vpn-dhcp114.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [dispatch] WebTransport Mailing List X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2019 21:29:04 -0000 --Apple-Mail=_CBCF54D4-C02E-456E-9792-6851BF941040 Content-Type: multipart/alternative; boundary="Apple-Mail=_9C2CC47E-110E-4838-ABF0-460CE1ACEE5A" --Apple-Mail=_9C2CC47E-110E-4838-ABF0-460CE1ACEE5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Victor, Sorry if this has been covered, but for those of us out of the room, = could you provide two or three sentences as to what the mailing list is = supposed to cover? Is this more BCP 190 stuff or something more generic = or just something else? Thanks, Eliot > On 29 Jul 2019, at 22:58, Victor Vasiliev = wrote: >=20 > Hello everyone, >=20 > Judging from the in-person discussions in Montreal, there appears to = be a decent amount of interest in the WebTransport work. Everyone = interested is invited to join our mailing list: >=20 > https://www.ietf.org/mailman/listinfo/webtransport = >=20 > Cheers, > Victor. --Apple-Mail=_9C2CC47E-110E-4838-ABF0-460CE1ACEE5A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Victor,

Sorry if = this has been covered, but for those of us out of the room, could you = provide two or three sentences as to what the mailing list is supposed = to cover?  Is this more BCP 190 stuff or something more generic or = just something else?

Thanks,

Eliot

On 29 Jul 2019, at 22:58, = Victor Vasiliev <vasilvv=3D40google.com@dmarc.ietf.org> = wrote:

Hello = everyone,

Judging from the in-person discussions in Montreal, there = appears to be a decent amount of interest in the WebTransport = work.  Everyone interested is invited to join our mailing list:

  https://www.ietf.org/mailman/listinfo/webtransport

Cheers,
  Victor.

= --Apple-Mail=_9C2CC47E-110E-4838-ABF0-460CE1ACEE5A-- --Apple-Mail=_CBCF54D4-C02E-456E-9792-6851BF941040 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXT9lGQAKCRBugA9nE248 uLz5AKCAAXDoHe3vGH8LHoq0lzqldPgt2QCgkcM7PPyzh4iVXZ0z7LAB8ePk8hw= =iIQn -----END PGP SIGNATURE----- --Apple-Mail=_CBCF54D4-C02E-456E-9792-6851BF941040-- From nobody Mon Jul 29 14:32:53 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E1012004E for ; Mon, 29 Jul 2019 14:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 n_FuG965dRft for ; Mon, 29 Jul 2019 14:32:44 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 ADED312006F for ; Mon, 29 Jul 2019 14:32:43 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id m8so26407580lji.7 for ; Mon, 29 Jul 2019 14:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aIos4LByFU6Z0GxlSl4YOzuVFvSE8StZjEoHJusGg8Y=; b=Mh9rEVPhOhNAaATDVKtwK6Lo82WhgyZ5GCoJKxhz1tDdfhdxKX15i+7a4DYowfBgyU +cxyQ5PoPRDrXdOhzxixDHDdm/Ab58QrEnMMLyb6iIcmlTfEtlJBEcWjByIxVF0pi/Sh Ap13xhFtQZcwJefKsD0eNccbyyt2eqHX5CZKRSl96bO+EkmbpYvOaULMmU4PB2mLCkOp Vp2PQ7N5841QDF+U0xx85kPzS8keaW/Dr8b/wlBif8cYBtjxays0igYMBfX73QISWIG/ HzGT0fwj1Wo2gFtwHDK7fzdakmcmbXw8Up05TeeV2MFB7CuCHiI02+c49mdDJogaU7wc BTbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aIos4LByFU6Z0GxlSl4YOzuVFvSE8StZjEoHJusGg8Y=; b=ttP98AjhfO/ntMmj4HBBgeJ1oGm7cAa1RQXYAoyOoGQMJfqHyPPE4Jv2Opszu/hGwJ jT8vJlh/w+csBjsGRIDtGVp2h9oPr6rC2TVel3U0D/3bu0p16iV9Wc3b60/OAGHninnT rejMviZD81KCv2MV6RLxIkJ/RS7rMTiMEAfQnldGAHOgCJ/qBi4RBF4LwINNBUyEJtnD GH6Z/RlN9AKeLQ3xMxVNj9YkRNV5uKMB6KOrxzyHGraRRSkUF2vRoUF8A59Jcykl5KWq pXE+fJmMk+HvrXKggV+lpnv4gl04CI3JXp01+b6QEVTq7/11yvy/VR1qLwmFSAuxoXkO F/aA== X-Gm-Message-State: APjAAAXyw8obtIv5Y7gIC3jcNVIxqPl+i2u+6DK2Kz5/U8S0e9XSyqv3 5cfCpPTKRwi3xgg5+sc8oQKdyD5p2YmCnKXTWrYtTg== X-Google-Smtp-Source: APXvYqwIXjxuEVWuGyy3DfmjRX8yadSwJbNtTUFDxMCOnrCYLnxAgesgkF7SGCtx7mgFC9nQhpi9tknCiM1RPOE4ekw= X-Received: by 2002:a2e:9a96:: with SMTP id p22mr58467783lji.57.1564435961630; Mon, 29 Jul 2019 14:32:41 -0700 (PDT) MIME-Version: 1.0 References: <85E74088-6D84-47CB-97CC-C637167959B0@cisco.com> In-Reply-To: <85E74088-6D84-47CB-97CC-C637167959B0@cisco.com> From: Victor Vasiliev Date: Mon, 29 Jul 2019 17:32:30 -0400 Message-ID: To: Eliot Lear Cc: dispatch@ietf.org, IETF QUIC WG , HTTP Working Group , hybi@ietf.org, webtransport@ietf.org Content-Type: multipart/alternative; boundary="000000000000c49c62058ed8a126" Archived-At: Subject: Re: [dispatch] WebTransport Mailing List X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2019 21:32:46 -0000 --000000000000c49c62058ed8a126 Content-Type: text/plain; charset="UTF-8" Hi Eliot, WebTransport is roughly "WebSockets, but for unreliable transport", currently described in https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 and https://wicg.github.io/web-transport/. It's not related to BCP 190 discussion that happened at the other portion of ARTAREA meeting. Cheers, Victor. On Mon, Jul 29, 2019 at 5:29 PM Eliot Lear wrote: > Hi Victor, > > Sorry if this has been covered, but for those of us out of the room, could > you provide two or three sentences as to what the mailing list is supposed > to cover? Is this more BCP 190 stuff or something more generic or just > something else? > > Thanks, > > Eliot > > On 29 Jul 2019, at 22:58, Victor Vasiliev < > vasilvv=40google.com@dmarc.ietf.org> wrote: > > Hello everyone, > > Judging from the in-person discussions in Montreal, there appears to be a > decent amount of interest in the WebTransport work. Everyone interested is > invited to join our mailing list: > > https://www.ietf.org/mailman/listinfo/webtransport > > Cheers, > Victor. > > > --000000000000c49c62058ed8a126 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eliot,

WebTransport is roughly "= ;WebSockets, but for unreliable transport", currently described in=C2= =A0https://tools.ietf.org/html/draft-vvv-webtransport-overview-00=C2=A0= and=C2=A0https://wicg.git= hub.io/web-transport/.=C2=A0 It's not related to BCP 190 discussion= that happened at the other portion of ARTAREA meeting.

Cheers,
=C2=A0 Victor.

On Mon, Jul 29, 2019 at 5:29 PM= Eliot Lear <lear@cisco.com> wr= ote:
Hi Victor,

Sorry if this= has been covered, but for those of us out of the room, could you provide t= wo or three sentences as to what the mailing list is supposed to cover?=C2= =A0 Is this more BCP 190 stuff or something more generic or just something = else?

Thanks,

Eliot
=

On 29 Jul 2019, at 22:58, Vict= or Vasiliev <vasilvv=3D40google.com@dmarc.ietf.org> wrote:
<= br class=3D"gmail-m_-8947632560352852245Apple-interchange-newline">
Hello everyone,

Judging from th= e in-person discussions in Montreal, there appears to be a decent amount of= interest in the WebTransport work.=C2=A0 Everyone interested is invited to= join our mailing list:


Cheers,
=C2=A0 Victor.

--000000000000c49c62058ed8a126-- From nobody Mon Jul 29 20:53:54 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8F5120165; Mon, 29 Jul 2019 20:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=itaoyama.onmicrosoft.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 I3-bY4DqqucR; Mon, 29 Jul 2019 20:53:35 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-eopbgr1320119.outbound.protection.outlook.com [40.107.132.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296B41201DD; Mon, 29 Jul 2019 20:53:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dFzJZLYSwTTAVwv9qzm9vk+XtgsulIZ1PZsauPTE02lUZHg5VGqiRyzkd6q3/6PtXuUVWpce8poPjZm0KtrXQxiih6JACrf7rV5O4FUMujPTv7VcwrlgJPNXBFV+bH2i/s2YkH21cTr3EIcKDHeXspe7Jh7tTy+qkNpea/9qkBCxrJGbkBVJKG9nEqY4hpaPxBBlvMKx4L3wnS6pT25IuvT2jwQpdWiDS0kHCoAakGbn8gIlOtp/Ztvi0O7Zlnz4tBGPOX5JlyxE6mZIMGu6d/rEbHlpZAFmE0hPjArDXAorP6Y5AhuKYPrIYcDqEcvFKYurY8y/vDrRe2OTZ9tZsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IkE3HJaxWnjcoMN0I5Wd5Nktkcc6yNDKZDlQrANXbC8=; b=U48U5+cI7ypDTXPWeqJ9SSAGNXi0NnV19yn6TpstLggzYqQZqbPI64Ot4uQTlP6J+ovoEZIcGDYbyCJ+fQUSvGn5tbZGjPEGoEMJILmBIQHORjs0AEfiyk4GJ5LuhFd5eZOVLGeMxzCMBDv1Aif8aIgSTMj5JXrBUkyUF0FHHORKhXIHKh+N4ac3//rmGQaeOK/O6wWx386E+3PoM/pXC9DaA8PhQod0p8neRXSn5GsMFy7LqRJDOK2bIFTfnFBp4hNBUiYYCsU2sP8AmqcXxPuhhgfm8BJLtK5KNmhsese159TJQcgl+X6Cc5ul7kG4JoYBxMyoXOKjZ6IW7aDZOQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=it.aoyama.ac.jp;dmarc=pass action=none header.from=it.aoyama.ac.jp;dkim=pass header.d=it.aoyama.ac.jp;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IkE3HJaxWnjcoMN0I5Wd5Nktkcc6yNDKZDlQrANXbC8=; b=lUpkPbNaFfBFn7C5+oo2fEVUTTzonDsJHWu9tZscS+yCn5h1XaoIrIcBeweaEdn/6aHQAPR+mkpeQDdHs+u35DvPxxTWU9oUteYqUFhp4MD2toTQZsnM4gZF0jP4vTHKyKJvIYK39Lnes5Uxc+z2MdWgYJ7/7p93ysDj7B8aDkY= Received: from TY2PR01MB3401.jpnprd01.prod.outlook.com (20.178.141.204) by TY2PR01MB2713.jpnprd01.prod.outlook.com (20.177.96.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.14; Tue, 30 Jul 2019 03:53:32 +0000 Received: from TY2PR01MB3401.jpnprd01.prod.outlook.com ([fe80::9538:388:6e72:4340]) by TY2PR01MB3401.jpnprd01.prod.outlook.com ([fe80::9538:388:6e72:4340%5]) with mapi id 15.20.2115.005; Tue, 30 Jul 2019 03:53:32 +0000 From: =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= To: Victor Vasiliev , Eliot Lear CC: "hybi@ietf.org" , "webtransport@ietf.org" , "dispatch@ietf.org" , HTTP Working Group , IETF QUIC WG Thread-Topic: [hybi] WebTransport Mailing List Thread-Index: AQHVRlUxpEm+QG8xMEyOzfHeOUgXIKbiiAeA Date: Tue, 30 Jul 2019 03:53:32 +0000 Message-ID: <4f6894c1-b6ea-46c6-d662-9b2e2f4daf02@it.aoyama.ac.jp> References: <85E74088-6D84-47CB-97CC-C637167959B0@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: TY2PR0101CA0013.apcprd01.prod.exchangelabs.com (2603:1096:404:92::25) To TY2PR01MB3401.jpnprd01.prod.outlook.com (2603:1096:404:d1::12) authentication-results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.2.210.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 414777c7-0e39-414f-671e-08d714a17d6f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7025125)(7027125)(7023125)(2017052603328)(7193020); SRVR:TY2PR01MB2713; x-ms-traffictypediagnostic: TY2PR01MB2713: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0114FF88F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400004)(396003)(346002)(366004)(136003)(376002)(199004)(189003)(53754006)(3846002)(85182001)(966005)(14454004)(7736002)(8676002)(5660300002)(54906003)(6306002)(508600001)(4326008)(8936002)(256004)(81156014)(6512007)(6246003)(6436002)(53936002)(81166006)(66066001)(110136005)(186003)(305945005)(68736007)(446003)(76176011)(26005)(66476007)(66446008)(64756008)(66556008)(66946007)(786003)(316002)(31696002)(6486002)(71200400001)(486006)(71190400001)(2616005)(386003)(6506007)(53546011)(99286004)(31686004)(102836004)(11346002)(85202003)(476003)(86362001)(229853002)(6116002)(52116002)(25786009)(2906002)(130980200001)(223123001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY2PR01MB2713; H:TY2PR01MB3401.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: LcG3bc/ws0RHYBQavYW47Pn2Bnb49abRv4+vUY9FRhyUSxXxpi9fe1UwqfkVHGshZYB6J93Uhq/LejQ0AJbh7H6TGF5dTy6ueU1Sx9InO7l8qD4SnF2v9R9/Bl0gL+WHNTFSljtoM/TjWPx2tCdo28or2CPxyeO6lJg+DGnWgnAyFOd3TLIknBiErVHEjt6HqomoOlXavdsHLstwTS82hRDNzqjzZoFgyxX0HgE+WUq1prwMl168URoTtOiuiN5l2E49sSsIro3Dhs11pHhMKUVL8eQMEFWdkvgwkG3aQY029QHp7pblpUowfpiCvd/HtLrgxTMMntCJO7VgWYO5pPAovuv/DGBzpPbafLqg726W7LspMMScPzv86YeEfzIV35U75Gj+E4MGIOIujGALNuQ5kB8PLF+MXvFqpHerWqw= Content-Type: text/plain; charset="utf-8" Content-ID: <22F1CC631DF8F64CAD7C5A40822F3FD4@jpnprd01.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 414777c7-0e39-414f-671e-08d714a17d6f X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2019 03:53:32.4326 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: duerst@it.aoyama.ac.jp X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB2713 Archived-At: Subject: Re: [dispatch] [hybi] WebTransport Mailing List X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 03:53:46 -0000 SSB0aGluayBFbGlvdCdzIHF1ZXN0aW9uIHNob3dzIHRoYXQgIldlYlRyYW5zcG9ydCIgbWF5IGdy ZWF0bHkgYmVuZWZpdCANCmZyb20gYSBiZXR0ZXIgbmFtZSAob3IgYWNyb255bSkuDQoNClJlZ2Fy ZHMsICAgTWFydGluLg0KDQpQLlMuOiBJIGFscmVhZHkgc3Vic2NyaWJlZCB0byB0aGUgbGlzdC4N Cg0KT24gMjAxOS8wNy8zMCAwNjozMiwgVmljdG9yIFZhc2lsaWV2IHdyb3RlOg0KPiBIaSBFbGlv dCwNCj4gDQo+IFdlYlRyYW5zcG9ydCBpcyByb3VnaGx5ICJXZWJTb2NrZXRzLCBidXQgZm9yIHVu cmVsaWFibGUgdHJhbnNwb3J0IiwNCj4gY3VycmVudGx5IGRlc2NyaWJlZCBpbg0KPiBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdnZ2LXdlYnRyYW5zcG9ydC1vdmVydmlldy0wMCBh bmQNCj4gaHR0cHM6Ly93aWNnLmdpdGh1Yi5pby93ZWItdHJhbnNwb3J0Ly4gIEl0J3Mgbm90IHJl bGF0ZWQgdG8gQkNQIDE5MA0KPiBkaXNjdXNzaW9uIHRoYXQgaGFwcGVuZWQgYXQgdGhlIG90aGVy IHBvcnRpb24gb2YgQVJUQVJFQSBtZWV0aW5nLg0KPiANCj4gQ2hlZXJzLA0KPiAgICBWaWN0b3Iu DQo+IA0KPiBPbiBNb24sIEp1bCAyOSwgMjAxOSBhdCA1OjI5IFBNIEVsaW90IExlYXIgPGxlYXJA Y2lzY28uY29tPiB3cm90ZToNCj4gDQo+PiBIaSBWaWN0b3IsDQo+Pg0KPj4gU29ycnkgaWYgdGhp cyBoYXMgYmVlbiBjb3ZlcmVkLCBidXQgZm9yIHRob3NlIG9mIHVzIG91dCBvZiB0aGUgcm9vbSwg Y291bGQNCj4+IHlvdSBwcm92aWRlIHR3byBvciB0aHJlZSBzZW50ZW5jZXMgYXMgdG8gd2hhdCB0 aGUgbWFpbGluZyBsaXN0IGlzIHN1cHBvc2VkDQo+PiB0byBjb3Zlcj8gIElzIHRoaXMgbW9yZSBC Q1AgMTkwIHN0dWZmIG9yIHNvbWV0aGluZyBtb3JlIGdlbmVyaWMgb3IganVzdA0KPj4gc29tZXRo aW5nIGVsc2U/DQo+Pg0KPj4gVGhhbmtzLA0KPj4NCj4+IEVsaW90DQo+Pg0KPj4gT24gMjkgSnVs IDIwMTksIGF0IDIyOjU4LCBWaWN0b3IgVmFzaWxpZXYgPA0KPj4gdmFzaWx2dj00MGdvb2dsZS5j b21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPj4NCj4+IEhlbGxvIGV2ZXJ5b25lLA0KPj4NCj4+ IEp1ZGdpbmcgZnJvbSB0aGUgaW4tcGVyc29uIGRpc2N1c3Npb25zIGluIE1vbnRyZWFsLCB0aGVy ZSBhcHBlYXJzIHRvIGJlIGENCj4+IGRlY2VudCBhbW91bnQgb2YgaW50ZXJlc3QgaW4gdGhlIFdl YlRyYW5zcG9ydCB3b3JrLiAgRXZlcnlvbmUgaW50ZXJlc3RlZCBpcw0KPj4gaW52aXRlZCB0byBq b2luIG91ciBtYWlsaW5nIGxpc3Q6DQo+Pg0KPj4gICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby93ZWJ0cmFuc3BvcnQNCj4+DQo+PiBDaGVlcnMsDQo+PiAgICBWaWN0b3Iu DQo+Pg0KPj4NCj4+DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gaHliaSBtYWlsaW5nIGxpc3QNCj4gaHliaUBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h5YmkNCj4gDQoNCi0tIA0KUHJv Zi4gRHIuc2MuIE1hcnRpbiBKLiBEw7xyc3QNCkRlcGFydG1lbnQgb2YgSW50ZWxsaWdlbnQgSW5m b3JtYXRpb24gVGVjaG5vbG9neQ0KQ29sbGVnZSBvZiBTY2llbmNlIGFuZCBFbmdpbmVlcmluZw0K QW95YW1hIEdha3VpbiBVbml2ZXJzaXR5DQpGdWNoaW5vYmUgNS0xLTEwLCBDaHVvLWt1LCBTYWdh bWloYXJhDQoyNTItNTI1OCBKYXBhbg0K From nobody Wed Jul 31 06:49:53 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98B8120018; Wed, 31 Jul 2019 06:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=i3zd1sWl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cNAB4Rjp 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 GJH_n8JaZc07; Wed, 31 Jul 2019 06:49:35 -0700 (PDT) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B6212004F; Wed, 31 Jul 2019 06:49:35 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id E0AEC1FBD; Wed, 31 Jul 2019 09:49:33 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 31 Jul 2019 09:49:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=e 8oLACul+KAOHEyqSm9hMXQsbf2RFaP03ZEIw6sH2XM=; b=i3zd1sWlv3rGPLP28 ufnhQ5jCN5Rbydrjkr0EWGvkfxTE8oPDyTF3OdiXNOtKYzsqPQ9frH1ay2waEjG6 QalK0vKHLYJBPLJHRpXKN+l80JPCG21HGOI27MkC+pPEqLsXDQyKlnGCsm+5BJqC XZzac4gaaOcWcQumRo+b+XlagKyhm0TB3WF3QyZPkNY4JZ+HpRpOp2w0BCVtD3sJ iq5yiKI4EThXqWb9EDisnM2AFX4iKsvFkKdVqkx/iMM+QAwa8cGkutNFQ2jiIIEv ugiFF5pecGoDPm5OIIHEm5F4ZqV6X118KMfB/yP5RSzXx03DJt0IWR6nhiPWem2J n9LTg== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=e8oLACul+KAOHEyqSm9hMXQsbf2RFaP03ZEIw6sH2 XM=; b=cNAB4RjpYbB7CM7hyBNHme9Lh8nzvfxcnelkiH8ulE8c558pfA7KdZdcI bkKOdyRsEUD8AYL2k6NmpEOEcr/uFOsmsuXATpWY98Hw26M0SJgImki396vrrQoW KQRAmGLRDsp6btDNyCtXXPD3IPSgEt0PUpqTfBqD0he389M/WgGJyZj9zzRQiZGt bS57596KDz+c9VBZOLBVnZbMfDwJiY/jVmVin8FTgv4Xj1t1fshBFCy11HqkeCOV Zj+0kQEnxPRBnSnr57/rFoWW20feDbeGnuhgGsYRcaF1ACVSYcbOmvdeamYidGmR xCXF+0oc6/gV1A8m6vuj99DQTA5cw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrleehgdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenog fuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughrpegtggfuhfgjfffgkfhfvffo sehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnoh htsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrihhopdhivghtfhdr ohhrghdpmhhnohhtrdhnvghtnecukfhppedvudeirddvuddrudelfedrjeeknecurfgrrh grmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfu ihiivgeptd X-ME-Proxy: Received: from [10.20.2.23] (unknown [216.21.193.78]) by mail.messagingengine.com (Postfix) with ESMTPA id A909B80060; Wed, 31 Jul 2019 09:49:31 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mark Nottingham In-Reply-To: <4f6894c1-b6ea-46c6-d662-9b2e2f4daf02@it.aoyama.ac.jp> Date: Wed, 31 Jul 2019 09:49:30 -0400 Cc: Victor Vasiliev , Eliot Lear , "dispatch@ietf.org" , "webtransport@ietf.org" , "hybi@ietf.org" , HTTP Working Group , IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <433A2B37-704A-419B-B56F-F7B697E35741@mnot.net> References: <85E74088-6D84-47CB-97CC-C637167959B0@cisco.com> <4f6894c1-b6ea-46c6-d662-9b2e2f4daf02@it.aoyama.ac.jp> To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dispatch] [hybi] WebTransport Mailing List X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 13:49:39 -0000 +1.=20 Naming things is hard, but when they're generic and confusable with = other things, it's worth the pain. > On 29 Jul 2019, at 11:53 pm, Martin J. D=C3=BCrst = wrote: >=20 > I think Eliot's question shows that "WebTransport" may greatly benefit=20= > from a better name (or acronym). >=20 > Regards, Martin. >=20 > P.S.: I already subscribed to the list. >=20 > On 2019/07/30 06:32, Victor Vasiliev wrote: >> Hi Eliot, >>=20 >> WebTransport is roughly "WebSockets, but for unreliable transport", >> currently described in >> https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 and >> https://wicg.github.io/web-transport/. It's not related to BCP 190 >> discussion that happened at the other portion of ARTAREA meeting. >>=20 >> Cheers, >> Victor. >>=20 >> On Mon, Jul 29, 2019 at 5:29 PM Eliot Lear wrote: >>=20 >>> Hi Victor, >>>=20 >>> Sorry if this has been covered, but for those of us out of the room, = could >>> you provide two or three sentences as to what the mailing list is = supposed >>> to cover? Is this more BCP 190 stuff or something more generic or = just >>> something else? >>>=20 >>> Thanks, >>>=20 >>> Eliot >>>=20 >>> On 29 Jul 2019, at 22:58, Victor Vasiliev < >>> vasilvv=3D40google.com@dmarc.ietf.org> wrote: >>>=20 >>> Hello everyone, >>>=20 >>> Judging from the in-person discussions in Montreal, there appears to = be a >>> decent amount of interest in the WebTransport work. Everyone = interested is >>> invited to join our mailing list: >>>=20 >>> https://www.ietf.org/mailman/listinfo/webtransport >>>=20 >>> Cheers, >>> Victor. >>>=20 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >>=20 >=20 > --=20 > Prof. Dr.sc. Martin J. D=C3=BCrst > Department of Intelligent Information Technology > College of Science and Engineering > Aoyama Gakuin University > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > 252-5258 Japan > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jul 31 13:37:39 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EEE120018 for ; Wed, 31 Jul 2019 13:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 U7Y8RAtS1sl6 for ; Wed, 31 Jul 2019 13:37:23 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 EB7E3120077 for ; Wed, 31 Jul 2019 13:37:18 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id g11so714813uak.0 for ; Wed, 31 Jul 2019 13:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OBfJJvtpDjldJZKsRY7KC6mQrlqiw6TYVcoW+ucL8sQ=; b=tj+IfxYCpuv7HiKg13DhktVrOFrp0SBG26SKxHw6GX4LscP6jsaJV1NLXWYfmdcIDW eE21LrqGAdp9LEITVO5JQ8SsTQTvuLfAmKJ/OVwOEF434ByRBXuAg1RnJ9tFZYswpoRu lC6yTH3tgBY5lwtezWwq9qj2b/9DTxCoLA5dsCLbuA5mAOHxrvrGP09/85zflBS55sPn YxGHnqIyfPK/Ofk1LsGL5inI/JVyr80EEHse5Ir9LmR8zXn6+dpUaT6pzHHXnqbJmZAh 4pbvAaPlDdvNHR55NJO1o7P5nIh6+Qmgnx3xZM5Rynbp/Dehzr9QSQlmdod1VhSRB6b3 lPJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OBfJJvtpDjldJZKsRY7KC6mQrlqiw6TYVcoW+ucL8sQ=; b=tOPgKHIaVXFnGP17V6+BAQvnrFRgJHDm2EIPAWiSTbit4SSxbhShi+fI/+cbM8R3JP ETFc4n9PhWV1ZF293tjbz7yssgJX/4yaWiW2Qbwwbg4t2plso0DSZyYVX7FJ0NkScmhW /H2zbCJKPtUCXHqr9s1yEfz/65PswUC/Xxiv3MzFSSdat8hlt4CtOyk9gbONUgbctxEU Lq0DM88P1WPvW5HI4IsAZy5UkwecQTiHqtzgtbqVaI/jHRp4oLUDzEjwk8rMrruc7H7Q G0qbEUh8LQBM8ccCsaoKbpAtqsUCEVneYGxgiNGlJljKui4Q9KyKMcz25bbc4DK8BrBq xnAA== X-Gm-Message-State: APjAAAUoMtXAAvvAyDzjKfploKyHGKcskel9Zqo7UeG1MFCrH4yI3wSz 0Tbl71Jvyowfl/xMOrg199f0C8TRDu9E2ycqSphkCw== X-Google-Smtp-Source: APXvYqw4qktjqrBXHoFActWkHUWbtFpeF2n/jVNh/oPcnhJWiRSEtct9f+k1y9jEC4cBEh9iV3eapu7y+MYGnAq6VUU= X-Received: by 2002:ab0:30c7:: with SMTP id c7mr17309878uam.143.1564605437577; Wed, 31 Jul 2019 13:37:17 -0700 (PDT) MIME-Version: 1.0 References: <85E74088-6D84-47CB-97CC-C637167959B0@cisco.com> <4f6894c1-b6ea-46c6-d662-9b2e2f4daf02@it.aoyama.ac.jp> <433A2B37-704A-419B-B56F-F7B697E35741@mnot.net> In-Reply-To: <433A2B37-704A-419B-B56F-F7B697E35741@mnot.net> From: Peter Thatcher Date: Wed, 31 Jul 2019 13:36:41 -0700 Message-ID: To: Mark Nottingham Cc: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Victor Vasiliev , "hybi@ietf.org" , Eliot Lear , "webtransport@ietf.org" , "dispatch@ietf.org" , HTTP Working Group , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000005284d9058f001741" Archived-At: Subject: Re: [dispatch] [hybi] WebTransport Mailing List X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 20:37:26 -0000 --0000000000005284d9058f001741 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What's wrong with "WebTransport"? It seems like a good name to me. With what is it confusable? On Wed, Jul 31, 2019 at 6:50 AM Mark Nottingham wrote: > +1. > > Naming things is hard, but when they're generic and confusable with other > things, it's worth the pain. > > > > On 29 Jul 2019, at 11:53 pm, Martin J. D=C3=BCrst > wrote: > > > > I think Eliot's question shows that "WebTransport" may greatly benefit > > from a better name (or acronym). > > > > Regards, Martin. > > > > P.S.: I already subscribed to the list. > > > > On 2019/07/30 06:32, Victor Vasiliev wrote: > >> Hi Eliot, > >> > >> WebTransport is roughly "WebSockets, but for unreliable transport", > >> currently described in > >> https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 and > >> https://wicg.github.io/web-transport/. It's not related to BCP 190 > >> discussion that happened at the other portion of ARTAREA meeting. > >> > >> Cheers, > >> Victor. > >> > >> On Mon, Jul 29, 2019 at 5:29 PM Eliot Lear wrote: > >> > >>> Hi Victor, > >>> > >>> Sorry if this has been covered, but for those of us out of the room, > could > >>> you provide two or three sentences as to what the mailing list is > supposed > >>> to cover? Is this more BCP 190 stuff or something more generic or ju= st > >>> something else? > >>> > >>> Thanks, > >>> > >>> Eliot > >>> > >>> On 29 Jul 2019, at 22:58, Victor Vasiliev < > >>> vasilvv=3D40google.com@dmarc.ietf.org> wrote: > >>> > >>> Hello everyone, > >>> > >>> Judging from the in-person discussions in Montreal, there appears to > be a > >>> decent amount of interest in the WebTransport work. Everyone > interested is > >>> invited to join our mailing list: > >>> > >>> https://www.ietf.org/mailman/listinfo/webtransport > >>> > >>> Cheers, > >>> Victor. > >>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> hybi mailing list > >> hybi@ietf.org > >> https://www.ietf.org/mailman/listinfo/hybi > >> > > > > -- > > Prof. Dr.sc. Martin J. D=C3=BCrst > > Department of Intelligent Information Technology > > College of Science and Engineering > > Aoyama Gakuin University > > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > > 252-5258 Japan > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0000000000005284d9058f001741 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What's wrong with "WebTransport"?=C2=A0= It seems like a good name to me.=C2=A0 With what is it confusable?

On= Wed, Jul 31, 2019 at 6:50 AM Mark Nottingham <mnot@mnot.net> wrote:
+1.

Naming things is hard, but when they're generic and confusable with oth= er things, it's worth the pain.


> On 29 Jul 2019, at 11:53 pm, Martin J. D=C3=BCrst <duerst@it.aoyama.ac.jp> = wrote:
>
> I think Eliot's question shows that "WebTransport" may g= reatly benefit
> from a better name (or acronym).
>
> Regards,=C2=A0 =C2=A0Martin.
>
> P.S.: I already subscribed to the list.
>
> On 2019/07/30 06:32, Victor Vasiliev wrote:
>> Hi Eliot,
>>
>> WebTransport is roughly "WebSockets, but for unreliable trans= port",
>> currently described in
>> https://tools.ietf.org/html/d= raft-vvv-webtransport-overview-00 and
>> https://wicg.github.io/web-transport/.=C2=A0 It= 9;s not related to BCP 190
>> discussion that happened at the other portion of ARTAREA meeting.<= br> >>
>> Cheers,
>>=C2=A0 =C2=A0Victor.
>>
>> On Mon, Jul 29, 2019 at 5:29 PM Eliot Lear <lear@cisco.com> wrote:
>>
>>> Hi Victor,
>>>
>>> Sorry if this has been covered, but for those of us out of the= room, could
>>> you provide two or three sentences as to what the mailing list= is supposed
>>> to cover?=C2=A0 Is this more BCP 190 stuff or something more g= eneric or just
>>> something else?
>>>
>>> Thanks,
>>>
>>> Eliot
>>>
>>> On 29 Jul 2019, at 22:58, Victor Vasiliev <
>>> vasilvv=3D40google.com@dmarc.ietf.org> wrote:
>>>
>>> Hello everyone,
>>>
>>> Judging from the in-person discussions in Montreal, there appe= ars to be a
>>> decent amount of interest in the WebTransport work.=C2=A0 Ever= yone interested is
>>> invited to join our mailing list:
>>>
>>>=C2=A0 =C2=A0https://www.ietf.org/mail= man/listinfo/webtransport
>>>
>>> Cheers,
>>>=C2=A0 =C2=A0Victor.
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi >>
>
> --
> Prof. Dr.sc. Martin J. D=C3=BCrst
> Department of Intelligent Information Technology
> College of Science and Engineering
> Aoyama Gakuin University
> Fuchinobe 5-1-10, Chuo-ku, Sagamihara
> 252-5258 Japan
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--0000000000005284d9058f001741-- From nobody Wed Jul 31 13:50:46 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328041200A4; Wed, 31 Jul 2019 13:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable 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 VofQe1auPP6h; Wed, 31 Jul 2019 13:50:34 -0700 (PDT) Received: from warmcat.com (warmcat.com [46.105.127.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7D012006D; Wed, 31 Jul 2019 13:50:34 -0700 (PDT) Date: Wed, 31 Jul 2019 21:50:23 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: hybi@ietf.org, Victor Vasiliev , dispatch@ietf.org, IETF QUIC WG , HTTP Working Group , webtransport@ietf.org From: Andy Green Message-ID: Archived-At: Subject: Re: [dispatch] [hybi] WebTransport Mailing List X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 20:50:37 -0000 On July 29, 2019 9:58:23 PM GMT+01:00, Victor Vasiliev wrote: >Hello everyone, > >Judging from the in-person discussions in Montreal, there appears to be >a Could you find a moment in your busy schedule to respond to what I wrote o= n this list before making your own new and exciting list, esp wrt this shou= ld find a way to target h2? -Andy >decent amount of interest in the WebTransport work=2E Everyone >interested is >invited to join our mailing list: > > https://www=2Eietf=2Eorg/mailman/listinfo/webtransport > >Cheers, > Victor=2E From nobody Wed Jul 31 14:00:10 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786B2120077; Wed, 31 Jul 2019 13:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 AJXB6XEZEDYg; Wed, 31 Jul 2019 13:43:46 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 2D8FD12006D; Wed, 31 Jul 2019 13:43:46 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id w13so67041581eds.4; Wed, 31 Jul 2019 13:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=FxSAM7wLdAS/gJet0b4tWn6fxwojHIvcQE2QPXrOJEM=; b=J+aXrmT62/IZFASlRRHSl4b21+aDPeBuznIdb/Baf3lM9cIb8ZIV7sCv0p+06+1FjZ Cj8ZrPk/9P/SGInYCszglVxqr0pYUHK5jTvvZYYfI0uOQihuK/GI6KX++BBnsdEOJI5H HI+Be/Mj8ag28X1fr378md6sLR0bG1nIFanxXdWyEfqCKqjEv+i399xZDLmLhw7dgb2X eRU359Mdit48nEiUdMu/shvaVlOedWeIC6PKBdOHNg9cLH04BHgJ1oUPFy9qoU2XAhCa fB1qy4JcQby6/sGioaVmg6AVZdjN3z9oWA5+HrExNwPLEkjEAmLCBgLXE3OABpKG+DTv ZebA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=FxSAM7wLdAS/gJet0b4tWn6fxwojHIvcQE2QPXrOJEM=; b=l4gzvwW1i2r53+VwbinkXO1DJvLOtYRxt06SqWzeGWhJxP8fjWaobMTjfT6sEUqAGN +1iYstqd9h1ZMEGge+msUxZYdOu1xC1W+IFHiFV+mATSh13GA+YH+tYrjquhDvYhbumO Yijav/obBYBLmHbhAICT9PvJp/QMYotC+5Xe7uKTJIfknEYX024uqzwQv/d5DOdrTpM0 V2vpSNLmuBrqcMoL7Rn2VaOaa+HifV+XpUBSz+bVfSX3pnu74YHumBAt2EI8RbhMY8Hw RWAZGO8+pYoW0BmgZbjP1/o6V8qr+mypdPAmcAAfXFxScPzhIHUN7GtZaGPSChY798SN kt2A== X-Gm-Message-State: APjAAAXRGayXm7+o3yiIdf054sSgzsw01DKeUF9WeV/xWvTr/MI9J1Rm zF5lfA6eQ4flH7OQNV0n+/q4cUtj0lzeK7eDG+w= X-Google-Smtp-Source: APXvYqzcvpEklhlFOPeJpAh4NY16tny7FK5h0HLBwafjPmZFcYlPXUeBoQSLMfIaFVF8HDx2HnkjZg5fCcw+bz9m+kM= X-Received: by 2002:a17:906:4882:: with SMTP id v2mr35756468ejq.100.1564605824661; Wed, 31 Jul 2019 13:43:44 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 31 Jul 2019 13:43:43 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <85E74088-6D84-47CB-97CC-C637167959B0@cisco.com> <4f6894c1-b6ea-46c6-d662-9b2e2f4daf02@it.aoyama.ac.jp> <433A2B37-704A-419B-B56F-F7B697E35741@mnot.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 31 Jul 2019 13:43:43 -0700 Message-ID: To: Peter Thatcher , Mark Nottingham Cc: "webtransport@ietf.org" , IETF QUIC WG , Victor Vasiliev , HTTP Working Group , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , "dispatch@ietf.org" , "hybi@ietf.org" , Eliot Lear Content-Type: multipart/alternative; boundary="000000000000647f5f058f002e28" Archived-At: X-Mailman-Approved-At: Wed, 31 Jul 2019 14:00:06 -0700 Subject: Re: [dispatch] [hybi] WebTransport Mailing List X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 20:43:50 -0000 --000000000000647f5f058f002e28 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Same as for WebAssembly and WebSocket when not used with a browser with HTTP. For example MQTT over WebSocket to penetrate firewalls has very little to do with Web. On 31 July 2019 at 22.37.39, Peter Thatcher ( pthatcher=3D40google.com@dmarc.ietf.org) wrote: What's wrong with "WebTransport"? It seems like a good name to me. With what is it confusable? On Wed, Jul 31, 2019 at 6:50 AM Mark Nottingham wrote: > +1. > > Naming things is hard, but when they're generic and confusable with other > things, it's worth the pain. > > > > On 29 Jul 2019, at 11:53 pm, Martin J. D=C3=BCrst > wrote: > > > > I think Eliot's question shows that "WebTransport" may greatly benefit > > from a better name (or acronym). > > > > Regards, Martin. > > > > P.S.: I already subscribed to the list. > > > > On 2019/07/30 06:32, Victor Vasiliev wrote: > >> Hi Eliot, > >> > >> WebTransport is roughly "WebSockets, but for unreliable transport", > >> currently described in > >> https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 and > >> https://wicg.github.io/web-transport/. It's not related to BCP 190 > >> discussion that happened at the other portion of ARTAREA meeting. > >> > >> Cheers, > >> Victor. > >> > >> On Mon, Jul 29, 2019 at 5:29 PM Eliot Lear wrote: > >> > >>> Hi Victor, > >>> > >>> Sorry if this has been covered, but for those of us out of the room, > could > >>> you provide two or three sentences as to what the mailing list is > supposed > >>> to cover? Is this more BCP 190 stuff or something more generic or ju= st > >>> something else? > >>> > >>> Thanks, > >>> > >>> Eliot > >>> > >>> On 29 Jul 2019, at 22:58, Victor Vasiliev < > >>> vasilvv=3D40google.com@dmarc.ietf.org> wrote: > >>> > >>> Hello everyone, > >>> > >>> Judging from the in-person discussions in Montreal, there appears to > be a > >>> decent amount of interest in the WebTransport work. Everyone > interested is > >>> invited to join our mailing list: > >>> > >>> https://www.ietf.org/mailman/listinfo/webtransport > >>> > >>> Cheers, > >>> Victor. > >>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> hybi mailing list > >> hybi@ietf.org > >> https://www.ietf.org/mailman/listinfo/hybi > >> > > > > -- > > Prof. Dr.sc. Martin J. D=C3=BCrst > > Department of Intelligent Information Technology > > College of Science and Engineering > > Aoyama Gakuin University > > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > > 252-5258 Japan > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000647f5f058f002e28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Same as for WebAssem= bly and WebSocket when not used with a browser with HTTP.

For example MQTT over WebSocket to pen= etrate firewalls has very little to do with Web.

On 31 July 2019 at 22.37.39, Peter Thatcher (pthatcher=3D40google.com@dmarc.ietf.or= g) wrote:

<= div>
What's wrong with "WebTransport"?=C2=A0 It seems like a = good name to me.=C2=A0 With what is it confusable?

On Wed, Jul 31, 2019 at 6:50 AM Mark Nottingham <mnot@mnot.net> = wrote:
+1.

Naming things is hard, but when they're generic and confusable with other things, it's worth the pain.


> On 29 Jul 2019, at 11:53 pm, Martin J. D=C3=BCrst <duerst@it.aoyama.ac.jp> = wrote:
>
> I think Eliot's question shows that "WebTransport" may g= reatly benefit
> from a better name (or acronym).
>
> Regards,=C2=A0 =C2=A0Martin.
>
> P.S.: I already subscribed to the list.
>
> On 2019/07/30 06:32, Victor Vasiliev wrote:
>> Hi Eliot,
>>
>> WebTransport is roughly "WebSockets, but for unreliable transport",
>> currently described in
>> https://tools.ietf.org/html/d= raft-vvv-webtransport-overview-00 and
>> https://wicg.github.io/web-transport/.=C2=A0 It= 9;s not related to BCP 190
>> discussion that happened at the other portion of ARTAREA meeting.
>>
>> Cheers,
>>=C2=A0 =C2=A0Victor.
>>
>> On Mon, Jul 29, 2019 at 5:29 PM Eliot Lear <lear@cisco.com> wrote:
>>
>>> Hi Victor,
>>>
>>> Sorry if this has been covered, but for those of us out of the room, could
>>> you provide two or three sentences as to what the mailing list is supposed
>>> to cover?=C2=A0 Is this more BCP 190 stuff or something more generic or just
>>> something else?
>>>
>>> Thanks,
>>>
>>> Eliot
>>>
>>> On 29 Jul 2019, at 22:58, Victor Vasiliev <
>>> vasilvv=3D40google.com@dmarc.ietf.org> wrote:
>>>
>>> Hello everyone,
>>>
>>> Judging from the in-person discussions in Montreal, there appears to be a
>>> decent amount of interest in the WebTransport work.=C2=A0 Everyone interested is
>>> invited to join our mailing list:
>>>
>>>=C2=A0 =C2=A0https://www.ietf.org/mail= man/listinfo/webtransport
>>>
>>> Cheers,
>>>=C2=A0 =C2=A0Victor.
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi >>
>
> --
> Prof. Dr.sc. Martin J. D=C3=BCrst
> Department of Intelligent Information Technology
> College of Science and Engineering
> Aoyama Gakuin University
> Fuchinobe 5-1-10, Chuo-ku, Sagamihara
> 252-5258 Japan
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
=
--000000000000647f5f058f002e28--