From nobody Thu Jan 2 17:15:57 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6FD120822 for ; Thu, 2 Jan 2020 17:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 i6AkdYHnwEzH for ; Thu, 2 Jan 2020 17:15:52 -0800 (PST) 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 4A046120803 for ; Thu, 2 Jan 2020 17:15:52 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id t12so26461683vso.13 for ; Thu, 02 Jan 2020 17:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=poWOvdG3yKaXnY0xgehSwEu2GI+fJLM+mzoymWiQS2o=; b=RyCTkbvEyuJAP6NEXtvjPo8iRZlU6ByWFrsrmjZJq831uYu9uhPqYMhbXnne4f7V09 ex0hTBeGoV9RFoYmryCkK5YBaGaJocZIqoKriW3UxgX64z4L45EljIVjprdioqxPTB6W 0qabV211+DlJeFnImFr28Ipr7loCz2CNAFZwCkoIKkSbBBy11vINVMKj6S96b6UKcjN6 T3zWlEJUM/ssDeWLTjYdhc9qCUVkd8FEfZ9UJR6h0cI9gg6hC/9HrbcDdz28VtfMcBkV ol80CN+kyBJ6DT9s1hgc/XMdVmVkJYHlxRl7iOA9Png7UBuB9O7A/EwlsVKBo0Yr7FkE fwdw== 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=poWOvdG3yKaXnY0xgehSwEu2GI+fJLM+mzoymWiQS2o=; b=tXQcG59jBu8gU3uUDIgEfptPHPoTBBjLCmIBAUCUE7rXUpGpnsUCR5cPRYG+987RwL eR+z3HmvFooHd+ao8lQ2reZFCX1KMyglTo7L+yCHr63zxsIPBgFCWji/We3aE91TKhqr 6V27tIfWaahheWlMlhIZO9SShqtseN8pkBDHPVRUqmJsBKoOcOK4aNN6wyD+GCgzD/Gf WtFEk4JUGR9wGj2lZlo1wyu8DBwmyL+dTYE3u5jEqiLO3MQhEnvjyjNVDkuve0IwuHJK hpV6tagsFowQqQ7GBDitIJVXcM7GZrpArD7b8Z2IXxIhGkia8uwfRyehUMXZGbZrWAZ5 HPIw== X-Gm-Message-State: APjAAAXzi/l4pK25sTZPKbT+IWf8RB2gXFob63EBoJSVb3oxDCXEKsI4 PjFUlkcaChLVWwvVnk0ZN5BmQrLZBmNAGx4wYyKAT6fI X-Google-Smtp-Source: APXvYqzHkyvcCqdqdOE7/o8HJG/uFpXunEBxkyTe0ZvbHJ3BHxLRlRmvu8HZFKDZm4k/Hi8Vt/tlY9ng5Z7p/7H8bW8= X-Received: by 2002:a67:de12:: with SMTP id q18mr42865891vsk.104.1578014150924; Thu, 02 Jan 2020 17:15:50 -0800 (PST) MIME-Version: 1.0 From: Bernard Aboba Date: Thu, 2 Jan 2020 17:15:42 -0800 Message-ID: To: webtransport@ietf.org Content-Type: multipart/alternative; boundary="000000000000ea9daf059b320c9e" Archived-At: Subject: [Webtransport] WEBTRANS objectives and potential work items X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 01:15:56 -0000 --000000000000ea9daf059b320c9e Content-Type: text/plain; charset="UTF-8" During the WEBTRANS BOF there were some questions relating to objectives as well as potential work items. This included some questions relating to "failover transport" (e.g. whether new work was needed for this or not). Also, EKR questioned why it was necessary to define two protocols (one for webtransport over HTTP/3, and another for direct usage of QUIC streams and datagrams). I've submitted a PR to clarify the objectives and work items: https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5 The modified description and milestones are provided below. Comments welcome. ----------------------------------------------------------------------------------------------- Description of Working Group The WebTransport working group will define new client-server protocols or protocol extensions in order to support the development of the W3C WebTransport API https://wicg.github.io/web-transport. These protocols will support: - Reliable bidirectional and unidirectional communication that provides greater efficiency than Websockets (e.g. removal of head-of-line blocking). - Unreliable datagram communication, functionality not available in Websockets. - Origin checks to allow supporting the Web's origin-based security model. The WebTransport working group will define a protocol or set of protocols that fits these requirements. Multiple protocols might be required to support different usage scenarios, such as multiplexing with HTTP/3 or networks where UDP is blocked. The group will pay attention to security issues arising from the above scenarios so as to ensure against creation of new modes of attack, as well as to ensure that security issues addressed in the design of Websockets remain addressed in the new work. To assist in the coordination with W3C, the group will initially develop an overview document containing use cases and requirements in order to clarify the goals of the effort. Feedback will also be solicited at various points along the way in order to ensure the best possible match between the protocol extensions and the needs of the W3C WebTransport API. The clarity and interoperability of specifications will be confirmed via test events and hackathons. The group will also coordinate with other working groups within the IETF (e.g. QUIC, HTTPBIS) as appropriate. Goals and Milestones - March 2020 - Adopt a WebTransport Overview draft as a WG work item - March 2020 - Adopt a draft defining a WebTransport protocol as a WG work item - August 2020 - Issue WG last call of the WebTransport Overview document. - November 2020 - Issue WG last call on the first WebTransport protocol document --000000000000ea9daf059b320c9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
During the WEBTRANS BOF = there were some questions relating to objectives as well as potential work = items.

This included some = questions relating to "failover transport" (e.g. whether new work= was needed for this or not).=C2=A0 Also, EKR questioned why it was necessa= ry to define two protocols (one for webtransport over HTTP/3, and another f= or direct usage of QUIC streams and datagrams).

I've= submitted a PR to clarify the objectives and work items:=C2=A0
<= a href=3D"https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5">ht= tps://github.com/DavidSchinazi/webtrans-wg-materials/pull/5

The modified description and milestones=C2=A0are provided= below.=C2=A0 Comments welcome.

------------------= ---------------------------------------------------------------------------= --

Descri= ption of Working Group

The WebTransport working group will define = new client-server protocols or protocol extensions in order to support the = development of the W3C WebTransport API https://wicg.github.io/web-transport.

These protocols will suppo= rt:

  • Reliable bidirectional and unidirectional communication that provides gr= eater efficiency than Websockets (e.g. removal of head-of-line blocking).

  • Unreliable datagram communication, functiona= lity not available in Websockets.

  • Origin c= hecks to allow supporting the Web's origin-based security model.=

The WebTransport working group will define a protocol or set of= protocols that fits these requirements. Multiple protocols might be requir= ed to support different usage scenarios, such as multiplexing with HTTP/3 o= r networks where UDP is blocked.

The group will pay attention to se= curity issues arising from the above scenarios so as to ensure against crea= tion of new modes of attack, as well as to ensure that security issues addr= essed in the design of Websockets remain addressed in the new work.<= /p>

To assist in the coordination with W3C, the group will initially develop a= n overview document containing use cases and requirements in order to clari= fy the goals of the effort. Feedback will also be solicited at various poin= ts along the way in order to ensure the best possible match between the pro= tocol extensions and the needs of the W3C WebTransport API. The clarity and= interoperability of specifications will be confirmed via test events and h= ackathons.

T= he group will also coordinate with other working groups within the IETF (e.= g. QUIC, HTTPBIS) as appropriate.

Goals and Milestones

  • March 2020 - Adopt a WebTrans= port Overview draft as a WG work item

  • Marc= h 2020 - Adopt a draft defining a WebTransport protocol as a WG work item

  • August 2020 - Issue WG last call of the WebT= ransport Overview document.

  • November 2020 - Issue WG last call on the first WebTransport protocol = document

--000000000000ea9daf059b320c9e-- From nobody Thu Jan 2 19:29:31 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3F112004E for ; Thu, 2 Jan 2020 19:29:30 -0800 (PST) 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=lowentropy.net header.b=gReDtsUo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MELi5q1k 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 J7Xw6LPpFcx6 for ; Thu, 2 Jan 2020 19:29:27 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8EF812004D for ; Thu, 2 Jan 2020 19:29:27 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 27FAE5A6 for ; Thu, 2 Jan 2020 22:29:27 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 02 Jan 2020 22:29:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=ExFr1aW7GS4DQinBtk33w8oR+XZmrL9 QxhELJBZAH3M=; b=gReDtsUoVUbqCPIYO48hJHYpS544OfhCbwZG/7wPPOjkyeR LpIhVtfJZz8j2rV/Az+hOHFcUO0aTaXyRkVHUoitdIiF7GGoFYjD8631Khzu5vSg zscZnvRd/FEePhNQNXeghsLu94+0lbVpUiE0bKS8WzODvywjmF1vUz3GEHs/Y5Je w/W4BeIS4a/GmRYgfKy5sv1U/GGwdWJej/hvmDPMbLb7U3A2YD9i9chsCNoH1YiT 97EA8tSzaToH7jJQo5Dklhp98HbSuVTnH97+WHm7SO593I2ec3Ea1A9OUakU4rQE x3WZY+3IgK/LeBPVZoMVf0hb6DTazTZzHJj8Rjg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm1; bh=ExFr1a W7GS4DQinBtk33w8oR+XZmrL9QxhELJBZAH3M=; b=MELi5q1kio9EtLIvGU/N7l icR8FQV3Q5VlXL3qzVY5CpCYncBHO2R5UzZRUOWkAJdH0zFqHo1bepKr4gpUeuFq cniCjXVNjzfKwB1kYw//eObEEX+uC/3rCKKcUB/7Zkv5yD28HMSFZ0L7mHqDVzG+ Cg5y7F/2p3zz6OXAPNa6R81BiLiR+FoIZzkzvuqD1gZxMWoI9Cfxd3KPtqwG/G1V FSs0wHha6hHrkfZw9iKegbXzadRGHSUibMYqmyZYWx2522aVl8I16ajNefcPuIZf fFb7Nh4hlNws6Gjf5N7ipGlEwlLrROVSav4FxnrTgHsyFnlhHWHFgphJIJliEYnQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdegvddgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgoufhushhpvggtthffohhmrghinhculdegledmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuff homhgrihhnpehgihhthhhusgdrihhopdhgihhthhhusgdrtghomhdpihgvthhfrdhorhhg necurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 78FF2E00A7; Thu, 2 Jan 2020 22:29:26 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-694-gd5bab98-fmstable-20191218v1 Mime-Version: 1.0 Message-Id: <7674d2cc-2897-4d25-9049-37adf5e7fdf7@www.fastmail.com> In-Reply-To: References: Date: Fri, 03 Jan 2020 14:28:47 +1100 From: "Martin Thomson" To: webtransport@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Webtransport] WEBTRANS objectives and potential work items X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 03:29:31 -0000 Hi Bernard, The way this is written it implies that the bulleted list contains enough detail for requirements, but I don't think that these are in fact clear enough. On the contrary, I'm finding them to be confusing. The underlying protocol in WebSockets provides a bidirectional stream of finite sized messages, which are in turn finite length sequences of bytes. By mentioning WebSockets, this text implies that the requirements for WebSockets apply, but also says that it won't induce head-of-line blocking. I'm having a hard time reconciling those. I suspect that what is really in order here is "whatever we decide in the W3C API makes sense to support, based on what QUIC can provide and (maybe) what can be emulated with some arrangement of WebSockets and HTTP where case QUIC isn't available". The later text on building overview and requirements supports that view, which is what makes the detail confusing. Like WebSockets, we could decide to build a message-based system with ordering between messages, but how that is implemented could vary greatly. Even within QUIC, there are many possibilities: * We might decide to use a single bidirectional QUIC stream that uses message delimiters on that streams to distinguish messages. * We might use unidirectional streams in much the same way, but then build some mechanism to couple them into pairs as needed. * We might allow messages to be sent asynchronously without explicit ordering, then use references to those streams from another stream to establish an ordering. * We might use different streams for each message and indicate ordering in the stream header. That's not exhaustive, I'm sure. The possibility that a single connection might allow multiplexing of different "subprotocols" on the same QUIC connection makes some of these options more difficult or even invalid. I know Victor is prepared to argue that multiplexing is Hard and likely incompatible with some of the things he aspires to do eventually, but I don't think we should decide that question in the charter. I tend to think that there is value in being able to interact with multiple "resources" on the same connection, even if I think that the "subprotocol" concept is an abject failure. Maybe the right answer is to reduce this to a simpler statement to replace the paragraphs starting from "These protocols" and ending at "blocked.": > The WebTransport working group will define a protocol or suite of protocols that support a range of simple communication methods. These must include unreliable messages (that might be limited to by the path MTU), reliable messages, and ordered streams of reliable messages. Attention will be paid to performance of the protocol, in particular protocol overheads and the potential for head-of-line blocking; its ability to be deployed and used reliably under different network conditions; and the ability to integrate protocol use into the Web security model. I don't want to say that this includes a superset of the capabilities provided by thewebsocketprotocol, because that seems to be an open question, but I'm not opposed to deciding that early in the process if that is where we end up. I also don't think that you need to worry about HTTP/3 multiplexing at this level either. That comes with working out how to integrate it. Cheers, Martin On Fri, Jan 3, 2020, at 12:15, Bernard Aboba wrote: > During the WEBTRANS BOF there were some questions relating to > objectives as well as potential work items. > > This included some questions relating to "failover transport" (e.g. > whether new work was needed for this or not). Also, EKR questioned why > it was necessary to define two protocols (one for webtransport over > HTTP/3, and another for direct usage of QUIC streams and datagrams). > > I've submitted a PR to clarify the objectives and work items: > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5 > > The modified description and milestones are provided below. Comments welcome. > > ----------------------------------------------------------------------------------------------- > Description of Working Group > > The WebTransport working group will define new client-server protocols > or protocol extensions in order to support the development of the W3C > WebTransport API https://wicg.github.io/web-transport. > > These protocols will support: > > * Reliable bidirectional and unidirectional communication that > provides greater efficiency than Websockets (e.g. removal of > head-of-line blocking). > > * Unreliable datagram communication, functionality not available in Websockets. > > * Origin checks to allow supporting the Web's origin-based security model. > > The WebTransport working group will define a protocol or set of > protocols that fits these requirements. Multiple protocols might be > required to support different usage scenarios, such as multiplexing > with HTTP/3 or networks where UDP is blocked. > > The group will pay attention to security issues arising from the above > scenarios so as to ensure against creation of new modes of attack, as > well as to ensure that security issues addressed in the design of > Websockets remain addressed in the new work. > > To assist in the coordination with W3C, the group will initially > develop an overview document containing use cases and requirements in > order to clarify the goals of the effort. Feedback will also be > solicited at various points along the way in order to ensure the best > possible match between the protocol extensions and the needs of the W3C > WebTransport API. The clarity and interoperability of specifications > will be confirmed via test events and hackathons. > > The group will also coordinate with other working groups within the > IETF (e.g. QUIC, HTTPBIS) as appropriate. > > Goals and Milestones > > * March 2020 - Adopt a WebTransport Overview draft as a WG work item > > * March 2020 - Adopt a draft defining a WebTransport protocol as a WG work item > > * August 2020 - Issue WG last call of the WebTransport Overview document. > > * November 2020 - Issue WG last call on the first WebTransport > protocol document > > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > From nobody Mon Jan 6 10:18:27 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0101200FD for ; Mon, 6 Jan 2020 10:18:21 -0800 (PST) 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 BpgQsjWyXXWC for ; Mon, 6 Jan 2020 10:18:18 -0800 (PST) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 3CC6F1200B3 for ; Mon, 6 Jan 2020 10:18:18 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id h32so11014564uah.4 for ; Mon, 06 Jan 2020 10:18:18 -0800 (PST) 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=f/oo56h/QukbMczkoZP0dFxRNZkntN7Rbxvxypq5dWg=; b=j7oBY0b+Hr05/kU3TYtOrKvl5Xj76ovZO2jNEGZTjY9gqcnCQX0wONQL4dEJ8wYXV+ Xu5DZAZwwOFrQBFKS9iy5rWy/a5XpasqTt8Ec4JjXgQoEuMIlya+JKwW44QEyQsfK9bq q0mOgadl9bX83ARNle2BAuIcxTcM16Yxn0ujB+ZndVHr335g9SNeprB0aO6QJfXk63Hk 6WTcBgpgg2ujyE8M4WTFaI7Yq/a7MpEhgXPDHoTrkmhYs9NUYHzwxtsVTVBZNDYCabH0 JplBXZaJj/ZBujEPnoUjZx6LPTPk1XVUtnXJ0rY2MVJ/yQrzLsZoEzve3K3piwiLkORI aTjQ== 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=f/oo56h/QukbMczkoZP0dFxRNZkntN7Rbxvxypq5dWg=; b=Rd/EZeocdXEDyf/FM5Jwklch8a33pWT4GvoCuQ55JgCF4DHsFjSJR3a+FT8/+6Aqab gOj8tzVq03y3p2hzTsA20UR2dUM0lEqazBisXKVw0pVcD9EOuha8DmaZRmo3cuLaPTyu VWBXGxxkgVIToQWyhDNJaptoz82dU4fvNd5bvWS9Z94ZsT9Y3VtYo7O07rxo/nZBhEDT 8BTBgXHOQZbvQ/6YiczTyAPI46PF0nHocBl66mnlvpV9qCVLjuxspxfnSfiL6j82277X jclacKn737Va/NHA6Xjr3gebX9DBsmrNfNlKzg+TQxj2ft6Pk8Mb0cy0eU6fJUO8CI6l 3zBg== X-Gm-Message-State: APjAAAWORXdaKbJz9TpYs7KcGdqGO7FYHSYO1ErwrpAaIgwTxyUWYIso mkNL6uz4hTBGyKalaI6W6weguyY9wFtqZEyalQX5qMQu X-Google-Smtp-Source: APXvYqz09H3z4z/SQ61YcssBZWBucgbzyxaDRBvfmsKeCWyO/YO+z9NAV1pnb/rw4cX5y4BLT8/dhgtqTSahEmKUZWI= X-Received: by 2002:ab0:2a1a:: with SMTP id o26mr60896366uar.62.1578334697162; Mon, 06 Jan 2020 10:18:17 -0800 (PST) MIME-Version: 1.0 References: <7674d2cc-2897-4d25-9049-37adf5e7fdf7@www.fastmail.com> In-Reply-To: <7674d2cc-2897-4d25-9049-37adf5e7fdf7@www.fastmail.com> From: Bernard Aboba Date: Mon, 6 Jan 2020 10:18:06 -0800 Message-ID: To: Martin Thomson Cc: webtransport@ietf.org Content-Type: multipart/alternative; boundary="000000000000f61286059b7cae90" Archived-At: Subject: Re: [Webtransport] WEBTRANS objectives and potential work items X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 18:18:23 -0000 --000000000000f61286059b7cae90 Content-Type: text/plain; charset="UTF-8" Thanks, Martin. I've incorporated your suggestions into a modified PR: https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5 On Thu, Jan 2, 2020 at 7:29 PM Martin Thomson wrote: > Hi Bernard, > > The way this is written it implies that the bulleted list contains enough > detail for requirements, but I don't think that these are in fact clear > enough. On the contrary, I'm finding them to be confusing. > > The underlying protocol in WebSockets provides a bidirectional stream of > finite sized messages, which are in turn finite length sequences of bytes. > By mentioning WebSockets, this text implies that the requirements for > WebSockets apply, but also says that it won't induce head-of-line > blocking. I'm having a hard time reconciling those. I suspect that what > is really in order here is "whatever we decide in the W3C API makes sense > to support, based on what QUIC can provide and (maybe) what can be emulated > with some arrangement of WebSockets and HTTP where case QUIC isn't > available". The later text on building overview and requirements supports > that view, which is what makes the detail confusing. > > Like WebSockets, we could decide to build a message-based system with > ordering between messages, but how that is implemented could vary greatly. > Even within QUIC, there are many possibilities: > > * We might decide to use a single bidirectional QUIC stream that uses > message delimiters on that streams to distinguish messages. > * We might use unidirectional streams in much the same way, but then build > some mechanism to couple them into pairs as needed. > * We might allow messages to be sent asynchronously without explicit > ordering, then use references to those streams from another stream to > establish an ordering. > * We might use different streams for each message and indicate ordering in > the stream header. > > That's not exhaustive, I'm sure. > > The possibility that a single connection might allow multiplexing of > different "subprotocols" on the same QUIC connection makes some of these > options more difficult or even invalid. I know Victor is prepared to argue > that multiplexing is Hard and likely incompatible with some of the things > he aspires to do eventually, but I don't think we should decide that > question in the charter. I tend to think that there is value in being able > to interact with multiple "resources" on the same connection, even if I > think that the "subprotocol" concept is an abject failure. > > Maybe the right answer is to reduce this to a simpler statement to replace > the paragraphs starting from "These protocols" and ending at "blocked.": > > > The WebTransport working group will define a protocol or suite of > protocols that support a range of simple communication methods. These must > include unreliable messages (that might be limited to by the path MTU), > reliable messages, and ordered streams of reliable messages. Attention > will be paid to performance of the protocol, in particular protocol > overheads and the potential for head-of-line blocking; its ability to be > deployed and used reliably under different network conditions; and the > ability to integrate protocol use into the Web security model. > > I don't want to say that this includes a superset of the capabilities > provided by thewebsocketprotocol, because that seems to be an open > question, but I'm not opposed to deciding that early in the process if that > is where we end up. I also don't think that you need to worry about HTTP/3 > multiplexing at this level either. That comes with working out how to > integrate it. > > Cheers, > Martin > > On Fri, Jan 3, 2020, at 12:15, Bernard Aboba wrote: > > During the WEBTRANS BOF there were some questions relating to > > objectives as well as potential work items. > > > > This included some questions relating to "failover transport" (e.g. > > whether new work was needed for this or not). Also, EKR questioned why > > it was necessary to define two protocols (one for webtransport over > > HTTP/3, and another for direct usage of QUIC streams and datagrams). > > > > I've submitted a PR to clarify the objectives and work items: > > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5 > > > > The modified description and milestones are provided below. Comments > welcome. > > > > > ----------------------------------------------------------------------------------------------- > > Description of Working Group > > > > The WebTransport working group will define new client-server protocols > > or protocol extensions in order to support the development of the W3C > > WebTransport API https://wicg.github.io/web-transport. > > > > These protocols will support: > > > > * Reliable bidirectional and unidirectional communication that > > provides greater efficiency than Websockets (e.g. removal of > > head-of-line blocking). > > > > * Unreliable datagram communication, functionality not available in > Websockets. > > > > * Origin checks to allow supporting the Web's origin-based security > model. > > > > The WebTransport working group will define a protocol or set of > > protocols that fits these requirements. Multiple protocols might be > > required to support different usage scenarios, such as multiplexing > > with HTTP/3 or networks where UDP is blocked. > > > > The group will pay attention to security issues arising from the above > > scenarios so as to ensure against creation of new modes of attack, as > > well as to ensure that security issues addressed in the design of > > Websockets remain addressed in the new work. > > > > To assist in the coordination with W3C, the group will initially > > develop an overview document containing use cases and requirements in > > order to clarify the goals of the effort. Feedback will also be > > solicited at various points along the way in order to ensure the best > > possible match between the protocol extensions and the needs of the W3C > > WebTransport API. The clarity and interoperability of specifications > > will be confirmed via test events and hackathons. > > > > The group will also coordinate with other working groups within the > > IETF (e.g. QUIC, HTTPBIS) as appropriate. > > > > Goals and Milestones > > > > * March 2020 - Adopt a WebTransport Overview draft as a WG work item > > > > * March 2020 - Adopt a draft defining a WebTransport protocol as a WG > work item > > > > * August 2020 - Issue WG last call of the WebTransport Overview > document. > > > > * November 2020 - Issue WG last call on the first WebTransport > > protocol document > > > > -- > > Webtransport mailing list > > Webtransport@ietf.org > > https://www.ietf.org/mailman/listinfo/webtransport > > > > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --000000000000f61286059b7cae90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Martin.=C2=A0

= I've incorporated your suggestions into a modified PR:

On Thu, Jan 2, 2020 at 7:29 PM Martin Thomson= <mt@lowentropy.net> wrote:<= br>
Hi Bernard,

The way this is written it implies that the bulleted list contains enough d= etail for requirements, but I don't think that these are in fact clear = enough.=C2=A0 On the contrary, I'm finding them to be confusing.

The underlying protocol in WebSockets provides a bidirectional stream of fi= nite sized messages, which are in turn finite length sequences of bytes.=C2= =A0 By mentioning WebSockets, this text implies that the requirements for W= ebSockets apply, but also says that it won't induce head-of-line blocki= ng.=C2=A0 I'm having a hard time reconciling those.=C2=A0 I suspect tha= t what is really in order here is "whatever we decide in the W3C API m= akes sense to support, based on what QUIC can provide and (maybe) what can = be emulated with some arrangement of WebSockets and HTTP where case QUIC is= n't available".=C2=A0 The later text on building overview and requ= irements supports that view, which is what makes the detail confusing.

Like WebSockets, we could decide to build a message-based system with order= ing between messages, but how that is implemented could vary greatly.=C2=A0= Even within QUIC, there are many possibilities:

* We might decide to use a single bidirectional QUIC stream that uses messa= ge delimiters on that streams to distinguish messages.
* We might use unidirectional streams in much the same way, but then build = some mechanism to couple them into pairs as needed.
* We might allow messages to be sent asynchronously without explicit orderi= ng, then use references to those streams from another stream to establish a= n ordering.
* We might use different streams for each message and indicate ordering in = the stream header.

That's not exhaustive, I'm sure.

The possibility that a single connection might allow multiplexing of differ= ent "subprotocols" on the same QUIC connection makes some of thes= e options more difficult or even invalid.=C2=A0 I know Victor is prepared t= o argue that multiplexing is Hard and likely incompatible with some of the = things he aspires to do eventually, but I don't think we should decide = that question in the charter.=C2=A0 I tend to think that there is value in = being able to interact with multiple "resources" on the same conn= ection, even if I think that the "subprotocol" concept is an abje= ct failure.

Maybe the right answer is to reduce this to a simpler statement to replace = the paragraphs starting from "These protocols" and ending at &quo= t;blocked.":

> The WebTransport working group will define a protocol or suite of prot= ocols that support a range of simple communication methods.=C2=A0 These mus= t include unreliable messages (that might be limited to by the path MTU), r= eliable messages, and ordered streams of reliable messages.=C2=A0 Attention= will be paid to performance of the protocol, in particular protocol overhe= ads and the potential for head-of-line blocking; its ability to be deployed= and used reliably under different network conditions; and the ability to i= ntegrate protocol use into the Web security model.

I don't want to say that this includes a superset of the capabilities p= rovided by thewebsocketprotocol, because that seems to be an open question,= but I'm not opposed to deciding that early in the process if that is w= here we end up.=C2=A0 I also don't think that you need to worry about H= TTP/3 multiplexing at this level either.=C2=A0 That comes with working out = how to integrate it.

Cheers,
Martin

On Fri, Jan 3, 2020, at 12:15, Bernard Aboba wrote:
> During the WEBTRANS BOF there were some questions relating to
> objectives as well as potential work items.
>
> This included some questions relating to "failover transport"= ; (e.g.
> whether new work was needed for this or not). Also, EKR questioned why=
> it was necessary to define two protocols (one for webtransport over > HTTP/3, and another for direct usage of QUIC streams and datagrams). >
> I've submitted a PR to clarify the objectives and work items:
> https://github.com/DavidSchinazi/w= ebtrans-wg-materials/pull/5
>
> The modified description and milestones are provided below. Comments w= elcome.
>
> ----------------------------------------------------------------------= -------------------------
> Description of Working Group
>
> The WebTransport working group will define new client-server protocols=
> or protocol extensions in order to support the development of the W3C =
> WebTransport API https://wicg.github.io/web-transport.=
>
> These protocols will support:
>
>=C2=A0 * Reliable bidirectional and unidirectional communication that <= br> > provides greater efficiency than Websockets (e.g. removal of
> head-of-line blocking).
>
>=C2=A0 * Unreliable datagram communication, functionality not available= in Websockets.
>
>=C2=A0 * Origin checks to allow supporting the Web's origin-based s= ecurity model.
>
> The WebTransport working group will define a protocol or set of
> protocols that fits these requirements. Multiple protocols might be > required to support different usage scenarios, such as multiplexing > with HTTP/3 or networks where UDP is blocked.
>
> The group will pay attention to security issues arising from the above=
> scenarios so as to ensure against creation of new modes of attack, as =
> well as to ensure that security issues addressed in the design of
> Websockets remain addressed in the new work.
>
> To assist in the coordination with W3C, the group will initially
> develop an overview document containing use cases and requirements in =
> order to clarify the goals of the effort. Feedback will also be
> solicited at various points along the way in order to ensure the best =
> possible match between the protocol extensions and the needs of the W3= C
> WebTransport API. The clarity and interoperability of specifications <= br> > will be confirmed via test events and hackathons.
>
> The group will also coordinate with other working groups within the > IETF (e.g. QUIC, HTTPBIS) as appropriate.
>
> Goals and Milestones
>
>=C2=A0 * March 2020 - Adopt a WebTransport Overview draft as a WG work = item
>
>=C2=A0 * March 2020 - Adopt a draft defining a WebTransport protocol as= a WG work item
>
>=C2=A0 * August 2020 - Issue WG last call of the WebTransport Overview = document.
>
>=C2=A0 * November 2020 - Issue WG last call on the first WebTransport <= br> > protocol document
>
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport
>

--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--000000000000f61286059b7cae90-- From nobody Mon Jan 6 13:08:23 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3321B12007A for ; Mon, 6 Jan 2020 13:08:22 -0800 (PST) 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 ZOM62wEy-6qz for ; Mon, 6 Jan 2020 13:08:19 -0800 (PST) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 8374F1200A3 for ; Mon, 6 Jan 2020 13:08:19 -0800 (PST) Received: by mail-wm1-x32a.google.com with SMTP id p17so16957224wmb.0 for ; Mon, 06 Jan 2020 13:08:19 -0800 (PST) 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=aC8gjHWI6hOftYSuZYGNa9h+dEqbV9/+1JMEoxrbs+k=; b=iJlcZ+mAxr/hD4NCY2XTC8vTR92HjDhTnaiCzKiQ2ww+76YZ8qUUaaC97XNVB0GM8s WDicg00C2m/S8bGFFRCiJZ1ltq2wBimcTZ8Pch5oH1MALL049yZCg6utW6RjyyiwOxSi 5Ce9xIY8SABRoecklYUbTsp44b3gJPX2OvN46DhTB2kRh/art/KJ7rzt1S4TrQaiBBDn nIVyEfnew7B7Fd4RCQLqNHemGVlFwIsygkvvMPg3kAlKnBa2zR6JxZ7yhAx6ddqjKEPI cP6NTKPpPm+BYGjjiv0hOXl2Xk5m2RAcdrV6lh2jNvP0n9FfNljbe+gll7+QTGyyh1PE VzgQ== 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=aC8gjHWI6hOftYSuZYGNa9h+dEqbV9/+1JMEoxrbs+k=; b=OOnZA6CRNDwZIOm/AhTjIjz/DMh3LWf0s6tZC6nXvKtF7NRoaiHhiNBoCUDdQkiThE aDi+aeZWvjfjgFSjnYoj/9iOfYt59sIOIcf4f4om9bO8eCeMe1NYWu3G0QjCW3wbV4Ws BN0GnDUvjZbxvkUtjO2hf7EdJs5rRgViElot9CEjOuMiDy/7876mzFGQRKc06+zh7vY4 cLfla+83VVh9rHaFxACLEDFrIXijwSuGrm6Be88S+oKg6KjwK+mz2ja1dVVh3v/MUE7H FQuGQpwYyW5uG7zRzZ8nH5M4g6JuTlU6j96BoXFzPZbvx80DXkMb0BJ8K9gNmmqkZ9MV ZZtQ== X-Gm-Message-State: APjAAAVb0yL0Jkk7Z1be6hasQEK3pLWihaa5RiNvL+/3er5agS5mv2X5 P5QZ7wehX9vjAd9b+xodjjlLGPzb84HlAwWjxmQ= X-Google-Smtp-Source: APXvYqy5qmuqiYWByfhOuOhoDhJTYTHwZdSkGAZgGzagyv3cacGfQaAhXK+sO+3V0BZ38ZIGs1Cgqb+Go4FepehBz+A= X-Received: by 2002:a05:600c:2050:: with SMTP id p16mr34154043wmg.176.1578344898025; Mon, 06 Jan 2020 13:08:18 -0800 (PST) MIME-Version: 1.0 References: <7674d2cc-2897-4d25-9049-37adf5e7fdf7@www.fastmail.com> In-Reply-To: From: Sergio Garcia Murillo Date: Mon, 6 Jan 2020 22:08:05 +0100 Message-ID: To: Bernard Aboba Cc: Martin Thomson , webtransport@ietf.org Content-Type: multipart/alternative; boundary="000000000000fadb1a059b7f0e26" Archived-At: Subject: Re: [Webtransport] WEBTRANS objectives and potential work items X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 21:08:22 -0000 --000000000000fadb1a059b7f0e26 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable one question, is p2p browser to browser connection in the scope of webtransport? El lun., 6 ene. 2020 19:18, Bernard Aboba escribi=C3=B3: > Thanks, Martin. > > I've incorporated your suggestions into a modified PR: > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5 > > On Thu, Jan 2, 2020 at 7:29 PM Martin Thomson wrote: > >> Hi Bernard, >> >> The way this is written it implies that the bulleted list contains enoug= h >> detail for requirements, but I don't think that these are in fact clear >> enough. On the contrary, I'm finding them to be confusing. >> >> The underlying protocol in WebSockets provides a bidirectional stream of >> finite sized messages, which are in turn finite length sequences of byte= s. >> By mentioning WebSockets, this text implies that the requirements for >> WebSockets apply, but also says that it won't induce head-of-line >> blocking. I'm having a hard time reconciling those. I suspect that wha= t >> is really in order here is "whatever we decide in the W3C API makes sens= e >> to support, based on what QUIC can provide and (maybe) what can be emula= ted >> with some arrangement of WebSockets and HTTP where case QUIC isn't >> available". The later text on building overview and requirements suppor= ts >> that view, which is what makes the detail confusing. >> >> Like WebSockets, we could decide to build a message-based system with >> ordering between messages, but how that is implemented could vary greatl= y. >> Even within QUIC, there are many possibilities: >> >> * We might decide to use a single bidirectional QUIC stream that uses >> message delimiters on that streams to distinguish messages. >> * We might use unidirectional streams in much the same way, but then >> build some mechanism to couple them into pairs as needed. >> * We might allow messages to be sent asynchronously without explicit >> ordering, then use references to those streams from another stream to >> establish an ordering. >> * We might use different streams for each message and indicate ordering >> in the stream header. >> >> That's not exhaustive, I'm sure. >> >> The possibility that a single connection might allow multiplexing of >> different "subprotocols" on the same QUIC connection makes some of these >> options more difficult or even invalid. I know Victor is prepared to ar= gue >> that multiplexing is Hard and likely incompatible with some of the thing= s >> he aspires to do eventually, but I don't think we should decide that >> question in the charter. I tend to think that there is value in being a= ble >> to interact with multiple "resources" on the same connection, even if I >> think that the "subprotocol" concept is an abject failure. >> >> Maybe the right answer is to reduce this to a simpler statement to >> replace the paragraphs starting from "These protocols" and ending at >> "blocked.": >> >> > The WebTransport working group will define a protocol or suite of >> protocols that support a range of simple communication methods. These m= ust >> include unreliable messages (that might be limited to by the path MTU), >> reliable messages, and ordered streams of reliable messages. Attention >> will be paid to performance of the protocol, in particular protocol >> overheads and the potential for head-of-line blocking; its ability to be >> deployed and used reliably under different network conditions; and the >> ability to integrate protocol use into the Web security model. >> >> I don't want to say that this includes a superset of the capabilities >> provided by thewebsocketprotocol, because that seems to be an open >> question, but I'm not opposed to deciding that early in the process if t= hat >> is where we end up. I also don't think that you need to worry about HTT= P/3 >> multiplexing at this level either. That comes with working out how to >> integrate it. >> >> Cheers, >> Martin >> >> On Fri, Jan 3, 2020, at 12:15, Bernard Aboba wrote: >> > During the WEBTRANS BOF there were some questions relating to >> > objectives as well as potential work items. >> > >> > This included some questions relating to "failover transport" (e.g. >> > whether new work was needed for this or not). Also, EKR questioned why >> > it was necessary to define two protocols (one for webtransport over >> > HTTP/3, and another for direct usage of QUIC streams and datagrams). >> > >> > I've submitted a PR to clarify the objectives and work items: >> > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5 >> > >> > The modified description and milestones are provided below. Comments >> welcome. >> > >> > >> ------------------------------------------------------------------------= ----------------------- >> > Description of Working Group >> > >> > The WebTransport working group will define new client-server protocols >> > or protocol extensions in order to support the development of the W3C >> > WebTransport API https://wicg.github.io/web-transport. >> > >> > These protocols will support: >> > >> > * Reliable bidirectional and unidirectional communication that >> > provides greater efficiency than Websockets (e.g. removal of >> > head-of-line blocking). >> > >> > * Unreliable datagram communication, functionality not available in >> Websockets. >> > >> > * Origin checks to allow supporting the Web's origin-based security >> model. >> > >> > The WebTransport working group will define a protocol or set of >> > protocols that fits these requirements. Multiple protocols might be >> > required to support different usage scenarios, such as multiplexing >> > with HTTP/3 or networks where UDP is blocked. >> > >> > The group will pay attention to security issues arising from the above >> > scenarios so as to ensure against creation of new modes of attack, as >> > well as to ensure that security issues addressed in the design of >> > Websockets remain addressed in the new work. >> > >> > To assist in the coordination with W3C, the group will initially >> > develop an overview document containing use cases and requirements in >> > order to clarify the goals of the effort. Feedback will also be >> > solicited at various points along the way in order to ensure the best >> > possible match between the protocol extensions and the needs of the W3= C >> > WebTransport API. The clarity and interoperability of specifications >> > will be confirmed via test events and hackathons. >> > >> > The group will also coordinate with other working groups within the >> > IETF (e.g. QUIC, HTTPBIS) as appropriate. >> > >> > Goals and Milestones >> > >> > * March 2020 - Adopt a WebTransport Overview draft as a WG work item >> > >> > * March 2020 - Adopt a draft defining a WebTransport protocol as a WG >> work item >> > >> > * August 2020 - Issue WG last call of the WebTransport Overview >> document. >> > >> > * November 2020 - Issue WG last call on the first WebTransport >> > protocol document >> > >> > -- >> > Webtransport mailing list >> > Webtransport@ietf.org >> > https://www.ietf.org/mailman/listinfo/webtransport >> > >> >> -- >> Webtransport mailing list >> Webtransport@ietf.org >> https://www.ietf.org/mailman/listinfo/webtransport >> > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --000000000000fadb1a059b7f0e26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
one question,=C2=A0 is p2p browser to browser connection = in the scope of webtransport?

El lun., 6 ene. 2020 19:18, Bernard Aboba <= ;bernard.aboba@gmail.com>= escribi=C3=B3:
Thanks, Martin.=C2=A0

I've incorporat= ed your suggestions into a modified PR:

On Thu, Jan 2, 2020 at 7:29 PM = Martin Thomson <mt@lowentropy.net> wrote:
Hi Bernard,

The way this is written it implies that the bulleted list contains enough d= etail for requirements, but I don't think that these are in fact clear = enough.=C2=A0 On the contrary, I'm finding them to be confusing.

The underlying protocol in WebSockets provides a bidirectional stream of fi= nite sized messages, which are in turn finite length sequences of bytes.=C2= =A0 By mentioning WebSockets, this text implies that the requirements for W= ebSockets apply, but also says that it won't induce head-of-line blocki= ng.=C2=A0 I'm having a hard time reconciling those.=C2=A0 I suspect tha= t what is really in order here is "whatever we decide in the W3C API m= akes sense to support, based on what QUIC can provide and (maybe) what can = be emulated with some arrangement of WebSockets and HTTP where case QUIC is= n't available".=C2=A0 The later text on building overview and requ= irements supports that view, which is what makes the detail confusing.

Like WebSockets, we could decide to build a message-based system with order= ing between messages, but how that is implemented could vary greatly.=C2=A0= Even within QUIC, there are many possibilities:

* We might decide to use a single bidirectional QUIC stream that uses messa= ge delimiters on that streams to distinguish messages.
* We might use unidirectional streams in much the same way, but then build = some mechanism to couple them into pairs as needed.
* We might allow messages to be sent asynchronously without explicit orderi= ng, then use references to those streams from another stream to establish a= n ordering.
* We might use different streams for each message and indicate ordering in = the stream header.

That's not exhaustive, I'm sure.

The possibility that a single connection might allow multiplexing of differ= ent "subprotocols" on the same QUIC connection makes some of thes= e options more difficult or even invalid.=C2=A0 I know Victor is prepared t= o argue that multiplexing is Hard and likely incompatible with some of the = things he aspires to do eventually, but I don't think we should decide = that question in the charter.=C2=A0 I tend to think that there is value in = being able to interact with multiple "resources" on the same conn= ection, even if I think that the "subprotocol" concept is an abje= ct failure.

Maybe the right answer is to reduce this to a simpler statement to replace = the paragraphs starting from "These protocols" and ending at &quo= t;blocked.":

> The WebTransport working group will define a protocol or suite of prot= ocols that support a range of simple communication methods.=C2=A0 These mus= t include unreliable messages (that might be limited to by the path MTU), r= eliable messages, and ordered streams of reliable messages.=C2=A0 Attention= will be paid to performance of the protocol, in particular protocol overhe= ads and the potential for head-of-line blocking; its ability to be deployed= and used reliably under different network conditions; and the ability to i= ntegrate protocol use into the Web security model.

I don't want to say that this includes a superset of the capabilities p= rovided by thewebsocketprotocol, because that seems to be an open question,= but I'm not opposed to deciding that early in the process if that is w= here we end up.=C2=A0 I also don't think that you need to worry about H= TTP/3 multiplexing at this level either.=C2=A0 That comes with working out = how to integrate it.

Cheers,
Martin

On Fri, Jan 3, 2020, at 12:15, Bernard Aboba wrote:
> During the WEBTRANS BOF there were some questions relating to
> objectives as well as potential work items.
>
> This included some questions relating to "failover transport"= ; (e.g.
> whether new work was needed for this or not). Also, EKR questioned why=
> it was necessary to define two protocols (one for webtransport over > HTTP/3, and another for direct usage of QUIC streams and datagrams). >
> I've submitted a PR to clarify the objectives and work items:
> https://github.com/Davi= dSchinazi/webtrans-wg-materials/pull/5
>
> The modified description and milestones are provided below. Comments w= elcome.
>
> ----------------------------------------------------------------------= -------------------------
> Description of Working Group
>
> The WebTransport working group will define new client-server protocols=
> or protocol extensions in order to support the development of the W3C =
> WebTransport API https://wicg.github.io/web-tra= nsport.
>
> These protocols will support:
>
>=C2=A0 * Reliable bidirectional and unidirectional communication that <= br> > provides greater efficiency than Websockets (e.g. removal of
> head-of-line blocking).
>
>=C2=A0 * Unreliable datagram communication, functionality not available= in Websockets.
>
>=C2=A0 * Origin checks to allow supporting the Web's origin-based s= ecurity model.
>
> The WebTransport working group will define a protocol or set of
> protocols that fits these requirements. Multiple protocols might be > required to support different usage scenarios, such as multiplexing > with HTTP/3 or networks where UDP is blocked.
>
> The group will pay attention to security issues arising from the above=
> scenarios so as to ensure against creation of new modes of attack, as =
> well as to ensure that security issues addressed in the design of
> Websockets remain addressed in the new work.
>
> To assist in the coordination with W3C, the group will initially
> develop an overview document containing use cases and requirements in =
> order to clarify the goals of the effort. Feedback will also be
> solicited at various points along the way in order to ensure the best =
> possible match between the protocol extensions and the needs of the W3= C
> WebTransport API. The clarity and interoperability of specifications <= br> > will be confirmed via test events and hackathons.
>
> The group will also coordinate with other working groups within the > IETF (e.g. QUIC, HTTPBIS) as appropriate.
>
> Goals and Milestones
>
>=C2=A0 * March 2020 - Adopt a WebTransport Overview draft as a WG work = item
>
>=C2=A0 * March 2020 - Adopt a draft defining a WebTransport protocol as= a WG work item
>
>=C2=A0 * August 2020 - Issue WG last call of the WebTransport Overview = document.
>
>=C2=A0 * November 2020 - Issue WG last call on the first WebTransport <= br> > protocol document
>
> --
> Webtransport mailing list
> Webtransport@ietf.org
> https://www.ietf.org/mailman/listi= nfo/webtransport
>

--
Webtransport mailing list
Webtransport@ietf.org
https://www.ietf.org/mailman/listinfo/w= ebtransport
--
Webtransport mailing list
Webtransport@ietf.org
https://www.ietf.org/mailman/listinfo/w= ebtransport
--000000000000fadb1a059b7f0e26-- From nobody Mon Jan 6 14:21:40 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7F81200CE for ; Mon, 6 Jan 2020 14:21:38 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.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 tWPnafDolv7P for ; Mon, 6 Jan 2020 14:21:36 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 05DEF120018 for ; Mon, 6 Jan 2020 14:21:36 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id 9so37441159lfq.10 for ; Mon, 06 Jan 2020 14:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iLbStO/hXkCAi9sS67fs1/pvRtVTyJJnK3sqARQVup8=; b=biSBIL0lrPmMj/Z39eBFN0Zsk3tM/wftrLht5JNzoLDlpRasuJiSyyUbi1clNre8g0 5Jt2WVsaDW3nDIfPmXINd7uO5cpNv25cm8kU3XMoFtXl789ITxXLFdaxaALJlzZFZUep wGUJJ6lIqI47RAZAXLLABPj61vmVHngsw14OUPVxI9BBfce09dyXQJrL+9sQgAmQbSKS W6j/Z3merQyWDSiERNRsZnrkyL45cbW44tu6aYcmf2IwKmrv3LgE/hzVlYxMlBXfYGYF lWrz3yVb+UG2fGxMgpbwO1k8kndBBbscposGKZRgov7vgQpDLbfq9oXrVVNkvuBWeCBf fTrA== 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=iLbStO/hXkCAi9sS67fs1/pvRtVTyJJnK3sqARQVup8=; b=gFx1PgFDuw/s0UhARnwm571Wq33/+xN08uffMSniJSw3JdhPQ3N50rpIzYi1XK1iLM eF67Tm54nnEAzJVKJKbIKtm31pbneJUo+gzusRTagS3xC70zDLLfFmvAE6ecTsFWBQc9 znc7lcaryNLt6Hosyx6LygvuSlEXOZOq3yLdThwIG3AX3d5SC6FAMtly66u+D8RfV38j Yu1xatuqPV9tT1uwr2/ZSo0EImoSQfO89iBAtwFc4hgrrUH1xJ2t3bNQFITajm+GjYAW CEXARe1Q8cO4C56mKeDNIXP2wHI34ILB+W3uBSr5srC8VNypdRCKW71idFbnffpfPGOl XthA== X-Gm-Message-State: APjAAAXIsBTxMuykPBcYrERRjCAyJKbHmGiwg1ji/KlLNp9tbj8iiqKB 5ksKTcuxIW05fdRJef1AzlPDByNWGnAAahBZrxp2ZQ== X-Google-Smtp-Source: APXvYqyZhZEVlzDraux3VT9KV2a7+K9Lj71oqox7I38jXTsxmcfYqhqFYECpUTsxRKm8xXA5e29AZ9Si5De5IIUlKv4= X-Received: by 2002:a05:6512:25c:: with SMTP id b28mr4200184lfo.184.1578349294219; Mon, 06 Jan 2020 14:21:34 -0800 (PST) MIME-Version: 1.0 References: <7674d2cc-2897-4d25-9049-37adf5e7fdf7@www.fastmail.com> In-Reply-To: From: Eric Rescorla Date: Mon, 6 Jan 2020 14:20:58 -0800 Message-ID: To: Bernard Aboba Cc: Martin Thomson , webtransport@ietf.org Content-Type: multipart/alternative; boundary="000000000000037db6059b801551" Archived-At: Subject: Re: [Webtransport] WEBTRANS objectives and potential work items X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 22:21:39 -0000 --000000000000037db6059b801551 Content-Type: text/plain; charset="UTF-8" This seems like an improvement. However, perhaps we can skip the stage where we have science fiction-based milestones? Being done by end of 2020 seems....unlike.y -Ekr On Mon, Jan 6, 2020 at 10:18 AM Bernard Aboba wrote: > Thanks, Martin. > > I've incorporated your suggestions into a modified PR: > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5 > > On Thu, Jan 2, 2020 at 7:29 PM Martin Thomson wrote: > >> Hi Bernard, >> >> The way this is written it implies that the bulleted list contains enough >> detail for requirements, but I don't think that these are in fact clear >> enough. On the contrary, I'm finding them to be confusing. >> >> The underlying protocol in WebSockets provides a bidirectional stream of >> finite sized messages, which are in turn finite length sequences of bytes. >> By mentioning WebSockets, this text implies that the requirements for >> WebSockets apply, but also says that it won't induce head-of-line >> blocking. I'm having a hard time reconciling those. I suspect that what >> is really in order here is "whatever we decide in the W3C API makes sense >> to support, based on what QUIC can provide and (maybe) what can be emulated >> with some arrangement of WebSockets and HTTP where case QUIC isn't >> available". The later text on building overview and requirements supports >> that view, which is what makes the detail confusing. >> >> Like WebSockets, we could decide to build a message-based system with >> ordering between messages, but how that is implemented could vary greatly. >> Even within QUIC, there are many possibilities: >> >> * We might decide to use a single bidirectional QUIC stream that uses >> message delimiters on that streams to distinguish messages. >> * We might use unidirectional streams in much the same way, but then >> build some mechanism to couple them into pairs as needed. >> * We might allow messages to be sent asynchronously without explicit >> ordering, then use references to those streams from another stream to >> establish an ordering. >> * We might use different streams for each message and indicate ordering >> in the stream header. >> >> That's not exhaustive, I'm sure. >> >> The possibility that a single connection might allow multiplexing of >> different "subprotocols" on the same QUIC connection makes some of these >> options more difficult or even invalid. I know Victor is prepared to argue >> that multiplexing is Hard and likely incompatible with some of the things >> he aspires to do eventually, but I don't think we should decide that >> question in the charter. I tend to think that there is value in being able >> to interact with multiple "resources" on the same connection, even if I >> think that the "subprotocol" concept is an abject failure. >> >> Maybe the right answer is to reduce this to a simpler statement to >> replace the paragraphs starting from "These protocols" and ending at >> "blocked.": >> >> > The WebTransport working group will define a protocol or suite of >> protocols that support a range of simple communication methods. These must >> include unreliable messages (that might be limited to by the path MTU), >> reliable messages, and ordered streams of reliable messages. Attention >> will be paid to performance of the protocol, in particular protocol >> overheads and the potential for head-of-line blocking; its ability to be >> deployed and used reliably under different network conditions; and the >> ability to integrate protocol use into the Web security model. >> >> I don't want to say that this includes a superset of the capabilities >> provided by thewebsocketprotocol, because that seems to be an open >> question, but I'm not opposed to deciding that early in the process if that >> is where we end up. I also don't think that you need to worry about HTTP/3 >> multiplexing at this level either. That comes with working out how to >> integrate it. >> >> Cheers, >> Martin >> >> On Fri, Jan 3, 2020, at 12:15, Bernard Aboba wrote: >> > During the WEBTRANS BOF there were some questions relating to >> > objectives as well as potential work items. >> > >> > This included some questions relating to "failover transport" (e.g. >> > whether new work was needed for this or not). Also, EKR questioned why >> > it was necessary to define two protocols (one for webtransport over >> > HTTP/3, and another for direct usage of QUIC streams and datagrams). >> > >> > I've submitted a PR to clarify the objectives and work items: >> > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5 >> > >> > The modified description and milestones are provided below. Comments >> welcome. >> > >> > >> ----------------------------------------------------------------------------------------------- >> > Description of Working Group >> > >> > The WebTransport working group will define new client-server protocols >> > or protocol extensions in order to support the development of the W3C >> > WebTransport API https://wicg.github.io/web-transport. >> > >> > These protocols will support: >> > >> > * Reliable bidirectional and unidirectional communication that >> > provides greater efficiency than Websockets (e.g. removal of >> > head-of-line blocking). >> > >> > * Unreliable datagram communication, functionality not available in >> Websockets. >> > >> > * Origin checks to allow supporting the Web's origin-based security >> model. >> > >> > The WebTransport working group will define a protocol or set of >> > protocols that fits these requirements. Multiple protocols might be >> > required to support different usage scenarios, such as multiplexing >> > with HTTP/3 or networks where UDP is blocked. >> > >> > The group will pay attention to security issues arising from the above >> > scenarios so as to ensure against creation of new modes of attack, as >> > well as to ensure that security issues addressed in the design of >> > Websockets remain addressed in the new work. >> > >> > To assist in the coordination with W3C, the group will initially >> > develop an overview document containing use cases and requirements in >> > order to clarify the goals of the effort. Feedback will also be >> > solicited at various points along the way in order to ensure the best >> > possible match between the protocol extensions and the needs of the W3C >> > WebTransport API. The clarity and interoperability of specifications >> > will be confirmed via test events and hackathons. >> > >> > The group will also coordinate with other working groups within the >> > IETF (e.g. QUIC, HTTPBIS) as appropriate. >> > >> > Goals and Milestones >> > >> > * March 2020 - Adopt a WebTransport Overview draft as a WG work item >> > >> > * March 2020 - Adopt a draft defining a WebTransport protocol as a WG >> work item >> > >> > * August 2020 - Issue WG last call of the WebTransport Overview >> document. >> > >> > * November 2020 - Issue WG last call on the first WebTransport >> > protocol document >> > >> > -- >> > Webtransport mailing list >> > Webtransport@ietf.org >> > https://www.ietf.org/mailman/listinfo/webtransport >> > >> >> -- >> Webtransport mailing list >> Webtransport@ietf.org >> https://www.ietf.org/mailman/listinfo/webtransport >> > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --000000000000037db6059b801551 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This seems like an improvement. However, perhaps we c= an skip the stage where we have science fiction-based milestones? Being don= e by end of 2020 seems....unlike.y

-Ekr
<= div>

On Mon, Jan 6, 2020 at 10:18 AM Bernard Aboba <bernard.aboba@gmail.com> wrote:<= br>
Thanks, Martin.=C2=A0

I've incorpo= rated your suggestions into a modified PR:

On Thu, Jan 2, 2020 at 7:29 PM Martin Thomson= <mt@lowentropy.n= et> wrote:
https://github.com/DavidSchinazi/w= ebtrans-wg-materials/pull/5
>
> The modified description and milestones are provided below. Comments w= elcome.
>
> ----------------------------------------------------------------------= -------------------------
> Description of Working Group
>
> The WebTransport working group will define new client-server protocols=
> or protocol extensions in order to support the development of the W3C =
> WebTransport API https://wicg.github.io/web-transport.=
>
> These protocols will support:
>
>=C2=A0 * Reliable bidirectional and unidirectional communication that <= br> > provides greater efficiency than Websockets (e.g. removal of
> head-of-line blocking).
>
>=C2=A0 * Unreliable datagram communication, functionality not available= in Websockets.
>
>=C2=A0 * Origin checks to allow supporting the Web's origin-based s= ecurity model.
>
> The WebTransport working group will define a protocol or set of
> protocols that fits these requirements. Multiple protocols might be > required to support different usage scenarios, such as multiplexing > with HTTP/3 or networks where UDP is blocked.
>
> The group will pay attention to security issues arising from the above=
> scenarios so as to ensure against creation of new modes of attack, as =
> well as to ensure that security issues addressed in the design of
> Websockets remain addressed in the new work.
>
> To assist in the coordination with W3C, the group will initially
> develop an overview document containing use cases and requirements in =
> order to clarify the goals of the effort. Feedback will also be
> solicited at various points along the way in order to ensure the best =
> possible match between the protocol extensions and the needs of the W3= C
> WebTransport API. The clarity and interoperability of specifications <= br> > will be confirmed via test events and hackathons.
>
> The group will also coordinate with other working groups within the > IETF (e.g. QUIC, HTTPBIS) as appropriate.
>
> Goals and Milestones
>
>=C2=A0 * March 2020 - Adopt a WebTransport Overview draft as a WG work = item
>
>=C2=A0 * March 2020 - Adopt a draft defining a WebTransport protocol as= a WG work item
>
>=C2=A0 * August 2020 - Issue WG last call of the WebTransport Overview = document.
>
>=C2=A0 * November 2020 - Issue WG last call on the first WebTransport <= br> > protocol document
>
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport
>

--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--000000000000037db6059b801551-- From nobody Tue Jan 7 01:47:36 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E7F1200E6 for ; Tue, 7 Jan 2020 01:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 okSAn5EmY_8z for ; Tue, 7 Jan 2020 01:47:31 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 35010120019 for ; Tue, 7 Jan 2020 01:47:31 -0800 (PST) Received: from mue-88-130-61-058.dsl.tropolys.de ([88.130.61.58] helo=emb-w4epjhc9.fritz.box); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iolSR-0006La-6A; Tue, 07 Jan 2020 10:47:27 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Tue, 7 Jan 2020 10:47:26 +0100 Cc: webtransport@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <44C5844F-2EFC-49C5-B0BB-C3F3BBB1A5ED@kuehlewind.net> References: <7674d2cc-2897-4d25-9049-37adf5e7fdf7@www.fastmail.com> To: Bernard Aboba X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578390451;e9db9291; X-HE-SMSGID: 1iolSR-0006La-6A Archived-At: Subject: Re: [Webtransport] WEBTRANS objectives and potential work items X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 09:47:35 -0000 Hi Bernard, Thanks for the update. I have to say I find the term "protocol or suite of protocols=E2=80=9D a = bit vague (which can make the charter very open-ended). I don=E2=80=99t = think that's the intention (given the very concrete and fine = milestones). How about saying something concrete like: "The WebTransport working group will define the WebTransport protocol = which supports a suite of simple client-server communication methods = that include unreliable messages (that might be limited by the path = MTU), reliable messages, and ordered streams of reliable messages. = Initially the working group will work on WebTransport directly over QUIC = or layered over HTTP/3.=E2=80=9D Further if there is already agreement that this should not be an = extension of Websockets or a new version or something, I think that = should be added to the charter together with some some reasoning why = that is not the appropriate approach. If there is still an open question = for discussion how close the WebTransport protocol should be designed to = WebSockets, then I think Websockets should be mention in the charter as = well. Mirja > On 6. Jan 2020, at 19:18, Bernard Aboba = wrote: >=20 > Thanks, Martin.=20 >=20 > I've incorporated your suggestions into a modified PR: > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5 >=20 > On Thu, Jan 2, 2020 at 7:29 PM Martin Thomson = wrote: > Hi Bernard, >=20 > The way this is written it implies that the bulleted list contains = enough detail for requirements, but I don't think that these are in fact = clear enough. On the contrary, I'm finding them to be confusing. >=20 > The underlying protocol in WebSockets provides a bidirectional stream = of finite sized messages, which are in turn finite length sequences of = bytes. By mentioning WebSockets, this text implies that the = requirements for WebSockets apply, but also says that it won't induce = head-of-line blocking. I'm having a hard time reconciling those. I = suspect that what is really in order here is "whatever we decide in the = W3C API makes sense to support, based on what QUIC can provide and = (maybe) what can be emulated with some arrangement of WebSockets and = HTTP where case QUIC isn't available". The later text on building = overview and requirements supports that view, which is what makes the = detail confusing. >=20 > Like WebSockets, we could decide to build a message-based system with = ordering between messages, but how that is implemented could vary = greatly. Even within QUIC, there are many possibilities: >=20 > * We might decide to use a single bidirectional QUIC stream that uses = message delimiters on that streams to distinguish messages. > * We might use unidirectional streams in much the same way, but then = build some mechanism to couple them into pairs as needed. > * We might allow messages to be sent asynchronously without explicit = ordering, then use references to those streams from another stream to = establish an ordering. > * We might use different streams for each message and indicate = ordering in the stream header. >=20 > That's not exhaustive, I'm sure. >=20 > The possibility that a single connection might allow multiplexing of = different "subprotocols" on the same QUIC connection makes some of these = options more difficult or even invalid. I know Victor is prepared to = argue that multiplexing is Hard and likely incompatible with some of the = things he aspires to do eventually, but I don't think we should decide = that question in the charter. I tend to think that there is value in = being able to interact with multiple "resources" on the same connection, = even if I think that the "subprotocol" concept is an abject failure. >=20 > Maybe the right answer is to reduce this to a simpler statement to = replace the paragraphs starting from "These protocols" and ending at = "blocked.":=20 >=20 > > The WebTransport working group will define a protocol or suite of = protocols that support a range of simple communication methods. These = must include unreliable messages (that might be limited to by the path = MTU), reliable messages, and ordered streams of reliable messages. = Attention will be paid to performance of the protocol, in particular = protocol overheads and the potential for head-of-line blocking; its = ability to be deployed and used reliably under different network = conditions; and the ability to integrate protocol use into the Web = security model. >=20 > I don't want to say that this includes a superset of the capabilities = provided by thewebsocketprotocol, because that seems to be an open = question, but I'm not opposed to deciding that early in the process if = that is where we end up. I also don't think that you need to worry = about HTTP/3 multiplexing at this level either. That comes with working = out how to integrate it. >=20 > Cheers, > Martin >=20 > On Fri, Jan 3, 2020, at 12:15, Bernard Aboba wrote: > > During the WEBTRANS BOF there were some questions relating to=20 > > objectives as well as potential work items. > >=20 > > This included some questions relating to "failover transport" (e.g.=20= > > whether new work was needed for this or not). Also, EKR questioned = why=20 > > it was necessary to define two protocols (one for webtransport over=20= > > HTTP/3, and another for direct usage of QUIC streams and datagrams). > >=20 > > I've submitted a PR to clarify the objectives and work items:=20 > > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5 > >=20 > > The modified description and milestones are provided below. Comments = welcome. > >=20 > > = --------------------------------------------------------------------------= --------------------- > > Description of Working Group > >=20 > > The WebTransport working group will define new client-server = protocols=20 > > or protocol extensions in order to support the development of the = W3C=20 > > WebTransport API https://wicg.github.io/web-transport. > >=20 > > These protocols will support: > >=20 > > * Reliable bidirectional and unidirectional communication that=20 > > provides greater efficiency than Websockets (e.g. removal of=20 > > head-of-line blocking). > >=20 > > * Unreliable datagram communication, functionality not available in = Websockets. > >=20 > > * Origin checks to allow supporting the Web's origin-based security = model. > >=20 > > The WebTransport working group will define a protocol or set of=20 > > protocols that fits these requirements. Multiple protocols might be=20= > > required to support different usage scenarios, such as multiplexing=20= > > with HTTP/3 or networks where UDP is blocked. > >=20 > > The group will pay attention to security issues arising from the = above=20 > > scenarios so as to ensure against creation of new modes of attack, = as=20 > > well as to ensure that security issues addressed in the design of=20 > > Websockets remain addressed in the new work. > >=20 > > To assist in the coordination with W3C, the group will initially=20 > > develop an overview document containing use cases and requirements = in=20 > > order to clarify the goals of the effort. Feedback will also be=20 > > solicited at various points along the way in order to ensure the = best=20 > > possible match between the protocol extensions and the needs of the = W3C=20 > > WebTransport API. The clarity and interoperability of specifications=20= > > will be confirmed via test events and hackathons. > >=20 > > The group will also coordinate with other working groups within the=20= > > IETF (e.g. QUIC, HTTPBIS) as appropriate. > >=20 > > Goals and Milestones > >=20 > > * March 2020 - Adopt a WebTransport Overview draft as a WG work = item > >=20 > > * March 2020 - Adopt a draft defining a WebTransport protocol as a = WG work item > >=20 > > * August 2020 - Issue WG last call of the WebTransport Overview = document. > >=20 > > * November 2020 - Issue WG last call on the first WebTransport=20 > > protocol document > >=20 > > --=20 > > Webtransport mailing list > > Webtransport@ietf.org > > https://www.ietf.org/mailman/listinfo/webtransport > > >=20 > --=20 > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --=20 > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport From nobody Wed Jan 8 10:02:03 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178421208C3 for ; Wed, 8 Jan 2020 10:02:03 -0800 (PST) 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 qxdYWSpmrKlk for ; Wed, 8 Jan 2020 10:01:58 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 689161208C7 for ; Wed, 8 Jan 2020 10:01:55 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id a13so4239137ljm.10 for ; Wed, 08 Jan 2020 10:01:55 -0800 (PST) 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=eEzwCOHLmf2AZM+nheKJ2RthZtsiPhGI36vyXFPMCyM=; b=qikJ7RJGVZY5q6t7fn8fIlw6j5eRohVRQEYIXDDf5WBrx4mGv0OYdxWNUHpTOy+Kok CYNnLrjaC1i/N7DzbEWRPg8O9jAspX8Ztop1Goq5NIqn6bLth/g9VawZGKN36JA3keAb jXCr2NaZTMoqdo1bM+motT9erthXAm0G4U/i5oR6AhpB6UdkX/Jj9joMzARfb3pfdfN1 Lp1/jwdgagiru8weeSSxT9+UtUS8Q1eDPVsAO+UdfF0b3rGAZ7dARKxcqTPq/LwouoSv QKY03rWFr+cHWqaO8ef+tW+4Y5SfXv+l9fwb2p+YDzwayK+Zeira0R2avNEm883QHltT I8Sw== 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=eEzwCOHLmf2AZM+nheKJ2RthZtsiPhGI36vyXFPMCyM=; b=rmYOib5jXj5VBorWGfHeH78jpbiXIVJ892vRty74loZAZ3Kr/phOMErPKSdlqIwe1s ajFQ17DZp9wU5cdscurvAyvFnS7EDeVTxE0LyFzqrHomOQEXWOzW9ME4S0iDSuI2HPPT HJ1+/J6pgpyJcu2ccFEmqBBeb9GpEkio6ZCBcmSmFcEQqsXtNDSkkEzfJsIRBT4ovsZr GG4PObMe6sZCYdpdzcvNTQTP8fLfYoqnm3lszTz7HU1ixcqescPX5YWJaE/CEG4adkwv 1kxLglA0F4nKKmfX2kezV+/ZrydhuXVSqTsiv7bGEBywKHFy0s1R+wJ8VL9pABfFLeSd HHbQ== X-Gm-Message-State: APjAAAW/Xm+ex3kYxmPx4RVN1IM+pwfn5tBbKD70KZYLkIv/GfKtIpoo DC3DoQLIYHHpwoIfu/xYZnmOBS3lpw+gyyt20uo= X-Google-Smtp-Source: APXvYqzKDvlnAtB/Bvl8yLwuVMEEolUTZLvW+IWwQFUEEPtBHK89/5Kux94Y6H5i7SUgwfAKCT1+zGpaUWJh3AhjbJs= X-Received: by 2002:a2e:b1c3:: with SMTP id e3mr3645470lja.137.1578506513485; Wed, 08 Jan 2020 10:01:53 -0800 (PST) MIME-Version: 1.0 References: <7674d2cc-2897-4d25-9049-37adf5e7fdf7@www.fastmail.com> <44C5844F-2EFC-49C5-B0BB-C3F3BBB1A5ED@kuehlewind.net> In-Reply-To: <44C5844F-2EFC-49C5-B0BB-C3F3BBB1A5ED@kuehlewind.net> From: David Schinazi Date: Wed, 8 Jan 2020 10:01:41 -0800 Message-ID: To: Mirja Kuehlewind Cc: Bernard Aboba , WebTransport Content-Type: multipart/alternative; boundary="000000000000031514059ba4b02e" Archived-At: Subject: Re: [Webtransport] WEBTRANS objectives and potential work items X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 18:02:03 -0000 --000000000000031514059ba4b02e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, and thanks for the feedback! We've made some changes to the PR to incorporate it: https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5/files Most notably, we've removed all mentions of Websocket to the charter as that was more confusing than helpful. Hi Mirja, we use the term "protocol or suite of protocols=E2=80=9D to indic= ate that the working group might decide to either - build a single protocol that addresses all known use-cases - build multiple protocols that suit different use-cases We don't have consensus between these points yet, and we'll want to discuss this inside the working group, so we're wording the charter in such a way that allows both options to be discussed. We got clear feedback in Singapore that while there is shared interest in the topic, there is not yet consensus on the solutions, so we're intentionally no baking solutions into the charter to let us discuss options within the working group. Thanks, David On Tue, Jan 7, 2020 at 1:47 AM Mirja Kuehlewind wrote= : > Hi Bernard, > > Thanks for the update. > > I have to say I find the term "protocol or suite of protocols=E2=80=9D a = bit vague > (which can make the charter very open-ended). I don=E2=80=99t think that'= s the > intention (given the very concrete and fine milestones). How about saying > something concrete like: > > "The WebTransport working group will define the WebTransport protocol > which supports a suite of simple client-server communication methods that > include unreliable messages (that might be limited by the path MTU), > reliable messages, and ordered streams of reliable messages. Initially th= e > working group will work on WebTransport directly over QUIC or layered ove= r > HTTP/3.=E2=80=9D > > Further if there is already agreement that this should not be an extensio= n > of Websockets or a new version or something, I think that should be added > to the charter together with some some reasoning why that is not the > appropriate approach. If there is still an open question for discussion h= ow > close the WebTransport protocol should be designed to WebSockets, then I > think Websockets should be mention in the charter as well. > > Mirja > > > > On 6. Jan 2020, at 19:18, Bernard Aboba wrote= : > > > > Thanks, Martin. > > > > I've incorporated your suggestions into a modified PR: > > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5 > > > > On Thu, Jan 2, 2020 at 7:29 PM Martin Thomson wrote= : > > Hi Bernard, > > > > The way this is written it implies that the bulleted list contains > enough detail for requirements, but I don't think that these are in fact > clear enough. On the contrary, I'm finding them to be confusing. > > > > The underlying protocol in WebSockets provides a bidirectional stream o= f > finite sized messages, which are in turn finite length sequences of bytes= . > By mentioning WebSockets, this text implies that the requirements for > WebSockets apply, but also says that it won't induce head-of-line > blocking. I'm having a hard time reconciling those. I suspect that what > is really in order here is "whatever we decide in the W3C API makes sense > to support, based on what QUIC can provide and (maybe) what can be emulat= ed > with some arrangement of WebSockets and HTTP where case QUIC isn't > available". The later text on building overview and requirements support= s > that view, which is what makes the detail confusing. > > > > Like WebSockets, we could decide to build a message-based system with > ordering between messages, but how that is implemented could vary greatly= . > Even within QUIC, there are many possibilities: > > > > * We might decide to use a single bidirectional QUIC stream that uses > message delimiters on that streams to distinguish messages. > > * We might use unidirectional streams in much the same way, but then > build some mechanism to couple them into pairs as needed. > > * We might allow messages to be sent asynchronously without explicit > ordering, then use references to those streams from another stream to > establish an ordering. > > * We might use different streams for each message and indicate ordering > in the stream header. > > > > That's not exhaustive, I'm sure. > > > > The possibility that a single connection might allow multiplexing of > different "subprotocols" on the same QUIC connection makes some of these > options more difficult or even invalid. I know Victor is prepared to arg= ue > that multiplexing is Hard and likely incompatible with some of the things > he aspires to do eventually, but I don't think we should decide that > question in the charter. I tend to think that there is value in being ab= le > to interact with multiple "resources" on the same connection, even if I > think that the "subprotocol" concept is an abject failure. > > > > Maybe the right answer is to reduce this to a simpler statement to > replace the paragraphs starting from "These protocols" and ending at > "blocked.": > > > > > The WebTransport working group will define a protocol or suite of > protocols that support a range of simple communication methods. These mu= st > include unreliable messages (that might be limited to by the path MTU), > reliable messages, and ordered streams of reliable messages. Attention > will be paid to performance of the protocol, in particular protocol > overheads and the potential for head-of-line blocking; its ability to be > deployed and used reliably under different network conditions; and the > ability to integrate protocol use into the Web security model. > > > > I don't want to say that this includes a superset of the capabilities > provided by thewebsocketprotocol, because that seems to be an open > question, but I'm not opposed to deciding that early in the process if th= at > is where we end up. I also don't think that you need to worry about HTTP= /3 > multiplexing at this level either. That comes with working out how to > integrate it. > > > > Cheers, > > Martin > > > > On Fri, Jan 3, 2020, at 12:15, Bernard Aboba wrote: > > > During the WEBTRANS BOF there were some questions relating to > > > objectives as well as potential work items. > > > > > > This included some questions relating to "failover transport" (e.g. > > > whether new work was needed for this or not). Also, EKR questioned wh= y > > > it was necessary to define two protocols (one for webtransport over > > > HTTP/3, and another for direct usage of QUIC streams and datagrams). > > > > > > I've submitted a PR to clarify the objectives and work items: > > > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5 > > > > > > The modified description and milestones are provided below. Comments > welcome. > > > > > > > -------------------------------------------------------------------------= ---------------------- > > > Description of Working Group > > > > > > The WebTransport working group will define new client-server protocol= s > > > or protocol extensions in order to support the development of the W3C > > > WebTransport API https://wicg.github.io/web-transport. > > > > > > These protocols will support: > > > > > > * Reliable bidirectional and unidirectional communication that > > > provides greater efficiency than Websockets (e.g. removal of > > > head-of-line blocking). > > > > > > * Unreliable datagram communication, functionality not available in > Websockets. > > > > > > * Origin checks to allow supporting the Web's origin-based security > model. > > > > > > The WebTransport working group will define a protocol or set of > > > protocols that fits these requirements. Multiple protocols might be > > > required to support different usage scenarios, such as multiplexing > > > with HTTP/3 or networks where UDP is blocked. > > > > > > The group will pay attention to security issues arising from the abov= e > > > scenarios so as to ensure against creation of new modes of attack, as > > > well as to ensure that security issues addressed in the design of > > > Websockets remain addressed in the new work. > > > > > > To assist in the coordination with W3C, the group will initially > > > develop an overview document containing use cases and requirements in > > > order to clarify the goals of the effort. Feedback will also be > > > solicited at various points along the way in order to ensure the best > > > possible match between the protocol extensions and the needs of the > W3C > > > WebTransport API. The clarity and interoperability of specifications > > > will be confirmed via test events and hackathons. > > > > > > The group will also coordinate with other working groups within the > > > IETF (e.g. QUIC, HTTPBIS) as appropriate. > > > > > > Goals and Milestones > > > > > > * March 2020 - Adopt a WebTransport Overview draft as a WG work item > > > > > > * March 2020 - Adopt a draft defining a WebTransport protocol as a W= G > work item > > > > > > * August 2020 - Issue WG last call of the WebTransport Overview > document. > > > > > > * November 2020 - Issue WG last call on the first WebTransport > > > protocol document > > > > > > -- > > > Webtransport mailing list > > > Webtransport@ietf.org > > > https://www.ietf.org/mailman/listinfo/webtransport > > > > > > > -- > > Webtransport mailing list > > Webtransport@ietf.org > > https://www.ietf.org/mailman/listinfo/webtransport > > -- > > Webtransport mailing list > > Webtransport@ietf.org > > https://www.ietf.org/mailman/listinfo/webtransport > > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --000000000000031514059ba4b02e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone, and thanks for the feedback!

We've made some changes to the PR to incorporate it:
Most notably, we've removed all mentions of Websocket to the= charter as that was more confusing than helpful.

= Hi Mirja, we use the term=C2=A0"protocol or suite of protocols=E2=80= =9D to indicate that the working group might decide to either
- b= uild a single protocol that addresses all known use-cases
- build= multiple protocols that suit different use-cases
We don't ha= ve consensus between these points yet, and we'll want to discuss this i= nside the working group,
so we're wording the charter in such= a way that allows both options to be discussed. We got clear feedback
in Singapore that while there is shared interest in the topic, there = is not yet consensus on the solutions, so
we're intentionally= =C2=A0no baking solutions into the charter to let us discuss options within= the working group.

Thanks,
David
<= div>

On Tue, Jan 7, 2020 at 1:47 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
Hi Bernard,

Thanks for the update.

I have to say I find the term "protocol or suite of protocols=E2=80=9D= a bit vague (which can make the charter very open-ended). I don=E2=80=99t = think that's the intention (given the very concrete and fine milestones= ). How about saying something concrete like:

"The WebTransport working group will define the WebTransport protocol = which supports a suite of simple client-server communication methods that i= nclude unreliable messages (that might be limited by the path MTU), reliabl= e messages, and ordered streams of reliable messages. Initially the working= group will work on WebTransport directly over QUIC or layered over HTTP/3.= =E2=80=9D

Further if there is already agreement that this should not be an extension = of Websockets or a new version or something, I think that should be added t= o the charter together with some some reasoning why that is not the appropr= iate approach. If there is still an open question for discussion how close = the WebTransport protocol should be designed to WebSockets, then I think We= bsockets should be mention in the charter as well.

Mirja


> On 6. Jan 2020, at 19:18, Bernard Aboba <bernard.aboba@gmail.com> wrote: >
> Thanks, Martin.
>
> I've incorporated your suggestions into a modified PR:
> https://github.com/DavidSchinazi/w= ebtrans-wg-materials/pull/5
>
> On Thu, Jan 2, 2020 at 7:29 PM Martin Thomson <mt@lowentropy.net> wrote:
> Hi Bernard,
>
> The way this is written it implies that the bulleted list contains eno= ugh detail for requirements, but I don't think that these are in fact c= lear enough.=C2=A0 On the contrary, I'm finding them to be confusing. >
> The underlying protocol in WebSockets provides a bidirectional stream = of finite sized messages, which are in turn finite length sequences of byte= s.=C2=A0 By mentioning WebSockets, this text implies that the requirements = for WebSockets apply, but also says that it won't induce head-of-line b= locking.=C2=A0 I'm having a hard time reconciling those.=C2=A0 I suspec= t that what is really in order here is "whatever we decide in the W3C = API makes sense to support, based on what QUIC can provide and (maybe) what= can be emulated with some arrangement of WebSockets and HTTP where case QU= IC isn't available".=C2=A0 The later text on building overview and= requirements supports that view, which is what makes the detail confusing.=
>
> Like WebSockets, we could decide to build a message-based system with = ordering between messages, but how that is implemented could vary greatly.= =C2=A0 Even within QUIC, there are many possibilities:
>
> * We might decide to use a single bidirectional QUIC stream that uses = message delimiters on that streams to distinguish messages.
> * We might use unidirectional streams in much the same way, but then b= uild some mechanism to couple them into pairs as needed.
> * We might allow messages to be sent asynchronously without explicit o= rdering, then use references to those streams from another stream to establ= ish an ordering.
> * We might use different streams for each message and indicate orderin= g in the stream header.
>
> That's not exhaustive, I'm sure.
>
> The possibility that a single connection might allow multiplexing of d= ifferent "subprotocols" on the same QUIC connection makes some of= these options more difficult or even invalid.=C2=A0 I know Victor is prepa= red to argue that multiplexing is Hard and likely incompatible with some of= the things he aspires to do eventually, but I don't think we should de= cide that question in the charter.=C2=A0 I tend to think that there is valu= e in being able to interact with multiple "resources" on the same= connection, even if I think that the "subprotocol" concept is an= abject failure.
>
> Maybe the right answer is to reduce this to a simpler statement to rep= lace the paragraphs starting from "These protocols" and ending at= "blocked.":
>
> > The WebTransport working group will define a protocol or suite of= protocols that support a range of simple communication methods.=C2=A0 Thes= e must include unreliable messages (that might be limited to by the path MT= U), reliable messages, and ordered streams of reliable messages.=C2=A0 Atte= ntion will be paid to performance of the protocol, in particular protocol o= verheads and the potential for head-of-line blocking; its ability to be dep= loyed and used reliably under different network conditions; and the ability= to integrate protocol use into the Web security model.
>
> I don't want to say that this includes a superset of the capabilit= ies provided by thewebsocketprotocol, because that seems to be an open ques= tion, but I'm not opposed to deciding that early in the process if that= is where we end up.=C2=A0 I also don't think that you need to worry ab= out HTTP/3 multiplexing at this level either.=C2=A0 That comes with working= out how to integrate it.
>
> Cheers,
> Martin
>
> On Fri, Jan 3, 2020, at 12:15, Bernard Aboba wrote:
> > During the WEBTRANS BOF there were some questions relating to > > objectives as well as potential work items.
> >
> > This included some questions relating to "failover transport= " (e.g.
> > whether new work was needed for this or not). Also, EKR questione= d why
> > it was necessary to define two protocols (one for webtransport ov= er
> > HTTP/3, and another for direct usage of QUIC streams and datagram= s).
> >
> > I've submitted a PR to clarify the objectives and work items:=
> > https://github.com/DavidSchin= azi/webtrans-wg-materials/pull/5
> >
> > The modified description and milestones are provided below. Comme= nts welcome.
> >
> > -----------------------------------------------------------------= ------------------------------
> > Description of Working Group
> >
> > The WebTransport working group will define new client-server prot= ocols
> > or protocol extensions in order to support the development of the= W3C
> > WebTransport API https://wicg.github.io/web-transport<= /a>.
> >
> > These protocols will support:
> >
> >=C2=A0 * Reliable bidirectional and unidirectional communication t= hat
> > provides greater efficiency than Websockets (e.g. removal of
> > head-of-line blocking).
> >
> >=C2=A0 * Unreliable datagram communication, functionality not avai= lable in Websockets.
> >
> >=C2=A0 * Origin checks to allow supporting the Web's origin-ba= sed security model.
> >
> > The WebTransport working group will define a protocol or set of <= br> > > protocols that fits these requirements. Multiple protocols might = be
> > required to support different usage scenarios, such as multiplexi= ng
> > with HTTP/3 or networks where UDP is blocked.
> >
> > The group will pay attention to security issues arising from the = above
> > scenarios so as to ensure against creation of new modes of attack= , as
> > well as to ensure that security issues addressed in the design of=
> > Websockets remain addressed in the new work.
> >
> > To assist in the coordination with W3C, the group will initially =
> > develop an overview document containing use cases and requirement= s in
> > order to clarify the goals of the effort. Feedback will also be <= br> > > solicited at various points along the way in order to ensure the = best
> > possible match between the protocol extensions and the needs of t= he W3C
> > WebTransport API. The clarity and interoperability of specificati= ons
> > will be confirmed via test events and hackathons.
> >
> > The group will also coordinate with other working groups within t= he
> > IETF (e.g. QUIC, HTTPBIS) as appropriate.
> >
> > Goals and Milestones
> >
> >=C2=A0 * March 2020 - Adopt a WebTransport Overview draft as a WG = work item
> >
> >=C2=A0 * March 2020 - Adopt a draft defining a WebTransport protoc= ol as a WG work item
> >
> >=C2=A0 * August 2020 - Issue WG last call of the WebTransport Over= view document.
> >
> >=C2=A0 * November 2020 - Issue WG last call on the first WebTransp= ort
> > protocol document
> >
> > --
> > Webtransport mailing list
> > Webtra= nsport@ietf.org
> > https://www.ietf.org/mailman/listinfo/we= btransport
> >
>
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport

--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--000000000000031514059ba4b02e-- From nobody Tue Jan 21 16:24:07 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468AA120018 for ; Tue, 21 Jan 2020 16:24:06 -0800 (PST) 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 jw0K81JKc2JE for ; Tue, 21 Jan 2020 16:24:04 -0800 (PST) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 A2A261200A1 for ; Tue, 21 Jan 2020 16:24:04 -0800 (PST) Received: by mail-vs1-xe36.google.com with SMTP id n27so3162391vsa.0 for ; Tue, 21 Jan 2020 16:24:04 -0800 (PST) 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=kVh1cyAIUa7pngcNo5tJPffmX/3PG+DcCpYtCeoGXlk=; b=mBiE7o9+DGSCQpjbPs/j+L4UB3VD0dUb+XWIIV/NtR6LUD+oXhkwFlq/VbCqppv+zM FwdiL7MVOfZEEldjYrHuArlaY4cFzKQXeRyv82hCB2kmygUbTHx8ZbeF7hfaHDl02GrC dv5qa2G8gRUbQWjuziyCTlDnAuVoOwjhDOejqzMJirQLZ9Pi5KE5a6biCqHZMxXdUcrF CSGDgzGs61JHRjhsvLYMfnaby/GfREabUtbrD25WzPo+2P1eGNFmwuy00Ujjq2kV6MN4 I69qTwjHx7DdkWdP57YbU1uE0gRzTY5gZLme0PDq4HxCqd3KRgd4DQkn0cwkmlICxJ6K 91yQ== 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=kVh1cyAIUa7pngcNo5tJPffmX/3PG+DcCpYtCeoGXlk=; b=cZ+NKsK5yKGC73AePgmw9XEOKy55zvG51VOtHsvxsvv4XWmApHrhBM7NpyF3QKOjE9 8VbGpZhjbHE57KBa5Tba2Z0IJDqu114UyRf5/jxigmm4FbhMQnThLOvpYMzfKb8Yunqn SdclODp9TxyJgRhpCmJxIx3fGP8/qSp7DgUTulVjbJnOmCkkv5y03Oo8r+NEr1eV+koc jdWtMcSbFh6k9kkYUnAzoU3otoPfPqmXwBQdJ89k+z847rUvgsvcetSyVD0PCbZJIHLU G3HsbuhqEMf21rZvtTescCbUdqZx0SgSuIXbLBTfUANeZoikG6HBKBU7vAj5Vt8wvq85 GQyg== X-Gm-Message-State: APjAAAWPPpqEHgluUfSTsioeemLu8pXGojGYP7gwl9GopZhBo+myu0FK 8DL54qhzlSGIC0ArUxpZPscEh8ko3UATpVOjdd5BErCT X-Google-Smtp-Source: APXvYqy+x7mQR7LArArmwUGNSIATKuxkulbi1ltsV5gHjUUIaxvNYXcwiVPEn83QXp80OztycX4/eprT4A89YJdojPE= X-Received: by 2002:a67:e443:: with SMTP id n3mr1094277vsm.137.1579652643289; Tue, 21 Jan 2020 16:24:03 -0800 (PST) MIME-Version: 1.0 From: Bernard Aboba Date: Tue, 21 Jan 2020 16:23:52 -0800 Message-ID: To: webtransport@ietf.org Cc: David Schinazi Content-Type: multipart/alternative; boundary="000000000000abff65059caf8ad2" Archived-At: Subject: Re: [Webtransport] WEBTRANS objectives and potential work items X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 00:24:06 -0000 --000000000000abff65059caf8ad2 Content-Type: text/plain; charset="UTF-8" David said: "We've made some changes to the PR to incorporate it: https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5/files Most notably, we've removed all mentions of Websocket to the charter as that was more confusing than helpful." [BA] Thanks. The changes look good. --000000000000abff65059caf8ad2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
David said:=C2=A0

&quo= t;We've made some changes to the PR= to incorporate it:
https://github.com/DavidSchinazi/webtrans-wg-materia=
ls/pull/5/files
Most notably, we've removed all mentions of Websocket to the charter as
that was more confusing than helpful."
[BA] Thanks.  Th=
e changes look good.
--000000000000abff65059caf8ad2-- From nobody Wed Jan 22 00:21:13 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE981200F9 for ; Wed, 22 Jan 2020 00:21:12 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 1HnnlpvuiSqy for ; Wed, 22 Jan 2020 00:21:10 -0800 (PST) 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 77544120164 for ; Wed, 22 Jan 2020 00:21:10 -0800 (PST) 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 00M8HJv9009516; Wed, 22 Jan 2020 00:21:09 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=koP9nPUzYRpIb+gk7SjZ2vgwheSZdZBcixSB9Sva6pY=; b=nK0skDdL+52fBMgsRARvVnOWm+wvxAV4ADvV927HT44htmfu6nnRsvyUj0mkFmNWOeGr JMNJ6ucIJ+/lhVzSftezUgSWQBYh2mzbaH+mGAHxOmO3FLE1sAIIY9wd7vN9MfuZXefQ 8ZW2krdfUmoRwXBEnFTlDW57/lpzEmx081keaIAudtFE+iQ1CbuyFERa+mE3pgHYNAFK EhnBa0n0hpm88/5N75mAuUUGh+UMXHYkqOBfq13fSGvnE1qpMCv1zw5LhyYqzv/xQ0l/ qeJ9RuFD7HYD3yRiUL0hp/F46nqPnrFDtnfL2TVYIf2xGfuJexlQEkat5d4lFyv7Q15J 2w== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2xm1w0v6gr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Jan 2020 00:21:09 -0800 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q4I00BJG1V8KT10@mr2-mtap-s02.rno.apple.com>; Wed, 22 Jan 2020 00:21:08 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q4I003001U9PB00@nwk-mmpp-sz12.apple.com>; Wed, 22 Jan 2020 00:21:08 -0800 (PST) X-Va-A: X-Va-T-CD: fe077d8f1c27092a2d8cfb916a9cf8d8 X-Va-E-CD: 358e1dcced727e315c867d63d4bdd9ce X-Va-R-CD: 3e95f3290d410c3745bc7e110a28f86c X-Va-CD: 0 X-Va-ID: dc8abefa-12b9-463e-bfb0-74f09e8f6fe7 X-V-A: X-V-T-CD: fe077d8f1c27092a2d8cfb916a9cf8d8 X-V-E-CD: 358e1dcced727e315c867d63d4bdd9ce X-V-R-CD: 3e95f3290d410c3745bc7e110a28f86c X-V-CD: 0 X-V-ID: 87f6a910-de48-4f9e-9825-e9e2f3ae0ec4 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-17_05:,, signatures=0 Received: from [17.234.40.12] (unknown [17.234.40.12]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q4I001T01V67T20@nwk-mmpp-sz12.apple.com>; Wed, 22 Jan 2020 00:21:07 -0800 (PST) Sender: ekinnear@apple.com From: Eric Kinnear Message-id: <20C8EB31-4F0E-4BC8-A9C4-206384EFBD33@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_CDBE99F4-1092-4560-B221-5357EAB3DFDF" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Wed, 22 Jan 2020 00:21:06 -0800 In-reply-to: Cc: webtransport@ietf.org, David Schinazi To: Bernard Aboba References: X-Mailer: Apple Mail (2.3608.80.4) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-17_05:, , signatures=0 Archived-At: Subject: Re: [Webtransport] WEBTRANS objectives and potential work items X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 08:21:13 -0000 --Apple-Mail=_CDBE99F4-1092-4560-B221-5357EAB3DFDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Nice, the changes in that PR look like a definite improvement, and the = resulting text is looking pretty good overall. Thanks, Eric > On Jan 21, 2020, at 4:23 PM, Bernard Aboba = wrote: >=20 > David said:=20 >=20 > "We've made some changes to the PR to incorporate it: > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5/files = > Most notably, we've removed all mentions of Websocket to the charter = as > that was more confusing than helpful." > [BA] Thanks. The changes look good.=20 > --=20 > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport --Apple-Mail=_CDBE99F4-1092-4560-B221-5357EAB3DFDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Nice,= the changes in that PR look like a definite improvement, and the = resulting text is looking pretty good overall.

Thanks,
Eric


On Jan 21, 2020, at 4:23 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

David said: 

"We've made some changes to the PR to incorporate = it:
https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5/f=
iles
Most notably, we've removed all mentions of Websocket to the charter as
that was more confusing than helpful."
[BA] Thanks.  The changes look good.
--
Webtransport mailing list
Webtransport@ietf.org
https://www.ietf.org/mailman/listinfo/webtransport

= --Apple-Mail=_CDBE99F4-1092-4560-B221-5357EAB3DFDF-- From nobody Fri Jan 24 15:49:10 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01AA120047 for ; Fri, 24 Jan 2020 15:49:08 -0800 (PST) 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 67XA-lELv_ER for ; Fri, 24 Jan 2020 15:49:06 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 761F112001B for ; Fri, 24 Jan 2020 15:49:05 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id q8so4498697ljj.11 for ; Fri, 24 Jan 2020 15:49:05 -0800 (PST) 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=r372DsN/oVxgPBTWtaah3/ZY0kTYrwha/9+txJ88AK4=; b=ISSSLEdaj0FhxNZKit9FvBqbma+tOv3sq+P6Pmjv2M5t00VdQWnzkSyolTHOjg3Z6N 2cwAsDzgRQI7/6ty4EWvI5VsakUASR4THWM8OXgevWUi/lo0u0DkcDaVrxC9S6ZXjhko 2u20GgaJ4Nmtrzphs1mON3ONrFTKCwmFCnykbggGXeQH9+T+RxHFxjvC2iKpPD1akQAF MGT9vX1ALkAHvTIvCHgE/MkmLFhxprjiiJ11VapJ3iQVDt8jYZOJJD6pyvu3xEAmo/f+ 1FK2Q030Fw/k4rMQXpS0iXXsCJRb8MQ51noiEfxDMqF1h/YRr2lcCugJwlHqhQ87qGyx VLAA== 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=r372DsN/oVxgPBTWtaah3/ZY0kTYrwha/9+txJ88AK4=; b=ocu1cWKyyvYeZj6XmVLqjVag5t6IMTl+sXASrC1VfX34rWUUxrffybvZnWOUo77YPV MqnJh34PFFm2clLssSTOoVqv1Ctd61W9naQng8eAEiLHUpdAd697gZWgsEJV1wkFV0Jl ctmSAsWDgRASEPW4O53obgA8UecmVbmUKXVhIgU4dHRxlnXmJEyCsICdFlpJmDka52wh 8rBQIosEiNURywYrIfU5ObsDfXYXCVCt1XiQmVlHqujqTMnYQdkhkX3rPXC/Wc9RJSmK U7kzDN2/rer1MvPsC6EBvU5e0eY+rUUiPLMjfzEn19vhIVTCD7yw11IxZ3N/nVOJEC42 Rt1A== X-Gm-Message-State: APjAAAV/nin1OhR6Br3ExFqOqp8FmMbMZyKOiUT0rTw22buS/+62gerY +X7JVopzuQuUov44PasDfpkFX/bOKzCXJBNzKUYJPQ== X-Google-Smtp-Source: APXvYqzcS3hyp0658LcxX9j5eQfpfLKZ/t8VuhaseQWuNlnxrskaYH+33j9lc2U0vONfnsWPF4AhjttVc66tpH9f8mo= X-Received: by 2002:a2e:5357:: with SMTP id t23mr3490738ljd.227.1579909743169; Fri, 24 Jan 2020 15:49:03 -0800 (PST) MIME-Version: 1.0 References: <7674d2cc-2897-4d25-9049-37adf5e7fdf7@www.fastmail.com> <44C5844F-2EFC-49C5-B0BB-C3F3BBB1A5ED@kuehlewind.net> In-Reply-To: From: Victor Vasiliev Date: Fri, 24 Jan 2020 18:48:51 -0500 Message-ID: To: David Schinazi Cc: Mirja Kuehlewind , WebTransport , Bernard Aboba Content-Type: multipart/alternative; boundary="000000000000053aab059ceb67b4" Archived-At: Subject: Re: [Webtransport] WEBTRANS objectives and potential work items X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 23:49:09 -0000 --000000000000053aab059ceb67b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've looked at the text of the charter, and it looks great. Left a small comment about wording on the GitHub PR. On Wed, Jan 8, 2020 at 1:02 PM David Schinazi wrote: > Hi everyone, and thanks for the feedback! > > We've made some changes to the PR to incorporate it: > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5/files > Most notably, we've removed all mentions of Websocket to the charter as > that was more confusing than helpful. > > Hi Mirja, we use the term "protocol or suite of protocols=E2=80=9D to ind= icate > that the working group might decide to either > - build a single protocol that addresses all known use-cases > - build multiple protocols that suit different use-cases > We don't have consensus between these points yet, and we'll want to > discuss this inside the working group, > so we're wording the charter in such a way that allows both options to be > discussed. We got clear feedback > in Singapore that while there is shared interest in the topic, there is > not yet consensus on the solutions, so > we're intentionally no baking solutions into the charter to let us discus= s > options within the working group. > > Thanks, > David > > > On Tue, Jan 7, 2020 at 1:47 AM Mirja Kuehlewind > wrote: > >> Hi Bernard, >> >> Thanks for the update. >> >> I have to say I find the term "protocol or suite of protocols=E2=80=9D a= bit >> vague (which can make the charter very open-ended). I don=E2=80=99t thin= k that's >> the intention (given the very concrete and fine milestones). How about >> saying something concrete like: >> >> "The WebTransport working group will define the WebTransport protocol >> which supports a suite of simple client-server communication methods tha= t >> include unreliable messages (that might be limited by the path MTU), >> reliable messages, and ordered streams of reliable messages. Initially t= he >> working group will work on WebTransport directly over QUIC or layered ov= er >> HTTP/3.=E2=80=9D >> >> Further if there is already agreement that this should not be an >> extension of Websockets or a new version or something, I think that shou= ld >> be added to the charter together with some some reasoning why that is no= t >> the appropriate approach. If there is still an open question for discuss= ion >> how close the WebTransport protocol should be designed to WebSockets, th= en >> I think Websockets should be mention in the charter as well. >> >> Mirja >> >> >> > On 6. Jan 2020, at 19:18, Bernard Aboba >> wrote: >> > >> > Thanks, Martin. >> > >> > I've incorporated your suggestions into a modified PR: >> > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5 >> > >> > On Thu, Jan 2, 2020 at 7:29 PM Martin Thomson >> wrote: >> > Hi Bernard, >> > >> > The way this is written it implies that the bulleted list contains >> enough detail for requirements, but I don't think that these are in fact >> clear enough. On the contrary, I'm finding them to be confusing. >> > >> > The underlying protocol in WebSockets provides a bidirectional stream >> of finite sized messages, which are in turn finite length sequences of >> bytes. By mentioning WebSockets, this text implies that the requirement= s >> for WebSockets apply, but also says that it won't induce head-of-line >> blocking. I'm having a hard time reconciling those. I suspect that wha= t >> is really in order here is "whatever we decide in the W3C API makes sens= e >> to support, based on what QUIC can provide and (maybe) what can be emula= ted >> with some arrangement of WebSockets and HTTP where case QUIC isn't >> available". The later text on building overview and requirements suppor= ts >> that view, which is what makes the detail confusing. >> > >> > Like WebSockets, we could decide to build a message-based system with >> ordering between messages, but how that is implemented could vary greatl= y. >> Even within QUIC, there are many possibilities: >> > >> > * We might decide to use a single bidirectional QUIC stream that uses >> message delimiters on that streams to distinguish messages. >> > * We might use unidirectional streams in much the same way, but then >> build some mechanism to couple them into pairs as needed. >> > * We might allow messages to be sent asynchronously without explicit >> ordering, then use references to those streams from another stream to >> establish an ordering. >> > * We might use different streams for each message and indicate orderin= g >> in the stream header. >> > >> > That's not exhaustive, I'm sure. >> > >> > The possibility that a single connection might allow multiplexing of >> different "subprotocols" on the same QUIC connection makes some of these >> options more difficult or even invalid. I know Victor is prepared to ar= gue >> that multiplexing is Hard and likely incompatible with some of the thing= s >> he aspires to do eventually, but I don't think we should decide that >> question in the charter. I tend to think that there is value in being a= ble >> to interact with multiple "resources" on the same connection, even if I >> think that the "subprotocol" concept is an abject failure. >> > >> > Maybe the right answer is to reduce this to a simpler statement to >> replace the paragraphs starting from "These protocols" and ending at >> "blocked.": >> > >> > > The WebTransport working group will define a protocol or suite of >> protocols that support a range of simple communication methods. These m= ust >> include unreliable messages (that might be limited to by the path MTU), >> reliable messages, and ordered streams of reliable messages. Attention >> will be paid to performance of the protocol, in particular protocol >> overheads and the potential for head-of-line blocking; its ability to be >> deployed and used reliably under different network conditions; and the >> ability to integrate protocol use into the Web security model. >> > >> > I don't want to say that this includes a superset of the capabilities >> provided by thewebsocketprotocol, because that seems to be an open >> question, but I'm not opposed to deciding that early in the process if t= hat >> is where we end up. I also don't think that you need to worry about HTT= P/3 >> multiplexing at this level either. That comes with working out how to >> integrate it. >> > >> > Cheers, >> > Martin >> > >> > On Fri, Jan 3, 2020, at 12:15, Bernard Aboba wrote: >> > > During the WEBTRANS BOF there were some questions relating to >> > > objectives as well as potential work items. >> > > >> > > This included some questions relating to "failover transport" (e.g. >> > > whether new work was needed for this or not). Also, EKR questioned >> why >> > > it was necessary to define two protocols (one for webtransport over >> > > HTTP/3, and another for direct usage of QUIC streams and datagrams). >> > > >> > > I've submitted a PR to clarify the objectives and work items: >> > > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5 >> > > >> > > The modified description and milestones are provided below. Comments >> welcome. >> > > >> > > >> ------------------------------------------------------------------------= ----------------------- >> > > Description of Working Group >> > > >> > > The WebTransport working group will define new client-server >> protocols >> > > or protocol extensions in order to support the development of the W3= C >> > > WebTransport API https://wicg.github.io/web-transport. >> > > >> > > These protocols will support: >> > > >> > > * Reliable bidirectional and unidirectional communication that >> > > provides greater efficiency than Websockets (e.g. removal of >> > > head-of-line blocking). >> > > >> > > * Unreliable datagram communication, functionality not available in >> Websockets. >> > > >> > > * Origin checks to allow supporting the Web's origin-based security >> model. >> > > >> > > The WebTransport working group will define a protocol or set of >> > > protocols that fits these requirements. Multiple protocols might be >> > > required to support different usage scenarios, such as multiplexing >> > > with HTTP/3 or networks where UDP is blocked. >> > > >> > > The group will pay attention to security issues arising from the >> above >> > > scenarios so as to ensure against creation of new modes of attack, a= s >> > > well as to ensure that security issues addressed in the design of >> > > Websockets remain addressed in the new work. >> > > >> > > To assist in the coordination with W3C, the group will initially >> > > develop an overview document containing use cases and requirements i= n >> > > order to clarify the goals of the effort. Feedback will also be >> > > solicited at various points along the way in order to ensure the bes= t >> > > possible match between the protocol extensions and the needs of the >> W3C >> > > WebTransport API. The clarity and interoperability of specifications >> > > will be confirmed via test events and hackathons. >> > > >> > > The group will also coordinate with other working groups within the >> > > IETF (e.g. QUIC, HTTPBIS) as appropriate. >> > > >> > > Goals and Milestones >> > > >> > > * March 2020 - Adopt a WebTransport Overview draft as a WG work ite= m >> > > >> > > * March 2020 - Adopt a draft defining a WebTransport protocol as a >> WG work item >> > > >> > > * August 2020 - Issue WG last call of the WebTransport Overview >> document. >> > > >> > > * November 2020 - Issue WG last call on the first WebTransport >> > > protocol document >> > > >> > > -- >> > > Webtransport mailing list >> > > Webtransport@ietf.org >> > > https://www.ietf.org/mailman/listinfo/webtransport >> > > >> > >> > -- >> > Webtransport mailing list >> > Webtransport@ietf.org >> > https://www.ietf.org/mailman/listinfo/webtransport >> > -- >> > Webtransport mailing list >> > Webtransport@ietf.org >> > https://www.ietf.org/mailman/listinfo/webtransport >> >> -- >> Webtransport mailing list >> Webtransport@ietf.org >> https://www.ietf.org/mailman/listinfo/webtransport >> > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --000000000000053aab059ceb67b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've looked at the text of the charter, and it looks g= reat.=C2=A0 Left a small comment about wording on the GitHub PR.
<= br>
On Wed,= Jan 8, 2020 at 1:02 PM David Schinazi <dschinazi.ietf@gmail.com> wrote:
Hi everyone, and thank= s for the feedback!

We've made some changes to the P= R to incorporate it:
Most notab= ly, we've removed all mentions of Websocket to the charter as that was = more confusing than helpful.

Hi Mirja, we use the = term=C2=A0"protocol or suite of protocols=E2=80=9D to indicate that th= e working group might decide to either
- build a single protocol = that addresses all known use-cases
- build multiple protocols tha= t suit different use-cases
We don't have consensus between th= ese points yet, and we'll want to discuss this inside the working group= ,
so we're wording the charter in such a way that allows both= options to be discussed. We got clear feedback
in Singapore that= while there is shared interest in the topic, there is not yet consensus on= the solutions, so
we're intentionally=C2=A0no baking solutio= ns into the charter to let us discuss options within the working group.

Thanks,
David

On Tue, J= an 7, 2020 at 1:47 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
Hi Bernard,

Thanks for the update.

I have to say I find the term "protocol or suite of protocols=E2=80=9D= a bit vague (which can make the charter very open-ended). I don=E2=80=99t = think that's the intention (given the very concrete and fine milestones= ). How about saying something concrete like:

"The WebTransport working group will define the WebTransport protocol = which supports a suite of simple client-server communication methods that i= nclude unreliable messages (that might be limited by the path MTU), reliabl= e messages, and ordered streams of reliable messages. Initially the working= group will work on WebTransport directly over QUIC or layered over HTTP/3.= =E2=80=9D

Further if there is already agreement that this should not be an extension = of Websockets or a new version or something, I think that should be added t= o the charter together with some some reasoning why that is not the appropr= iate approach. If there is still an open question for discussion how close = the WebTransport protocol should be designed to WebSockets, then I think We= bsockets should be mention in the charter as well.

Mirja


> On 6. Jan 2020, at 19:18, Bernard Aboba <bernard.aboba@gmail.com> wrote: >
> Thanks, Martin.
>
> I've incorporated your suggestions into a modified PR:
> https://github.com/DavidSchinazi/w= ebtrans-wg-materials/pull/5
>
> On Thu, Jan 2, 2020 at 7:29 PM Martin Thomson <mt@lowentropy.net> wrote:
> Hi Bernard,
>
> The way this is written it implies that the bulleted list contains eno= ugh detail for requirements, but I don't think that these are in fact c= lear enough.=C2=A0 On the contrary, I'm finding them to be confusing. >
> The underlying protocol in WebSockets provides a bidirectional stream = of finite sized messages, which are in turn finite length sequences of byte= s.=C2=A0 By mentioning WebSockets, this text implies that the requirements = for WebSockets apply, but also says that it won't induce head-of-line b= locking.=C2=A0 I'm having a hard time reconciling those.=C2=A0 I suspec= t that what is really in order here is "whatever we decide in the W3C = API makes sense to support, based on what QUIC can provide and (maybe) what= can be emulated with some arrangement of WebSockets and HTTP where case QU= IC isn't available".=C2=A0 The later text on building overview and= requirements supports that view, which is what makes the detail confusing.=
>
> Like WebSockets, we could decide to build a message-based system with = ordering between messages, but how that is implemented could vary greatly.= =C2=A0 Even within QUIC, there are many possibilities:
>
> * We might decide to use a single bidirectional QUIC stream that uses = message delimiters on that streams to distinguish messages.
> * We might use unidirectional streams in much the same way, but then b= uild some mechanism to couple them into pairs as needed.
> * We might allow messages to be sent asynchronously without explicit o= rdering, then use references to those streams from another stream to establ= ish an ordering.
> * We might use different streams for each message and indicate orderin= g in the stream header.
>
> That's not exhaustive, I'm sure.
>
> The possibility that a single connection might allow multiplexing of d= ifferent "subprotocols" on the same QUIC connection makes some of= these options more difficult or even invalid.=C2=A0 I know Victor is prepa= red to argue that multiplexing is Hard and likely incompatible with some of= the things he aspires to do eventually, but I don't think we should de= cide that question in the charter.=C2=A0 I tend to think that there is valu= e in being able to interact with multiple "resources" on the same= connection, even if I think that the "subprotocol" concept is an= abject failure.
>
> Maybe the right answer is to reduce this to a simpler statement to rep= lace the paragraphs starting from "These protocols" and ending at= "blocked.":
>
> > The WebTransport working group will define a protocol or suite of= protocols that support a range of simple communication methods.=C2=A0 Thes= e must include unreliable messages (that might be limited to by the path MT= U), reliable messages, and ordered streams of reliable messages.=C2=A0 Atte= ntion will be paid to performance of the protocol, in particular protocol o= verheads and the potential for head-of-line blocking; its ability to be dep= loyed and used reliably under different network conditions; and the ability= to integrate protocol use into the Web security model.
>
> I don't want to say that this includes a superset of the capabilit= ies provided by thewebsocketprotocol, because that seems to be an open ques= tion, but I'm not opposed to deciding that early in the process if that= is where we end up.=C2=A0 I also don't think that you need to worry ab= out HTTP/3 multiplexing at this level either.=C2=A0 That comes with working= out how to integrate it.
>
> Cheers,
> Martin
>
> On Fri, Jan 3, 2020, at 12:15, Bernard Aboba wrote:
> > During the WEBTRANS BOF there were some questions relating to > > objectives as well as potential work items.
> >
> > This included some questions relating to "failover transport= " (e.g.
> > whether new work was needed for this or not). Also, EKR questione= d why
> > it was necessary to define two protocols (one for webtransport ov= er
> > HTTP/3, and another for direct usage of QUIC streams and datagram= s).
> >
> > I've submitted a PR to clarify the objectives and work items:=
> > https://github.com/DavidSchin= azi/webtrans-wg-materials/pull/5
> >
> > The modified description and milestones are provided below. Comme= nts welcome.
> >
> > -----------------------------------------------------------------= ------------------------------
> > Description of Working Group
> >
> > The WebTransport working group will define new client-server prot= ocols
> > or protocol extensions in order to support the development of the= W3C
> > WebTransport API https://wicg.github.io/web-transport<= /a>.
> >
> > These protocols will support:
> >
> >=C2=A0 * Reliable bidirectional and unidirectional communication t= hat
> > provides greater efficiency than Websockets (e.g. removal of
> > head-of-line blocking).
> >
> >=C2=A0 * Unreliable datagram communication, functionality not avai= lable in Websockets.
> >
> >=C2=A0 * Origin checks to allow supporting the Web's origin-ba= sed security model.
> >
> > The WebTransport working group will define a protocol or set of <= br> > > protocols that fits these requirements. Multiple protocols might = be
> > required to support different usage scenarios, such as multiplexi= ng
> > with HTTP/3 or networks where UDP is blocked.
> >
> > The group will pay attention to security issues arising from the = above
> > scenarios so as to ensure against creation of new modes of attack= , as
> > well as to ensure that security issues addressed in the design of=
> > Websockets remain addressed in the new work.
> >
> > To assist in the coordination with W3C, the group will initially =
> > develop an overview document containing use cases and requirement= s in
> > order to clarify the goals of the effort. Feedback will also be <= br> > > solicited at various points along the way in order to ensure the = best
> > possible match between the protocol extensions and the needs of t= he W3C
> > WebTransport API. The clarity and interoperability of specificati= ons
> > will be confirmed via test events and hackathons.
> >
> > The group will also coordinate with other working groups within t= he
> > IETF (e.g. QUIC, HTTPBIS) as appropriate.
> >
> > Goals and Milestones
> >
> >=C2=A0 * March 2020 - Adopt a WebTransport Overview draft as a WG = work item
> >
> >=C2=A0 * March 2020 - Adopt a draft defining a WebTransport protoc= ol as a WG work item
> >
> >=C2=A0 * August 2020 - Issue WG last call of the WebTransport Over= view document.
> >
> >=C2=A0 * November 2020 - Issue WG last call on the first WebTransp= ort
> > protocol document
> >
> > --
> > Webtransport mailing list
> > Webtra= nsport@ietf.org
> > https://www.ietf.org/mailman/listinfo/we= btransport
> >
>
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport

--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--000000000000053aab059ceb67b4-- From nobody Fri Jan 24 15:55:30 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D1C12008A for ; Fri, 24 Jan 2020 15:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=KD4nuKcD; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=BwEEBDg0 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 iG-p4vVp0xtp for ; Fri, 24 Jan 2020 15:55:25 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 05491120047 for ; Fri, 24 Jan 2020 15:55:25 -0800 (PST) Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00ONqt2L006734; Fri, 24 Jan 2020 15:55:20 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=9gnQQTkCm9P4I83yTNk08+QE0MhI1CcOFGNN7iJDuF4=; b=KD4nuKcDQc1RRx/iWpaOMj3p/fMYC6rhEiR8mHeGUx/yYxTacWQRAfTo9pF9RMdD30f4 BqfNYITfnl7Xw1akptpjukVahgAkN79z/37inXciHxQ8qU/5HIKhfpncb0NV2qIyydP9 IGwB1OuSmRgfxHTd94QypYnEsXNm5iDikQU= Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 2xr63e19a5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 24 Jan 2020 15:55:20 -0800 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.35.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Fri, 24 Jan 2020 15:55:18 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jpVGuniGAgnwCGaSajFwJDTt01Ac/hx18BC199dlOQqSIKr39jPJQGwptYe1x1hqBe1MrDGLptmWoXX+Df74ESu8S1CG4vO6B/HtC08tjltbowpn56trzvK3eSH4QqSsY3JyETo29SSDLyAhpN/PsGvethK5nHCIc5XhNY7dhpxVYIIwC789rvGZDoDsolJfrZ4TJoDZMYmCTmfalbKIfbxeaH9p3Edg7J1m5K5HqoiO4dofCNlBSTeNBVa7N3vpl0HVfwPcFNiAGw0c6u+vvYZGea5RXtXpobgr2Cf16K7Zqh937Ao6Kp6rmNryfJD39JoX6bzHVVcrKxv5G/9GZQ== 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=9gnQQTkCm9P4I83yTNk08+QE0MhI1CcOFGNN7iJDuF4=; b=gI3wiQdpM8dlFKoXHI5xrOnPLh8BmRakmLusH2VWlK6JWdAYtkUV4s7lRONIL6+/3VDjcsE2hHYzvy1rXFX+BggVD5CQnE4ByDcgtktuZHwd0MbZm9uMcXlseVRHmT89Zt2xpXzCxFm3GnpZP4ietvhlE5pfZWmVb0NSyXi9m2t0UrIxX2m5XQOY9eZjmwZoucwrFqjyaLi9VJjZ3WFtsdMe882A9wqyMJjWrWHFBzhZAYb39aR8KeCxVaiZUQB5WVYy5i7SPbeDZ2mdetUqOSnzI2w31L5hu4iQOMy/OqD7pqL//qOtfu1jOQWK9teNeQvh0F51gvitKCrA31n/4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector2-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9gnQQTkCm9P4I83yTNk08+QE0MhI1CcOFGNN7iJDuF4=; b=BwEEBDg0k/ChDsvb/AV+ca/Ff6TLAn+AStgzhWIKCYzjQxXNbijnxjInarhJ70/IzsxzxNZf+F3FOq/q+c9I40xI+MgQ9fKB80NaHeZDWLbRh4cOhSRpcScY9yR7OWCGN39s6ON08/L3pYQSKK2oHU3I30YVTp53CXl3HhftyA0= Received: from DM5PR15MB1292.namprd15.prod.outlook.com (10.173.209.150) by DM5PR15MB1322.namprd15.prod.outlook.com (10.173.211.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.22; Fri, 24 Jan 2020 23:55:17 +0000 Received: from DM5PR15MB1292.namprd15.prod.outlook.com ([fe80::6c58:a32d:a511:128d]) by DM5PR15MB1292.namprd15.prod.outlook.com ([fe80::6c58:a32d:a511:128d%2]) with mapi id 15.20.2665.017; Fri, 24 Jan 2020 23:55:17 +0000 From: Alan Frindell To: Victor Vasiliev , David Schinazi CC: WebTransport , Mirja Kuehlewind , Bernard Aboba Thread-Topic: [Webtransport] WEBTRANS objectives and potential work items Thread-Index: AQHVwdNnVAmtAU+Y/0yX0EWxVxbbcKfYSCqAgAWvdwCAAQOnAIACHG2AgBmGTID//3uwgA== Date: Fri, 24 Jan 2020 23:55:17 +0000 Message-ID: <61BD8339-8F26-40F2-886D-B4CE402EE111@fb.com> References: <7674d2cc-2897-4d25-9049-37adf5e7fdf7@www.fastmail.com> <44C5844F-2EFC-49C5-B0BB-C3F3BBB1A5ED@kuehlewind.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-originating-ip: [2620:10d:c090:200::54f4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: feef0259-4ac1-421d-2ce6-08d7a128dd2c x-ms-traffictypediagnostic: DM5PR15MB1322: x-microsoft-antispam-prvs: x-fb-source: Internal x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02929ECF07 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(136003)(396003)(39850400004)(189003)(199004)(8936002)(966005)(66556008)(6486002)(66446008)(91956017)(4326008)(66946007)(66476007)(6512007)(316002)(64756008)(110136005)(76116006)(478600001)(54906003)(2906002)(81156014)(81166006)(8676002)(86362001)(53546011)(36756003)(71200400001)(6506007)(186003)(2616005)(33656002)(5660300002)(87944003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR15MB1322; H:DM5PR15MB1292.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VXh/1XVtnKGSsaq2WfckFIFSBQOqqCzk2BCW0B6I6GL2Etjzp7RK/vpLLXBxxTfUOz9tC3Az1DJHlsEqPpSzwCGfv6TJNrZ5zqV39ujP8GuReIAo6NNmOAfxhzDvCZf3waGLHTEkRnp3f3MonSHWozZ8X6Te3DrTGZ+zUVqSXOu51tXnS9bG3nHxslfmlSW36+OSHq6cSqIR8lrMP6Lhcv9DG6276H5Qc1g6F7J3dLkvSkMEm3rUPpvbx+xqkg4KJ7QOAHRiO3f5aqzeX89TCU2fCrImVsJpb/go7rzTXUjh9oaJiPouJ0XYDRVt8zVYteDJEXRcTfTP4Ab6BaLOO2+eheTH6P20lGNha4FH2R9M52FFlP1e9n1ZjYPCjCFZmraAkocnXqDG2DO6QpxP2tscbQ0+fsTonce8s3j9qrZYiy3aWPjaFzsQ4xKiDl5mEf1CyOVV+O8bhgh1UCendepAFVD/udJ7V5JPplVMSQHb4fhdf+2wf1do6h+2Jo3ClLximwGInLaQ1soAwnqG0Q== x-ms-exchange-antispam-messagedata: SeTBIjSKSRecmtDDwyFk1MuGHYYyrYqhpzy2Iwphwe0bhcQj6dM/fNct1x+r6j2WByNFfJIn2N5gPalVXQ3v3BFp9jatBp3PD35h7CoMJXkMNQ+3LGfzOoq9Kqqgz4cH0SLTjPVpnu8Ii286FEUqUiF+p+0BOc+aJ/xNQ94iclA= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_61BD83398F2640F2886DB4CE402EE111fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: feef0259-4ac1-421d-2ce6-08d7a128dd2c X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2020 23:55:17.6458 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: J7SAj8Am4qcpi5nnfrowRlNM906TmGc3YxDMkzzC1p6zkDiOCeltlc14EdQaVCbB X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1322 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-24_08:2020-01-24, 2020-01-24 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 malwarescore=0 adultscore=0 priorityscore=1501 bulkscore=0 phishscore=0 impostorscore=0 spamscore=0 clxscore=1011 suspectscore=0 mlxlogscore=999 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1911200001 definitions=main-2001240193 X-FB-Internal: deliver Archived-At: Subject: Re: [Webtransport] WEBTRANS objectives and potential work items X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 23:55:28 -0000 --_000_61BD83398F2640F2886DB4CE402EE111fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbHNvIGxlZnQgYSBtaW5vciBjb21tZW50IG9uIHRoZSBwcm9wb3NlZCB0ZXh0IGJ1dCBvdGhl cndpc2UgdGhlIGNoYXJ0ZXIgbG9va3MgZ29vZCB0byBtZS4NCg0KLUFsYW4NCg0KRnJvbTogV2Vi dHJhbnNwb3J0IDx3ZWJ0cmFuc3BvcnQtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFZp Y3RvciBWYXNpbGlldiA8dmFzaWx2dj00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRl OiBGcmlkYXksIEphbnVhcnkgMjQsIDIwMjAgYXQgMzo0OSBQTQ0KVG86IERhdmlkIFNjaGluYXpp IDxkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20+DQpDYzogV2ViVHJhbnNwb3J0IDx3ZWJ0cmFuc3Bv cnRAaWV0Zi5vcmc+LCBNaXJqYSBLdWVobGV3aW5kIDxpZXRmQGt1ZWhsZXdpbmQubmV0PiwgQmVy bmFyZCBBYm9iYSA8YmVybmFyZC5hYm9iYUBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW1dlYnRy YW5zcG9ydF0gV0VCVFJBTlMgb2JqZWN0aXZlcyBhbmQgcG90ZW50aWFsIHdvcmsgaXRlbXMNCg0K SSd2ZSBsb29rZWQgYXQgdGhlIHRleHQgb2YgdGhlIGNoYXJ0ZXIsIGFuZCBpdCBsb29rcyBncmVh dC4gIExlZnQgYSBzbWFsbCBjb21tZW50IGFib3V0IHdvcmRpbmcgb24gdGhlIEdpdEh1YiBQUi4N Cg0KT24gV2VkLCBKYW4gOCwgMjAyMCBhdCAxOjAyIFBNIERhdmlkIFNjaGluYXppIDxkc2NoaW5h emkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbT4+IHdyb3Rl Og0KSGkgZXZlcnlvbmUsIGFuZCB0aGFua3MgZm9yIHRoZSBmZWVkYmFjayENCg0KV2UndmUgbWFk ZSBzb21lIGNoYW5nZXMgdG8gdGhlIFBSIHRvIGluY29ycG9yYXRlIGl0Og0KaHR0cHM6Ly9naXRo dWIuY29tL0RhdmlkU2NoaW5hemkvd2VidHJhbnMtd2ctbWF0ZXJpYWxzL3B1bGwvNS9maWxlcw0K TW9zdCBub3RhYmx5LCB3ZSd2ZSByZW1vdmVkIGFsbCBtZW50aW9ucyBvZiBXZWJzb2NrZXQgdG8g dGhlIGNoYXJ0ZXIgYXMgdGhhdCB3YXMgbW9yZSBjb25mdXNpbmcgdGhhbiBoZWxwZnVsLg0KDQpI aSBNaXJqYSwgd2UgdXNlIHRoZSB0ZXJtICJwcm90b2NvbCBvciBzdWl0ZSBvZiBwcm90b2NvbHPi gJ0gdG8gaW5kaWNhdGUgdGhhdCB0aGUgd29ya2luZyBncm91cCBtaWdodCBkZWNpZGUgdG8gZWl0 aGVyDQotIGJ1aWxkIGEgc2luZ2xlIHByb3RvY29sIHRoYXQgYWRkcmVzc2VzIGFsbCBrbm93biB1 c2UtY2FzZXMNCi0gYnVpbGQgbXVsdGlwbGUgcHJvdG9jb2xzIHRoYXQgc3VpdCBkaWZmZXJlbnQg dXNlLWNhc2VzDQpXZSBkb24ndCBoYXZlIGNvbnNlbnN1cyBiZXR3ZWVuIHRoZXNlIHBvaW50cyB5 ZXQsIGFuZCB3ZSdsbCB3YW50IHRvIGRpc2N1c3MgdGhpcyBpbnNpZGUgdGhlIHdvcmtpbmcgZ3Jv dXAsDQpzbyB3ZSdyZSB3b3JkaW5nIHRoZSBjaGFydGVyIGluIHN1Y2ggYSB3YXkgdGhhdCBhbGxv d3MgYm90aCBvcHRpb25zIHRvIGJlIGRpc2N1c3NlZC4gV2UgZ290IGNsZWFyIGZlZWRiYWNrDQpp biBTaW5nYXBvcmUgdGhhdCB3aGlsZSB0aGVyZSBpcyBzaGFyZWQgaW50ZXJlc3QgaW4gdGhlIHRv cGljLCB0aGVyZSBpcyBub3QgeWV0IGNvbnNlbnN1cyBvbiB0aGUgc29sdXRpb25zLCBzbw0Kd2Un cmUgaW50ZW50aW9uYWxseSBubyBiYWtpbmcgc29sdXRpb25zIGludG8gdGhlIGNoYXJ0ZXIgdG8g bGV0IHVzIGRpc2N1c3Mgb3B0aW9ucyB3aXRoaW4gdGhlIHdvcmtpbmcgZ3JvdXAuDQoNClRoYW5r cywNCkRhdmlkDQoNCg0KT24gVHVlLCBKYW4gNywgMjAyMCBhdCAxOjQ3IEFNIE1pcmphIEt1ZWhs ZXdpbmQgPGlldGZAa3VlaGxld2luZC5uZXQ8bWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXQ+PiB3 cm90ZToNCkhpIEJlcm5hcmQsDQoNClRoYW5rcyBmb3IgdGhlIHVwZGF0ZS4NCg0KSSBoYXZlIHRv IHNheSBJIGZpbmQgdGhlIHRlcm0gInByb3RvY29sIG9yIHN1aXRlIG9mIHByb3RvY29sc+KAnSBh IGJpdCB2YWd1ZSAod2hpY2ggY2FuIG1ha2UgdGhlIGNoYXJ0ZXIgdmVyeSBvcGVuLWVuZGVkKS4g SSBkb27igJl0IHRoaW5rIHRoYXQncyB0aGUgaW50ZW50aW9uIChnaXZlbiB0aGUgdmVyeSBjb25j cmV0ZSBhbmQgZmluZSBtaWxlc3RvbmVzKS4gSG93IGFib3V0IHNheWluZyBzb21ldGhpbmcgY29u Y3JldGUgbGlrZToNCg0KIlRoZSBXZWJUcmFuc3BvcnQgd29ya2luZyBncm91cCB3aWxsIGRlZmlu ZSB0aGUgV2ViVHJhbnNwb3J0IHByb3RvY29sIHdoaWNoIHN1cHBvcnRzIGEgc3VpdGUgb2Ygc2lt cGxlIGNsaWVudC1zZXJ2ZXIgY29tbXVuaWNhdGlvbiBtZXRob2RzIHRoYXQgaW5jbHVkZSB1bnJl bGlhYmxlIG1lc3NhZ2VzICh0aGF0IG1pZ2h0IGJlIGxpbWl0ZWQgYnkgdGhlIHBhdGggTVRVKSwg cmVsaWFibGUgbWVzc2FnZXMsIGFuZCBvcmRlcmVkIHN0cmVhbXMgb2YgcmVsaWFibGUgbWVzc2Fn ZXMuIEluaXRpYWxseSB0aGUgd29ya2luZyBncm91cCB3aWxsIHdvcmsgb24gV2ViVHJhbnNwb3J0 IGRpcmVjdGx5IG92ZXIgUVVJQyBvciBsYXllcmVkIG92ZXIgSFRUUC8zLuKAnQ0KDQpGdXJ0aGVy IGlmIHRoZXJlIGlzIGFscmVhZHkgYWdyZWVtZW50IHRoYXQgdGhpcyBzaG91bGQgbm90IGJlIGFu IGV4dGVuc2lvbiBvZiBXZWJzb2NrZXRzIG9yIGEgbmV3IHZlcnNpb24gb3Igc29tZXRoaW5nLCBJ IHRoaW5rIHRoYXQgc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBjaGFydGVyIHRvZ2V0aGVyIHdpdGgg c29tZSBzb21lIHJlYXNvbmluZyB3aHkgdGhhdCBpcyBub3QgdGhlIGFwcHJvcHJpYXRlIGFwcHJv YWNoLiBJZiB0aGVyZSBpcyBzdGlsbCBhbiBvcGVuIHF1ZXN0aW9uIGZvciBkaXNjdXNzaW9uIGhv dyBjbG9zZSB0aGUgV2ViVHJhbnNwb3J0IHByb3RvY29sIHNob3VsZCBiZSBkZXNpZ25lZCB0byBX ZWJTb2NrZXRzLCB0aGVuIEkgdGhpbmsgV2Vic29ja2V0cyBzaG91bGQgYmUgbWVudGlvbiBpbiB0 aGUgY2hhcnRlciBhcyB3ZWxsLg0KDQpNaXJqYQ0KDQoNCj4gT24gNi4gSmFuIDIwMjAsIGF0IDE5 OjE4LCBCZXJuYXJkIEFib2JhIDxiZXJuYXJkLmFib2JhQGdtYWlsLmNvbTxtYWlsdG86YmVybmFy ZC5hYm9iYUBnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4gVGhhbmtzLCBNYXJ0aW4uDQo+DQo+IEkn dmUgaW5jb3Jwb3JhdGVkIHlvdXIgc3VnZ2VzdGlvbnMgaW50byBhIG1vZGlmaWVkIFBSOg0KPiBo dHRwczovL2dpdGh1Yi5jb20vRGF2aWRTY2hpbmF6aS93ZWJ0cmFucy13Zy1tYXRlcmlhbHMvcHVs bC81DQo+DQo+IE9uIFRodSwgSmFuIDIsIDIwMjAgYXQgNzoyOSBQTSBNYXJ0aW4gVGhvbXNvbiA8 bXRAbG93ZW50cm9weS5uZXQ8bWFpbHRvOm10QGxvd2VudHJvcHkubmV0Pj4gd3JvdGU6DQo+IEhp IEJlcm5hcmQsDQo+DQo+IFRoZSB3YXkgdGhpcyBpcyB3cml0dGVuIGl0IGltcGxpZXMgdGhhdCB0 aGUgYnVsbGV0ZWQgbGlzdCBjb250YWlucyBlbm91Z2ggZGV0YWlsIGZvciByZXF1aXJlbWVudHMs IGJ1dCBJIGRvbid0IHRoaW5rIHRoYXQgdGhlc2UgYXJlIGluIGZhY3QgY2xlYXIgZW5vdWdoLiAg T24gdGhlIGNvbnRyYXJ5LCBJJ20gZmluZGluZyB0aGVtIHRvIGJlIGNvbmZ1c2luZy4NCj4NCj4g VGhlIHVuZGVybHlpbmcgcHJvdG9jb2wgaW4gV2ViU29ja2V0cyBwcm92aWRlcyBhIGJpZGlyZWN0 aW9uYWwgc3RyZWFtIG9mIGZpbml0ZSBzaXplZCBtZXNzYWdlcywgd2hpY2ggYXJlIGluIHR1cm4g ZmluaXRlIGxlbmd0aCBzZXF1ZW5jZXMgb2YgYnl0ZXMuICBCeSBtZW50aW9uaW5nIFdlYlNvY2tl dHMsIHRoaXMgdGV4dCBpbXBsaWVzIHRoYXQgdGhlIHJlcXVpcmVtZW50cyBmb3IgV2ViU29ja2V0 cyBhcHBseSwgYnV0IGFsc28gc2F5cyB0aGF0IGl0IHdvbid0IGluZHVjZSBoZWFkLW9mLWxpbmUg YmxvY2tpbmcuICBJJ20gaGF2aW5nIGEgaGFyZCB0aW1lIHJlY29uY2lsaW5nIHRob3NlLiAgSSBz dXNwZWN0IHRoYXQgd2hhdCBpcyByZWFsbHkgaW4gb3JkZXIgaGVyZSBpcyAid2hhdGV2ZXIgd2Ug ZGVjaWRlIGluIHRoZSBXM0MgQVBJIG1ha2VzIHNlbnNlIHRvIHN1cHBvcnQsIGJhc2VkIG9uIHdo YXQgUVVJQyBjYW4gcHJvdmlkZSBhbmQgKG1heWJlKSB3aGF0IGNhbiBiZSBlbXVsYXRlZCB3aXRo IHNvbWUgYXJyYW5nZW1lbnQgb2YgV2ViU29ja2V0cyBhbmQgSFRUUCB3aGVyZSBjYXNlIFFVSUMg aXNuJ3QgYXZhaWxhYmxlIi4gIFRoZSBsYXRlciB0ZXh0IG9uIGJ1aWxkaW5nIG92ZXJ2aWV3IGFu ZCByZXF1aXJlbWVudHMgc3VwcG9ydHMgdGhhdCB2aWV3LCB3aGljaCBpcyB3aGF0IG1ha2VzIHRo ZSBkZXRhaWwgY29uZnVzaW5nLg0KPg0KPiBMaWtlIFdlYlNvY2tldHMsIHdlIGNvdWxkIGRlY2lk ZSB0byBidWlsZCBhIG1lc3NhZ2UtYmFzZWQgc3lzdGVtIHdpdGggb3JkZXJpbmcgYmV0d2VlbiBt ZXNzYWdlcywgYnV0IGhvdyB0aGF0IGlzIGltcGxlbWVudGVkIGNvdWxkIHZhcnkgZ3JlYXRseS4g IEV2ZW4gd2l0aGluIFFVSUMsIHRoZXJlIGFyZSBtYW55IHBvc3NpYmlsaXRpZXM6DQo+DQo+ICog V2UgbWlnaHQgZGVjaWRlIHRvIHVzZSBhIHNpbmdsZSBiaWRpcmVjdGlvbmFsIFFVSUMgc3RyZWFt IHRoYXQgdXNlcyBtZXNzYWdlIGRlbGltaXRlcnMgb24gdGhhdCBzdHJlYW1zIHRvIGRpc3Rpbmd1 aXNoIG1lc3NhZ2VzLg0KPiAqIFdlIG1pZ2h0IHVzZSB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGlu IG11Y2ggdGhlIHNhbWUgd2F5LCBidXQgdGhlbiBidWlsZCBzb21lIG1lY2hhbmlzbSB0byBjb3Vw bGUgdGhlbSBpbnRvIHBhaXJzIGFzIG5lZWRlZC4NCj4gKiBXZSBtaWdodCBhbGxvdyBtZXNzYWdl cyB0byBiZSBzZW50IGFzeW5jaHJvbm91c2x5IHdpdGhvdXQgZXhwbGljaXQgb3JkZXJpbmcsIHRo ZW4gdXNlIHJlZmVyZW5jZXMgdG8gdGhvc2Ugc3RyZWFtcyBmcm9tIGFub3RoZXIgc3RyZWFtIHRv IGVzdGFibGlzaCBhbiBvcmRlcmluZy4NCj4gKiBXZSBtaWdodCB1c2UgZGlmZmVyZW50IHN0cmVh bXMgZm9yIGVhY2ggbWVzc2FnZSBhbmQgaW5kaWNhdGUgb3JkZXJpbmcgaW4gdGhlIHN0cmVhbSBo ZWFkZXIuDQo+DQo+IFRoYXQncyBub3QgZXhoYXVzdGl2ZSwgSSdtIHN1cmUuDQo+DQo+IFRoZSBw b3NzaWJpbGl0eSB0aGF0IGEgc2luZ2xlIGNvbm5lY3Rpb24gbWlnaHQgYWxsb3cgbXVsdGlwbGV4 aW5nIG9mIGRpZmZlcmVudCAic3VicHJvdG9jb2xzIiBvbiB0aGUgc2FtZSBRVUlDIGNvbm5lY3Rp b24gbWFrZXMgc29tZSBvZiB0aGVzZSBvcHRpb25zIG1vcmUgZGlmZmljdWx0IG9yIGV2ZW4gaW52 YWxpZC4gIEkga25vdyBWaWN0b3IgaXMgcHJlcGFyZWQgdG8gYXJndWUgdGhhdCBtdWx0aXBsZXhp bmcgaXMgSGFyZCBhbmQgbGlrZWx5IGluY29tcGF0aWJsZSB3aXRoIHNvbWUgb2YgdGhlIHRoaW5n cyBoZSBhc3BpcmVzIHRvIGRvIGV2ZW50dWFsbHksIGJ1dCBJIGRvbid0IHRoaW5rIHdlIHNob3Vs ZCBkZWNpZGUgdGhhdCBxdWVzdGlvbiBpbiB0aGUgY2hhcnRlci4gIEkgdGVuZCB0byB0aGluayB0 aGF0IHRoZXJlIGlzIHZhbHVlIGluIGJlaW5nIGFibGUgdG8gaW50ZXJhY3Qgd2l0aCBtdWx0aXBs ZSAicmVzb3VyY2VzIiBvbiB0aGUgc2FtZSBjb25uZWN0aW9uLCBldmVuIGlmIEkgdGhpbmsgdGhh dCB0aGUgInN1YnByb3RvY29sIiBjb25jZXB0IGlzIGFuIGFiamVjdCBmYWlsdXJlLg0KPg0KPiBN YXliZSB0aGUgcmlnaHQgYW5zd2VyIGlzIHRvIHJlZHVjZSB0aGlzIHRvIGEgc2ltcGxlciBzdGF0 ZW1lbnQgdG8gcmVwbGFjZSB0aGUgcGFyYWdyYXBocyBzdGFydGluZyBmcm9tICJUaGVzZSBwcm90 b2NvbHMiIGFuZCBlbmRpbmcgYXQgImJsb2NrZWQuIjoNCj4NCj4gPiBUaGUgV2ViVHJhbnNwb3J0 IHdvcmtpbmcgZ3JvdXAgd2lsbCBkZWZpbmUgYSBwcm90b2NvbCBvciBzdWl0ZSBvZiBwcm90b2Nv bHMgdGhhdCBzdXBwb3J0IGEgcmFuZ2Ugb2Ygc2ltcGxlIGNvbW11bmljYXRpb24gbWV0aG9kcy4g IFRoZXNlIG11c3QgaW5jbHVkZSB1bnJlbGlhYmxlIG1lc3NhZ2VzICh0aGF0IG1pZ2h0IGJlIGxp bWl0ZWQgdG8gYnkgdGhlIHBhdGggTVRVKSwgcmVsaWFibGUgbWVzc2FnZXMsIGFuZCBvcmRlcmVk IHN0cmVhbXMgb2YgcmVsaWFibGUgbWVzc2FnZXMuICBBdHRlbnRpb24gd2lsbCBiZSBwYWlkIHRv IHBlcmZvcm1hbmNlIG9mIHRoZSBwcm90b2NvbCwgaW4gcGFydGljdWxhciBwcm90b2NvbCBvdmVy aGVhZHMgYW5kIHRoZSBwb3RlbnRpYWwgZm9yIGhlYWQtb2YtbGluZSBibG9ja2luZzsgaXRzIGFi aWxpdHkgdG8gYmUgZGVwbG95ZWQgYW5kIHVzZWQgcmVsaWFibHkgdW5kZXIgZGlmZmVyZW50IG5l dHdvcmsgY29uZGl0aW9uczsgYW5kIHRoZSBhYmlsaXR5IHRvIGludGVncmF0ZSBwcm90b2NvbCB1 c2UgaW50byB0aGUgV2ViIHNlY3VyaXR5IG1vZGVsLg0KPg0KPiBJIGRvbid0IHdhbnQgdG8gc2F5 IHRoYXQgdGhpcyBpbmNsdWRlcyBhIHN1cGVyc2V0IG9mIHRoZSBjYXBhYmlsaXRpZXMgcHJvdmlk ZWQgYnkgdGhld2Vic29ja2V0cHJvdG9jb2wsIGJlY2F1c2UgdGhhdCBzZWVtcyB0byBiZSBhbiBv cGVuIHF1ZXN0aW9uLCBidXQgSSdtIG5vdCBvcHBvc2VkIHRvIGRlY2lkaW5nIHRoYXQgZWFybHkg aW4gdGhlIHByb2Nlc3MgaWYgdGhhdCBpcyB3aGVyZSB3ZSBlbmQgdXAuICBJIGFsc28gZG9uJ3Qg dGhpbmsgdGhhdCB5b3UgbmVlZCB0byB3b3JyeSBhYm91dCBIVFRQLzMgbXVsdGlwbGV4aW5nIGF0 IHRoaXMgbGV2ZWwgZWl0aGVyLiAgVGhhdCBjb21lcyB3aXRoIHdvcmtpbmcgb3V0IGhvdyB0byBp bnRlZ3JhdGUgaXQuDQo+DQo+IENoZWVycywNCj4gTWFydGluDQo+DQo+IE9uIEZyaSwgSmFuIDMs IDIwMjAsIGF0IDEyOjE1LCBCZXJuYXJkIEFib2JhIHdyb3RlOg0KPiA+IER1cmluZyB0aGUgV0VC VFJBTlMgQk9GIHRoZXJlIHdlcmUgc29tZSBxdWVzdGlvbnMgcmVsYXRpbmcgdG8NCj4gPiBvYmpl Y3RpdmVzIGFzIHdlbGwgYXMgcG90ZW50aWFsIHdvcmsgaXRlbXMuDQo+ID4NCj4gPiBUaGlzIGlu Y2x1ZGVkIHNvbWUgcXVlc3Rpb25zIHJlbGF0aW5nIHRvICJmYWlsb3ZlciB0cmFuc3BvcnQiIChl LmcuDQo+ID4gd2hldGhlciBuZXcgd29yayB3YXMgbmVlZGVkIGZvciB0aGlzIG9yIG5vdCkuIEFs c28sIEVLUiBxdWVzdGlvbmVkIHdoeQ0KPiA+IGl0IHdhcyBuZWNlc3NhcnkgdG8gZGVmaW5lIHR3 byBwcm90b2NvbHMgKG9uZSBmb3Igd2VidHJhbnNwb3J0IG92ZXINCj4gPiBIVFRQLzMsIGFuZCBh bm90aGVyIGZvciBkaXJlY3QgdXNhZ2Ugb2YgUVVJQyBzdHJlYW1zIGFuZCBkYXRhZ3JhbXMpLg0K PiA+DQo+ID4gSSd2ZSBzdWJtaXR0ZWQgYSBQUiB0byBjbGFyaWZ5IHRoZSBvYmplY3RpdmVzIGFu ZCB3b3JrIGl0ZW1zOg0KPiA+IGh0dHBzOi8vZ2l0aHViLmNvbS9EYXZpZFNjaGluYXppL3dlYnRy YW5zLXdnLW1hdGVyaWFscy9wdWxsLzUNCj4gPg0KPiA+IFRoZSBtb2RpZmllZCBkZXNjcmlwdGlv biBhbmQgbWlsZXN0b25lcyBhcmUgcHJvdmlkZWQgYmVsb3cuIENvbW1lbnRzIHdlbGNvbWUuDQo+ ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IERlc2Ny aXB0aW9uIG9mIFdvcmtpbmcgR3JvdXANCj4gPg0KPiA+IFRoZSBXZWJUcmFuc3BvcnQgd29ya2lu ZyBncm91cCB3aWxsIGRlZmluZSBuZXcgY2xpZW50LXNlcnZlciBwcm90b2NvbHMNCj4gPiBvciBw cm90b2NvbCBleHRlbnNpb25zIGluIG9yZGVyIHRvIHN1cHBvcnQgdGhlIGRldmVsb3BtZW50IG9m IHRoZSBXM0MNCj4gPiBXZWJUcmFuc3BvcnQgQVBJIGh0dHBzOi8vd2ljZy5naXRodWIuaW8vd2Vi LXRyYW5zcG9ydDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3dpY2cuZ2l0aHViLmlvX3dlYi0yRHRyYW5zcG9ydCZkPUR3TUZhUSZjPTVWRDBSVHRO bFRoM3ljZDQxYjNNVXcmcj0xSVRLc1pBZURhdzY1ZXlRY2RWR2N3Jm09OTlweEFqUnNwbHQzVWlJ U2R2bUt0MDhqbm42TkdXZVVSd2R0eExaT0l1byZzPUR1TjdheTVIU05RY2lxZGZjcTdaTjFDUnNK N2diN1Vvd0FOZXFMWFhfUkUmZT0+Lg0KPiA+DQo+ID4gVGhlc2UgcHJvdG9jb2xzIHdpbGwgc3Vw cG9ydDoNCj4gPg0KPiA+ICAqIFJlbGlhYmxlIGJpZGlyZWN0aW9uYWwgYW5kIHVuaWRpcmVjdGlv bmFsIGNvbW11bmljYXRpb24gdGhhdA0KPiA+IHByb3ZpZGVzIGdyZWF0ZXIgZWZmaWNpZW5jeSB0 aGFuIFdlYnNvY2tldHMgKGUuZy4gcmVtb3ZhbCBvZg0KPiA+IGhlYWQtb2YtbGluZSBibG9ja2lu ZykuDQo+ID4NCj4gPiAgKiBVbnJlbGlhYmxlIGRhdGFncmFtIGNvbW11bmljYXRpb24sIGZ1bmN0 aW9uYWxpdHkgbm90IGF2YWlsYWJsZSBpbiBXZWJzb2NrZXRzLg0KPiA+DQo+ID4gICogT3JpZ2lu IGNoZWNrcyB0byBhbGxvdyBzdXBwb3J0aW5nIHRoZSBXZWIncyBvcmlnaW4tYmFzZWQgc2VjdXJp dHkgbW9kZWwuDQo+ID4NCj4gPiBUaGUgV2ViVHJhbnNwb3J0IHdvcmtpbmcgZ3JvdXAgd2lsbCBk ZWZpbmUgYSBwcm90b2NvbCBvciBzZXQgb2YNCj4gPiBwcm90b2NvbHMgdGhhdCBmaXRzIHRoZXNl IHJlcXVpcmVtZW50cy4gTXVsdGlwbGUgcHJvdG9jb2xzIG1pZ2h0IGJlDQo+ID4gcmVxdWlyZWQg dG8gc3VwcG9ydCBkaWZmZXJlbnQgdXNhZ2Ugc2NlbmFyaW9zLCBzdWNoIGFzIG11bHRpcGxleGlu Zw0KPiA+IHdpdGggSFRUUC8zIG9yIG5ldHdvcmtzIHdoZXJlIFVEUCBpcyBibG9ja2VkLg0KPiA+ DQo+ID4gVGhlIGdyb3VwIHdpbGwgcGF5IGF0dGVudGlvbiB0byBzZWN1cml0eSBpc3N1ZXMgYXJp c2luZyBmcm9tIHRoZSBhYm92ZQ0KPiA+IHNjZW5hcmlvcyBzbyBhcyB0byBlbnN1cmUgYWdhaW5z dCBjcmVhdGlvbiBvZiBuZXcgbW9kZXMgb2YgYXR0YWNrLCBhcw0KPiA+IHdlbGwgYXMgdG8gZW5z dXJlIHRoYXQgc2VjdXJpdHkgaXNzdWVzIGFkZHJlc3NlZCBpbiB0aGUgZGVzaWduIG9mDQo+ID4g V2Vic29ja2V0cyByZW1haW4gYWRkcmVzc2VkIGluIHRoZSBuZXcgd29yay4NCj4gPg0KPiA+IFRv IGFzc2lzdCBpbiB0aGUgY29vcmRpbmF0aW9uIHdpdGggVzNDLCB0aGUgZ3JvdXAgd2lsbCBpbml0 aWFsbHkNCj4gPiBkZXZlbG9wIGFuIG92ZXJ2aWV3IGRvY3VtZW50IGNvbnRhaW5pbmcgdXNlIGNh c2VzIGFuZCByZXF1aXJlbWVudHMgaW4NCj4gPiBvcmRlciB0byBjbGFyaWZ5IHRoZSBnb2FscyBv ZiB0aGUgZWZmb3J0LiBGZWVkYmFjayB3aWxsIGFsc28gYmUNCj4gPiBzb2xpY2l0ZWQgYXQgdmFy aW91cyBwb2ludHMgYWxvbmcgdGhlIHdheSBpbiBvcmRlciB0byBlbnN1cmUgdGhlIGJlc3QNCj4g PiBwb3NzaWJsZSBtYXRjaCBiZXR3ZWVuIHRoZSBwcm90b2NvbCBleHRlbnNpb25zIGFuZCB0aGUg bmVlZHMgb2YgdGhlIFczQw0KPiA+IFdlYlRyYW5zcG9ydCBBUEkuIFRoZSBjbGFyaXR5IGFuZCBp bnRlcm9wZXJhYmlsaXR5IG9mIHNwZWNpZmljYXRpb25zDQo+ID4gd2lsbCBiZSBjb25maXJtZWQg dmlhIHRlc3QgZXZlbnRzIGFuZCBoYWNrYXRob25zLg0KPiA+DQo+ID4gVGhlIGdyb3VwIHdpbGwg YWxzbyBjb29yZGluYXRlIHdpdGggb3RoZXIgd29ya2luZyBncm91cHMgd2l0aGluIHRoZQ0KPiA+ IElFVEYgKGUuZy4gUVVJQywgSFRUUEJJUykgYXMgYXBwcm9wcmlhdGUuDQo+ID4NCj4gPiBHb2Fs cyBhbmQgTWlsZXN0b25lcw0KPiA+DQo+ID4gICogTWFyY2ggMjAyMCAtIEFkb3B0IGEgV2ViVHJh bnNwb3J0IE92ZXJ2aWV3IGRyYWZ0IGFzIGEgV0cgd29yayBpdGVtDQo+ID4NCj4gPiAgKiBNYXJj aCAyMDIwIC0gQWRvcHQgYSBkcmFmdCBkZWZpbmluZyBhIFdlYlRyYW5zcG9ydCBwcm90b2NvbCBh cyBhIFdHIHdvcmsgaXRlbQ0KPiA+DQo+ID4gICogQXVndXN0IDIwMjAgLSBJc3N1ZSBXRyBsYXN0 IGNhbGwgb2YgdGhlIFdlYlRyYW5zcG9ydCBPdmVydmlldyBkb2N1bWVudC4NCj4gPg0KPiA+ICAq IE5vdmVtYmVyIDIwMjAgLSBJc3N1ZSBXRyBsYXN0IGNhbGwgb24gdGhlIGZpcnN0IFdlYlRyYW5z cG9ydA0KPiA+IHByb3RvY29sIGRvY3VtZW50DQo+ID4NCj4gPiAtLQ0KPiA+IFdlYnRyYW5zcG9y dCBtYWlsaW5nIGxpc3QNCj4gPiBXZWJ0cmFuc3BvcnRAaWV0Zi5vcmc8bWFpbHRvOldlYnRyYW5z cG9ydEBpZXRmLm9yZz4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3dlYnRyYW5zcG9ydDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3dlYnRyYW5zcG9ydCZkPUR3 TUZhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj0xSVRLc1pBZURhdzY1ZXlRY2RWR2N3Jm09 OTlweEFqUnNwbHQzVWlJU2R2bUt0MDhqbm42TkdXZVVSd2R0eExaT0l1byZzPXdCUmhKY18tZXJ1 c2I0NW1hM2xPRy1kU25BLVRLT1FfcUxBT2FBODBIUXMmZT0+DQo+ID4NCj4NCj4gLS0NCj4gV2Vi dHJhbnNwb3J0IG1haWxpbmcgbGlzdA0KPiBXZWJ0cmFuc3BvcnRAaWV0Zi5vcmc8bWFpbHRvOldl YnRyYW5zcG9ydEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby93ZWJ0cmFuc3BvcnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb193ZWJ0cmFuc3BvcnQm ZD1Ed01GYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9MUlUS3NaQWVEYXc2NWV5UWNkVkdj dyZtPTk5cHhBalJzcGx0M1VpSVNkdm1LdDA4am5uNk5HV2VVUndkdHhMWk9JdW8mcz13QlJoSmNf LWVydXNiNDVtYTNsT0ctZFNuQS1US09RX3FMQU9hQTgwSFFzJmU9Pg0KPiAtLQ0KPiBXZWJ0cmFu c3BvcnQgbWFpbGluZyBsaXN0DQo+IFdlYnRyYW5zcG9ydEBpZXRmLm9yZzxtYWlsdG86V2VidHJh bnNwb3J0QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3dlYnRyYW5zcG9ydDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3dlYnRyYW5zcG9ydCZkPUR3 TUZhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj0xSVRLc1pBZURhdzY1ZXlRY2RWR2N3Jm09 OTlweEFqUnNwbHQzVWlJU2R2bUt0MDhqbm42TkdXZVVSd2R0eExaT0l1byZzPXdCUmhKY18tZXJ1 c2I0NW1hM2xPRy1kU25BLVRLT1FfcUxBT2FBODBIUXMmZT0+DQoNCi0tDQpXZWJ0cmFuc3BvcnQg bWFpbGluZyBsaXN0DQpXZWJ0cmFuc3BvcnRAaWV0Zi5vcmc8bWFpbHRvOldlYnRyYW5zcG9ydEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2VidHJhbnNw b3J0PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fd2VidHJhbnNwb3J0JmQ9RHdNRmFRJmM9NVZE MFJUdE5sVGgzeWNkNDFiM01VdyZyPTFJVEtzWkFlRGF3NjVleVFjZFZHY3cmbT05OXB4QWpSc3Bs dDNVaUlTZHZtS3QwOGpubjZOR1dlVVJ3ZHR4TFpPSXVvJnM9d0JSaEpjXy1lcnVzYjQ1bWEzbE9H LWRTbkEtVEtPUV9xTEFPYUE4MEhRcyZlPT4NCi0tDQpXZWJ0cmFuc3BvcnQgbWFpbGluZyBsaXN0 DQpXZWJ0cmFuc3BvcnRAaWV0Zi5vcmc8bWFpbHRvOldlYnRyYW5zcG9ydEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2VidHJhbnNwb3J0PGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9fd2VidHJhbnNwb3J0JmQ9RHdNRmFRJmM9NVZEMFJUdE5sVGgzeWNk NDFiM01VdyZyPTFJVEtzWkFlRGF3NjVleVFjZFZHY3cmbT05OXB4QWpSc3BsdDNVaUlTZHZtS3Qw OGpubjZOR1dlVVJ3ZHR4TFpPSXVvJnM9d0JSaEpjXy1lcnVzYjQ1bWEzbE9HLWRTbkEtVEtPUV9x TEFPYUE4MEhRcyZlPT4NCg== --_000_61BD83398F2640F2886DB4CE402EE111fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBhbHNvIGxlZnQgYSBtaW5vciBjb21tZW50IG9uIHRoZSBwcm9wb3Nl ZCB0ZXh0IGJ1dCBvdGhlcndpc2UgdGhlIGNoYXJ0ZXIgbG9va3MgZ29vZCB0byBtZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LUFsYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPldlYnRyYW5zcG9ydCAmbHQ7d2VidHJhbnNwb3J0LWJvdW5jZXNAaWV0Zi5vcmcm Z3Q7IG9uIGJlaGFsZiBvZiBWaWN0b3IgVmFzaWxpZXYgJmx0O3Zhc2lsdnY9NDBnb29nbGUuY29t QGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEphbnVhcnkgMjQs IDIwMjAgYXQgMzo0OSBQTTxicj4NCjxiPlRvOiA8L2I+RGF2aWQgU2NoaW5hemkgJmx0O2RzY2hp bmF6aS5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPldlYlRyYW5zcG9ydCAmbHQ7 d2VidHJhbnNwb3J0QGlldGYub3JnJmd0OywgTWlyamEgS3VlaGxld2luZCAmbHQ7aWV0ZkBrdWVo bGV3aW5kLm5ldCZndDssIEJlcm5hcmQgQWJvYmEgJmx0O2Jlcm5hcmQuYWJvYmFAZ21haWwuY29t Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1dlYnRyYW5zcG9ydF0gV0VCVFJBTlMgb2Jq ZWN0aXZlcyBhbmQgcG90ZW50aWFsIHdvcmsgaXRlbXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkndmUgbG9va2VkIGF0IHRoZSB0 ZXh0IG9mIHRoZSBjaGFydGVyLCBhbmQgaXQgbG9va3MgZ3JlYXQuJm5ic3A7IExlZnQgYSBzbWFs bCBjb21tZW50IGFib3V0IHdvcmRpbmcgb24gdGhlIEdpdEh1YiBQUi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSmFuIDgsIDIwMjAgYXQgMTow MiBQTSBEYXZpZCBTY2hpbmF6aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRzY2hpbmF6aS5pZXRmQGdt YWlsLmNvbSI+ZHNjaGluYXppLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGkgZXZlcnlvbmUsIGFuZCB0aGFua3MgZm9yIHRoZSBmZWVkYmFjayEgPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSd2ZSBtYWRlIHNvbWUgY2hhbmdlcyB0 byB0aGUgUFIgdG8gaW5jb3Jwb3JhdGUgaXQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vRGF2aWRT Y2hpbmF6aS93ZWJ0cmFucy13Zy1tYXRlcmlhbHMvcHVsbC81L2ZpbGVzIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9naXRodWIuY29tL0RhdmlkU2NoaW5hemkvd2VidHJhbnMtd2ctbWF0ZXJpYWxz L3B1bGwvNS9maWxlczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk1vc3Qgbm90YWJseSwgd2UndmUgcmVtb3ZlZCBhbGwgbWVudGlvbnMgb2Yg V2Vic29ja2V0IHRvIHRoZSBjaGFydGVyIGFzIHRoYXQgd2FzIG1vcmUgY29uZnVzaW5nIHRoYW4g aGVscGZ1bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGkgTWlyamEsIHdlIHVzZSB0aGUgdGVybSZuYnNwOyZxdW90O3Byb3RvY29sIG9yIHN1 aXRlIG9mIHByb3RvY29sc+KAnSB0byBpbmRpY2F0ZSB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIG1p Z2h0IGRlY2lkZSB0byBlaXRoZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi0gYnVpbGQgYSBzaW5nbGUgcHJvdG9jb2wgdGhhdCBhZGRyZXNzZXMg YWxsIGtub3duIHVzZS1jYXNlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LSBidWlsZCBtdWx0aXBsZSBwcm90b2NvbHMgdGhhdCBzdWl0IGRpZmZl cmVudCB1c2UtY2FzZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldlIGRvbid0IGhhdmUgY29uc2Vuc3VzIGJldHdlZW4gdGhlc2UgcG9pbnRzIHll dCwgYW5kIHdlJ2xsIHdhbnQgdG8gZGlzY3VzcyB0aGlzIGluc2lkZSB0aGUgd29ya2luZyBncm91 cCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNv IHdlJ3JlIHdvcmRpbmcgdGhlIGNoYXJ0ZXIgaW4gc3VjaCBhIHdheSB0aGF0IGFsbG93cyBib3Ro IG9wdGlvbnMgdG8gYmUgZGlzY3Vzc2VkLiBXZSBnb3QgY2xlYXIgZmVlZGJhY2s8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmluIFNpbmdhcG9yZSB0 aGF0IHdoaWxlIHRoZXJlIGlzIHNoYXJlZCBpbnRlcmVzdCBpbiB0aGUgdG9waWMsIHRoZXJlIGlz IG5vdCB5ZXQgY29uc2Vuc3VzIG9uIHRoZSBzb2x1dGlvbnMsIHNvPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53ZSdyZSBpbnRlbnRpb25hbGx5Jm5i c3A7bm8gYmFraW5nIHNvbHV0aW9ucyBpbnRvIHRoZSBjaGFydGVyIHRvIGxldCB1cyBkaXNjdXNz IG9wdGlvbnMgd2l0aGluIHRoZSB3b3JraW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZpZDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSmFuIDcsIDIw MjAgYXQgMTo0NyBBTSBNaXJqYSBLdWVobGV3aW5kICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBr dWVobGV3aW5kLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAa3VlaGxld2luZC5uZXQ8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhpIEJlcm5hcmQsPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB0aGUgdXBkYXRlLjxi cj4NCjxicj4NCkkgaGF2ZSB0byBzYXkgSSBmaW5kIHRoZSB0ZXJtICZxdW90O3Byb3RvY29sIG9y IHN1aXRlIG9mIHByb3RvY29sc+KAnSBhIGJpdCB2YWd1ZSAod2hpY2ggY2FuIG1ha2UgdGhlIGNo YXJ0ZXIgdmVyeSBvcGVuLWVuZGVkKS4gSSBkb27igJl0IHRoaW5rIHRoYXQncyB0aGUgaW50ZW50 aW9uIChnaXZlbiB0aGUgdmVyeSBjb25jcmV0ZSBhbmQgZmluZSBtaWxlc3RvbmVzKS4gSG93IGFi b3V0IHNheWluZyBzb21ldGhpbmcgY29uY3JldGUgbGlrZTo8YnI+DQo8YnI+DQomcXVvdDtUaGUg V2ViVHJhbnNwb3J0IHdvcmtpbmcgZ3JvdXAgd2lsbCBkZWZpbmUgdGhlIFdlYlRyYW5zcG9ydCBw cm90b2NvbCB3aGljaCBzdXBwb3J0cyBhIHN1aXRlIG9mIHNpbXBsZSBjbGllbnQtc2VydmVyIGNv bW11bmljYXRpb24gbWV0aG9kcyB0aGF0IGluY2x1ZGUgdW5yZWxpYWJsZSBtZXNzYWdlcyAodGhh dCBtaWdodCBiZSBsaW1pdGVkIGJ5IHRoZSBwYXRoIE1UVSksIHJlbGlhYmxlIG1lc3NhZ2VzLCBh bmQgb3JkZXJlZCBzdHJlYW1zIG9mIHJlbGlhYmxlDQogbWVzc2FnZXMuIEluaXRpYWxseSB0aGUg d29ya2luZyBncm91cCB3aWxsIHdvcmsgb24gV2ViVHJhbnNwb3J0IGRpcmVjdGx5IG92ZXIgUVVJ QyBvciBsYXllcmVkIG92ZXIgSFRUUC8zLuKAnTxicj4NCjxicj4NCkZ1cnRoZXIgaWYgdGhlcmUg aXMgYWxyZWFkeSBhZ3JlZW1lbnQgdGhhdCB0aGlzIHNob3VsZCBub3QgYmUgYW4gZXh0ZW5zaW9u IG9mIFdlYnNvY2tldHMgb3IgYSBuZXcgdmVyc2lvbiBvciBzb21ldGhpbmcsIEkgdGhpbmsgdGhh dCBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGNoYXJ0ZXIgdG9nZXRoZXIgd2l0aCBzb21lIHNvbWUg cmVhc29uaW5nIHdoeSB0aGF0IGlzIG5vdCB0aGUgYXBwcm9wcmlhdGUgYXBwcm9hY2guIElmIHRo ZXJlIGlzIHN0aWxsDQogYW4gb3BlbiBxdWVzdGlvbiBmb3IgZGlzY3Vzc2lvbiBob3cgY2xvc2Ug dGhlIFdlYlRyYW5zcG9ydCBwcm90b2NvbCBzaG91bGQgYmUgZGVzaWduZWQgdG8gV2ViU29ja2V0 cywgdGhlbiBJIHRoaW5rIFdlYnNvY2tldHMgc2hvdWxkIGJlIG1lbnRpb24gaW4gdGhlIGNoYXJ0 ZXIgYXMgd2VsbC48YnI+DQo8YnI+DQpNaXJqYTxicj4NCjxicj4NCjxicj4NCiZndDsgT24gNi4g SmFuIDIwMjAsIGF0IDE5OjE4LCBCZXJuYXJkIEFib2JhICZsdDs8YSBocmVmPSJtYWlsdG86YmVy bmFyZC5hYm9iYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5iZXJuYXJkLmFib2JhQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFua3MsIE1hcnRpbi4g PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkndmUgaW5jb3Jwb3JhdGVkIHlvdXIgc3VnZ2VzdGlvbnMg aW50byBhIG1vZGlmaWVkIFBSOjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29t L0RhdmlkU2NoaW5hemkvd2VidHJhbnMtd2ctbWF0ZXJpYWxzL3B1bGwvNSIgdGFyZ2V0PSJfYmxh bmsiPg0KaHR0cHM6Ly9naXRodWIuY29tL0RhdmlkU2NoaW5hemkvd2VidHJhbnMtd2ctbWF0ZXJp YWxzL3B1bGwvNTwvYT48YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gVGh1LCBKYW4gMiwgMjAyMCBh dCA3OjI5IFBNIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bXRAbG93ZW50cm9w eS5uZXQiIHRhcmdldD0iX2JsYW5rIj5tdEBsb3dlbnRyb3B5Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxi cj4NCiZndDsgSGkgQmVybmFyZCw8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIHdheSB0aGlzIGlz IHdyaXR0ZW4gaXQgaW1wbGllcyB0aGF0IHRoZSBidWxsZXRlZCBsaXN0IGNvbnRhaW5zIGVub3Vn aCBkZXRhaWwgZm9yIHJlcXVpcmVtZW50cywgYnV0IEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGVzZSBh cmUgaW4gZmFjdCBjbGVhciBlbm91Z2guJm5ic3A7IE9uIHRoZSBjb250cmFyeSwgSSdtIGZpbmRp bmcgdGhlbSB0byBiZSBjb25mdXNpbmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSB1bmRlcmx5 aW5nIHByb3RvY29sIGluIFdlYlNvY2tldHMgcHJvdmlkZXMgYSBiaWRpcmVjdGlvbmFsIHN0cmVh bSBvZiBmaW5pdGUgc2l6ZWQgbWVzc2FnZXMsIHdoaWNoIGFyZSBpbiB0dXJuIGZpbml0ZSBsZW5n dGggc2VxdWVuY2VzIG9mIGJ5dGVzLiZuYnNwOyBCeSBtZW50aW9uaW5nIFdlYlNvY2tldHMsIHRo aXMgdGV4dCBpbXBsaWVzIHRoYXQgdGhlIHJlcXVpcmVtZW50cyBmb3IgV2ViU29ja2V0cyBhcHBs eSwgYnV0IGFsc28gc2F5cyB0aGF0DQogaXQgd29uJ3QgaW5kdWNlIGhlYWQtb2YtbGluZSBibG9j a2luZy4mbmJzcDsgSSdtIGhhdmluZyBhIGhhcmQgdGltZSByZWNvbmNpbGluZyB0aG9zZS4mbmJz cDsgSSBzdXNwZWN0IHRoYXQgd2hhdCBpcyByZWFsbHkgaW4gb3JkZXIgaGVyZSBpcyAmcXVvdDt3 aGF0ZXZlciB3ZSBkZWNpZGUgaW4gdGhlIFczQyBBUEkgbWFrZXMgc2Vuc2UgdG8gc3VwcG9ydCwg YmFzZWQgb24gd2hhdCBRVUlDIGNhbiBwcm92aWRlIGFuZCAobWF5YmUpIHdoYXQgY2FuIGJlIGVt dWxhdGVkIHdpdGgNCiBzb21lIGFycmFuZ2VtZW50IG9mIFdlYlNvY2tldHMgYW5kIEhUVFAgd2hl cmUgY2FzZSBRVUlDIGlzbid0IGF2YWlsYWJsZSZxdW90Oy4mbmJzcDsgVGhlIGxhdGVyIHRleHQg b24gYnVpbGRpbmcgb3ZlcnZpZXcgYW5kIHJlcXVpcmVtZW50cyBzdXBwb3J0cyB0aGF0IHZpZXcs IHdoaWNoIGlzIHdoYXQgbWFrZXMgdGhlIGRldGFpbCBjb25mdXNpbmcuPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IExpa2UgV2ViU29ja2V0cywgd2UgY291bGQgZGVjaWRlIHRvIGJ1aWxkIGEgbWVzc2Fn ZS1iYXNlZCBzeXN0ZW0gd2l0aCBvcmRlcmluZyBiZXR3ZWVuIG1lc3NhZ2VzLCBidXQgaG93IHRo YXQgaXMgaW1wbGVtZW50ZWQgY291bGQgdmFyeSBncmVhdGx5LiZuYnNwOyBFdmVuIHdpdGhpbiBR VUlDLCB0aGVyZSBhcmUgbWFueSBwb3NzaWJpbGl0aWVzOjxicj4NCiZndDsgPGJyPg0KJmd0OyAq IFdlIG1pZ2h0IGRlY2lkZSB0byB1c2UgYSBzaW5nbGUgYmlkaXJlY3Rpb25hbCBRVUlDIHN0cmVh bSB0aGF0IHVzZXMgbWVzc2FnZSBkZWxpbWl0ZXJzIG9uIHRoYXQgc3RyZWFtcyB0byBkaXN0aW5n dWlzaCBtZXNzYWdlcy48YnI+DQomZ3Q7ICogV2UgbWlnaHQgdXNlIHVuaWRpcmVjdGlvbmFsIHN0 cmVhbXMgaW4gbXVjaCB0aGUgc2FtZSB3YXksIGJ1dCB0aGVuIGJ1aWxkIHNvbWUgbWVjaGFuaXNt IHRvIGNvdXBsZSB0aGVtIGludG8gcGFpcnMgYXMgbmVlZGVkLjxicj4NCiZndDsgKiBXZSBtaWdo dCBhbGxvdyBtZXNzYWdlcyB0byBiZSBzZW50IGFzeW5jaHJvbm91c2x5IHdpdGhvdXQgZXhwbGlj aXQgb3JkZXJpbmcsIHRoZW4gdXNlIHJlZmVyZW5jZXMgdG8gdGhvc2Ugc3RyZWFtcyBmcm9tIGFu b3RoZXIgc3RyZWFtIHRvIGVzdGFibGlzaCBhbiBvcmRlcmluZy48YnI+DQomZ3Q7ICogV2UgbWln aHQgdXNlIGRpZmZlcmVudCBzdHJlYW1zIGZvciBlYWNoIG1lc3NhZ2UgYW5kIGluZGljYXRlIG9y ZGVyaW5nIGluIHRoZSBzdHJlYW0gaGVhZGVyLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGF0J3Mg bm90IGV4aGF1c3RpdmUsIEknbSBzdXJlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgcG9zc2li aWxpdHkgdGhhdCBhIHNpbmdsZSBjb25uZWN0aW9uIG1pZ2h0IGFsbG93IG11bHRpcGxleGluZyBv ZiBkaWZmZXJlbnQgJnF1b3Q7c3VicHJvdG9jb2xzJnF1b3Q7IG9uIHRoZSBzYW1lIFFVSUMgY29u bmVjdGlvbiBtYWtlcyBzb21lIG9mIHRoZXNlIG9wdGlvbnMgbW9yZSBkaWZmaWN1bHQgb3IgZXZl biBpbnZhbGlkLiZuYnNwOyBJIGtub3cgVmljdG9yIGlzIHByZXBhcmVkIHRvIGFyZ3VlIHRoYXQg bXVsdGlwbGV4aW5nIGlzIEhhcmQgYW5kIGxpa2VseQ0KIGluY29tcGF0aWJsZSB3aXRoIHNvbWUg b2YgdGhlIHRoaW5ncyBoZSBhc3BpcmVzIHRvIGRvIGV2ZW50dWFsbHksIGJ1dCBJIGRvbid0IHRo aW5rIHdlIHNob3VsZCBkZWNpZGUgdGhhdCBxdWVzdGlvbiBpbiB0aGUgY2hhcnRlci4mbmJzcDsg SSB0ZW5kIHRvIHRoaW5rIHRoYXQgdGhlcmUgaXMgdmFsdWUgaW4gYmVpbmcgYWJsZSB0byBpbnRl cmFjdCB3aXRoIG11bHRpcGxlICZxdW90O3Jlc291cmNlcyZxdW90OyBvbiB0aGUgc2FtZSBjb25u ZWN0aW9uLCBldmVuIGlmIEkgdGhpbmsNCiB0aGF0IHRoZSAmcXVvdDtzdWJwcm90b2NvbCZxdW90 OyBjb25jZXB0IGlzIGFuIGFiamVjdCBmYWlsdXJlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBNYXli ZSB0aGUgcmlnaHQgYW5zd2VyIGlzIHRvIHJlZHVjZSB0aGlzIHRvIGEgc2ltcGxlciBzdGF0ZW1l bnQgdG8gcmVwbGFjZSB0aGUgcGFyYWdyYXBocyBzdGFydGluZyBmcm9tICZxdW90O1RoZXNlIHBy b3RvY29scyZxdW90OyBhbmQgZW5kaW5nIGF0ICZxdW90O2Jsb2NrZWQuJnF1b3Q7Og0KPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlIFdlYlRyYW5zcG9ydCB3b3JraW5nIGdyb3VwIHdpbGwg ZGVmaW5lIGEgcHJvdG9jb2wgb3Igc3VpdGUgb2YgcHJvdG9jb2xzIHRoYXQgc3VwcG9ydCBhIHJh bmdlIG9mIHNpbXBsZSBjb21tdW5pY2F0aW9uIG1ldGhvZHMuJm5ic3A7IFRoZXNlIG11c3QgaW5j bHVkZSB1bnJlbGlhYmxlIG1lc3NhZ2VzICh0aGF0IG1pZ2h0IGJlIGxpbWl0ZWQgdG8gYnkgdGhl IHBhdGggTVRVKSwgcmVsaWFibGUgbWVzc2FnZXMsIGFuZCBvcmRlcmVkIHN0cmVhbXMNCiBvZiBy ZWxpYWJsZSBtZXNzYWdlcy4mbmJzcDsgQXR0ZW50aW9uIHdpbGwgYmUgcGFpZCB0byBwZXJmb3Jt YW5jZSBvZiB0aGUgcHJvdG9jb2wsIGluIHBhcnRpY3VsYXIgcHJvdG9jb2wgb3ZlcmhlYWRzIGFu ZCB0aGUgcG90ZW50aWFsIGZvciBoZWFkLW9mLWxpbmUgYmxvY2tpbmc7IGl0cyBhYmlsaXR5IHRv IGJlIGRlcGxveWVkIGFuZCB1c2VkIHJlbGlhYmx5IHVuZGVyIGRpZmZlcmVudCBuZXR3b3JrIGNv bmRpdGlvbnM7IGFuZCB0aGUgYWJpbGl0eSB0bw0KIGludGVncmF0ZSBwcm90b2NvbCB1c2UgaW50 byB0aGUgV2ViIHNlY3VyaXR5IG1vZGVsLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGRvbid0IHdh bnQgdG8gc2F5IHRoYXQgdGhpcyBpbmNsdWRlcyBhIHN1cGVyc2V0IG9mIHRoZSBjYXBhYmlsaXRp ZXMgcHJvdmlkZWQgYnkgdGhld2Vic29ja2V0cHJvdG9jb2wsIGJlY2F1c2UgdGhhdCBzZWVtcyB0 byBiZSBhbiBvcGVuIHF1ZXN0aW9uLCBidXQgSSdtIG5vdCBvcHBvc2VkIHRvIGRlY2lkaW5nIHRo YXQgZWFybHkgaW4gdGhlIHByb2Nlc3MgaWYgdGhhdCBpcyB3aGVyZSB3ZSBlbmQgdXAuJm5ic3A7 IEkgYWxzbyBkb24ndCB0aGluayB0aGF0DQogeW91IG5lZWQgdG8gd29ycnkgYWJvdXQgSFRUUC8z IG11bHRpcGxleGluZyBhdCB0aGlzIGxldmVsIGVpdGhlci4mbmJzcDsgVGhhdCBjb21lcyB3aXRo IHdvcmtpbmcgb3V0IGhvdyB0byBpbnRlZ3JhdGUgaXQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENo ZWVycyw8YnI+DQomZ3Q7IE1hcnRpbjxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBGcmksIEphbiAz LCAyMDIwLCBhdCAxMjoxNSwgQmVybmFyZCBBYm9iYSB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgRHVy aW5nIHRoZSBXRUJUUkFOUyBCT0YgdGhlcmUgd2VyZSBzb21lIHF1ZXN0aW9ucyByZWxhdGluZyB0 byA8YnI+DQomZ3Q7ICZndDsgb2JqZWN0aXZlcyBhcyB3ZWxsIGFzIHBvdGVudGlhbCB3b3JrIGl0 ZW1zLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhpcyBpbmNsdWRlZCBzb21lIHF1 ZXN0aW9ucyByZWxhdGluZyB0byAmcXVvdDtmYWlsb3ZlciB0cmFuc3BvcnQmcXVvdDsgKGUuZy4g PGJyPg0KJmd0OyAmZ3Q7IHdoZXRoZXIgbmV3IHdvcmsgd2FzIG5lZWRlZCBmb3IgdGhpcyBvciBu b3QpLiBBbHNvLCBFS1IgcXVlc3Rpb25lZCB3aHkgPGJyPg0KJmd0OyAmZ3Q7IGl0IHdhcyBuZWNl c3NhcnkgdG8gZGVmaW5lIHR3byBwcm90b2NvbHMgKG9uZSBmb3Igd2VidHJhbnNwb3J0IG92ZXIg PGJyPg0KJmd0OyAmZ3Q7IEhUVFAvMywgYW5kIGFub3RoZXIgZm9yIGRpcmVjdCB1c2FnZSBvZiBR VUlDIHN0cmVhbXMgYW5kIGRhdGFncmFtcykuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyBJJ3ZlIHN1Ym1pdHRlZCBhIFBSIHRvIGNsYXJpZnkgdGhlIG9iamVjdGl2ZXMgYW5kIHdvcmsg aXRlbXM6IDxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vRGF2aWRT Y2hpbmF6aS93ZWJ0cmFucy13Zy1tYXRlcmlhbHMvcHVsbC81IiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL2dpdGh1Yi5jb20vRGF2aWRTY2hpbmF6aS93ZWJ0cmFucy13Zy1tYXRlcmlhbHMvcHVs bC81PC9hPjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlIG1vZGlmaWVkIGRlc2Ny aXB0aW9uIGFuZCBtaWxlc3RvbmVzIGFyZSBwcm92aWRlZCBiZWxvdy4gQ29tbWVudHMgd2VsY29t ZS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IERlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3Jv dXA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZSBXZWJUcmFuc3BvcnQgd29ya2lu ZyBncm91cCB3aWxsIGRlZmluZSBuZXcgY2xpZW50LXNlcnZlciBwcm90b2NvbHMgPGJyPg0KJmd0 OyAmZ3Q7IG9yIHByb3RvY29sIGV4dGVuc2lvbnMgaW4gb3JkZXIgdG8gc3VwcG9ydCB0aGUgZGV2 ZWxvcG1lbnQgb2YgdGhlIFczQyA8YnI+DQomZ3Q7ICZndDsgV2ViVHJhbnNwb3J0IEFQSSA8YSBo cmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3dpY2cuZ2l0aHViLmlvX3dlYi0yRHRyYW5zcG9ydCZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJU dE5sVGgzeWNkNDFiM01VdyZhbXA7cj0xSVRLc1pBZURhdzY1ZXlRY2RWR2N3JmFtcDttPTk5cHhB alJzcGx0M1VpSVNkdm1LdDA4am5uNk5HV2VVUndkdHhMWk9JdW8mYW1wO3M9RHVON2F5NUhTTlFj aXFkZmNxN1pOMUNSc0o3Z2I3VW93QU5lcUxYWF9SRSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vd2ljZy5naXRodWIuaW8vd2ViLXRyYW5zcG9ydDwvYT4uPGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyBUaGVzZSBwcm90b2NvbHMgd2lsbCBzdXBwb3J0Ojxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgKiBSZWxpYWJsZSBiaWRpcmVjdGlvbmFsIGFuZCB1 bmlkaXJlY3Rpb25hbCBjb21tdW5pY2F0aW9uIHRoYXQgPGJyPg0KJmd0OyAmZ3Q7IHByb3ZpZGVz IGdyZWF0ZXIgZWZmaWNpZW5jeSB0aGFuIFdlYnNvY2tldHMgKGUuZy4gcmVtb3ZhbCBvZiA8YnI+ DQomZ3Q7ICZndDsgaGVhZC1vZi1saW5lIGJsb2NraW5nKS48YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICogVW5yZWxpYWJsZSBkYXRhZ3JhbSBjb21tdW5pY2F0aW9uLCBmdW5j dGlvbmFsaXR5IG5vdCBhdmFpbGFibGUgaW4gV2Vic29ja2V0cy48YnI+DQomZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICogT3JpZ2luIGNoZWNrcyB0byBhbGxvdyBzdXBwb3J0aW5nIHRo ZSBXZWIncyBvcmlnaW4tYmFzZWQgc2VjdXJpdHkgbW9kZWwuPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBUaGUgV2ViVHJhbnNwb3J0IHdvcmtpbmcgZ3JvdXAgd2lsbCBkZWZpbmUgYSBw cm90b2NvbCBvciBzZXQgb2YgPGJyPg0KJmd0OyAmZ3Q7IHByb3RvY29scyB0aGF0IGZpdHMgdGhl c2UgcmVxdWlyZW1lbnRzLiBNdWx0aXBsZSBwcm90b2NvbHMgbWlnaHQgYmUgPGJyPg0KJmd0OyAm Z3Q7IHJlcXVpcmVkIHRvIHN1cHBvcnQgZGlmZmVyZW50IHVzYWdlIHNjZW5hcmlvcywgc3VjaCBh cyBtdWx0aXBsZXhpbmcgPGJyPg0KJmd0OyAmZ3Q7IHdpdGggSFRUUC8zIG9yIG5ldHdvcmtzIHdo ZXJlIFVEUCBpcyBibG9ja2VkLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlIGdy b3VwIHdpbGwgcGF5IGF0dGVudGlvbiB0byBzZWN1cml0eSBpc3N1ZXMgYXJpc2luZyBmcm9tIHRo ZSBhYm92ZSA8YnI+DQomZ3Q7ICZndDsgc2NlbmFyaW9zIHNvIGFzIHRvIGVuc3VyZSBhZ2FpbnN0 IGNyZWF0aW9uIG9mIG5ldyBtb2RlcyBvZiBhdHRhY2ssIGFzIDxicj4NCiZndDsgJmd0OyB3ZWxs IGFzIHRvIGVuc3VyZSB0aGF0IHNlY3VyaXR5IGlzc3VlcyBhZGRyZXNzZWQgaW4gdGhlIGRlc2ln biBvZiA8YnI+DQomZ3Q7ICZndDsgV2Vic29ja2V0cyByZW1haW4gYWRkcmVzc2VkIGluIHRoZSBu ZXcgd29yay48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRvIGFzc2lzdCBpbiB0aGUg Y29vcmRpbmF0aW9uIHdpdGggVzNDLCB0aGUgZ3JvdXAgd2lsbCBpbml0aWFsbHkgPGJyPg0KJmd0 OyAmZ3Q7IGRldmVsb3AgYW4gb3ZlcnZpZXcgZG9jdW1lbnQgY29udGFpbmluZyB1c2UgY2FzZXMg YW5kIHJlcXVpcmVtZW50cyBpbiA8YnI+DQomZ3Q7ICZndDsgb3JkZXIgdG8gY2xhcmlmeSB0aGUg Z29hbHMgb2YgdGhlIGVmZm9ydC4gRmVlZGJhY2sgd2lsbCBhbHNvIGJlIDxicj4NCiZndDsgJmd0 OyBzb2xpY2l0ZWQgYXQgdmFyaW91cyBwb2ludHMgYWxvbmcgdGhlIHdheSBpbiBvcmRlciB0byBl bnN1cmUgdGhlIGJlc3QgPGJyPg0KJmd0OyAmZ3Q7IHBvc3NpYmxlIG1hdGNoIGJldHdlZW4gdGhl IHByb3RvY29sIGV4dGVuc2lvbnMgYW5kIHRoZSBuZWVkcyBvZiB0aGUgVzNDIDxicj4NCiZndDsg Jmd0OyBXZWJUcmFuc3BvcnQgQVBJLiBUaGUgY2xhcml0eSBhbmQgaW50ZXJvcGVyYWJpbGl0eSBv ZiBzcGVjaWZpY2F0aW9ucyA8YnI+DQomZ3Q7ICZndDsgd2lsbCBiZSBjb25maXJtZWQgdmlhIHRl c3QgZXZlbnRzIGFuZCBoYWNrYXRob25zLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg VGhlIGdyb3VwIHdpbGwgYWxzbyBjb29yZGluYXRlIHdpdGggb3RoZXIgd29ya2luZyBncm91cHMg d2l0aGluIHRoZSA8YnI+DQomZ3Q7ICZndDsgSUVURiAoZS5nLiBRVUlDLCBIVFRQQklTKSBhcyBh cHByb3ByaWF0ZS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEdvYWxzIGFuZCBNaWxl c3RvbmVzPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAqIE1hcmNoIDIwMjAg LSBBZG9wdCBhIFdlYlRyYW5zcG9ydCBPdmVydmlldyBkcmFmdCBhcyBhIFdHIHdvcmsgaXRlbTxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgKiBNYXJjaCAyMDIwIC0gQWRvcHQg YSBkcmFmdCBkZWZpbmluZyBhIFdlYlRyYW5zcG9ydCBwcm90b2NvbCBhcyBhIFdHIHdvcmsgaXRl bTxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgKiBBdWd1c3QgMjAyMCAtIElz c3VlIFdHIGxhc3QgY2FsbCBvZiB0aGUgV2ViVHJhbnNwb3J0IE92ZXJ2aWV3IGRvY3VtZW50Ljxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgKiBOb3ZlbWJlciAyMDIwIC0gSXNz dWUgV0cgbGFzdCBjYWxsIG9uIHRoZSBmaXJzdCBXZWJUcmFuc3BvcnQgPGJyPg0KJmd0OyAmZ3Q7 IHByb3RvY29sIGRvY3VtZW50PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAtLSA8YnI+ DQomZ3Q7ICZndDsgV2VidHJhbnNwb3J0IG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyA8YSBo cmVmPSJtYWlsdG86V2VidHJhbnNwb3J0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+V2VidHJh bnNwb3J0QGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX3dlYnRyYW5zcG9ydCZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJUdE5sVGgz eWNkNDFiM01VdyZhbXA7cj0xSVRLc1pBZURhdzY1ZXlRY2RWR2N3JmFtcDttPTk5cHhBalJzcGx0 M1VpSVNkdm1LdDA4am5uNk5HV2VVUndkdHhMWk9JdW8mYW1wO3M9d0JSaEpjXy1lcnVzYjQ1bWEz bE9HLWRTbkEtVEtPUV9xTEFPYUE4MEhRcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2VidHJhbnNwb3J0PC9hPjxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IFdlYnRyYW5zcG9ydCBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpXZWJ0cmFuc3BvcnRAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5XZWJ0cmFuc3BvcnRAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3dlYnRyYW5zcG9ydCZhbXA7ZD1Ed01G YVEmYW1wO2M9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj0xSVRLc1pBZURhdzY1ZXlRY2RW R2N3JmFtcDttPTk5cHhBalJzcGx0M1VpSVNkdm1LdDA4am5uNk5HV2VVUndkdHhMWk9JdW8mYW1w O3M9d0JSaEpjXy1lcnVzYjQ1bWEzbE9HLWRTbkEtVEtPUV9xTEFPYUE4MEhRcyZhbXA7ZT0iIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2Vi dHJhbnNwb3J0PC9hPjxicj4NCiZndDsgLS0gPGJyPg0KJmd0OyBXZWJ0cmFuc3BvcnQgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86V2VidHJhbnNwb3J0QGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+V2VidHJhbnNwb3J0QGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJl Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193 d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb193ZWJ0cmFuc3BvcnQmYW1wO2Q9RHdNRmFRJmFt cDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9MUlUS3NaQWVEYXc2NWV5UWNkVkdjdyZh bXA7bT05OXB4QWpSc3BsdDNVaUlTZHZtS3QwOGpubjZOR1dlVVJ3ZHR4TFpPSXVvJmFtcDtzPXdC UmhKY18tZXJ1c2I0NW1hM2xPRy1kU25BLVRLT1FfcUxBT2FBODBIUXMmYW1wO2U9IiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYnRyYW5z cG9ydDwvYT48YnI+DQo8YnI+DQotLSA8YnI+DQpXZWJ0cmFuc3BvcnQgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOldlYnRyYW5zcG9ydEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PldlYnRyYW5zcG9ydEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFu X2xpc3RpbmZvX3dlYnRyYW5zcG9ydCZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJUdE5sVGgzeWNk NDFiM01VdyZhbXA7cj0xSVRLc1pBZURhdzY1ZXlRY2RWR2N3JmFtcDttPTk5cHhBalJzcGx0M1Vp SVNkdm1LdDA4am5uNk5HV2VVUndkdHhMWk9JdW8mYW1wO3M9d0JSaEpjXy1lcnVzYjQ1bWEzbE9H LWRTbkEtVEtPUV9xTEFPYUE4MEhRcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYnRyYW5zcG9ydDwvYT48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0K V2VidHJhbnNwb3J0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpXZWJ0cmFuc3Bv cnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5XZWJ0cmFuc3BvcnRAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb193ZWJ0cmFuc3BvcnQmYW1wO2Q9 RHdNRmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9MUlUS3NaQWVEYXc2NWV5 UWNkVkdjdyZhbXA7bT05OXB4QWpSc3BsdDNVaUlTZHZtS3QwOGpubjZOR1dlVVJ3ZHR4TFpPSXVv JmFtcDtzPXdCUmhKY18tZXJ1c2I0NW1hM2xPRy1kU25BLVRLT1FfcUxBT2FBODBIUXMmYW1wO2U9 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93 ZWJ0cmFuc3BvcnQ8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_61BD83398F2640F2886DB4CE402EE111fbcom_-- From nobody Tue Jan 28 07:44:12 2020 Return-Path: X-Original-To: webtransport@ietf.org Delivered-To: webtransport@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 721061208E7; Tue, 28 Jan 2020 07:44:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158022624846.4520.16770481947112396070.idtracker@ietfa.amsl.com> Date: Tue, 28 Jan 2020 07:44:08 -0800 From: IETF Secretariat Archived-At: Subject: [Webtransport] Datatracker State Update Notice: X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 15:44:08 -0000 State changed to Start Chartering/Rechartering (Internal IESG/IAB Review). Datatracker URL: https://datatracker.ietf.org/doc/charter-ietf-webtrans/ From nobody Tue Jan 28 07:46:55 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7841C120882 for ; Tue, 28 Jan 2020 07:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 IHhEE4NeHekP for ; Tue, 28 Jan 2020 07:46:52 -0800 (PST) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) (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 1E79C12024E for ; Tue, 28 Jan 2020 07:46:52 -0800 (PST) Received: by mail-io1-f51.google.com with SMTP id s24so13223883iog.5 for ; Tue, 28 Jan 2020 07:46:52 -0800 (PST) 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=twyV4MUY3028j7keh0h+aBwGzHRR/KiWlFkIDLw/R1Y=; b=TI0vCZi55MTGgXKbHFMR9KP7Hiz1A2wtnwnzqpKw8qgadC/VF5NTPMmMaic8V6MSGm vxRnXDVaGTJ4gWbHCOtUuJmXGM+rN3xjwdE2A0ojjewFKmfHWDma4G8gk9bbg7/w36m0 imh/Almn+QZ0Ps/2TJ8fuqnCCHWekFGbg8VRWhzCS/qsImaZxDY8OfM3DK0DKOteV+73 sYBVpUjvY9fdlUB341oe3jVFJefuTtA3gpRP1Q0B4J1uJWt+kia6Fchyudyc1t4zXVp4 7vhixkju9UIl0lEgp2+1l5TGwrxbo7DRYVifsP9MgmWcprbL87jGNoUWa1ATyYOvIa1R wZqQ== X-Gm-Message-State: APjAAAUIRQjkx7Z37yrdQYFOB5nXnghVfbnwnYJGrVf5NmgK1nFCuece UT4+/bibC/B643p9Aks7zZjuEVdz6Ny8XqHJmgg= X-Google-Smtp-Source: APXvYqx44xeomFtvAPM2gZj5AIXhkot1dTNYXYHZEdSxBFX0C8Nq7vef5gj5P/Z7GQPND3LjFF6nPSPv8OSt5sEtNH4= X-Received: by 2002:a05:6638:2b6:: with SMTP id d22mr18512069jaq.59.1580226411031; Tue, 28 Jan 2020 07:46:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Tue, 28 Jan 2020 07:46:40 -0800 Message-ID: To: Bernard Aboba Cc: webtransport@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Webtransport] Revised WEBTRANS charter X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 15:46:53 -0000 Thanks, Bernard. I have started the chartering process with the text below= . Barry, ART AD On Mon, Jan 27, 2020 at 1:27 PM Bernard Aboba wro= te: > > Thanks for all the feedback on the proposed WEBTRANS charter. David and = I have incorporated the suggestions into a revision, available here. A cop= y is also enclosed below. > > Description of Working Group > > The WebTransport working group will define new client-server protocols or= protocol extensions in order to support the development of the W3C WebTran= sport API https://wicg.github.io/web-transport. > > The WebTransport working group will define a protocol or suite of protoco= ls that support a range of simple communication methods. These must include= unreliable messages (that might be limited by the path MTU), reliable mess= ages, and ordered streams of reliable messages. Attention will be paid to t= he performance of the protocol, in particular protocol overheads and the po= tential for head-of-line blocking; its ability to be deployed and used reli= ably under different network conditions; and the ability to integrate proto= col use into the Web security model. > > The group will pay attention to security issues arising from the above sc= enarios so as to ensure against creation of new modes of attack. > > To assist in the coordination with W3C, the group will initially develop = an overview document containing use cases and requirements in order to clar= ify the goals of the effort. Feedback will also be solicited at various poi= nts along the way in order to ensure the best possible match between the pr= otocol extensions and the needs of the W3C WebTransport API. > > The group will also coordinate with other working groups within the IETF = (e.g. QUIC, HTTPBIS) as appropriate. > > Goals and Milestones > > March 2020 - Adopt a WebTransport Overview draft as a WG work item > March 2020 - Adopt a draft defining a WebTransport protocol as a WG work = item > October 2020 - Issue WG last call of the WebTransport Overview document. > January 2021 - Issue WG last call on the first WebTransport protocol docu= ment From nobody Tue Jan 28 09:38:17 2020 Return-Path: X-Original-To: webtransport@ietf.org Delivered-To: webtransport@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EDB120024; Tue, 28 Jan 2020 09:38:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158023309558.4591.543594362258487463.idtracker@ietfa.amsl.com> Date: Tue, 28 Jan 2020 09:38:15 -0800 From: IETF Secretariat Archived-At: Subject: [Webtransport] Telechat update notice: X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 17:38:15 -0000 Placed on agenda for telechat - 2020-02-06 Datatracker URL: https://datatracker.ietf.org/doc/charter-ietf-webtrans/ From nobody Fri Jan 31 08:39:10 2020 Return-Path: X-Original-To: webtransport@ietf.org Delivered-To: webtransport@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE845120120; Fri, 31 Jan 2020 08:39:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: webtransport@ietf.org, webtrans-chairs@ietf.org, webtransport@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2020 08:39:09 -0800 Archived-At: Subject: [Webtransport] Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 16:39:10 -0000 Magnus Westerlund has entered the following ballot position for charter-ietf-webtrans-00-00: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-webtrans/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- This charter is so open ended on what protocol that is to be developed that it could define a new IP version as well as transport protocols. I don't think that is the intention. To my understanding this effort could more clearly be defined as defining one or two application protocol that fulfills the WebTransport API and is using QUIC or HTTP/3. If the charter can be clarified to not include transport protocol work and which existing transport protocols or other protocols the solution will build on it would be much better and well defined work. I also think creating mappings to other transport protocols should require rechartering to enable a wider discussion of such choices. Secondly: The group will also coordinate with related working groups within the IETF, such as QUIC and HTTPBIS, as appropriate. With the current state of QUIC developement and HTTP/3 mapping definition, i.e. still working on the initial version, I would like to have a more firm wording that the WebTrans WG will actually have to take any requests for extensions of HTTP/3 and QUIC to the relevant WG. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I also would appreciate if someone can clarify what stage of formality the Web-Transport API has been adopted in W3C and is being worked on. Trying to find anything about which group it belongs to on the W3C page didn't give me any information. All I found is that there have been a workshop on game communication where this was discussed and raised in some discussions. Having lived through the WebRTC / RTCWeb interactions it would good to know more how the interaction between the bodies are intended to work. Especially as changes to the API can have significant impact on what work needs to happen in the IETF. The current API draft does not include any discussion of priority. However draft-vvv-webtrans-overview does mention priorities. As this API appears to support multiple parallel transmissions and transfers I think at a minimal a sender transport protocol scheduling or HTTP/3 priority would be likely to be part of the work. I also have to ask if this is likely to attempted to be mapped also towards the network level, for example DSCPs? If any such work is expected and intended I think that needs to be raised. Otherwise I would assume that at most what this work will be to use the undefined APIs to HTTP/3 and QUIC to influence those protocol to perform stream priorities. From nobody Fri Jan 31 10:37:38 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88398120815; Fri, 31 Jan 2020 10:37:34 -0800 (PST) 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 Q4ReXdso8UMJ; Fri, 31 Jan 2020 10:37:32 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 1B83912011B; Fri, 31 Jan 2020 10:37:29 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id v19so8183106oic.12; Fri, 31 Jan 2020 10:37:29 -0800 (PST) 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=J6AO3qOYOBeQ5fR1Qyejm0zOBUabdS9txn6jnkgDvhY=; b=lfST4lSoCJEBTYPtFNjcI6vF8W3+DZKAIQaKAaQ91+2eUrVxuLKWeq+hu5wxdfPBh3 X/Oq9ABqeLsCHyyfTOHm4G/39TyIz7kiMbEL9uof1vm7BuPMmmSjQZoSaOfS4OHU/mac /NhfAFHLYBVjprDQBTtDCRiB8gOY3rHaqA0SmgIdMolvSPdW0FMqGogVqcKD540Q5hFC R4FhsJDPihn5ZpfHAgMKEWCI5GysWm9JRtTDokELcs6Mo/4XPO+ZWgSUJp13e1ymbSFd dMrDJoXGzeCOyhmIV8Gh59+HpoVBMTaTpa+ZheiqgpdJBiEc7edKzko1VLrVIHIlITnI 1mfg== 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=J6AO3qOYOBeQ5fR1Qyejm0zOBUabdS9txn6jnkgDvhY=; b=AfK73n2oQeDwyFFSADYrYO6Ivxk1a5wDCk8ICo9NHkT8SFWYIe5BLwiy7dlUgPadbO p4JI7EIaGuza0FNcsJkaHEGx/KvLyZ4JZ9Zwa5hu2Fa0oubi80rHLcgFJLu/WNuz8a2N HeapaS40FKur93EajqhR5vn43Ea1YclM9dBsHZS3rHATZG8lTY27shTnEfI4/h7mQhCG ZHeOuSbj9uWUQC0b4xiRWgLuNVcqXU4fN9WlUDhB1DiNBy4MVVahvx3VwWI5iockrpnE KIFkHJZt6fZ1jYBbtvaY1omW8r0pmlk/X+FVFwfESwGp0jihPcpSQLOueeHDj8KMSmvA s2dA== X-Gm-Message-State: APjAAAVGI+NXWBAuejYyU6lc9MVNaEwf+7kx4RlRT5wzDUJ9/Bw4JXsp X6gewyN2536UagNugFhahAZhfV71xHeFZ8skruI= X-Google-Smtp-Source: APXvYqy8FNy+7E3AheHSN6hPkkSOn3slb5QGdmL5hUqYtKY0LtFgcFmCyzZoBaad5WEhco2iDRjZJGnmhk2KeR3tTzc= X-Received: by 2002:aca:b483:: with SMTP id d125mr7481934oif.167.1580495848198; Fri, 31 Jan 2020 10:37:28 -0800 (PST) MIME-Version: 1.0 References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> In-Reply-To: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> From: Ted Hardie Date: Fri, 31 Jan 2020 10:37:03 -0800 Message-ID: To: Magnus Westerlund Cc: The IESG , webtrans-chairs@ietf.org, webtransport@ietf.org Content-Type: multipart/alternative; boundary="00000000000099d783059d73dd9a" Archived-At: Subject: Re: [Webtransport] Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 18:37:35 -0000 --00000000000099d783059d73dd9a Content-Type: text/plain; charset="UTF-8" Howdy Magnus, One small point, below. On Fri, Jan 31, 2020 at 8:39 AM Magnus Westerlund via Datatracker < noreply@ietf.org> wrote: > Magnus Westerlund has entered the following ballot position for > charter-ietf-webtrans-00-00: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-webtrans/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > This charter is so open ended on what protocol that is to be developed > that it > could define a new IP version as well as transport protocols. I don't think > that is the intention. To my understanding this effort could more clearly > be > defined as defining one or two application protocol that fulfills the > WebTransport API and is using QUIC or HTTP/3. If the charter can be > clarified > to not include transport protocol work and which existing transport > protocols > or other protocols the solution will build on it would be much better and > well > defined work. I also think creating mappings to other transport protocols > should require rechartering to enable a wider discussion of such choices. > > Secondly: > > The group will also coordinate with related working groups within the IETF, > such as QUIC and HTTPBIS, as appropriate. > > With the current state of QUIC developement and HTTP/3 mapping definition, > i.e. > still working on the initial version, I would like to have a more firm > wording > that the WebTrans WG will actually have to take any requests for > extensions of > HTTP/3 and QUIC to the relevant WG. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I also would appreciate if someone can clarify what stage of formality the > Web-Transport API has been adopted in W3C and is being worked on. Trying to > find anything about which group it belongs to on the W3C page didn't give > me > any information. All I found is that there have been a workshop on game > communication where this was discussed and raised in some discussions. > > Having lived through the WebRTC / RTCWeb interactions it would good to know > more how the interaction between the bodies are intended to work. > Especially as > changes to the API can have significant impact on what work needs to > happen in > the IETF. > > The current API draft does not include any discussion of priority. However > draft-vvv-webtrans-overview does mention priorities. As this API appears to > support multiple parallel transmissions and transfers I think at a minimal > a > sender transport protocol scheduling or HTTP/3 priority would be likely > to be > part of the work. HTTP/3 priority is, uh, well, um, here's the draft: A.2.1. Prioritization Differences HTTP/2 specifies priority assignments in PRIORITY frames and (optionally) in HEADERS frames. HTTP/3 does not provide a means of signaling priority. Note that while there is no explicit signaling for priority, this does not mean that prioritization is not important for achieving good performance. The working group has been up and down that hill and eventually decided not to die on it, so that the work could go forward more rapidly. If you'd like to grab someone for the backstory, Jana or Roberto Peon would be possible choices. > I also have to ask if this is likely to attempted to be > mapped also towards the network level, for example DSCPs? If any such work > is > expected and intended I think that needs to be raised. Otherwise I would > assume > that at most what this work will be to use the undefined APIs to HTTP/3 and > QUIC to influence those protocol to perform stream priorities. > regards, Ted --00000000000099d783059d73dd9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy Magnus,

One small point, below.

On Fri, Jan 31, 2020 at 8:39 AM Magnus = Westerlund via Datatracker <noreply@= ietf.org> wrote:
Magnus Westerlund has entered the following ballot position for
charter-ietf-webtrans-00-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf= -webtrans/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

This charter is so open ended on what protocol that is to be developed that= it
could define a new IP version as well as transport protocols. I don't t= hink
that is the intention. To my understanding this effort could more clearly b= e
defined as defining one or two application protocol that fulfills the
WebTransport API and is using QUIC or HTTP/3. If the charter can be clarifi= ed
to not include transport protocol work and which existing transport protoco= ls
or other protocols the solution will build on it would be much better and w= ell
defined work. I also think creating mappings to other transport protocols should require rechartering to enable a wider discussion of such choices.
Secondly:

The group will also coordinate with related working groups within the IETF,=
such as QUIC and HTTPBIS, as appropriate.

With the current state of QUIC developement and HTTP/3 mapping definition, = i.e.
still working on the initial version, I would like to have a more firm word= ing
that the WebTrans WG will actually have to take any requests for extensions= of
HTTP/3 and QUIC to the relevant WG.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I also would appreciate if someone can clarify what stage of formality the<= br> Web-Transport API has been adopted in W3C and is being worked on. Trying to=
find anything about which group it belongs to on the W3C page didn't gi= ve me
any information. All I found is that there have been a workshop on game
communication where this was discussed and raised in some discussions.

Having lived through the WebRTC / RTCWeb interactions it would good to know=
more how the interaction between the bodies are intended to work. Especiall= y as
changes to the API can have significant impact on what work needs to happen= in
the IETF.

The current API draft does not include any discussion of priority. However<= br> draft-vvv-webtrans-overview does mention priorities. As this API appears to=
support multiple parallel transmissions and transfers I think at a minimal = a
sender transport protocol scheduling or HTTP/3 priority=C2=A0 would be like= ly to be
part of the work.

HTTP/3 priority is, uh, = well, um, here's the draft:

A.2.1. Prioritization Di= fferences

HTTP/2 specifies priority assignments in PR= IORITY frames and (optionally) in HEADERS frames. HTTP/3 does not provide a means of signaling priority.

N= ote that while there is no explicit signaling for priority, this does not m= ean that prioritization is not important for achieving good performance.
<= div>
The working group has been up and down that hill and eve= ntually decided not to die on it, so that the work could go forward more ra= pidly.=C2=A0 If you'd like to grab someone for the backstory, Jana or R= oberto Peon would be possible choices.=C2=A0
=C2=A0
I also have to ask if this i= s likely to attempted to be
mapped also towards the network level, for example DSCPs? If any such work = is
expected and intended I think that needs to be raised. Otherwise I would as= sume
that at most what this work will be to use the undefined APIs to HTTP/3 and=
QUIC to influence those protocol to perform stream priorities.

regards,

Ted
--00000000000099d783059d73dd9a-- From nobody Fri Jan 31 19:09:41 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B837512004C; Fri, 31 Jan 2020 19:09:39 -0800 (PST) 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, MIME_QP_LONG_LINE=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 8q9vqAC_q3UO; Fri, 31 Jan 2020 19:09:37 -0800 (PST) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 7B8D3120018; Fri, 31 Jan 2020 19:09:37 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id j7so3569571plt.1; Fri, 31 Jan 2020 19:09:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:cc:to; bh=pffjDZEdmhmAkpwtBtWTe1rx7qqVNcK9Wg3fvRQFVZw=; b=Eb1DQCq7vj7APF2WurIagVAgkiR08nTU3Zs00yc8xqCjJH01jhzwpW86TQP1NwnzDN l2rvM5SBoFK/Euy8hBpgSzaw+uG+IAtvtHujardD0CMOFwd2rZrzYV4RaJN14ONslgK9 DFBH3tXWGRzcGMbP+/91hiiIhuzJ8Do9bsXM6pFFukavX02zUOlO+8DAlP1zJ1r65Hyo 9D4ip03+zLY/Je/mMkNakwNs+/wNG/E6+b2UXibmDnEu54IPq1Sk+WRIV7rWH+JN5iZ5 wXvnWnfLNdxowLDPNINgstf3KoG8rK1cZdkDMloBtowxd9oJzc0xX1bK36CJc6j1Mbpd L3pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:cc:to; bh=pffjDZEdmhmAkpwtBtWTe1rx7qqVNcK9Wg3fvRQFVZw=; b=YCa0Etj0TcXpgpmQF1RZH5DUM1jKYWgFozrRQrcQWgU3uzrNhd0RvqqrcvtkSJrGTd kUbY5/DbyZiOURXnJfHfF6dBKbWVoK4GpkroGngx4eTJLXRjUPT0y36SWhcmhDb1/ZPH JfGudshRxfd1ZAC62DLA0GpREYoo1jSy09wKxWbTo5R5u/RcxiMiGcmMIpDgJIcxi/l+ D18EwNjvw2w/6eO+r8vcGbsmxrbp2Gj4rkvBu0zRG19QzF5mi2AuXRH49n2gWxSPpwBf mWQH1QbXI5Cg5Udq1FjdZo4GZhYfsyEAFbmDMwFPDLLkPhatWPauRsUgZ1Jd7n3phDPQ Y3Vg== X-Gm-Message-State: APjAAAUi4/GjQl5syK+nXezNnGj1U8fA3julxTl7dOTMf/Bv8Pc5jEGr VN4EWYctYOWKEcPyrWMuoRcvYw9c X-Google-Smtp-Source: APXvYqwGrRVfu7dk9ZkadFi+kKmBI/IMirfhU/EoP3RMiFBnAkD+ibizCcepVTSwNRZRBwScC3lwRg== X-Received: by 2002:a17:90a:cc02:: with SMTP id b2mr15399587pju.137.1580526576610; Fri, 31 Jan 2020 19:09:36 -0800 (PST) Received: from [10.37.8.67] ([96.74.14.221]) by smtp.gmail.com with ESMTPSA id c34sm11382745pgc.61.2020.01.31.19.09.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Jan 2020 19:09:35 -0800 (PST) From: Bernard Aboba X-Google-Original-From: Bernard Aboba Content-Type: multipart/alternative; boundary=Apple-Mail-D62B40CB-A749-4F4B-9F46-08C73906C4AE Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Fri, 31 Jan 2020 19:09:35 -0800 Message-Id: References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> Cc: webtrans-chairs@ietf.org To: Magnus Westerlund , webtransport@ietf.org X-Mailer: iPad Mail (17D50) Archived-At: Subject: [Webtransport] Fwd: Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 03:09:40 -0000 --Apple-Mail-D62B40CB-A749-4F4B-9F46-08C73906C4AE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Comments below. > From: Magnus Westerlund via Datatracker > Date: January 31, 2020 at 08:39:10 PST > To: The IESG > Cc: webtransport@ietf.org, webtrans-chairs@ietf.org, webtransport@ietf.org= > Subject: Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with B= LOCK and COMMENT) > Reply-To: Magnus Westerlund >=20 > =EF=BB=BFMagnus Westerlund has entered the following ballot position for > charter-ietf-webtrans-00-00: Block >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-webtrans/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- >=20 > This charter is so open ended on what protocol that is to be developed tha= t it > could define a new IP version as well as transport protocols. I don't thin= k > that is the intention. [BA] Definitely not the intention . > To my understanding this effort could more clearly be > defined as defining one or two application protocol that fulfills the > WebTransport API and is using QUIC or HTTP/3. [BA] Would it be sufficient to add this clarification to the existing senten= ce? The result would look like this. The WebTransport working group will define new client-server protocols or pr= otocol extensions using QUIC or HTTP3 in order to support the development of= the W3C WebTransport API https://wicg.github.io/web-transport. > If the charter can be clarified > to not include transport protocol work and which existing transport protoc= ols > or other protocols the solution will build on it would be much better and w= ell > defined work. I also think creating mappings to other transport protocols > should require rechartering to enable a wider discussion of such choices. >=20 > Secondly: >=20 > The group will also coordinate with related working groups within the IETF,= > such as QUIC and HTTPBIS, as appropriate. >=20 > With the current state of QUIC development and HTTP/3 mapping definition, i= .e. > still working on the initial version, I would like to have a more firm wor= ding > that the WebTrans WG will actually have to take any requests for extension= s of > HTTP/3 and QUIC to the relevant WG. [BA] Would the following work? =E2=80=9CThe group will also coordinate with related working groups within t= he IETF, such as QUIC and HTTPBIS, as appropriate. Requests for extensions of HTTP/3= and QUIC will be brought to the relevant WG.=E2=80=9D > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I also would appreciate if someone can clarify what stage of formality the= > Web-Transport API has been adopted in W3C and is being worked on. [BA] The WebTransport API is currently under development within the W3C WICG= :=20 https://wicg.github.io/web-transport/ Since the API is maturing, there is interest in moving ahead with the standa= rdization process. However, the next steps are not yet clear. My last conv= ersation with W3C management indicated that they were considering the implic= ations of the recently concluded W3C-WHATWG agreement. See the end of this m= essage for details.=20 > Trying to > find anything about which group it belongs to on the W3C page didn't give m= e > any information. All I found is that there have been a workshop on game > communication where this was discussed and raised in some discussions. > Having lived through the WebRTC / RTCWeb interactions it would good to kno= w > more how the interaction between the bodies are intended to work. Especial= ly as > changes to the API can have significant impact on what work needs to happe= n in > the IETF. [BA] Overall, the information flow seems more likely to go from protocol to A= PI than the other way around. At least that=E2=80=99s how things have worke= d so far with the WebTransport API, whose development mirrored the developme= nt of the QUIC transport protocol (e.g. Introducing uni-directional streams o= nce this was introduced in the protocol). Also, please keep in mind that pr= otocols tend to have a longer lifetime than APIs (e.g. there are multiple We= bSockets APIs, some message-based, others streams-based).=20 >=20 > The current API draft does not include any discussion of priority. However= > draft-vvv-webtrans-overview does mention priorities. As this API appears t= o > support multiple parallel transmissions and transfers I think at a minimal= a > sender transport protocol scheduling or HTTP/3 priority would be likely t= o be > part of the work. I also have to ask if this is likely to attempted to be > mapped also towards the network level, for example DSCPs? If any such work= is > expected and intended I think that needs to be raised. Otherwise I would a= ssume > that at most what this work will be to use the undefined APIs to HTTP/3 an= d > QUIC to influence those protocol to perform stream priorities. [BA] Priority has not faired well within recent W3C API efforts, including R= TCDataChannel and WebRTC. So not sure how much energy there is. Also see Te= d=E2=80=99s message relating to the status of priority in HTTP/3.=20 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94 W3C/WHATWG Observations below =E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94- The history of W3C and WHATWG appears to be relevant to the prospective stan= dardization path for WebTransport API. 1. A potential analog to the WebTransport API is the WebSockets API. After i= ts initial development in W3C, the WebSockets API was transitioned over to a= Living Standard in the WHATWG:=20 https://html.spec.whatwg.org/multipage/web-sockets.html#the-websocket-interf= ace 2. Since the transition of WebSockets API to WHATWG, subsequent work (includ= ing the WebSocket-Stream API and WebTransport) has been based on the WHATWG S= treams API (now also a Living Standard):=20 https://streams.spec.whatwg.org/ FYI, Info on the WebSockets-Stream API is here: https://docs.google.com/document/d/1XuxEshh5VYBYm1qRVKordTamCOsR-uGQBCYFcHXP= 4L0/edit#heading=3Dh.4f9946en7wca While I=E2=80=99m not personally familiar with the history of WebSockets API= development in W3C or why that API and subsequent work Is now being handled= in WHATWG, the history (and the subsequent agreement between W3C and WHATWG= ) seems to be a factor in considering whether work of this type belongs in W= 3C versus WHATWG. That said, folks interested in WebTransport API seem to favor moving ahead i= n W3C rather than WHATWG. --Apple-Mail-D62B40CB-A749-4F4B-9F46-08C73906C4AE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Comments below.

From:= Magnus Westerlund via Datatracker <noreply@ietf.org>
Date: J= anuary 31, 2020 at 08:39:10 PST
To: The IESG <iesg@ietf.org>=
Cc: webtransport@ietf.org, webtrans-chairs@ietf.org, webtransport= @ietf.org
Subject: Magnus Westerlund's Block on charter-ietf-we= btrans-00-00: (with BLOCK and COMMENT)
Reply-To: Magnus Wester= lund <magnus.westerlund@ericsson.com>

=EF=BB=BFMagnus Westerlund has en= tered the following ballot position for
charter-ietf-webtran= s-00-00: Block

When responding, please keep= the subject line intact and reply to all
email addresses in= cluded in the To and CC lines. (Feel free to cut this
introd= uctory paragraph, however.)



The document, along with other ballot positions, can be f= ound here:
https://datatracker.ietf.org/doc/charter-ietf-web= trans/



--= --------------------------------------------------------------------<= br>BLOCK:
--------------------------------------------= --------------------------

This charter is s= o open ended on what protocol that is to be developed that it
could define a new IP version as well as transport protocols. I don't thin= k
that is the intention.

=
[BA] Definitely not the intention .

=
To my understanding this effort could more clearly be=
defined as defining one or two application protocol that fu= lfills the
WebTransport API and is using QUIC or HTTP/3.

[BA] Would it be sufficient to ad= d this clarification to the existing sentence? The result would look like th= is.

The WebTransport working group will define new client-server proto=
cols or protocol extensions using QUIC or HTTP3 in order to support the deve=
lopment of the W3C WebTransport API https://wicg=
.github.io/web-transport.

If the charter can be clarified
to not incl= ude transport protocol work and which existing transport protocolsor other protocols the solution will build on it would be much better= and well
defined work. I also think creating mappings to ot= her transport protocols
should require rechartering to enabl= e a wider discussion of such choices.

Secon= dly:

The group will also coordinate with re= lated working groups within the IETF,
such as QUIC and HTTPB= IS, as appropriate.

With the current state o= f QUIC development and HTTP/3 mapping definition, i.e.
still= working on the initial version, I would like to have a more firm wording
that the WebTrans WG will actually have to take any requests f= or extensions of
HTTP/3 and QUIC to the relevant WG.<= br>

[BA] Would the following work?

=E2=80=9CThe group will also coordinate with related workin= g groups within the IETF,
such as QUIC and HTTPBIS, as appropriate= .  Requests for extensions of HTTP/3 and QUIC will be brought to the re= levant WG.=E2=80=9D

----------------------------------------------= ------------------------
COMMENT:
----------= ------------------------------------------------------------

I also would appreciate if someone can clarify what stage o= f formality the
Web-Transport API has been adopted in W3C an= d is being worked on.

[BA] The W= ebTransport API is currently under development within the W3C WICG: 

Since the API is maturing, t= here is interest in moving ahead with the standardization process.  How= ever, the next steps are not yet clear.  My last conversation with W3C m= anagement indicated that they were considering the implications of the recen= tly concluded W3C-WHATWG agreement.  See the end of this message for de= tails. 

= Trying to
find anything about which group it belongs t= o on the W3C page didn't give me
any information. All I foun= d is that there have been a workshop on game
communication w= here this was discussed and raised in some discussions.

Having lived through the WebRTC / RTCWeb interactions it would goo= d to know
more how the interaction between the bodies are in= tended to work. Especially as
changes to the API can have si= gnificant impact on what work needs to happen in
the IETF.

[BA] Overall, the informatio= n flow seems more likely to go from protocol to API than the other way aroun= d.  At least that=E2=80=99s how things have worked so far with the WebT= ransport API, whose development mirrored the development of the QUIC transpo= rt protocol (e.g. Introducing uni-directional streams once this was introduc= ed in the protocol).  Also, please keep in mind that protocols tend to h= ave a longer lifetime than APIs (e.g. there are multiple WebSockets APIs, so= me message-based, others streams-based). 


The current API draft does not= include any discussion of priority. However
draft-vvv-webtr= ans-overview does mention priorities. As this API appears to
support multiple parallel transmissions and transfers I think at a minimal a=
sender transport protocol scheduling or HTTP/3 priority &nb= sp;would be likely to be
part of the work. I also have to as= k if this is likely to attempted to be
mapped also towards t= he network level, for example DSCPs? If any such work is
exp= ected and intended I think that needs to be raised. Otherwise I would assume=
that at most what this work will be to use the undefined AP= Is to HTTP/3 and
QUIC to influence those protocol to perform= stream priorities.

[BA] Pr= iority has not faired well within recent W3C API efforts, including RTCDataC= hannel and WebRTC.  So not sure how much energy there is. Also see Ted=E2= =80=99s message relating to the status of priority in HTTP/3. 

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94 W3C/WHATWG Observations below =E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94-=

The history of W3C and WHATWG appears to be releva= nt to the prospective standardization path for WebTransport API.
<= br>
1. A potential analog to the WebTransport API is the WebS= ockets API.  After its initial development in W3C, the WebSockets API w= as transitioned over to a Living Standard in the WHATWG: 

2. Since the transition of WebS= ockets API to WHATWG, subsequent work (including the WebSocket-Stream API an= d WebTransport) has been based on the WHATWG Streams API (now also a Living S= tandard): 

FYI, Info on the We= bSockets-Stream API is here:

Whil= e I=E2=80=99m not personally familiar with the history of WebSockets API dev= elopment in W3C or why that API and subsequent work Is now being handled in W= HATWG, the history (and the subsequent agreement between W3C and WHATWG) see= ms to be a factor in considering whether work of this type belongs in W3C ve= rsus WHATWG.

That said, folks interested in WebTran= sport API seem to favor moving ahead in W3C rather than WHATWG.
<= blockquote type=3D"cite">
= --Apple-Mail-D62B40CB-A749-4F4B-9F46-08C73906C4AE--