[Webtransport] Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT)
Magnus Westerlund via Datatracker <noreply@ietf.org> Fri, 31 January 2020 16:39 UTC
Return-Path: <noreply@ietf.org>
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 <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
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 <magnus.westerlund@ericsson.com>
Message-ID: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com>
Date: Fri, 31 Jan 2020 08:39:09 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/webtransport/M4f6Z8mV4WpS1TAuPEvH_5QPOj0>
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: <webtransport.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webtransport>, <mailto:webtransport-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webtransport/>
List-Post: <mailto:webtransport@ietf.org>
List-Help: <mailto:webtransport-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webtransport>, <mailto:webtransport-request@ietf.org?subject=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.
- [Webtransport] Magnus Westerlund's Block on chart… Magnus Westerlund via Datatracker
- Re: [Webtransport] Magnus Westerlund's Block on c… Ted Hardie
- [Webtransport] Fwd: Magnus Westerlund's Block on … Bernard Aboba
- Re: [Webtransport] Fwd: Magnus Westerlund's Block… Martin Thomson
- Re: [Webtransport] Fwd: Magnus Westerlund's Block… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… David Schinazi
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… David Schinazi
- Re: [Webtransport] Fwd: Magnus Westerlund's Block… Magnus Westerlund
- Re: [Webtransport] Magnus Westerlund's Block on c… Magnus Westerlund
- Re: [Webtransport] Magnus Westerlund's Block on c… Victor Vasiliev
- Re: [Webtransport] Magnus Westerlund's Block on c… David Schinazi
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… David Schinazi
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kühlewind (IETF)
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… David Schinazi
- Re: [Webtransport] Magnus Westerlund's Block on c… Barry Leiba
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… Barry Leiba
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Rob Wilton (rwilton)
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla