From nobody Tue Jun 9 16:14: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 117C83A0965 for ; Tue, 9 Jun 2020 16:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 5DKGYiG8MWHf for ; Tue, 9 Jun 2020 16:14:38 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 A317C3A0957 for ; Tue, 9 Jun 2020 16:14:37 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id r125so294044lff.13 for ; Tue, 09 Jun 2020 16:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ppVJQN75iKVMlRv2Mn5tx1b0VapTN8hnLC5RvfXbmUM=; b=gq8LJby7wHvDToA1nX52KFA9l8uP511KLOvSaPWrEpFU47lhG4cc76L7T5XRnDeR5z KndYSdbadgYkkMhsb9OBE4gviLmfIj7TNpgjdCLunZy4x3vqwiFs13N3PCekSzJ38vJv mYMyzeHrB7rQOpeDwGSKoHFBQePq9Xx428uy4ghHbAwImDoTKHtdgcYCQNVGoP2W3eGL Jw+FCwkf7xFzGn2OHFwX31C1TUmiJI718LTPOYdYSUAEy7LrqfxHwGk0Okx4yixdaOvR 5zzIXOTGQBbMzf2nGvOrCqGJF/O/kdu2zjwHflImEUWGsGQmefo+wan+rxnLgq5im/qm ppSg== 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=ppVJQN75iKVMlRv2Mn5tx1b0VapTN8hnLC5RvfXbmUM=; b=YCVi3HRPMZgIFTIyLrb3bXWTNRpfgfOdZyDwWIN92SjFgWO2B/lgRWy2mHLt7isLrA NEgcOya8/EhnWXYeEtqThKmb9JYJF1FYkvqbn7uaR42Qh9JewO+LVJynAQz4+nS5vPqo zGUgA25dO021LEjNUnUYlSqsVgUUhUbkyQRHIXZUNFtTDkulo4ko4DfLwII0WqQitZ5N ETMbqLcCc7xpDlEH4Ef71kO7izGNWnumvslLvpeQHRxiL7hYGp48EqU7IInFluHYh5QO OvqzcFlKGGZkxFfKbrOXD9gnDsi7tuby1YWo4q0pMF1ht149LJmXWImxzX8LI3V7qpgu qvzA== X-Gm-Message-State: AOAM532SdYFgwieJ9rs0BESSrl3Dul9ogZ8KjLzgOmph9gZPLkWP6ZGG xCvvaIeU21FBw87JlTt4OLipDoI9rvgz0j70KACQLHpN X-Google-Smtp-Source: ABdhPJwzX+QyN9uXm++Q1nI2GXtJyEhNSeGXfcSgM5hhlBy1lNqQNBZeeMx6svIzJWVG8dMP1XZNBqyB1yYM9K5j+u8= X-Received: by 2002:ac2:5314:: with SMTP id c20mr117954lfh.75.1591744475546; Tue, 09 Jun 2020 16:14:35 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Tue, 9 Jun 2020 16:14:24 -0700 Message-ID: To: webtransport@ietf.org Content-Type: multipart/alternative; boundary="00000000000009c7e105a7aee4b7" Archived-At: Subject: [Webtransport] IETF 108 Registration 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, 09 Jun 2020 23:14:39 -0000 --00000000000009c7e105a7aee4b7 Content-Type: text/plain; charset="UTF-8" Registration for IETF 108 (which will be a fully online meeting) is now open: https://registration.ietf.org/ For more details see the announcement below: https://mailarchive.ietf.org/arch/msg/ietf-announce/BPNyTxka355XbY03VSBtjl5y_So/ Note that registration for the meeting and hackathon are separate. --00000000000009c7e105a7aee4b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
Registration fo=
r IETF 108 (which will be a fully online meeting) is now open:
= 
https:=
//registration.ietf.org/
For more details = see the announcement below:

Note that registration for the meeting= and hackathon are separate.
--00000000000009c7e105a7aee4b7-- From nobody Wed Jun 10 14:59:32 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 4F8293A1581 for ; Wed, 10 Jun 2020 14:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 mH2obaGwwRTv for ; Wed, 10 Jun 2020 14:59:22 -0700 (PDT) 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 60EA83A157E for ; Wed, 10 Jun 2020 14:59:22 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id c17so4429047lji.11 for ; Wed, 10 Jun 2020 14:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9ovze9J9xEWThnm5Jf7gyjDzqePZD1JA+5ncgd8rfLI=; b=FnhkM+GyGRaYML2OFxEf8DSfyLdCjm0M8lxENMClax+40lDV5AyjTFQb1ymId3HeVU xBEAft8irrRkJI6jPLJH8wm1YKk2FWX8Q+FzikAlRcXlRvM7nVRFRytkMJpGz2v1SQou QEQ+LynMfNU37CVyTt7jp4O9YXIWTGnUeaY/ivX7JVYjBkePmYvMFwOOi8nRi3qiwP+H BQG4FXnIhbAr6rIPAY3aifAbgENjOGBDr/b6QeddN8fCAnl2dk6Amyo10Uz+Rqf2qUMK 0jYxLnOEwH+KdRdj5aOuJNyBnMXdER4v6S2LCArH9wL9F15NWYYWAg9rXj6AN6zgF2nD OiQA== 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; bh=9ovze9J9xEWThnm5Jf7gyjDzqePZD1JA+5ncgd8rfLI=; b=TKY2L6EtW1WSBC9u4wQ+61OCjtwp86XYBVoqouMSNWiS9YeECEWtMyilxsvsqkAKQU nMAI7K2dPnWCAeFrZBMh/SxYFYkO/nFLcaag0EGyQ4ETQwEuDCcydijiH9WykG7aPHkR 5XPbpohiMlLZnPHRmEqhwP4uiP9KIUOU8VwEOhT2Rlp4prZbL413WF3ISL1HzV8nDx8X 5TCo3iGq3gLf80Uej9bLcor3MrSaG+2tcuhbmTtR2HJzhovsszlCUK3tRoeesJaUYrRI Lq2G+qeS75ahs01e3knv8HdhEejpWBULxjZhZPUSVshusdTS3WGvkRtnkxouw5Fbp8Da Q9UA== X-Gm-Message-State: AOAM533c0F9EknE4Qrof2xyTsQxj2/UgMkVkDncQzKVu/MB4J+qLtGPS JQybXdnh1U2y6VpfIUkQ7TTjSdK4ykIglIDoM4psZW+g X-Google-Smtp-Source: ABdhPJz42Clu/fuqgs2x6/CpX3Bkyw25IGq4yRpGyB0qkO50RHlvSS23ttKvDOCkBR5cYuGGguapEQeGxA16AuDbK3I= X-Received: by 2002:a2e:589:: with SMTP id 131mr2551074ljf.317.1591826359551; Wed, 10 Jun 2020 14:59:19 -0700 (PDT) MIME-Version: 1.0 References: <159181529656.16063.6964178024900109434@ietfa.amsl.com> <90F43A4B-9A1E-480A-B7BF-75A93842C261@att.com> In-Reply-To: <90F43A4B-9A1E-480A-B7BF-75A93842C261@att.com> From: Bernard Aboba Date: Wed, 10 Jun 2020 14:59:08 -0700 Message-ID: To: webtransport@ietf.org Content-Type: multipart/alternative; boundary="000000000000b488c705a7c1f419" Archived-At: Subject: [Webtransport] Fwd: Nomcom 2020-2021 Second Call For Volunteers 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, 10 Jun 2020 21:59:31 -0000 --000000000000b488c705a7c1f419 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Begin forwarded message: *From:* NomCom Chair 2020 *Date:* June 10, 2020 at 1:55:21 PM CDT *To:* IETF Announcement List *Cc:* "ietf@ietf.org" *Subject:* *Nomcom 2020-2021 Second Call For Volunteers* =EF=BB=BFThis is the second sending of the call for volunteers for the 2020= -2021 NomCom. I wanted to mention a few updates from the previous email (sent 2 weeks ago): - I've fixed the URL at the bottom of the email to point to https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _nomcom_2020_&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vr= fog&m=3DZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&s=3DNgIu-7Ij0nEdsFcbJOL= cl2M56RxyREhLAtcaHLatD34&e=3D instead of /2019/. This was a test to see if anyone was paying attention. Apparently, some people were. ;) - The IETF 108 registration form includes a checkbox that will let you volunteer. You can use this instead of emailing me, when you register for IETF 108. - I currently have 39 volunteers. Last year had 149. I need more volunteers= ! ---------------------------------------------------------------------------= ------ The IETF NomCom appoints people to fill the open slots on the LLC, IETF Trust, the IAB, and the IESG. Ten voting members for the NomCom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the NomCom can be found in BCP 10 (RFC 8713). RFC 3797 details the selection algorithm. Special for this year (and only this year), we also have RFC 8788 (one-off update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer: Members of the IETF community must have attended at least three of the last five in-person IETF meetings in order to volunteer. The five meetings are the five most recent in-person meetings that ended prior to the date on which the solicitation for NomCom volunteers was submitted for distribution to the IETF community. Because no IETF 107 in-person meeting was held, for the 2020-2021 Nominating Committee those five meetings are IETFs 102 [Montreal, Canada; July 2018], 103 [Bangkok, Thailand; November 2018], 104 [Prague, Czech Republic; March 2019], 105 [Montreal, Canada; July 2019], and 106 [Singapore; November 2019]. Keep in mind that eligibility is based on in-person attendance at the five listed meetings. You can check your eligibility at: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_registr= ation_nomcom.py&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4= vrfog&m=3DZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&s=3D7_9x9PPoUIajJs2An= UFYg0KnEg8gkD3Jnwf1v079EQo&e=3D . If you qualify, please volunteer. Before you decide to volunteer, please remember that anyone appointed to this NomCom will not be considered as a candidate for any of the positions that the 2020 - 2021 NomCom is responsible for filling. People commonly volunteer by ticking the box on IETF registration forms. The IETF 106 form did not ask whether people were willing to volunteer. IETF 107 did ask, but all those registrations were canceled. I have asked the Secretariat if it is possible to get the list if volunteers from canceled IETF 107 registrations. If that list is available, I will contact all who are verified as eligible. But given the uncertainty of this process, I would encourage people to volunteer directly (see the bottom of this email for instructions). Thank you for volunteering! The list of people and posts whose terms end with the March 2021 IETF meeting, and thus the positions for which this NomCom is responsible, are IETF Trust: Joel Halpern LLC: Maja Andjelkovic IAB: Jari Arkko Jeff Tantsura Mark Nottingham Stephen Farrell Wes Hardaker Zhenbin Li IESG: Alissa Cooper, IETF Chair/GEN AD Alvaro Retana, RTG AD Barry Leiba, ART AD Deborah Brungard, RTG AD =C3=89ric Vyncke, INT AD Magnus Westerlund, TSV AD Roman Danyliw, SEC AD Warren Kumari, OPS AD All appointments are for 2 years. The Routing area has 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas (that have more than one AD) have at least one continuing AD. The primary activity for this NomCom will begin in July 2020 and should be completed in January 2021. The NomCom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. While being a NomCom member does require some time commitment it is also a very rewarding experience. As a member of the NomCom it is very important that you be willing and able to attend either videoconference or in-person meetings (which may not happen) during 14-20 November (IETF 109 - Bangkok) to conduct interviews. Videoconference attendance will be supported whether or not there are in-person meetings. Orientation and setting of the NomCom schedule will be done by videoconference during the week 20-24 July (exact time and date to be determined after NomCom membership is finalized on July 12), the week prior to IETF 108. Being at IETF 110 (Prague) is not essential. Please volunteer by sending me an email before 23:59 UTC June 24, 2020, as follows: To: nomcom-chair-2020@ietf.org Subject: NomCom 2020-21 Volunteer Please include the following information in the email body: Your Full Name: // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: // For confirmation if selected You should expect an email response from me within 5 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that NomCom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the NomCom is a great way to contribute to the IETF! You can find a detailed timeline on the NomCom web site at: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _nomcom_2020_&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vr= fog&m=3DZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&s=3DNgIu-7Ij0nEdsFcbJOL= cl2M56RxyREhLAtcaHLatD34&e=3D I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next few weeks. Thank you! Barbara Stark bs7652 at att dot com nomcom-chair-2020 at ietf dot org --000000000000b488c705a7c1f419 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Begin forwarded message:

From: NomCom Chair 2020 <nomcom-chair-2020@ietf.org>=
Date: June 10, 2020 at 1:55:21 PM CDT
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: "ietf@ie= tf.org" <iet= f@ietf.org>
Subject: Nomcom 2020-2021 Second Call For Volunteers

=EF=BB=BFThis is the second sending of the call for = volunteers for the 2020-2021 NomCom.

I wanted to mention a few updates from the previous email (sent 2 wee= ks ago):
- I've fixed the URL at the bottom of the email to point to https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf= .org_nomcom_2020_&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoG= zhC-8sc8SY8Tq4vrfog&m=3DZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&= ;s=3DNgIu-7Ij0nEdsFcbJOLcl2M56RxyREhLAtcaHLatD34&e=3D =C2=A0instead of /2019/. This was a test to see if anyone was paying atten= tion. Apparently, some people were. ;)
- The IETF 108 registration form includes a checkbox that will let yo= u volunteer. You can use this instead of emailing me, when you register for= IETF 108.
- I currently have 39 volunteers. Last year had 149. I need more volu= nteers!
---------------------------------------------------------------------= ------------
The IETF NomCom appoints people to fill the open slots on the LLC, IE= TF Trust, the IAB, and the IESG.

Ten voting members for the NomCom are selected in a verifiably random= way from a pool of volunteers. The more volunteers, the better chance we h= ave of choosing a random yet representative cross section of the IETF popul= ation.

The details of the operation of the NomCom can be found in BCP 10 (RF= C 8713). RFC 3797 details the selection algorithm.

Special for this year (and only this year), we also have RFC 8788 (on= e-off update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer:=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Members of the IETF community must have= attended at least three of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the last five in-person IETF meetings i= n order to volunteer.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The five meetings are the five most rec= ent in-person meetings that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ended prior to the date on which the so= licitation for NomCom
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0volunteers was submitted for distributi= on to the IETF community.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Because no IETF 107 in-person meeting w= as held, for the 2020-2021
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Nominating Committee those five meeting= s are IETFs
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0102 [Montreal, Canada; July= 2018],
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0103 [Bangkok, Thailand; Nov= ember 2018],
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0104 [Prague, Czech Republic= ; March 2019],
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0105 [Montreal, Canada; July= 2019], and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0106 [Singapore; November 20= 19].

Keep in mind that eligibility is based on in-person attendance at the= five listed meetings. You can check your eligibility at: https:= //urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_registration_= nomcom.py&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8= SY8Tq4vrfog&m=3DZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&s=3D7_9= x9PPoUIajJs2AnUFYg0KnEg8gkD3Jnwf1v079EQo&e=3D .

If you qualify, please volunteer. Before you decide to volunteer, ple= ase remember that anyone appointed to this NomCom will not be considered as= a candidate for any of the positions that the 2020 - 2021 NomCom is respon= sible for filling.

People commonly volunteer by ticking the box on IETF registration for= ms. The IETF 106 form did not ask whether people were willing to volunteer.= IETF 107 did ask, but all those registrations were canceled. I have asked = the Secretariat if it is possible to get the list if volunteers from canceled IETF 107 registrations. If tha= t list is available, I will contact all who are verified as eligible. But g= iven the uncertainty of this process, I would encourage people to volunteer= directly (see the bottom of this email for instructions). Thank you for volunteering!

The list of people and posts whose terms end with the March 2021 IETF= meeting, and thus the positions for which this NomCom is responsible, are<= /span>

IETF Trust:
=C2=A0=C2=A0=C2=A0Joel Halpern

LLC:
=C2=A0=C2=A0=C2=A0Maja Andjelkovic

IAB:
=C2=A0=C2=A0=C2=A0Jari Arkko
=C2=A0=C2=A0=C2=A0Jeff Tantsura
=C2=A0=C2=A0=C2=A0Mark Nottingham
=C2=A0=C2=A0=C2=A0Stephen Farrell
=C2=A0=C2=A0=C2=A0Wes Hardaker
=C2=A0=C2=A0=C2=A0Zhenbin Li

IESG:
=C2=A0=C2=A0=C2=A0Alissa Cooper, IETF Chair/GEN AD
=C2=A0=C2=A0=C2=A0Alvaro Retana, RTG AD
=C2=A0=C2=A0=C2=A0Barry Leiba, ART AD
=C2=A0=C2=A0=C2=A0Deborah Brungard, RTG AD
=C2=A0=C2=A0=C2=A0=C3=89ric Vyncke, INT AD
=C2=A0=C2=A0=C2=A0Magnus Westerlund, TSV AD
=C2=A0=C2=A0=C2=A0Roman Danyliw, SEC AD
=C2=A0=C2=A0=C2=A0Warren Kumari, OPS AD

All appointments are for 2 years. The Routing area has 3 ADs and the = General area has 1; all other areas have 2 ADs. Thus, all areas (that have = more than one AD) have at least one continuing AD.

The primary activity for this NomCom will begin in July 2020 and shou= ld be completed in January 2021.=C2=A0 The NomCom will have regularly sched= uled conference calls to ensure progress. There will be activities to colle= ct requirements from the community, review candidate questionnaires, review feedback from community members about can= didates, and talk to candidates.

While being a NomCom member does require some time commitment it is a= lso a very rewarding experience.

As a member of the NomCom it is very important that you be willing an= d able to attend either videoconference or in-person meetings (which may no= t happen) during 14-20 November (IETF 109 - Bangkok) to conduct interviews.= Videoconference attendance will be supported whether or not there are in-person meetings. Orientation and = setting of the NomCom schedule will be done by videoconference during the w= eek 20-24 July (exact time and date to be determined after NomCom membershi= p is finalized on July 12), the week prior to IETF 108.=C2=A0 Being at IETF 110 (Prague) is not essential.=

Please volunteer by sending me an email before 23:59 UTC June 24, 202= 0, as follows:

To: n= omcom-chair-2020@ietf.org
Subject: NomCom 2020-21 Volunteer

Please include the following information in the email body:
Your Full Name:
=C2=A0=C2=A0=C2=A0// as you write it on the IETF registration form

Current Primary Affiliation:
=C2=A0=C2=A0=C2=A0// Typically what goes in the Company field<= br> =C2=A0=C2=A0=C2=A0// in the IETF Registration Form

Emails:
=C2=A0=C2=A0// All email addresses used to register for the past 5 IE= TF meetings
=C2=A0=C2=A0// Preferred email address first

Telephone:
=C2=A0=C2=A0=C2=A0// For confirmation if selected

You should expect an email response from me within 5 business days st= ating whether or not you are qualified.=C2=A0 If you don't receive this= response, please re-send your email with the tag "RESEND"" = added to the subject line.

If you are not yet sure if you would like to volunteer, please consid= er that NomCom members play a very important role in shaping the leadership= of the IETF.=C2=A0 Questions by email or voice are welcome. Volunteering f= or the NomCom is a great way to contribute to the IETF!

You can find a detailed timeline on the NomCom web site at: =C2=A0=C2=A0=C2=A0https://urldefense.proofpoint.com/v2/url?u= =3Dhttps-3A__datatracker.ietf.org_nomcom_2020_&d=3DDwIDaQ&c=3DLFYZ-= o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3DZsNIRqCxjDeOYYDNal= OSHcuwQG23wBJtxzmEnsbPBtI&s=3DNgIu-7Ij0nEdsFcbJOLcl2M56RxyREhLAtcaHLatD= 34&e=3D

I will be publishing a more detailed target timetable, as well as det= ails of the randomness seeds to be used for the RFC 3797 selection process,= within the next few weeks.

Thank you!

Barbara Stark
bs7652 at att dot com
nomcom-chair-2020 at ietf dot org

--000000000000b488c705a7c1f419-- From nobody Wed Jun 10 17:15:14 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 C2D343A15CE for ; Wed, 10 Jun 2020 17:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=adligo-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 Z9KxyMTiy8pu for ; Wed, 10 Jun 2020 17:15:09 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 EEF133A15D2 for ; Wed, 10 Jun 2020 17:15:01 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id v13so3224717otp.4 for ; Wed, 10 Jun 2020 17:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adligo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=LVFwhYRvgkoTXxdHIxJs+4zbAjQJ3XZz+6PuhfZk0YY=; b=EUF8mg59eds/zpSd/gxcCIM6lue0QKiC3kmumHVVTayX1ck8i7pipOLDCkq1SsiJmY yDV2qJIRWc6KVlS3QaFxUiSTvhziktgdhUw8b4p5Vr+2ixqMxBSv0ZodZS4WkUFyaU7N CGLg5W+D1iIUSmOCJTa70ixLqw+KAV31Df77zBBZaOAEMMMJWh+9kxLS8gKFPAA23s6+ u/TmtBEIsBMpo8EAWn1BCDKgJzSNadYG3vXDxf2iZMYcnhRplL4NftI41k7PUZZPCt+2 LoL0Th10nMUnXogdblCTGtENXhngCZ27H/wiAo7Olzwxhhq4MLyMZLAIyJ9PpebfcA8Z mR1g== 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=LVFwhYRvgkoTXxdHIxJs+4zbAjQJ3XZz+6PuhfZk0YY=; b=maoFXl0Gb7rI0HtENJOaJvVgT3b1aBxGPGp7yVQgFRVxYZo2ATcz1Or2mP4L5zY46/ gKEJEBLj7A4HyqLKZNlzcEw3kJT3bLqHwr1yh1V6pNPeSnAQBInl6wSWkVp/dFNRKLKL DNqhOhfa3IfXZUmVxtRx67jjXOW0BrWhAbZHApPEG6gEvQTbCB4TEg7mHhkGyj8bTqaw cl80ozGdUP3y4vNuCvdGCvjVbI/kN9wbrhP2uANrPkbpWiOhhm17eV1/Ah9IIfFdQPEt xpH6etfY06LCQyOzG2utBXjk58/dYMTkwIRQPeSqCAg8g6T6gSjbvG1icuGvt9XOzcpE TFIA== X-Gm-Message-State: AOAM530VWFFRMc8aj0iFAJnQPWK8CKQjGJesPeTN12Uz3m8IRR2Jd2WK qki3YfbHbOZGgpv6Q+AyKFQc+1/2vtmNGy6qm/FdCT9XeDw= X-Google-Smtp-Source: ABdhPJypNk+YIbEVK5Sh19j6748hQNmAAlVvYdqE9vuYpnkv4JI1wCb9zRIBOqJn4uZTWUHef8V3PGCGvZAGAmWk3r0= X-Received: by 2002:a05:6830:1f1b:: with SMTP id u27mr4881712otg.327.1591834500551; Wed, 10 Jun 2020 17:15:00 -0700 (PDT) MIME-Version: 1.0 From: Scott Morgan Date: Wed, 10 Jun 2020 19:14:49 -0500 Message-ID: To: webtransport@ietf.org Content-Type: multipart/alternative; boundary="000000000000f2674105a7c3d9ed" Archived-At: Subject: [Webtransport] Standards for protocol headers? 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: Thu, 11 Jun 2020 00:15:12 -0000 --000000000000f2674105a7c3d9ed Content-Type: text/plain; charset="UTF-8" Hi All, I have been working with JSON, XML and some protocol headers recently and I am wondering... Why are there no real standard text formats for protocol headers, or am I missing something? It seems to me that a slightly more streamlined/optimal binary/markup standard could help protocols attain POCs and adoption much quicker and help reduce some of the work defining protocols. Any thoughts on this topic? -- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating https://github.com/adligo By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: *https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI * --000000000000f2674105a7c3d9ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

=C2=A0 =C2=A0I have been workin= g with JSON, XML and some protocol headers recently and I am wondering...
Why are there no real standard text formats for protocol=C2=A0head= ers,=C2=A0or am I missing something?

It seems to m= e that a slightly more streamlined/optimal binary/markup standard could hel= p protocols attain POCs and adoption much quicker and help reduce some of t= he work defining protocols.

Any thoughts on this t= opic?=C2=A0
--000000000000f2674105a7c3d9ed-- From nobody Thu Jun 11 05:53:26 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 B1AC23A07F4 for ; Thu, 11 Jun 2020 05:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 zwL1ocRbpKsJ for ; Thu, 11 Jun 2020 05:53:22 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933573A07EE for ; Thu, 11 Jun 2020 05:53:22 -0700 (PDT) Received: from [IPv6:2601:648:8400:8e7d:89bb:56c8:5bed:d3de] (unknown [IPv6:2601:648:8400:8e7d:89bb:56c8:5bed:d3de]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 19822AE4A2; Thu, 11 Jun 2020 14:53:18 +0200 (CEST) To: Scott Morgan , webtransport@ietf.org References: From: Marc Petit-Huguenin Autocrypt: addr=marc@petit-huguenin.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtC1NYXJjIFBldGl0 LUh1Z3VlbmluIDxtYXJjQHBldGl0LWh1Z3VlbmluLm9yZz6JAjsEEwEIACUCGyMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheAAhkBBQJX8tdbAAoJECnERZXWan7EiNkQAIbS72cyalFjxQ1l vEW9S8NjjwIMbb5+NC2XqDakAmZq+Aav/Yfk8aEc+eAWBboVC3NBBjYojMRXK1XEnD7xPQ1X rWd23TDibKajy/2fo/MS9/s6uPFOAINi1ykOMq8ShxMHcIPC/dvVt59a7DV1KPGlnUheNR7N 4rIbkL5KndatD38yTGkyKsFvVKTHJn3y5zqHTGP0BjE1rxsGEBn4h+EzxVCIMVFQUeMVPKPV dlQY9fxdicSGPK2WKo1KL3CVpnYTuNCAVIGA9DPTXPPKvEte+/+xv10I03pj4w87iMUZt7Ca FTO55Gsf8hZvmpuB224yzrAbquA450EUVcQ7KAPcHrph5KAu0d3nwrjrUDn/RWWbyRiVrPtf hmnAAhkSv7oOxzyMdLvqt7XKGKbABhrl1ZRF8QbquOkyu8n3Bz2Osgw7JyFn9N6svlFPmpML UTEi64NewvN6zszKs/zBS6bn7na75gxHNvjSZpSF6uSLYgmKbyG8vkY/i0s0e0njjOHcpNx1 0mNZ+wOoCgHtSCZFyv14ncioJTiSjtZCs+srW9PFlbOg73C1Op42xV5Y+dh/mCC+rweKtB3t yTAy52v8vPG0VjsLS52x6yUsoDjYV33AmTEaWmGzN5t8BX/qh7pgNIEd9TEwrR3B4LjqMmUk XXWSJG5IM8Zr2OE/t2vyuQINBE6Mh9wBEAC/i4Lh4XEgwi/yHr3XLx/+f38ztn5rrk8XRsK2 WUpu5evxw9iK2oelqWtS71XkW57EavJOjvP4t8FWqRKED5jWN741n12iW/EeLx3KoHMcPTfY 4WWvprxiZPfnCIpQ8j8x0QQSA+Hf96BSkAkOGNkiJDuus5z4XwTktn9gFOwLVx4VRMo+lrCy um6BDHI+4/sOWnrNp2WptI4YKM/uA0HpuLpPKLra0ZW6Bp2TewNpAjbst/VHjqewab0PeSCn CQiHkqIibdgOATT0K6KoVtMxp/WPRSfVImfWCHjT2G7HFMcb6w/jlPSb+u4VtL9yn76CCg8F SqTtzFuqPtbXkhrdSgks/grxiQryMXwpO0uSuUgZ3u2TSs+65Bl2CM5cq+2aBIER5qhpnCv7 B00uHuoNqUEK0VEpLKcqi2ZeVM5oO8iOaBgS9Gh082HQ5JDijEV2J5e4rwXjbRnJ4hqpTjSy caW8HnPI+4S0aqVxbnqW7T6l/xnn7ivK3aPqaRKqUSedHCU3oHIU31n0o5+f5htQeDs/Tpzn ARHkyzu9vZ9CvQXk8daZorA+j/38q6mWU6Mw8FRIu1qPQDmqljobk3vC9BZRSJOn3P8jNMM7 w1j+7Da3rxGBylfa3fmHPyY7dvdyeLmsq7egzTJkpAMN55Qat7iuXeeCdBQLAFHLBP1tvwAR AQABiQIfBBgBCAAJAhsMBQJX8tdcAAoJECnERZXWan7EkMgP/isd3lrSsm/8t+U44LY0/x67 cPmiKa9biveywJZ9Y+Zu/pUP44dP670mY7PmEDGC6lRiPKGmhf7vqq6JJFOqX64VWePQ9QZp kkzAUmIJwQ2Kmcmfrs0J5w2Lf5qaNji25fQYbon0eUFy6eN3BNRSIcg0+OsH7HubTWfpZeJu B7V7k8OFt2+HDx7aNdNutDJIu4V25AzGfonARQzJK62cmB0pwYXpcyDO152OwP12XbpXxXA1 xHGYQBRL98pSbMU5xsMw8j9VQHQRS94aT9Qqnz9SrYuISnMV2WGyIE0rAY3GGz3IcN5LVE1N vSP51ih+YJg/qsBYs8obbfEIZelOuznWf120RgV7P+7ZWCSBohmchuyELQzl9D7FXfulkXA3 RapKQcGJMVPIHYgnlvmE0OXfJl1z09nYRQHitoQhWtviHWl7x/KL42aUzHirLR61iVA2kqkO BhU+u+g2w8qrZj+lJfXIxlbVyLOuBVqkfcK28AR9RriB4Q5hvbDeQJMgfZsV2hBt7huBOqkH nnbSCguqfnmwLGkxoM7RVjCQwvC1M57uwdKMlsTVaBP0RreZnrDngLamK+ibXYe7p8pPAWD9 cuHvkkjML7cIfuvbScDYRmGzia3V9+LVzQCm+q/6xUY1SZvrDz7OaJOy3Xb1d+aPhYaNC0TQ 7IqA1dx8rZYQ Message-ID: <2804eb55-e79a-3383-9ebf-cd4f495b273a@petit-huguenin.org> Date: Thu, 11 Jun 2020 05:53:08 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Vo7xQuMWpF6bofIxpYWB5Zy8cLG36bcdb" Archived-At: Subject: Re: [Webtransport] Standards for protocol headers? 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: Thu, 11 Jun 2020 12:53:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Vo7xQuMWpF6bofIxpYWB5Zy8cLG36bcdb Content-Type: multipart/mixed; boundary="jQlrzVCpqpIsDjHfCIOYTF3aQRuC7DEth"; protected-headers="v1" From: Marc Petit-Huguenin To: Scott Morgan , webtransport@ietf.org Message-ID: <2804eb55-e79a-3383-9ebf-cd4f495b273a@petit-huguenin.org> Subject: Re: [Webtransport] Standards for protocol headers? References: In-Reply-To: --jQlrzVCpqpIsDjHfCIOYTF3aQRuC7DEth Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, On 6/10/20 5:14 PM, Scott Morgan wrote: > Hi All, >=20 > I have been working with JSON, XML and some protocol headers recentl= y > and I am wondering... > Why are there no real standard text formats for protocol headers, or am= I > missing something? >=20 > It seems to me that a slightly more streamlined/optimal binary/markup > standard could help protocols attain POCs and adoption much quicker and= > help reduce some of the work defining protocols. >=20 > Any thoughts on this topic? >=20 >=20 Can you please elaborate on what you mean by "protocol header"? My under= standing of that term is the fixed part at the beginning of a PDU, PDU th= at also contains a variable length part after it (as in UDP Header, TCP H= eader, RTP Header, HTTP, SIP, SMTP etc...), but that definition does not = seem to apply to JSON or XML (as a whole). --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --jQlrzVCpqpIsDjHfCIOYTF3aQRuC7DEth-- --Vo7xQuMWpF6bofIxpYWB5Zy8cLG36bcdb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAl7iKTQACgkQKcRFldZq fsSwKA//WZuS/XMMLFKlfQ73cKp6eVOwZIjSBE+oQgYOx9uvR8b9mTP7c/yPvCl+ /PsE0XmyofHott67tVNFmPX5S83D28TPIhwPmk8XNV+khWjLsrsXOudkHdmLPhl6 D9kBuvqMnYbf/S7YkDLAwv42KYuG6Wvx0XPAbYnIXdtHDAV7SneWDdsh0WtROxA2 Hg/51GZ+SR3QdHw5MU2oJtx5potE+eYFh8b2A6KWbnhxaMsqZNnp386sSRpekP6E 0JXlB5OIvPc72MKawhI86Y30u3Zzzxgk9hp0vZsi+1oki9qvbDPptVSRe9+EPKel GfN2nJ4hJi0bFaEbxouA2mKMwq2WmlgXNjzJwkTYNfz0SQo0lumCo3JMKr8pEKbd rFHnNqGhF/TrKAC/9SRa/eFMiINQ4DCFBjPMn+zZoKOBhGkVyKkpZR2LV0b0ZVM8 3MW0oVo0Zmi2OAROmPWax3WmR3KwmiUr9G3F9Lchlr0rdcktLLDbbQrNom31hpWS DXOQq4o/5oToxIt/LiBfE7maYeWvG2P8nM9pk4sWvAEtmovLT9sjRFtDNMD/hrj6 dv0qb/S1OUCF9BDzrTSBl4H7asdk/IHAlXpa1PW11Ioqu/oKC6YyM66ogwKArkWc 3et7flVcWSEFOXjcRZis67CUyBfVVxE5/QjokXRb3lI/MSC2yw8= =S135 -----END PGP SIGNATURE----- --Vo7xQuMWpF6bofIxpYWB5Zy8cLG36bcdb-- From nobody Fri Jun 12 07:25:44 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 925CC3A0833 for ; Fri, 12 Jun 2020 07:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=adligo-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 WnXFRouAkmLE for ; Fri, 12 Jun 2020 07:25:40 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 DE6653A0841 for ; Fri, 12 Jun 2020 07:25:39 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id m2so7443206otr.12 for ; Fri, 12 Jun 2020 07:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adligo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=FsfJTnpUYP/TLiHlbaFg2uvQv4KfQX7HiZiRX8Znets=; b=D+2rAOEmCPO39ewUOQ9aaT7bd2BduhQ8NAPojr1yElKCSIM1oSbKFwMelroYdbyj6T TlaSpNqyJXGdF6NyYYBqLcKTsMZ/Q7hz9moPvngTooeeoEShM6ePQNaSC//GvaMfL+tx lWgf/CbXEJg51+pTeWuhXnU30Ompe5vgLGGRCzQYjz7tA4/jVm0U9EOK4bc03drXOD1c w1IcSRc+E5PC8bZG1mxz66RDISg6nNpBM7hRA1E6Y53c3Hb5AmfT+hJgc0p5RkCE72HG vQMOd24HhtUasZeXtpnViCpPYbjwro8CmKByviXxwKQqrP5h5GZginI1pbJwfTDPHi2Q L+7Q== 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; bh=FsfJTnpUYP/TLiHlbaFg2uvQv4KfQX7HiZiRX8Znets=; b=Ok+6YPruaHz2VBZ/PtS1Ef8hUcbxmm1BPdXi2p6B/+p24Eil6IWunmkusguI6dM2TD L+Qu8KmmDVB5Mwbisix87Xk9ECexLy/dMaD4hNa3vOyWJp0HBP9e2AiF4o7noq6vw4/+ FZVuBAhCcdCGJw8FvMng68A2xg86/nrU0b9dnB9wcOf5IP+Cu07nNSZ0HwosrTtSRf/p rd6mxZi9HCGxUpuoQ6kiy9+BewyW6tfjNG4Scc8Jr3iAWW4TVQU2IG+M6EkXulMS4UIe RVuh7+j4zDnnhKSQK7+X95ew8Z4woyKS+gzg6fnxH7DyEcAPPLYtLE2uIL1vOdo7hWqa XVvg== X-Gm-Message-State: AOAM533tNk+PVRbO0fvYkfocVrkQHHE0aMG6cmEXj/DHQ9M2cU5qz2Te FzTZ2u6LTL6vbFGj+uqUA6Q0E+M51zE6r/MVyIjddToXyQU= X-Google-Smtp-Source: ABdhPJysZYmxU/Auu1vmOOJj1bJkeQ3eznL+X6Kmwxfsx/PEpXKBKf0wCKqXEBn3/Ry2tyaNdLOxgQu6kRhepAf2Mf4= X-Received: by 2002:a05:6830:1f1b:: with SMTP id u27mr11368481otg.327.1591971937610; Fri, 12 Jun 2020 07:25:37 -0700 (PDT) MIME-Version: 1.0 References: <2804eb55-e79a-3383-9ebf-cd4f495b273a@petit-huguenin.org> In-Reply-To: <2804eb55-e79a-3383-9ebf-cd4f495b273a@petit-huguenin.org> From: Scott Morgan Date: Fri, 12 Jun 2020 09:25:26 -0500 Message-ID: To: webtransport@ietf.org Content-Type: multipart/alternative; boundary="000000000000d57fd705a7e3d98b" Archived-At: Subject: Re: [Webtransport] Standards for protocol headers? 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, 12 Jun 2020 14:25:43 -0000 --000000000000d57fd705a7e3d98b Content-Type: text/plain; charset="UTF-8" Hi Marc, Thanks for responding! I meant 'protocol header' in the broadest sense. I have implemented some protocols in the past (Web Socket v13, SMTP etc) and work a lot with JSON and XML as I mentioned previously. Here are some general frustrations (i.e. problem statement) that I'm looking to overcome; 1) JSON and XML generally lack support for binary data (there are some workarounds but nothing is super great). 2) JSON and XML both now have the concept of a Schema Note I think the concept of a Schema is a good thing but also feel that Schemas often don't cover all Metadata that needs to be covered. Perhaps the concept of a Schema needs to be enhanced by UsageMetadata information. Also note I am frustrated with JSON's inability to provide human readable schemas (multi line text in the .json file (not /n)). I also have frustrations with XML schemas and XML (like everyone else who now favors JSON over XML) 3) Protocol's often have Headers and other information which act in a similar fashion to Schemas (i.e. they describe / specify data structures) I'm wondering if it's time for a new markup language that can support binary data and assist in specifying protocol byte segments in addition to more general purpose transport and storage data (like JSON & XML do). I'm thinking about calling it 'Classification Markup Notation'. I messaged this to the group just to throw the idea out there, to get feedback and also to find collaborators. On Thu, Jun 11, 2020 at 7:53 AM Marc Petit-Huguenin wrote: > Hi, > > On 6/10/20 5:14 PM, Scott Morgan wrote: > > Hi All, > > > > I have been working with JSON, XML and some protocol headers recently > > and I am wondering... > > Why are there no real standard text formats for protocol headers, or am I > > missing something? > > > > It seems to me that a slightly more streamlined/optimal binary/markup > > standard could help protocols attain POCs and adoption much quicker and > > help reduce some of the work defining protocols. > > > > Any thoughts on this topic? > > > > > > Can you please elaborate on what you mean by "protocol header"? My > understanding of that term is the fixed part at the beginning of a PDU, PDU > that also contains a variable length part after it (as in UDP Header, TCP > Header, RTP Header, HTTP, SIP, SMTP etc...), but that definition does not > seem to apply to JSON or XML (as a whole). > > -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: https://marc.petit-huguenin.org > Profile: https://www.linkedin.com/in/petithug > > -- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating https://github.com/adligo By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: *https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI * --000000000000d57fd705a7e3d98b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Marc,

=C2=A0 =C2=A0Thanks for respon= ding!=C2=A0 I meant=C2=A0'protocol header' in the broadest sense.= =C2=A0 I have implemented some protocols in the past (Web Socket v13, SMTP = etc) and work a lot with JSON and XML as I mentioned previously.=C2=A0 Here= are some general frustrations (i.e. problem statement) that I'm lookin= g to overcome;

1) JSON and XML generally lack supp= ort for binary data (there are some workarounds but nothing is super great)= .
2) JSON and XML both now have the concept of a Schema
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Note I think the concept of a Schema is = a good thing but also feel that Schemas often don't cover all
=C2=A0 =C2=A0 =C2=A0Metadata that needs to be covered.=C2=A0 Perhaps the c= oncept of a Schema needs to be enhanced by UsageMetadata information.
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Also note I am frustrated with JSON&= #39;s=C2=A0inability to provide human readable schemas (multi line text in = the .json file (not /n)).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I als= o have frustrations with XML schemas and XML (like everyone else who now fa= vors JSON over XML)
3) Protocol's often have Headers and othe= r information which act in a similar fashion to Schemas (i.e. they describe= / specify data structures)

=C2=A0 I'm wonderi= ng if it's time for a new markup language that can support binary data = and assist in specifying protocol byte segments in addition to more general= purpose transport and storage data (like JSON & XML do).=C2=A0=C2=A0
=C2=A0 I'm thinking about calling it 'Classification Marku= p Notation'.

=C2=A0 I messaged this to the gro= up just to throw the idea out there, to get feedback and also to find colla= borators.
=C2=A0 =C2=A0

On Thu, Jun 11, 2020 at 7:53 AM Marc= Petit-Huguenin <marc@petit-h= uguenin.org> wrote:
Hi,

On 6/10/20 5:14 PM, Scott Morgan wrote:
> Hi All,
>
>=C2=A0 =C2=A0 I have been working with JSON, XML and some protocol head= ers recently
> and I am wondering...
> Why are there no real standard text formats for protocol headers, or a= m I
> missing something?
>
> It seems to me that a slightly more streamlined/optimal binary/markup<= br> > standard could help protocols attain POCs and adoption much quicker an= d
> help reduce some of the work defining protocols.
>
> Any thoughts on this topic?
>
>

Can you please elaborate on what you mean by "protocol header"?= =C2=A0 My understanding of that term is the fixed part at the beginning of = a PDU, PDU that also contains a variable length part after it (as in UDP He= ader, TCP Header, RTP Header, HTTP, SIP, SMTP etc...), but that definition = does not seem to apply to JSON or XML (as a whole).

--
Marc Petit-Huguenin
Email: marc@pe= tit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug



--
=
Regards,
Scott Morgan
President & CEO
Adligo Inc
A+ Better Business Bureau Rating
By Appointment Only:=C2=A0
1-866-968-1893 Ex 101
--000000000000d57fd705a7e3d98b-- From nobody Fri Jun 12 08:03:20 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 3B2CA3A0B38 for ; Fri, 12 Jun 2020 08:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 thLJWZ-14LPs for ; Fri, 12 Jun 2020 08:03:16 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636293A09D6 for ; Fri, 12 Jun 2020 08:03:16 -0700 (PDT) Received: from [IPv6:2601:648:8400:8e7d:89bb:56c8:5bed:d3de] (unknown [IPv6:2601:648:8400:8e7d:89bb:56c8:5bed:d3de]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 92F30AE4A2; Fri, 12 Jun 2020 17:03:13 +0200 (CEST) To: Scott Morgan , webtransport@ietf.org References: <2804eb55-e79a-3383-9ebf-cd4f495b273a@petit-huguenin.org> From: Marc Petit-Huguenin Autocrypt: addr=petithug@acm.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtCZNYXJjIFBldGl0 LUh1Z3VlbmluIDxwZXRpdGh1Z0BhY20ub3JnPokCOAQTAQgAIgIbIwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AFAlfy11wACgkQKcRFldZqfsRWqBAAu/61DGo+j38UefTKnEse0mftPBXa S4lre7vknn33MI0L5QXmiM8zRs9FOKSuXPx0EV+JhI4pWZGW/2MJPuyifXHvnIChcdGInN8J GBdTLZSOgdDFZL9msO+QUsvMA8ZUsqlKOEcVL1NyoLupblCWNq4fYhBCx1zDwX9LZSuGn8lZ Mk8a4QFGoR6dWKaOxeCwnoquW5IK1CfRIhYjHfQMjA5gY0H46F0iCqBaFF/S7krQwIJd0XN4 YbSL4KOrWuxtgQ+iH/iaxxBXgJ1blBNRzXaWJBF4PHv23nSnEzWO17j+uVMaHJu7ycYEf8T9 pVc0xcok1BM2rCrNE5FUFAzsUtAtBZEEK6sSIeOhRG93uD/Hv1hrWzEwf+Z7B1tVQLCQQ4kL 7wyS7SXI/JTuW2xTEGCmwMeWYGERdkgsatmx4zi5nVHDjt3/mlPMj4L+u05SkI2iV4W6xxU1 jHlBIJDs7AVM0dsxzTyIPf2Sz843WyHuBgkoCskxGfOwlkZzDX9rwcWRKal1wjy1w/25LsBY U50INandw3UbrS2I73VX8ARI8uOWZrW7uzRLf8EmuPhtSQ35ThmdoNSgGMP9EXwNgzi/i+5G hbX5KbrSLG9SITFJEcJA4tnwu3nqmBh7D7vbd5ln5X7rmqPdyjidt0zcSjvuaBA+nkmakA4A O+choWy5Ag0EToyH3AEQAL+LguHhcSDCL/IevdcvH/5/fzO2fmuuTxdGwrZZSm7l6/HD2Ira h6Wpa1LvVeRbnsRq8k6O8/i3wVapEoQPmNY3vjWfXaJb8R4vHcqgcxw9N9jhZa+mvGJk9+cI ilDyPzHRBBID4d/3oFKQCQ4Y2SIkO66znPhfBOS2f2AU7AtXHhVEyj6WsLK6boEMcj7j+w5a es2nZam0jhgoz+4DQem4uk8outrRlboGnZN7A2kCNuy39UeOp7BpvQ95IKcJCIeSoiJt2A4B NPQroqhW0zGn9Y9FJ9UiZ9YIeNPYbscUxxvrD+OU9Jv67hW0v3KfvoIKDwVKpO3MW6o+1teS Gt1KCSz+CvGJCvIxfCk7S5K5SBne7ZNKz7rkGXYIzlyr7ZoEgRHmqGmcK/sHTS4e6g2pQQrR USkspyqLZl5Uzmg7yI5oGBL0aHTzYdDkkOKMRXYnl7ivBeNtGcniGqlONLJxpbwec8j7hLRq pXFuepbtPqX/GefuK8rdo+ppEqpRJ50cJTegchTfWfSjn5/mG1B4Oz9OnOcBEeTLO729n0K9 BeTx1pmisD6P/fyrqZZTozDwVEi7Wo9AOaqWOhuTe8L0FlFIk6fc/yM0wzvDWP7sNrevEYHK V9rd+Yc/Jjt293J4uayrt6DNMmSkAw3nlBq3uK5d54J0FAsAUcsE/W2/ABEBAAGJAh8EGAEI AAkCGwwFAlfy11wACgkQKcRFldZqfsSQyA/+Kx3eWtKyb/y35TjgtjT/Hrtw+aIpr1uK97LA ln1j5m7+lQ/jh0/rvSZjs+YQMYLqVGI8oaaF/u+qrokkU6pfrhVZ49D1BmmSTMBSYgnBDYqZ yZ+uzQnnDYt/mpo2OLbl9BhuifR5QXLp43cE1FIhyDT46wfse5tNZ+ll4m4HtXuTw4W3b4cP Hto10260Mki7hXbkDMZ+icBFDMkrrZyYHSnBhelzIM7XnY7A/XZdulfFcDXEcZhAFEv3ylJs xTnGwzDyP1VAdBFL3hpP1CqfP1Kti4hKcxXZYbIgTSsBjcYbPchw3ktUTU29I/nWKH5gmD+q wFizyhtt8Qhl6U67OdZ/XbRGBXs/7tlYJIGiGZyG7IQtDOX0PsVd+6WRcDdFqkpBwYkxU8gd iCeW+YTQ5d8mXXPT2dhFAeK2hCFa2+IdaXvH8ovjZpTMeKstHrWJUDaSqQ4GFT676DbDyqtm P6Ul9cjGVtXIs64FWqR9wrbwBH1GuIHhDmG9sN5AkyB9mxXaEG3uG4E6qQeedtIKC6p+ebAs aTGgztFWMJDC8LUznu7B0oyWxNVoE/RGt5mesOeAtqYr6Jtdh7unyk8BYP1y4e+SSMwvtwh+ 69tJwNhGYbOJrdX34tXNAKb6r/rFRjVJm+sPPs5ok7LddvV35o+Fho0LRNDsioDV3HytlhA= Message-ID: Date: Fri, 12 Jun 2020 08:03:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Pmw2ASNA6gA0YHWOLahJA9k9BGqzVcFBF" Archived-At: Subject: Re: [Webtransport] Standards for protocol headers? 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, 12 Jun 2020 15:03:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Pmw2ASNA6gA0YHWOLahJA9k9BGqzVcFBF Content-Type: multipart/mixed; boundary="aeaHsoj6FjWzclI85krZ9s2LqVGA7xaYW"; protected-headers="v1" From: Marc Petit-Huguenin To: Scott Morgan , webtransport@ietf.org Message-ID: Subject: Re: [Webtransport] Standards for protocol headers? References: <2804eb55-e79a-3383-9ebf-cd4f495b273a@petit-huguenin.org> In-Reply-To: --aeaHsoj6FjWzclI85krZ9s2LqVGA7xaYW Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Scott, I still find your terminology confusing. I am not sure if you are propos= ing to design a new PDU description language (ala ASN.1, ABNF, RBNF, CDDL= , XML RELAX, etc..) or a new structured PDU format (ala DER, BER, XML, JS= ON, CBOR, etc...). If it is the former, I would suggest to resend your e= mail to fdt@ietf.org, where we discuss this kind of things. Thanks. On 6/12/20 7:25 AM, Scott Morgan wrote: > Hi Marc, >=20 > Thanks for responding! I meant 'protocol header' in the broadest > sense. I have implemented some protocols in the past (Web Socket v13, = SMTP > etc) and work a lot with JSON and XML as I mentioned previously. Here = are > some general frustrations (i.e. problem statement) that I'm looking to > overcome; >=20 > 1) JSON and XML generally lack support for binary data (there are some > workarounds but nothing is super great). > 2) JSON and XML both now have the concept of a Schema > Note I think the concept of a Schema is a good thing but also = feel > that Schemas often don't cover all > Metadata that needs to be covered. Perhaps the concept of a Schem= a > needs to be enhanced by UsageMetadata information. > Also note I am frustrated with JSON's inability to provide hum= an > readable schemas (multi line text in the .json file (not /n)). > I also have frustrations with XML schemas and XML (like everyo= ne > else who now favors JSON over XML) > 3) Protocol's often have Headers and other information which act in a > similar fashion to Schemas (i.e. they describe / specify data structure= s) >=20 > I'm wondering if it's time for a new markup language that can support= > binary data and assist in specifying protocol byte segments in addition= to > more general purpose transport and storage data (like JSON & XML do). > I'm thinking about calling it 'Classification Markup Notation'. >=20 > I messaged this to the group just to throw the idea out there, to get= > feedback and also to find collaborators. >=20 >=20 > On Thu, Jun 11, 2020 at 7:53 AM Marc Petit-Huguenin > wrote: >=20 >> Hi, >> >> On 6/10/20 5:14 PM, Scott Morgan wrote: >>> Hi All, >>> >>> I have been working with JSON, XML and some protocol headers recen= tly >>> and I am wondering... >>> Why are there no real standard text formats for protocol headers, or = am I >>> missing something? >>> >>> It seems to me that a slightly more streamlined/optimal binary/markup= >>> standard could help protocols attain POCs and adoption much quicker a= nd >>> help reduce some of the work defining protocols. >>> >>> Any thoughts on this topic? >>> >>> >> >> Can you please elaborate on what you mean by "protocol header"? My >> understanding of that term is the fixed part at the beginning of a PDU= , PDU >> that also contains a variable length part after it (as in UDP Header, = TCP >> Header, RTP Header, HTTP, SIP, SMTP etc...), but that definition does = not >> seem to apply to JSON or XML (as a whole). >> --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --aeaHsoj6FjWzclI85krZ9s2LqVGA7xaYW-- --Pmw2ASNA6gA0YHWOLahJA9k9BGqzVcFBF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAl7jmSUACgkQKcRFldZq fsR4axAAmJGrEqCUESb1mQte8K/mUHH7aI9fSuDsxi4g+qvTiHrEsgeLruEKog6Y QBWJ646q+29qoQQU8Sb1pfXAcLa5qec+b/5CxqEzmk4R+JZ7KNGQGwi7gRizMazY aj40yrBy4AM3+0J0fopZNSgNGL6Kda8vLuBR26zUIxnP3zeec530mlGFvxu5ID/D OHMGkR6HxPVClRXpkbKq9PTEjz0ne9v9lCmiuntN4uOE1NLgW72g8koeopU+uOip lBNfaRqS1vAP3llSGUixWqY5yFBPx/l12kJr0C+9ibOJm1d4/tuMfXJgBKfIqJmU oI4gi2N0sf7NjKgbThBjevRe+egftRSMoe+IhEwCR41uxwiTXws80AkK1a0kzUP1 eul543mthQT9my6pV7RAjlkrv0v5DjEDIkGII9VMYSPiktOGDoSJ3mmNA9BdFWpm 7MFHnh1tn/D6QN8GVRw1GR1wWwVceXHVIpPMuFr3oQXNHWedgiWW/yiui1IZbD3A VQEWhV1Ta43TXgHD37prBtm1D7d8MAQkBSUlkqDVkBE6+hnhnwHAF5IqhRLLf969 kKuqPGTDlW31OxYUG0U9xPd62pLe1FDPiyXLEvM+IkAMUX8ZUtrtlIreq6i2thm/ Gv4Jd41aPZtEeqGtJNXcMimllJRjpwSZoQ8mj5cwf5ody44gquY= =qjWc -----END PGP SIGNATURE----- --Pmw2ASNA6gA0YHWOLahJA9k9BGqzVcFBF-- From nobody Fri Jun 12 17:53:20 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 031183A1682 for ; Fri, 12 Jun 2020 17:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=adligo-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 rA21eWGJKc-S for ; Fri, 12 Jun 2020 17:53:16 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97733A167C for ; Fri, 12 Jun 2020 17:53:16 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id x202so10394896oix.11 for ; Fri, 12 Jun 2020 17:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adligo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JhFHs77HANS5/BIIZ1afcIssx+jzBXfkDFXSL2A0Kzc=; b=JD42XqbSo+9SAMvR7raciYWjfjG+7N5WfupS2OY0r0aQQ+SFiwP9QZz1lnNCH1Yefk 9G5AH59GdmtYVbffs1lOIA1uPOvZBdXBm8yaipOezN9s25ypdRTQcAyBWNIKDMJ5+tQj fHcM3FrtlX9J7s387ZJILpRJHyDyCmwjlIs1m/yEpOixnhevyApyTKiEi+Wgz0DJvLqw bgXdpwx8fstk5rRlO8OOysYh2J/OXu7nbP0o7gSKdrwGWFm9lDIj0uiLFybPn4JfJa/o P+77PBxG3j0qpZK8XwRvZsr2hqc4ZmUUBsSlczyCngwRjD1/g9YB/Jtwrno2ojSx8XHU AeTw== 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; bh=JhFHs77HANS5/BIIZ1afcIssx+jzBXfkDFXSL2A0Kzc=; b=VpQXT9LIcUddZKR6Kt1XhVP86PF6CmwoSFxyKTAWRJZeEDYMFwFxn1s6Y1BWa/cfzk vLtCvW5i1VRyNP1fZxGNRpAGZJ87/cRayoG1Oz7WZ/C7/9d7+8UdrR89XoykC2UStKBY RrlT+pvtc8NzwAnnKVDULIeEsUbJKTuXvtBSnEt35Mo+2jb+bDl2C8Bfonabsg04uzgd OgR/uh56l05Nze7k3ogbsGm/iwooGxcQaxFOMWGAE6unoI/aI4ISDz7lCgz9V0T3PnCn p67DulLLqakRPYRdP6GCFG7DpZjp2hy6ciBcsbd5NmOkzUziLq5C7K5GXwxsHIPeMIWy SDxg== X-Gm-Message-State: AOAM531t49TvW7B4pvOstlGNUy1wbPOH3K7eGbyzm+A3XVzDFPAyZg/2 XEC8toriGf+bfx9stOPJil4QNsJVt1jf5rZXnVOtcA== X-Google-Smtp-Source: ABdhPJwtSEi1YWp0RdWAQwBWhR34d2Ux+kYl8Pdj5nYaLVkdiTQdjHdCnhAeCJ6DIOz2ovjSTTMcTpmQkl2NK3G+j48= X-Received: by 2002:aca:902:: with SMTP id 2mr1100462oij.151.1592009595870; Fri, 12 Jun 2020 17:53:15 -0700 (PDT) MIME-Version: 1.0 References: <2804eb55-e79a-3383-9ebf-cd4f495b273a@petit-huguenin.org> In-Reply-To: From: Scott Morgan Date: Fri, 12 Jun 2020 19:53:04 -0500 Message-ID: To: fdt@ietf.org, webtransport@ietf.org Content-Type: multipart/mixed; boundary="000000000000717e5405a7ec9e8f" Archived-At: Subject: [Webtransport] Fwd: Standards for protocol headers? 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, 13 Jun 2020 00:53:19 -0000 --000000000000717e5405a7ec9e8f Content-Type: multipart/alternative; boundary="000000000000717e5205a7ec9e8d" --000000000000717e5205a7ec9e8d Content-Type: text/plain; charset="UTF-8" Hi Marc, Thanks, I'm not trying to be intentionally confusing :) In an attempt to clarify, I'm trying to create a new structured PDU format that could be used to define PDU description languages (not a primary concern) as well as larger data structures like files or bytes in datagrams. https://en.wikipedia.org/wiki/Protocol_data_unit Lets continue @ fdt@ietf.org ! Cheers, Scott ---------- Forwarded message --------- From: Marc Petit-Huguenin Date: Fri, Jun 12, 2020 at 10:03 AM Subject: Re: [Webtransport] Standards for protocol headers? To: Scott Morgan , Hi Scott, I still find your terminology confusing. I am not sure if you are proposing to design a new PDU description language (ala ASN.1, ABNF, RBNF, CDDL, XML RELAX, etc..) or a new structured PDU format (ala DER, BER, XML, JSON, CBOR, etc...). If it is the former, I would suggest to resend your email to fdt@ietf.org, where we discuss this kind of things. Thanks. On 6/12/20 7:25 AM, Scott Morgan wrote: > Hi Marc, > > Thanks for responding! I meant 'protocol header' in the broadest > sense. I have implemented some protocols in the past (Web Socket v13, SMTP > etc) and work a lot with JSON and XML as I mentioned previously. Here are > some general frustrations (i.e. problem statement) that I'm looking to > overcome; > > 1) JSON and XML generally lack support for binary data (there are some > workarounds but nothing is super great). > 2) JSON and XML both now have the concept of a Schema > Note I think the concept of a Schema is a good thing but also feel > that Schemas often don't cover all > Metadata that needs to be covered. Perhaps the concept of a Schema > needs to be enhanced by UsageMetadata information. > Also note I am frustrated with JSON's inability to provide human > readable schemas (multi line text in the .json file (not /n)). > I also have frustrations with XML schemas and XML (like everyone > else who now favors JSON over XML) > 3) Protocol's often have Headers and other information which act in a > similar fashion to Schemas (i.e. they describe / specify data structures) > > I'm wondering if it's time for a new markup language that can support > binary data and assist in specifying protocol byte segments in addition to > more general purpose transport and storage data (like JSON & XML do). > I'm thinking about calling it 'Classification Markup Notation'. > > I messaged this to the group just to throw the idea out there, to get > feedback and also to find collaborators. > > > On Thu, Jun 11, 2020 at 7:53 AM Marc Petit-Huguenin < marc@petit-huguenin.org> > wrote: > >> Hi, >> >> On 6/10/20 5:14 PM, Scott Morgan wrote: >>> Hi All, >>> >>> I have been working with JSON, XML and some protocol headers recently >>> and I am wondering... >>> Why are there no real standard text formats for protocol headers, or am I >>> missing something? >>> >>> It seems to me that a slightly more streamlined/optimal binary/markup >>> standard could help protocols attain POCs and adoption much quicker and >>> help reduce some of the work defining protocols. >>> >>> Any thoughts on this topic? >>> >>> >> >> Can you please elaborate on what you mean by "protocol header"? My >> understanding of that term is the fixed part at the beginning of a PDU, PDU >> that also contains a variable length part after it (as in UDP Header, TCP >> Header, RTP Header, HTTP, SIP, SMTP etc...), but that definition does not >> seem to apply to JSON or XML (as a whole). >> -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug -- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating https://github.com/adligo By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: *https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI * --000000000000717e5205a7ec9e8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Marc,

=C2=A0 =C2=A0Thanks, I'm n= ot trying to be intentionally confusing :)=C2=A0 In an attempt to clarify, = I'm trying to create a new structured PDU format that could be used to = define PDU description languages (not a primary concern) as well as larger = data structures like files or bytes in=C2=A0datagrams.=C2=A0=C2=A0

Let= s continue=C2=A0@ fdt@ietf.org !
<= div>
Cheers,
Scott

---------- Forwarded message ------= ---
From: Marc Petit-Hug= uenin <p= etithug@acm.org>
Date: Fri, Jun 12, 2020 at 10:03 AM
Su= bject: Re: [Webtransport] Standards for protocol headers?
To: Scott Morg= an <scott@adligo.com>, <<= a href=3D"mailto:webtransport@ietf.org">webtransport@ietf.org>


Hi Scott,

I still find your terminology confusing.=C2=A0 I am not sure if you are pro= posing to design a new PDU description language (ala ASN.1, ABNF, RBNF, CDD= L, XML RELAX, etc..) or a new structured PDU format (ala DER, BER, XML, JSO= N, CBOR, etc...).=C2=A0 If it is the former, I would suggest to resend your= email to fdt@ietf.org, where we discuss this kind of things.

Thanks.

On 6/12/20 7:25 AM, Scott Morgan wrote:
> Hi Marc,
>
>=C2=A0 =C2=A0 Thanks for responding!=C2=A0 I meant 'protocol header= ' in the broadest
> sense.=C2=A0 I have implemented some protocols in the past (Web Socket= v13, SMTP
> etc) and work a lot with JSON and XML as I mentioned previously.=C2=A0= Here are
> some general frustrations (i.e. problem statement) that I'm lookin= g to
> overcome;
>
> 1) JSON and XML generally lack support for binary data (there are some=
> workarounds but nothing is super great).
> 2) JSON and XML both now have the concept of a Schema
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Note I think the concept of a Schema= is a good thing but also feel
> that Schemas often don't cover all
>=C2=A0 =C2=A0 =C2=A0 Metadata that needs to be covered.=C2=A0 Perhaps t= he concept of a Schema
> needs to be enhanced by UsageMetadata information.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Also note I am frustrated with JSON&= #39;s inability to provide human
> readable schemas (multi line text in the .json file (not /n)).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I also have frustrations with XML sc= hemas and XML (like everyone
> else who now favors JSON over XML)
> 3) Protocol's often have Headers and other information which act i= n a
> similar fashion to Schemas (i.e. they describe / specify data structur= es)
>
>=C2=A0 =C2=A0I'm wondering if it's time for a new markup langua= ge that can support
> binary data and assist in specifying protocol byte segments in additio= n to
> more general purpose transport and storage data (like JSON & XML d= o).
>=C2=A0 =C2=A0I'm thinking about calling it 'Classification Mark= up Notation'.
>
>=C2=A0 =C2=A0I messaged this to the group just to throw the idea out th= ere, to get
> feedback and also to find collaborators.
>
>
> On Thu, Jun 11, 2020 at 7:53 AM Marc Petit-Huguenin <marc@petit-huguenin.org&= gt;
> wrote:
>
>> Hi,
>>
>> On 6/10/20 5:14 PM, Scott Morgan wrote:
>>> Hi All,
>>>
>>>=C2=A0 =C2=A0 I have been working with JSON, XML and some proto= col headers recently
>>> and I am wondering...
>>> Why are there no real standard text formats for protocol heade= rs, or am I
>>> missing something?
>>>
>>> It seems to me that a slightly more streamlined/optimal binary= /markup
>>> standard could help protocols attain POCs and adoption much qu= icker and
>>> help reduce some of the work defining protocols.
>>>
>>> Any thoughts on this topic?
>>>
>>>
>>
>> Can you please elaborate on what you mean by "protocol header= "?=C2=A0 My
>> understanding of that term is the fixed part at the beginning of a= PDU, PDU
>> that also contains a variable length part after it (as in UDP Head= er, TCP
>> Header, RTP Header, HTTP, SIP, SMTP etc...), but that definition d= oes not
>> seem to apply to JSON or XML (as a whole).
>>

--
Marc Petit-Huguenin
Email: marc@pe= tit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug



--
=
Regards,
Scott Morgan
= President & CEO
Adligo Inc
https://www.linkedin.com/in/scott-morgan-21739415<= span style=3D"color:rgb(0,0,0);font-family:"Arial Unicode MS",Ari= al,sans-serif;font-size:small;font-weight:bold;text-align:-webkit-right">

By Appoi= ntment Only:=C2=A0
1-866-968-1893 Ex 101
Send Me Files Securely:=C2= =A0


=

=
--000000000000717e5205a7ec9e8d-- --000000000000717e5405a7ec9e8f Content-Type: text/plain; charset="US-ASCII"; name="signature.asc" Content-Disposition: attachment; filename="signature.asc" Content-Transfer-Encoding: base64 Content-ID: <172ab20344961a8e03b1> X-Attachment-Id: 172ab20344961a8e03b1 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCg0KaVFJekJBRUJDQUFkRmlFRUJTSStJdUNI VThNc0kxR2pLY1JGbGRacWZzUUZBbDdqbVNVQUNna1FLY1JGbGRacQ0KZnNSNGF4QUFtSkdyRXFD VUVTYjFtUXRlOEsvbVVISDdhSTlmU3VEc3hpNGcrcXZUaUhyRXNnZUxydUVLb2c2WQ0KUUJXSjY0 NnErMjlxb1FRVThTYjFwZlhBY0xhNXFlYytiLzVDeHFFem1rNFIrSlo3S05HUUd3aTdnUml6TWF6 WQ0KYWo0MHlyQnk0QU0zKzBKMGZvcFpOU2dOR0w2S2RhOHZMdUJSMjZ6VUl4blAzemVlYzUzMG1s R0Z2eHU1SUQvRA0KT0hNR2tSNkh4UFZDbFJYcGtiS3E5UFRFanowbmU5djlsQ21pdW50TjR1T0Ux TkxnVzcyZzhrb2VvcFUrdU9pcA0KbEJOZmFScVMxdkFQM2xsU0dVaXhXcVk1eUZCUHgvbDEya0py MEMrOWliT0ptMWQ0L3R1TWZYSmdCS2ZJcUptVQ0Kb0k0Z2kyTjBzZjdOaktnYlRoQmpldlJlK2Vn ZnRSU01vZStJaEV3Q1I0MXV4d2lUWHdzODBBa0sxYTBrelVQMQ0KZXVsNTQzbXRoUVQ5bXk2cFY3 UkFqbGtydjB2NURqRURJa0dJSTlWTVlTUGlrdE9HRG9TSjNtbU5BOUJkRldwbQ0KN01GSG5oMXRu L0Q2UU44R1ZSdzFHUjF3V3dWY2VYSFZJcFBNdUZyM29RWE5IV2VkZ2lXVy95aXVpMUlaYkQzQQ0K VlFFV2hWMVRhNDNUWGdIRDM3cHJCdG0xRDdkOE1BUWtCU1Vsa3FEVmtCRTYraG5obndIQUY1SXFo UkxMZjk2OQ0Ka0t1cVBHVERsVzMxT3hZVUcwVTl4UGQ2MnBMZTFGRFBpeVhMRXZNK0lrQU1VWDha VXRydGxJcmVxNmkydGhtLw0KR3Y0SmQ0MWFQWnRFZXFHdEpOWGNNaW1sbEpSanB3U1pvUThtajVj d2Y1b2R5NDRncXVZPQ0KPXFqV2MNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K --000000000000717e5405a7ec9e8f-- From nobody Sat Jun 13 05:08: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 212AF3A0840; Sat, 13 Jun 2020 05:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 (1024-bit key) header.d=gla.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_bqTgPvhaxC; Sat, 13 Jun 2020 05:08:02 -0700 (PDT) Received: from plockton.cent.gla.ac.uk (plockton.cent.gla.ac.uk [130.209.16.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A5003A0845; Sat, 13 Jun 2020 05:08:00 -0700 (PDT) Received: from cas08.campus.gla.ac.uk ([130.209.14.165]) by plockton.cent.gla.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1jk4x4-0007Ad-7t; Sat, 13 Jun 2020 13:07:58 +0100 Received: from CAS08.campus.gla.ac.uk (130.209.14.165) by cas08.campus.gla.ac.uk (130.209.14.165) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 13 Jun 2020 13:07:56 +0100 Received: from GBR01-LO2-obe.outbound.protection.outlook.com (104.47.21.51) by CAS08.campus.gla.ac.uk (130.209.14.165) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sat, 13 Jun 2020 13:07:56 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JQZRVJ9yodpVBiY5nnGQ7xQnAhXGwNxTlzHOC+6KhvJq1Ati0ZeudW3zwx6vpNy28usN3i+H+G/UpgxQccBV+3YnpeVV7+P506QfgguhOWmH43iatrnQQ2IoMqKzFyg8nXauSIp6r32UXfSphi2KSfwoPhH5HLbCQklhkrlRngPuBUF3A8/WVOI8/zNfD1zwvQYQMpycy5RWM7i0c5RGQ7esnfd7hnR1XmLoZCbF222E2bZKcr2bQ+/mBxnPHhG723tZ6r4VQk69/KlDo2vYdWQdsqniq4bd1cil270hYwBYDhDJH/f//rTpz4w1qZxoKKmlnAQNR23kutazlzGwTA== 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=R7vv3T+SPrJDQ/mISJ2bSgy8sg2mFzhEJclZw61sswA=; b=acnEeJSPMgsTBJNxvbqSyZdZDp7f+UnAC1d4RUUaAdy/5T10HzYV5OBBDtXC28wnuBs/nLKAmPDtqOnKvLfn6QdS9hdQ1jUThRrvVZC6GGL3nGDl/lydddUyLEgQLNaX8czGnLgbrf7S8WkIQoeeTc/w4PQxuC0vMBoA2m6gejqzMjR8MBLu7B4ObWfmhiunKqNx/nR0EkDeLExdl5n5Uk9WkeFQKGe5CdH+q10AJYPpt1FjenxCmz/SUGTfMcXMM35SoHT1O1tXeFNClER3E6hgsI4SaX8zD/6YxtCDaimMaLNzWwDvhF9izloBnggkG6xwcfgHmMwOSvWnmegCTw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=glasgow.ac.uk; dmarc=pass action=none header.from=glasgow.ac.uk; dkim=pass header.d=glasgow.ac.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gla.onmicrosoft.com; s=selector2-gla-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R7vv3T+SPrJDQ/mISJ2bSgy8sg2mFzhEJclZw61sswA=; b=oJ4DLkZmFm8BAA+Fj5RR2+0ioCg2cbD9YYetistbFWvss6bFfh5yl+8mfECPkFevBIPsA942/kxrJYoxS0ELqc6+sVffyF2kuN0BpqerbTztlgfZ9JOcYUc0uAFenUA6Yt+4FZ6eC0XKWg5H4aNGHmxHE/Tdctq4dOr+Nu9iWsE= Received: from LNXP265MB0827.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:1d::22) by LNXP265MB0314.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:1d::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.24; Sat, 13 Jun 2020 12:07:56 +0000 Received: from LNXP265MB0827.GBRP265.PROD.OUTLOOK.COM ([fe80::3190:f704:b62f:7371]) by LNXP265MB0827.GBRP265.PROD.OUTLOOK.COM ([fe80::3190:f704:b62f:7371%7]) with mapi id 15.20.3088.025; Sat, 13 Jun 2020 12:07:56 +0000 From: Stephen McQuistin To: Scott Morgan CC: "fdt@ietf.org" , "webtransport@ietf.org" Thread-Topic: [fdt] [Webtransport] Standards for protocol headers? Thread-Index: AQHWQXtF2VgPKOyIBkShMpks519YkA== Date: Sat, 13 Jun 2020 12:07:55 +0000 Message-ID: <9796F6C9-ABB9-4AD4-ADA0-A6E275DAE3EE@glasgow.ac.uk> References: <2804eb55-e79a-3383-9ebf-cd4f495b273a@petit-huguenin.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: adligo.com; dkim=none (message not signed) header.d=none;adligo.com; dmarc=none action=none header.from=glasgow.ac.uk; x-originating-ip: [81.157.158.157] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2b01b35b-dbef-44b4-21c6-08d80f92682c x-ms-traffictypediagnostic: LNXP265MB0314: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0433DB2766 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gTbwpSF0vpVqX1SSJCyx0FfwZF9kghv/rMuT3x1daPC0BG8t7MphRa+75avgsUTJn+U0J5GJr3X1sRQBaK8XctHWNqNwZqV+o3ASPvPyUdap7lZiYXPzIYrrIvHWdJEdCr8rP4Ism8dpolHqzjiIOR7nQ4VBDRTw1Hb7v6oZ7/nDLaVesv4SoXKXpJvvv7nOiVVzOkBUtODJQzLncJBOKq5/g7bazzcQfzy9q7nRxHW+zFRfhCkB4tVbqO/3WDePxb+UXVfNdQzSHzzO8cPqJf10DiWNCAogz5W4Q0OPtQFPXrlCS+wp7zrIGeiLQgSynC/imTep+aLXcZeLNu6mPHdZ8DxSDeKN+Qj4a0NOASbob4cBS8foPRwFDZxzXcVDGZTUh3dh1IdkIlFG86LPtA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LNXP265MB0827.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(136003)(396003)(366004)(39860400002)(346002)(376002)(66476007)(66556008)(26005)(53546011)(6506007)(45080400002)(66946007)(6512007)(64756008)(66446008)(316002)(166002)(33656002)(76116006)(8936002)(36756003)(4326008)(786003)(83380400001)(54906003)(6916009)(6486002)(478600001)(2906002)(8676002)(86362001)(71200400001)(966005)(186003)(2616005)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: K406omGpKaT+wRRzNkkvmba4Xki/Qwy2CFRTkxF3ZyuypBVcvRomYQLlU4POcT0pQ5Q36Vz6n6qzSFqN5oc3m5XgDiD63VhPmdEV9LqrS0zRiO33iSjsRMbQTtfR8iI4tdUY2mVJcN4dFNa6zkbB1Wd3j5KELno9CM28Vzv1fvb/CQHQOs7XXywKYD5T+cR4UjVzQiIa2mpS9co3W7JhRuNQ58fsvoyc/G54f353DfagtlJHDT40PbLkiBO7X9uwY512fUPXw2UndWNM6h3BvjGIyKDGS88m/scaabDD5UlhEXvP1MBhJro8Rd5i30rfmruDKhLbZmIesymT3cmhq+u+tkTu9ToLBYjPw7e+rvt/DZrH5gynqmsWpFpSAmzC/69FHhj/hYrA5NbC5vzZ19ZPdS7QWoXc4bAtSY5ShBHe50woOHSAc/JbDsaueJ2UIYjlxTbyhL5kVQDnVRDXSJgAevk84Iaaf9UFs6f0W/v/VAJFzp5r3JeZW26fVbwl x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_9796F6C9ABB94AD4ADA0A6E275DAE3EEglasgowacuk_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2b01b35b-dbef-44b4-21c6-08d80f92682c X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2020 12:07:55.8680 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6e725c29-763a-4f50-81f2-2e254f0133c8 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: B8Yf9OJPtYQ5U9kqlGJrdapCpreHLmZ1pKN2LUnp0xpoJ5e3vnzcaVlpsF5SdvbiIbQ4wnE5KyhY46sDsuMQOCN/ZQnNEbg0wVOxkxSFRaw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP265MB0314 X-OriginatorOrg: glasgow.ac.uk Archived-At: Subject: Re: [Webtransport] [fdt] Standards for protocol headers? 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, 13 Jun 2020 12:08:05 -0000 --_000_9796F6C9ABB94AD4ADA0A6E275DAE3EEglasgowacuk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2NvdHQsDQoNCldlIGhhdmUgYSBkcmFmdCAoZHJhZnQtbWNxdWlzdGluLWF1Z21lbnRlZC1h c2NpaS1kaWFncmFtcykgdGhhdCBpcyBsb29raW5nIHRvIGFkZCB0b29saW5nIChlLmcuLCB0byBn ZW5lcmF0ZSBwYXJzZXIgY29kZSkgYXJvdW5kIOKAnHRyYWRpdGlvbmFs4oCdIHBhY2tldCBoZWFk ZXIgZGlhZ3JhbXMsIGJ5IHVzaW5nIGEgY29uc2lzdGVudCBmb3JtYXQgZm9yIGJvdGggdGhlIGRp YWdyYW0gYW5kIHRoZSB0ZXh0IHRoYXQgYWNjb21wYW5pZXMgaXQuDQoNCkluIHRlcm1zIG9mIG90 aGVyIFBEVSBkZXNjcmlwdGlvbiBsYW5ndWFnZXMsIHRoZSByZWNlbnQgUVVJQyBkcmFmdHMgaGF2 ZSByZXBsYWNlZCBwYWNrZXQgZGlhZ3JhbXMgd2l0aCBhIGJlc3Bva2UgZGVzY3JpcHRpb24gbGFu Z3VhZ2U6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXF1aWMtdHJhbnNw b3J0LTI5I3NlY3Rpb24tMS4zLg0KDQpUaGVzZSBhcmUgYm90aCBtdWNoIHNpbXBsZXIgdGhhbiB0 aGUgbGFuZ3VhZ2VzIHRoYXQgTWFyYyBtZW50aW9uZWQsIGFuZCBvbmx5IGRlYWwgd2l0aCBQRFUg ZGVzY3JpcHRpb24gcmF0aGVyIHRoYW4gZGF0YSBsYXlvdXQgZGVzY3JpcHRpb24gbW9yZSBnZW5l cmFsbHksIGJ1dCBtaWdodCBiZSB3b3J0aCBhIGxvb2suDQoNClRoYW5rcywNCg0KU3RlcGhlbg0K DQpPbiAxMyBKdW4gMjAyMCwgYXQgMDE6NTMsIFNjb3R0IE1vcmdhbiA8c2NvdHRAYWRsaWdvLmNv bTxtYWlsdG86c2NvdHRAYWRsaWdvLmNvbT4+IHdyb3RlOg0KDQpIaSBNYXJjLA0KDQogICBUaGFu a3MsIEknbSBub3QgdHJ5aW5nIHRvIGJlIGludGVudGlvbmFsbHkgY29uZnVzaW5nIDopICBJbiBh biBhdHRlbXB0IHRvIGNsYXJpZnksIEknbSB0cnlpbmcgdG8gY3JlYXRlIGEgbmV3IHN0cnVjdHVy ZWQgUERVIGZvcm1hdCB0aGF0IGNvdWxkIGJlIHVzZWQgdG8gZGVmaW5lIFBEVSBkZXNjcmlwdGlv biBsYW5ndWFnZXMgKG5vdCBhIHByaW1hcnkgY29uY2VybikgYXMgd2VsbCBhcyBsYXJnZXIgZGF0 YSBzdHJ1Y3R1cmVzIGxpa2UgZmlsZXMgb3IgYnl0ZXMgaW4gZGF0YWdyYW1zLg0KaHR0cHM6Ly9l bi53aWtpcGVkaWEub3JnL3dpa2kvUHJvdG9jb2xfZGF0YV91bml0DQoNCkxldHMgY29udGludWUg QCBmZHRAaWV0Zi5vcmc8bWFpbHRvOmZkdEBpZXRmLm9yZz4gIQ0KDQpDaGVlcnMsDQpTY290dA0K DQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLQ0KRnJvbTogTWFyYyBQZXRp dC1IdWd1ZW5pbiA8cGV0aXRodWdAYWNtLm9yZzxtYWlsdG86cGV0aXRodWdAYWNtLm9yZz4+DQpE YXRlOiBGcmksIEp1biAxMiwgMjAyMCBhdCAxMDowMyBBTQ0KU3ViamVjdDogUmU6IFtXZWJ0cmFu c3BvcnRdIFN0YW5kYXJkcyBmb3IgcHJvdG9jb2wgaGVhZGVycz8NClRvOiBTY290dCBNb3JnYW4g PHNjb3R0QGFkbGlnby5jb208bWFpbHRvOnNjb3R0QGFkbGlnby5jb20+PiwgPHdlYnRyYW5zcG9y dEBpZXRmLm9yZzxtYWlsdG86d2VidHJhbnNwb3J0QGlldGYub3JnPj4NCg0KDQpIaSBTY290dCwN Cg0KSSBzdGlsbCBmaW5kIHlvdXIgdGVybWlub2xvZ3kgY29uZnVzaW5nLiAgSSBhbSBub3Qgc3Vy ZSBpZiB5b3UgYXJlIHByb3Bvc2luZyB0byBkZXNpZ24gYSBuZXcgUERVIGRlc2NyaXB0aW9uIGxh bmd1YWdlIChhbGEgQVNOLjEsIEFCTkYsIFJCTkYsIENEREwsIFhNTCBSRUxBWCwgZXRjLi4pIG9y IGEgbmV3IHN0cnVjdHVyZWQgUERVIGZvcm1hdCAoYWxhIERFUiwgQkVSLCBYTUwsIEpTT04sIENC T1IsIGV0Yy4uLikuICBJZiBpdCBpcyB0aGUgZm9ybWVyLCBJIHdvdWxkIHN1Z2dlc3QgdG8gcmVz ZW5kIHlvdXIgZW1haWwgdG8gZmR0QGlldGYub3JnPG1haWx0bzpmZHRAaWV0Zi5vcmc+LCB3aGVy ZSB3ZSBkaXNjdXNzIHRoaXMga2luZCBvZiB0aGluZ3MuDQoNClRoYW5rcy4NCg0KT24gNi8xMi8y MCA3OjI1IEFNLCBTY290dCBNb3JnYW4gd3JvdGU6DQo+IEhpIE1hcmMsDQo+DQo+ICAgIFRoYW5r cyBmb3IgcmVzcG9uZGluZyEgIEkgbWVhbnQgJ3Byb3RvY29sIGhlYWRlcicgaW4gdGhlIGJyb2Fk ZXN0DQo+IHNlbnNlLiAgSSBoYXZlIGltcGxlbWVudGVkIHNvbWUgcHJvdG9jb2xzIGluIHRoZSBw YXN0IChXZWIgU29ja2V0IHYxMywgU01UUA0KPiBldGMpIGFuZCB3b3JrIGEgbG90IHdpdGggSlNP TiBhbmQgWE1MIGFzIEkgbWVudGlvbmVkIHByZXZpb3VzbHkuICBIZXJlIGFyZQ0KPiBzb21lIGdl bmVyYWwgZnJ1c3RyYXRpb25zIChpLmUuIHByb2JsZW0gc3RhdGVtZW50KSB0aGF0IEknbSBsb29r aW5nIHRvDQo+IG92ZXJjb21lOw0KPg0KPiAxKSBKU09OIGFuZCBYTUwgZ2VuZXJhbGx5IGxhY2sg c3VwcG9ydCBmb3IgYmluYXJ5IGRhdGEgKHRoZXJlIGFyZSBzb21lDQo+IHdvcmthcm91bmRzIGJ1 dCBub3RoaW5nIGlzIHN1cGVyIGdyZWF0KS4NCj4gMikgSlNPTiBhbmQgWE1MIGJvdGggbm93IGhh dmUgdGhlIGNvbmNlcHQgb2YgYSBTY2hlbWENCj4gICAgICAgICAgTm90ZSBJIHRoaW5rIHRoZSBj b25jZXB0IG9mIGEgU2NoZW1hIGlzIGEgZ29vZCB0aGluZyBidXQgYWxzbyBmZWVsDQo+IHRoYXQg U2NoZW1hcyBvZnRlbiBkb24ndCBjb3ZlciBhbGwNCj4gICAgICBNZXRhZGF0YSB0aGF0IG5lZWRz IHRvIGJlIGNvdmVyZWQuICBQZXJoYXBzIHRoZSBjb25jZXB0IG9mIGEgU2NoZW1hDQo+IG5lZWRz IHRvIGJlIGVuaGFuY2VkIGJ5IFVzYWdlTWV0YWRhdGEgaW5mb3JtYXRpb24uDQo+ICAgICAgICAg IEFsc28gbm90ZSBJIGFtIGZydXN0cmF0ZWQgd2l0aCBKU09OJ3MgaW5hYmlsaXR5IHRvIHByb3Zp ZGUgaHVtYW4NCj4gcmVhZGFibGUgc2NoZW1hcyAobXVsdGkgbGluZSB0ZXh0IGluIHRoZSAuanNv biBmaWxlIChub3QgL24pKS4NCj4gICAgICAgICAgSSBhbHNvIGhhdmUgZnJ1c3RyYXRpb25zIHdp dGggWE1MIHNjaGVtYXMgYW5kIFhNTCAobGlrZSBldmVyeW9uZQ0KPiBlbHNlIHdobyBub3cgZmF2 b3JzIEpTT04gb3ZlciBYTUwpDQo+IDMpIFByb3RvY29sJ3Mgb2Z0ZW4gaGF2ZSBIZWFkZXJzIGFu ZCBvdGhlciBpbmZvcm1hdGlvbiB3aGljaCBhY3QgaW4gYQ0KPiBzaW1pbGFyIGZhc2hpb24gdG8g U2NoZW1hcyAoaS5lLiB0aGV5IGRlc2NyaWJlIC8gc3BlY2lmeSBkYXRhIHN0cnVjdHVyZXMpDQo+ DQo+ICAgSSdtIHdvbmRlcmluZyBpZiBpdCdzIHRpbWUgZm9yIGEgbmV3IG1hcmt1cCBsYW5ndWFn ZSB0aGF0IGNhbiBzdXBwb3J0DQo+IGJpbmFyeSBkYXRhIGFuZCBhc3Npc3QgaW4gc3BlY2lmeWlu ZyBwcm90b2NvbCBieXRlIHNlZ21lbnRzIGluIGFkZGl0aW9uIHRvDQo+IG1vcmUgZ2VuZXJhbCBw dXJwb3NlIHRyYW5zcG9ydCBhbmQgc3RvcmFnZSBkYXRhIChsaWtlIEpTT04gJiBYTUwgZG8pLg0K PiAgIEknbSB0aGlua2luZyBhYm91dCBjYWxsaW5nIGl0ICdDbGFzc2lmaWNhdGlvbiBNYXJrdXAg Tm90YXRpb24nLg0KPg0KPiAgIEkgbWVzc2FnZWQgdGhpcyB0byB0aGUgZ3JvdXAganVzdCB0byB0 aHJvdyB0aGUgaWRlYSBvdXQgdGhlcmUsIHRvIGdldA0KPiBmZWVkYmFjayBhbmQgYWxzbyB0byBm aW5kIGNvbGxhYm9yYXRvcnMuDQo+DQo+DQo+IE9uIFRodSwgSnVuIDExLCAyMDIwIGF0IDc6NTMg QU0gTWFyYyBQZXRpdC1IdWd1ZW5pbiA8bWFyY0BwZXRpdC1odWd1ZW5pbi5vcmc8bWFpbHRvOm1h cmNAcGV0aXQtaHVndWVuaW4ub3JnPj4NCj4gd3JvdGU6DQo+DQo+PiBIaSwNCj4+DQo+PiBPbiA2 LzEwLzIwIDU6MTQgUE0sIFNjb3R0IE1vcmdhbiB3cm90ZToNCj4+PiBIaSBBbGwsDQo+Pj4NCj4+ PiAgICBJIGhhdmUgYmVlbiB3b3JraW5nIHdpdGggSlNPTiwgWE1MIGFuZCBzb21lIHByb3RvY29s IGhlYWRlcnMgcmVjZW50bHkNCj4+PiBhbmQgSSBhbSB3b25kZXJpbmcuLi4NCj4+PiBXaHkgYXJl IHRoZXJlIG5vIHJlYWwgc3RhbmRhcmQgdGV4dCBmb3JtYXRzIGZvciBwcm90b2NvbCBoZWFkZXJz LCBvciBhbSBJDQo+Pj4gbWlzc2luZyBzb21ldGhpbmc/DQo+Pj4NCj4+PiBJdCBzZWVtcyB0byBt ZSB0aGF0IGEgc2xpZ2h0bHkgbW9yZSBzdHJlYW1saW5lZC9vcHRpbWFsIGJpbmFyeS9tYXJrdXAN Cj4+PiBzdGFuZGFyZCBjb3VsZCBoZWxwIHByb3RvY29scyBhdHRhaW4gUE9DcyBhbmQgYWRvcHRp b24gbXVjaCBxdWlja2VyIGFuZA0KPj4+IGhlbHAgcmVkdWNlIHNvbWUgb2YgdGhlIHdvcmsgZGVm aW5pbmcgcHJvdG9jb2xzLg0KPj4+DQo+Pj4gQW55IHRob3VnaHRzIG9uIHRoaXMgdG9waWM/DQo+ Pj4NCj4+Pg0KPj4NCj4+IENhbiB5b3UgcGxlYXNlIGVsYWJvcmF0ZSBvbiB3aGF0IHlvdSBtZWFu IGJ5ICJwcm90b2NvbCBoZWFkZXIiPyAgTXkNCj4+IHVuZGVyc3RhbmRpbmcgb2YgdGhhdCB0ZXJt IGlzIHRoZSBmaXhlZCBwYXJ0IGF0IHRoZSBiZWdpbm5pbmcgb2YgYSBQRFUsIFBEVQ0KPj4gdGhh dCBhbHNvIGNvbnRhaW5zIGEgdmFyaWFibGUgbGVuZ3RoIHBhcnQgYWZ0ZXIgaXQgKGFzIGluIFVE UCBIZWFkZXIsIFRDUA0KPj4gSGVhZGVyLCBSVFAgSGVhZGVyLCBIVFRQLCBTSVAsIFNNVFAgZXRj Li4uKSwgYnV0IHRoYXQgZGVmaW5pdGlvbiBkb2VzIG5vdA0KPj4gc2VlbSB0byBhcHBseSB0byBK U09OIG9yIFhNTCAoYXMgYSB3aG9sZSkuDQo+Pg0KDQotLQ0KTWFyYyBQZXRpdC1IdWd1ZW5pbg0K RW1haWw6IG1hcmNAcGV0aXQtaHVndWVuaW4ub3JnPG1haWx0bzptYXJjQHBldGl0LWh1Z3Vlbmlu Lm9yZz4NCkJsb2c6IGh0dHBzOi8vbWFyYy5wZXRpdC1odWd1ZW5pbi5vcmc8aHR0cHM6Ly9tYXJj LnBldGl0LWh1Z3VlbmluLm9yZy8+DQpQcm9maWxlOiBodHRwczovL3d3dy5saW5rZWRpbi5jb20v aW4vcGV0aXRodWcNCg0KDQoNCi0tDQpSZWdhcmRzLA0KU2NvdHQgTW9yZ2FuDQpQcmVzaWRlbnQg JiBDRU8NCkFkbGlnbyBJbmMNCmh0dHA6Ly93d3cuYWRsaWdvLmNvbTxodHRwOi8vd3d3LmFkbGln by5jb20vPg0KaHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2luL3Njb3R0LW1vcmdhbi0yMTczOTQx NQ0KQSsgQmV0dGVyIEJ1c2luZXNzIEJ1cmVhdSBSYXRpbmc8aHR0cHM6Ly93d3cuYmJiLm9yZy9j aGljYWdvL2J1c2luZXNzLXJldmlld3MvY29tcHV0ZXItc29mdHdhcmUtcHVibGlzaGVycy1hbmQt ZGV2ZWxvcGVycy9hZGxpZ28taW5jLWluLWNoaWNhZ28taWwtODgzODEyNTY+DQpodHRwczovL2dp dGh1Yi5jb20vYWRsaWdvDQoNCkJ5IEFwcG9pbnRtZW50IE9ubHk6DQoxLTg2Ni05NjgtMTg5MyBF eCAxMDENCnNjb3R0QGFkbGlnby5jb208bWFpbHRvOnNjb3R0QGFkbGlnby5jb20+DQpza3lwZTph ZGxpZ28xP2NhbGwNClNlbmQgTWUgRmlsZXMgU2VjdXJlbHk6DQpodHRwczovL3d3dy5zZW5kdGhp c2ZpbGUuY29tL2YuanNwP2lkPWV3T255ZUZRTTE4SURSZjdNTUlkb2xmSQ0KDQoNCg0KPHNpZ25h dHVyZS5hc2M+LS0NCkZEVCBtYWlsaW5nIGxpc3QNCkZEVEBpZXRmLm9yZzxtYWlsdG86RkRUQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mZHQNCg0K --_000_9796F6C9ABB94AD4ADA0A6E275DAE3EEglasgowacuk_ Content-Type: text/html; charset="utf-8" Content-ID: <2BA6ADA2C3B71C4490B3AFB176DF4E53@GBRP265.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIFNjb3R0LA0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2UgaGF2ZSBhIGRyYWZ0IChkcmFmdC1t Y3F1aXN0aW4tYXVnbWVudGVkLWFzY2lpLWRpYWdyYW1zKSB0aGF0IGlzIGxvb2tpbmcgdG8gYWRk IHRvb2xpbmcgKGUuZy4sIHRvIGdlbmVyYXRlIHBhcnNlciBjb2RlKSBhcm91bmQg4oCcdHJhZGl0 aW9uYWzigJ0gcGFja2V0IGhlYWRlciBkaWFncmFtcywgYnkgdXNpbmcgYSBjb25zaXN0ZW50IGZv cm1hdCBmb3IgYm90aCB0aGUgZGlhZ3JhbSBhbmQgdGhlIHRleHQgdGhhdCBhY2NvbXBhbmllcw0K IGl0LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+SW4gdGVybXMgb2Ygb3RoZXIgUERVIGRlc2NyaXB0aW9uIGxhbmd1YWdlcywg dGhlIHJlY2VudCBRVUlDIGRyYWZ0cyBoYXZlIHJlcGxhY2VkIHBhY2tldCBkaWFncmFtcyB3aXRo IGEgYmVzcG9rZSBkZXNjcmlwdGlvbiBsYW5ndWFnZTombmJzcDs8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC0yOSNzZWN0aW9uLTEu MyIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcXVpYy10 cmFuc3BvcnQtMjkjc2VjdGlvbi0xLjM8L2E+LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlc2UgYXJlIGJvdGggbXVjaCBzaW1wbGVy IHRoYW4gdGhlIGxhbmd1YWdlcyB0aGF0IE1hcmMgbWVudGlvbmVkLCBhbmQgb25seSBkZWFsIHdp dGggUERVIGRlc2NyaXB0aW9uIHJhdGhlciB0aGFuIGRhdGEgbGF5b3V0IGRlc2NyaXB0aW9uIG1v cmUgZ2VuZXJhbGx5LCBidXQgbWlnaHQgYmUgd29ydGggYSBsb29rLjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzLDwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U3RlcGhl bjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDEzIEp1biAyMDIwLCBhdCAw MTo1MywgU2NvdHQgTW9yZ2FuICZsdDs8YSBocmVmPSJtYWlsdG86c2NvdHRAYWRsaWdvLmNvbSIg Y2xhc3M9IiI+c2NvdHRAYWRsaWdvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNz PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0i bHRyIiBjbGFzcz0iIj5IaSBNYXJjLA0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO1RoYW5rcywgSSdtIG5vdCB0cnlpbmcgdG8g YmUgaW50ZW50aW9uYWxseSBjb25mdXNpbmcgOikmbmJzcDsgSW4gYW4gYXR0ZW1wdCB0byBjbGFy aWZ5LCBJJ20gdHJ5aW5nIHRvIGNyZWF0ZSBhIG5ldyBzdHJ1Y3R1cmVkIFBEVSBmb3JtYXQgdGhh dCBjb3VsZCBiZSB1c2VkIHRvIGRlZmluZSBQRFUgZGVzY3JpcHRpb24gbGFuZ3VhZ2VzIChub3Qg YSBwcmltYXJ5IGNvbmNlcm4pIGFzIHdlbGwgYXMgbGFyZ2VyIGRhdGEgc3RydWN0dXJlcw0KIGxp a2UgZmlsZXMgb3IgYnl0ZXMgaW4mbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6cmdiKDMyLDMzLDM0 KTtmb250LWZhbWlseTpzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4IiBjbGFzcz0iIj5kYXRhZ3Jh bXM8L3NwYW4+LiZuYnNwOyZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRw czovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9Qcm90b2NvbF9kYXRhX3VuaXQiIGNsYXNzPSIiPmh0 dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1Byb3RvY29sX2RhdGFfdW5pdDwvYT48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkxldHMg Y29udGludWUmbmJzcDtAIDxhIGhyZWY9Im1haWx0bzpmZHRAaWV0Zi5vcmciIGNsYXNzPSIiPmZk dEBpZXRmLm9yZzwvYT4gITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+Q2hlZXJzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5TY290dDxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYg ZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdl IC0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCkZyb206IDxzdHJvbmcgY2xhc3M9ImdtYWlsX3NlbmRl cm5hbWUiIGRpcj0iYXV0byI+TWFyYyBQZXRpdC1IdWd1ZW5pbjwvc3Ryb25nPiA8c3BhbiBkaXI9 ImF1dG8iIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpwZXRpdGh1Z0BhY20ub3JnIiBj bGFzcz0iIj5wZXRpdGh1Z0BhY20ub3JnPC9hPiZndDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KRGF0 ZTogRnJpLCBKdW4gMTIsIDIwMjAgYXQgMTA6MDMgQU08YnIgY2xhc3M9IiI+DQpTdWJqZWN0OiBS ZTogW1dlYnRyYW5zcG9ydF0gU3RhbmRhcmRzIGZvciBwcm90b2NvbCBoZWFkZXJzPzxiciBjbGFz cz0iIj4NClRvOiBTY290dCBNb3JnYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpzY290dEBhZGxpZ28u Y29tIiBjbGFzcz0iIj5zY290dEBhZGxpZ28uY29tPC9hPiZndDssICZsdDs8YSBocmVmPSJtYWls dG86d2VidHJhbnNwb3J0QGlldGYub3JnIiBjbGFzcz0iIj53ZWJ0cmFuc3BvcnRAaWV0Zi5vcmc8 L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KSGkgU2NvdHQsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBzdGlsbCBmaW5kIHlv dXIgdGVybWlub2xvZ3kgY29uZnVzaW5nLiZuYnNwOyBJIGFtIG5vdCBzdXJlIGlmIHlvdSBhcmUg cHJvcG9zaW5nIHRvIGRlc2lnbiBhIG5ldyBQRFUgZGVzY3JpcHRpb24gbGFuZ3VhZ2UgKGFsYSBB U04uMSwgQUJORiwgUkJORiwgQ0RETCwgWE1MIFJFTEFYLCBldGMuLikgb3IgYSBuZXcgc3RydWN0 dXJlZCBQRFUgZm9ybWF0IChhbGEgREVSLCBCRVIsIFhNTCwgSlNPTiwgQ0JPUiwgZXRjLi4uKS4m bmJzcDsgSWYgaXQgaXMgdGhlIGZvcm1lciwNCiBJIHdvdWxkIHN1Z2dlc3QgdG8gcmVzZW5kIHlv dXIgZW1haWwgdG8gPGEgaHJlZj0ibWFpbHRvOmZkdEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPg0KZmR0QGlldGYub3JnPC9hPiwgd2hlcmUgd2UgZGlzY3VzcyB0aGlzIGtpbmQg b2YgdGhpbmdzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoYW5rcy48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiA2LzEyLzIwIDc6MjUgQU0sIFNjb3R0IE1vcmdhbiB3cm90 ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7IEhpIE1hcmMsPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xh c3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBUaGFua3MgZm9yIHJlc3BvbmRpbmchJm5ic3A7IEkg bWVhbnQgJ3Byb3RvY29sIGhlYWRlcicgaW4gdGhlIGJyb2FkZXN0PGJyIGNsYXNzPSIiPg0KJmd0 OyBzZW5zZS4mbmJzcDsgSSBoYXZlIGltcGxlbWVudGVkIHNvbWUgcHJvdG9jb2xzIGluIHRoZSBw YXN0IChXZWIgU29ja2V0IHYxMywgU01UUDxiciBjbGFzcz0iIj4NCiZndDsgZXRjKSBhbmQgd29y ayBhIGxvdCB3aXRoIEpTT04gYW5kIFhNTCBhcyBJIG1lbnRpb25lZCBwcmV2aW91c2x5LiZuYnNw OyBIZXJlIGFyZTxiciBjbGFzcz0iIj4NCiZndDsgc29tZSBnZW5lcmFsIGZydXN0cmF0aW9ucyAo aS5lLiBwcm9ibGVtIHN0YXRlbWVudCkgdGhhdCBJJ20gbG9va2luZyB0bzxiciBjbGFzcz0iIj4N CiZndDsgb3ZlcmNvbWU7PGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IDEp IEpTT04gYW5kIFhNTCBnZW5lcmFsbHkgbGFjayBzdXBwb3J0IGZvciBiaW5hcnkgZGF0YSAodGhl cmUgYXJlIHNvbWU8YnIgY2xhc3M9IiI+DQomZ3Q7IHdvcmthcm91bmRzIGJ1dCBub3RoaW5nIGlz IHN1cGVyIGdyZWF0KS48YnIgY2xhc3M9IiI+DQomZ3Q7IDIpIEpTT04gYW5kIFhNTCBib3RoIG5v dyBoYXZlIHRoZSBjb25jZXB0IG9mIGEgU2NoZW1hPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTm90ZSBJIHRoaW5rIHRoZSBjb25jZXB0IG9mIGEg U2NoZW1hIGlzIGEgZ29vZCB0aGluZyBidXQgYWxzbyBmZWVsPGJyIGNsYXNzPSIiPg0KJmd0OyB0 aGF0IFNjaGVtYXMgb2Z0ZW4gZG9uJ3QgY292ZXIgYWxsPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7IE1ldGFkYXRhIHRoYXQgbmVlZHMgdG8gYmUgY292ZXJlZC4mbmJzcDsg UGVyaGFwcyB0aGUgY29uY2VwdCBvZiBhIFNjaGVtYTxiciBjbGFzcz0iIj4NCiZndDsgbmVlZHMg dG8gYmUgZW5oYW5jZWQgYnkgVXNhZ2VNZXRhZGF0YSBpbmZvcm1hdGlvbi48YnIgY2xhc3M9IiI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBbHNvIG5vdGUgSSBhbSBm cnVzdHJhdGVkIHdpdGggSlNPTidzIGluYWJpbGl0eSB0byBwcm92aWRlIGh1bWFuPGJyIGNsYXNz PSIiPg0KJmd0OyByZWFkYWJsZSBzY2hlbWFzIChtdWx0aSBsaW5lIHRleHQgaW4gdGhlIC5qc29u IGZpbGUgKG5vdCAvbikpLjxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IEkgYWxzbyBoYXZlIGZydXN0cmF0aW9ucyB3aXRoIFhNTCBzY2hlbWFzIGFu ZCBYTUwgKGxpa2UgZXZlcnlvbmU8YnIgY2xhc3M9IiI+DQomZ3Q7IGVsc2Ugd2hvIG5vdyBmYXZv cnMgSlNPTiBvdmVyIFhNTCk8YnIgY2xhc3M9IiI+DQomZ3Q7IDMpIFByb3RvY29sJ3Mgb2Z0ZW4g aGF2ZSBIZWFkZXJzIGFuZCBvdGhlciBpbmZvcm1hdGlvbiB3aGljaCBhY3QgaW4gYTxiciBjbGFz cz0iIj4NCiZndDsgc2ltaWxhciBmYXNoaW9uIHRvIFNjaGVtYXMgKGkuZS4gdGhleSBkZXNjcmli ZSAvIHNwZWNpZnkgZGF0YSBzdHJ1Y3R1cmVzKTxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNz PSIiPg0KJmd0OyZuYnNwOyAmbmJzcDtJJ20gd29uZGVyaW5nIGlmIGl0J3MgdGltZSBmb3IgYSBu ZXcgbWFya3VwIGxhbmd1YWdlIHRoYXQgY2FuIHN1cHBvcnQ8YnIgY2xhc3M9IiI+DQomZ3Q7IGJp bmFyeSBkYXRhIGFuZCBhc3Npc3QgaW4gc3BlY2lmeWluZyBwcm90b2NvbCBieXRlIHNlZ21lbnRz IGluIGFkZGl0aW9uIHRvPGJyIGNsYXNzPSIiPg0KJmd0OyBtb3JlIGdlbmVyYWwgcHVycG9zZSB0 cmFuc3BvcnQgYW5kIHN0b3JhZ2UgZGF0YSAobGlrZSBKU09OICZhbXA7IFhNTCBkbykuPGJyIGNs YXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDtJJ20gdGhpbmtpbmcgYWJvdXQgY2FsbGluZyBpdCAn Q2xhc3NpZmljYXRpb24gTWFya3VwIE5vdGF0aW9uJy48YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBj bGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7SSBtZXNzYWdlZCB0aGlzIHRvIHRoZSBncm91cCBq dXN0IHRvIHRocm93IHRoZSBpZGVhIG91dCB0aGVyZSwgdG8gZ2V0PGJyIGNsYXNzPSIiPg0KJmd0 OyBmZWVkYmFjayBhbmQgYWxzbyB0byBmaW5kIGNvbGxhYm9yYXRvcnMuPGJyIGNsYXNzPSIiPg0K Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgT24gVGh1LCBKdW4g MTEsIDIwMjAgYXQgNzo1MyBBTSBNYXJjIFBldGl0LUh1Z3VlbmluICZsdDs8YSBocmVmPSJtYWls dG86bWFyY0BwZXRpdC1odWd1ZW5pbi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5tYXJj QHBldGl0LWh1Z3VlbmluLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyB3cm90ZTo8YnIg Y2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IEhpLDxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgT24gNi8xMC8yMCA1OjE0IFBNLCBTY290 dCBNb3JnYW4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IEhpIEFsbCw8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5i c3A7IEkgaGF2ZSBiZWVuIHdvcmtpbmcgd2l0aCBKU09OLCBYTUwgYW5kIHNvbWUgcHJvdG9jb2wg aGVhZGVycyByZWNlbnRseTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBhbmQgSSBhbSB3b25k ZXJpbmcuLi48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgV2h5IGFyZSB0aGVyZSBubyByZWFs IHN0YW5kYXJkIHRleHQgZm9ybWF0cyBmb3IgcHJvdG9jb2wgaGVhZGVycywgb3IgYW0gSTxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBtaXNzaW5nIHNvbWV0aGluZz88YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgSXQgc2VlbXMgdG8gbWUgdGhh dCBhIHNsaWdodGx5IG1vcmUgc3RyZWFtbGluZWQvb3B0aW1hbCBiaW5hcnkvbWFya3VwPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsmZ3Q7IHN0YW5kYXJkIGNvdWxkIGhlbHAgcHJvdG9jb2xzIGF0dGFp biBQT0NzIGFuZCBhZG9wdGlvbiBtdWNoIHF1aWNrZXIgYW5kPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsmZ3Q7IGhlbHAgcmVkdWNlIHNvbWUgb2YgdGhlIHdvcmsgZGVmaW5pbmcgcHJvdG9jb2xzLjxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBBbnkg dGhvdWdodHMgb24gdGhpcyB0b3BpYz88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7IENhbiB5b3UgcGxlYXNlIGVsYWJvcmF0ZSBvbiB3aGF0IHlvdSBtZWFuIGJ5ICZx dW90O3Byb3RvY29sIGhlYWRlciZxdW90Oz8mbmJzcDsgTXk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyB1bmRlcnN0YW5kaW5nIG9mIHRoYXQgdGVybSBpcyB0aGUgZml4ZWQgcGFydCBhdCB0aGUgYmVn aW5uaW5nIG9mIGEgUERVLCBQRFU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyB0aGF0IGFsc28gY29u dGFpbnMgYSB2YXJpYWJsZSBsZW5ndGggcGFydCBhZnRlciBpdCAoYXMgaW4gVURQIEhlYWRlciwg VENQPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgSGVhZGVyLCBSVFAgSGVhZGVyLCBIVFRQLCBTSVAs IFNNVFAgZXRjLi4uKSwgYnV0IHRoYXQgZGVmaW5pdGlvbiBkb2VzIG5vdDxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7IHNlZW0gdG8gYXBwbHkgdG8gSlNPTiBvciBYTUwgKGFzIGEgd2hvbGUpLjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0gPGJyIGNs YXNzPSIiPg0KTWFyYyBQZXRpdC1IdWd1ZW5pbjxiciBjbGFzcz0iIj4NCkVtYWlsOiA8YSBocmVm PSJtYWlsdG86bWFyY0BwZXRpdC1odWd1ZW5pbi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij5tYXJjQHBldGl0LWh1Z3VlbmluLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpCbG9nOiA8YSBocmVm PSJodHRwczovL21hcmMucGV0aXQtaHVndWVuaW4ub3JnLyIgcmVsPSJub3JlZmVycmVyIiB0YXJn ZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpodHRwczovL21hcmMucGV0aXQtaHVndWVuaW4ub3JnPC9h PjxiciBjbGFzcz0iIj4NClByb2ZpbGU6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmxpbmtlZGluLmNv bS9pbi9wZXRpdGh1ZyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ DQpodHRwczovL3d3dy5saW5rZWRpbi5jb20vaW4vcGV0aXRodWc8L2E+PGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xlYXI9ImFsbCIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KLS0gPGJyIGNsYXNzPSIiPg0KPGRpdiBkaXI9 Imx0ciIgY2xhc3M9ImdtYWlsX3NpZ25hdHVyZSIgZGF0YS1zbWFydG1haWw9ImdtYWlsX3NpZ25h dHVyZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRp cj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0i bHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5TY290dCBNb3JnYW4NCjxk aXYgY2xhc3M9IiI+UHJlc2lkZW50ICZhbXA7IENFTzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BZGxp Z28gSW5jPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHA6Ly93d3cuYWRsaWdvLmNv bS8iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwOi8vd3d3LmFkbGlnby5jb208L2E+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9z Y290dC1tb3JnYW4tMjE3Mzk0MTUiIHN0eWxlPSJmb250LXNpemU6MTIuOHB4IiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2luL3Njb3R0LW1vcmdhbi0y MTczOTQxNTwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0FyaWFsIFVuaWNvZGUg TVMmcXVvdDssIEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IHNtYWxsOyBmb250LXdlaWdo dDogYm9sZDsgdGV4dC1hbGlnbjogLXdlYmtpdC1yaWdodDsiIGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuYmJi Lm9yZy9jaGljYWdvL2J1c2luZXNzLXJldmlld3MvY29tcHV0ZXItc29mdHdhcmUtcHVibGlzaGVy cy1hbmQtZGV2ZWxvcGVycy9hZGxpZ28taW5jLWluLWNoaWNhZ28taWwtODgzODEyNTYiIHRhcmdl dD0iX2JsYW5rIiBjbGFzcz0iIj5BJiM0MzsgQmV0dGVyIEJ1c2luZXNzIEJ1cmVhdSBSYXRpbmc8 L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9hZGxp Z28iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL2dpdGh1Yi5jb20vYWRsaWdvPC9h PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTpzbWFsbCIgY2xhc3M9IiI+ QnkgQXBwb2ludG1lbnQgT25seTombmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiAmcXVvdDtBcmlhbCBVbmljb2RlIE1TJnF1b3Q7LCBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiBzbWFsbDsgZm9udC13ZWlnaHQ6IGJvbGQ7IHRleHQtYWxpZ246IC13ZWJraXQtcmlnaHQ7 IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7QXJpYWwgVW5pY29kZSBNUyZxdW90OywgQXJp YWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogc21hbGw7IGZvbnQtd2VpZ2h0OiBib2xkOyB0ZXh0 LWFsaWduOiAtd2Via2l0LXJpZ2h0OyIgY2xhc3M9IiI+MS04NjYtOTY4LTE4OTMgRXggMTAxPC9z cGFuPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6ICZxdW90O0FyaWFsIFVuaWNvZGUgTVMmcXVvdDssIEFyaWFsLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IHNtYWxsOyBmb250LXdlaWdodDogYm9sZDsgdGV4dC1hbGlnbjogLXdlYmtp dC1yaWdodDsiIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzpzY290dEBhZGxpZ28uY29tIiB0YXJn ZXQ9Il9ibGFuayIgY2xhc3M9IiI+c2NvdHRAYWRsaWdvLmNvbTwvYT48L3NwYW4+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDoxOS4ycHgiIGNsYXNzPSIiPjxm b250IHNpemU9IjIiIGNsYXNzPSIiPjxhIGNsYXNzPSIiPnNreXBlOmFkbGlnbzE/Y2FsbDwvYT48 L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0ibGluZS1oZWln aHQ6MTkuMnB4IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOnNtYWxsIiBjbGFzcz0i Ij5TZW5kIE1lIEZpbGVzIFNlY3VyZWx5OiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDoxOS4ycHgiIGNsYXNzPSIiPjxiIHN0 eWxlPSJjb2xvcjpyZ2IoNTEsNTEsNTEpO2ZvbnQtZmFtaWx5OiZxdW90O215cmlhZCBwcm8mcXVv dDssbXlyaWFkLGZydXRpZ2VyLCZxdW90O2ZydXRpZ2VyIGxpbm90eXBlJnF1b3Q7LHVuaXZlcnMs Y2FsaWJyaSwmcXVvdDtnaWxsIHNhbnMmcXVvdDssJnF1b3Q7Z2lsbCBzYW5zIG10JnF1b3Q7LCZx dW90O2RlamF2dSBzYW5zIGNvbmRlbnNlZCZxdW90OywmcXVvdDtsaWJlcmF0aW9uIHNhbnMmcXVv dDssJnF1b3Q7bmltYnVzIHNhbnMgbCZxdW90Oyx0YWhvbWEsZ2VuZXZhLCZxdW90O2hlbHZldGlj YSBuZXVlJnF1b3Q7LGhlbHZldGljYWwsaGVsdmV0aWNhLGFyaWFsLGFyaWFsLHNhbnMtc2VyaWY7 Zm9udC1zaXplOjEycHg7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjM1 LDIzNSwyMzUpIiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3d3dy5zZW5kdGhpc2ZpbGUuY29t L2YuanNwP2lkPWV3T255ZUZRTTE4SURSZjdNTUlkb2xmSSIgc3R5bGU9ImNvbG9yOnJnYigxNyw4 NSwyMDQpIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuc2VuZHRoaXNmaWxl LmNvbS9mLmpzcD9pZD1ld09ueWVGUU0xOElEUmY3TU1JZG9sZkk8L2E+PC9iPjxmb250IHNpemU9 IjIiIGNsYXNzPSIiPjxhIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvYT48L2ZvbnQ+PC9zcGFu PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8c3BhbiBpZD0iY2lkOjE3MmFiMjAzNDQ5NjFhOGUwM2IxIj4mbHQ7c2lnbmF0 dXJlLmFzYyZndDs8L3NwYW4+LS0gPGJyIGNsYXNzPSIiPg0KRkRUIG1haWxpbmcgbGlzdDxiciBj bGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpGRFRAaWV0Zi5vcmciIGNsYXNzPSIiPkZEVEBpZXRm Lm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2ZkdDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9796F6C9ABB94AD4ADA0A6E275DAE3EEglasgowacuk_-- From nobody Mon Jun 15 10:52:08 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 CBB233A0827 for ; Mon, 15 Jun 2020 10:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 UmjDlAYeA94E for ; Mon, 15 Jun 2020 10:52:06 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 869E13A0826 for ; Mon, 15 Jun 2020 10:52:06 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id c1so9834307vsc.11 for ; Mon, 15 Jun 2020 10:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=WwU0nFt/U00eYfHvVxTBmEf9D/T9vg3WA7RwEt6SKwo=; b=cJXpQlI48YUgTLb7krMguDIvEhdawXxsicyi/rEaUf0sXBVp4vuNGEq/L5sa14xOsj WZV+Huhh0ajzaCWUJA8NxZQDqjBGm8V6zY16anLs7jBfpi59til5aOW+ne7Mft2Gh++w ilXjwwaUD6w4cz7ETTUei+mCdfYk9Fw4OWZNs32dwRTYKsRUj2114ZawLSnWNoCO0FPx QfeXx4RgT1+JphlXF5Aa7nXgUXhAaFSGoRRz/qr+6HJ/qKoY2zm6RZI3jwcUoym3EwQZ qMyaxO6d+eo8dpW0J8LRyz/Xapa33EJh6G1MsL4rPrEgkZcOybsRm+nKI1p37VeN/Xls +Qkw== 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=WwU0nFt/U00eYfHvVxTBmEf9D/T9vg3WA7RwEt6SKwo=; b=aBKeWL3zEvjnS1NReQo2IDpQ/wVDWgEC0ajsOzfjIBG/jVuP+epkxAuTd4n0zFXHnI s30qNRLla/hNnQWZMkSFxdyGhwJMnAMIkNcqnlJzCB+PM4h+Zq4QcMyGRUd02USRhGAu R6PIOVbhUZfgGG1HdN+ZJK9RM+OxYdMD6DckVHfFcK9SLt8YhIA5rlV3OXvBWROUV1Hs MriWFjclhmIliNcBEHLbkJ83JNsnJgWgc83SkNj0SqyWV8rZcWv4WETdeNpTQ1SL995k Qrr18B4DUL5GY5S8yfcJdfXlHf3IkJyf6dd/5Z/rwxcQ2ehoQZFjBToKmQm2RdElRBw+ LkYw== X-Gm-Message-State: AOAM533i87uvWNoJ9Hrg5cZVQPqNvN8ETW6YHgZjvEJpn0CcVJ5pEHEu ZD2q/s8wJEP1GiPNmWO6P1Z85ajgOjcbHirbtXwX9ATOWC4= X-Google-Smtp-Source: ABdhPJzN8jJVt8Yn/2ETGxi6GnhHNnX2VhnQ2JoqZXtZygsAtRx+2FM2vIEU2w8YHbjYxL7qtgrZIP6oxwxr5XVIvhY= X-Received: by 2002:a05:6102:41b:: with SMTP id d27mr20427259vsq.197.1592243525109; Mon, 15 Jun 2020 10:52:05 -0700 (PDT) MIME-Version: 1.0 From: virat tara Date: Mon, 15 Jun 2020 23:21:54 +0530 Message-ID: To: webtransport@ietf.org Content-Type: multipart/alternative; boundary="000000000000b5ccc205a8231532" Archived-At: Subject: [Webtransport] Demultiplexing in case of unreliable datagrams 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, 15 Jun 2020 17:52:08 -0000 --000000000000b5ccc205a8231532 Content-Type: text/plain; charset="UTF-8" Hi, In *Section 6* "Transport Properties" there is a point mentioning Pooling Support. In case of unreliable datagrams, how will demultiplexing be done on the receiver end? Streams, on the other hand, have a unique stream ID. I found a draft (draft-schinazi-quic-h3-datagram-03 ) that accomplishes this on HTTP/3 but since WebTransport will have its own dedicated connection as mentioned in *Section 1.1 *"Background" how will this be taken forward? Thanks, Virat --000000000000b5ccc205a8231532 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
=
In Section 6 "Transport Pro= perties" there is a point mentioning Pooling Support. In case of unrel= iable datagrams, how will demultiplexing be done on the receiver end? Strea= ms, on the other hand, have a unique stream ID. I found a draft (draft-schi= nazi-quic-h3-datagram-03) that accomplishes this on HTTP/3 but since We= bTransport will have its own dedicated connection as mentioned in Sectio= n 1.1 "Background" how will this be taken forward?

Thanks,
= Virat
--000000000000b5ccc205a8231532-- From nobody Mon Jun 15 11:54:04 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 7B6E53A0ABE for ; Mon, 15 Jun 2020 11:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=ducksong.com header.b=ScuxOq4I; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=CKDgf4Ps 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 79AAuCX31pVs for ; Mon, 15 Jun 2020 11:54:00 -0700 (PDT) Received: from outbound2o.ore.mailhop.org (outbound2o.ore.mailhop.org [54.187.213.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F69F3A0AB9 for ; Mon, 15 Jun 2020 11:53:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592247239; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=JlB8f1NhamL+hBYdxzgjoQbp+F915qJeQupg8rVPHpM5HGWlGOTvkqPyLn0juKgoxIF7p0A9MQl1T om2BJ+FoaEwN2AoYT6LNm2OBITzl65Nr+tTXuDa052KbxmTcAye4jiMl5GgMuc5ANZhs5sz5pDCncf CrcWR7aNDgYusLY4OSLIjx0kWEk42jydCyRJejb5lW2pMOsngH6UvtgfOeCfAKU6AzJaMHNzC6mzHd NrXeMN97Dvw0qIkrTMtfOrhjL0sYzGWgEJYy5BIZQaxJeyPWDe6CdDAic57MaipJemI1OeOjrwo/U8 pVAfs5mXM5yy1oP5FmCVqqsTVWWufCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=08n7Tb8xEtJNLgWoGy3pPvic0DNmWe8o7TnXS+jjDeE=; b=tpGT5xQnELUdrwCVnjRtiWxSSsgWnqau4u5hJ0e6s4iDxvx4qFe36rFnuvQ2NPDn6U7lkMydpEsXR gCNybyV54/S9eAEDvF3C8P+U9iJpgQftL3amndEHxW0GmPX8R5OXqLJNCkAdi+K5mCvXt9IloFdu2t oDJN1XNXqMTo6CqgWcCRBHQyzE4I8egpbVsfaFaF8VvE/g4IQjVOZOSQgyBN3SD3NTWmYxqtpDiBd7 VFlS1C1/N6UxRceZ6b3dZf5hk7GLU248BCKc1TrarymbCwuu6CjWtnm5jJA0y3GdrMTj3XwOdq4eH2 1AQvAn5WhUjDb/m1Q8PzmdpbbB6CFtQ== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.167.170; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=08n7Tb8xEtJNLgWoGy3pPvic0DNmWe8o7TnXS+jjDeE=; b=ScuxOq4IlF8vjKJike2Et9RD6yZyDG0iLTJHEdpmgPbYuiG0BFMsY5ioyccux7QmV0qYljfoOpE4F jVOPP1j7E7A4W22OL2Wy/CoGctWb/YNy/1WaGg8KCUe7RFG6oTO68nFLZyZ58R47Qm8NrqRY9JVlVT iaJZ7pdLBIiwand8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=08n7Tb8xEtJNLgWoGy3pPvic0DNmWe8o7TnXS+jjDeE=; b=CKDgf4PsUm7PZNSPTyVVoiLKN4PWu3NhOTY3osy+9OmpqkxcUE9bgKCIDXW8O8h08Dg3K4Brz5uRr 2MlWpS/eAH89trhpDl1qOkLG0Z5GZ0++gHrigQ77EX8GVY8qZB4MjmRHON3csvduWFoS17/UBoF+eV N39DV+0m2hM0YA8A9s+MIj8AFa0/Nm3I5EmJ9zFvXC5E36jb3Jv1zg4qlKYjsL7YPLtjWA2SSMvr/h QXFmvOC4hVxHMgTyaN1mFlEG0tCAlRWb5ZuoIwXDQu6e+hqzYdBXMUg4t5EANbehIczvJZYRTszPVS CmcDsLBIukyczb6TOuNjBul2/YebyKw== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 90dea8cb-af39-11ea-a067-6d02e42e573a X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.167.170 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 90dea8cb-af39-11ea-a067-6d02e42e573a; Mon, 15 Jun 2020 18:53:57 +0000 (UTC) Received: by mail-oi1-f170.google.com with SMTP id k4so16875268oik.2; Mon, 15 Jun 2020 11:53:56 -0700 (PDT) X-Gm-Message-State: AOAM530GhAdyzsWVsN6V6YImM5BIU5iSIv5lLl2D3159OtmZ4iv+yQwy HWBfpbMjyPyiKGK6xvhTJkkEw4c9XNG/O73D4Yg= X-Google-Smtp-Source: ABdhPJwnn6dozNHwpcDgpUd8Q9dKYF+YtlBcDgjDOkimuvrwpzdayTVWuYuznjkS/yJOpNZz5es+Uw9p9vjpw5aSfyA= X-Received: by 2002:aca:a814:: with SMTP id r20mr612729oie.91.1592247236444; Mon, 15 Jun 2020 11:53:56 -0700 (PDT) MIME-Version: 1.0 References: <2804eb55-e79a-3383-9ebf-cd4f495b273a@petit-huguenin.org> <9796F6C9-ABB9-4AD4-ADA0-A6E275DAE3EE@glasgow.ac.uk> In-Reply-To: <9796F6C9-ABB9-4AD4-ADA0-A6E275DAE3EE@glasgow.ac.uk> From: Patrick McManus Date: Mon, 15 Jun 2020 14:53:45 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Stephen McQuistin Cc: Scott Morgan , "webtransport@ietf.org" , "fdt@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ec47a005a823f23e" Archived-At: Subject: Re: [Webtransport] [fdt] Standards for protocol headers? 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, 15 Jun 2020 18:54:03 -0000 --000000000000ec47a005a823f23e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable you might be interested in structured field values for http https://datatracker.ietf.org/doc/draft-ietf-httpbis-header-structure/ -P On Sat, Jun 13, 2020 at 8:08 AM Stephen McQuistin < Stephen.McQuistin@glasgow.ac.uk> wrote: > Hi Scott, > > We have a draft (draft-mcquistin-augmented-ascii-diagrams) that is lookin= g > to add tooling (e.g., to generate parser code) around =E2=80=9Ctraditiona= l=E2=80=9D packet > header diagrams, by using a consistent format for both the diagram and th= e > text that accompanies it. > > In terms of other PDU description languages, the recent QUIC drafts have > replaced packet diagrams with a bespoke description language: > https://tools.ietf.org/html/draft-ietf-quic-transport-29#section-1.3. > > These are both much simpler than the languages that Marc mentioned, and > only deal with PDU description rather than data layout description more > generally, but might be worth a look. > > Thanks, > > Stephen > > On 13 Jun 2020, at 01:53, Scott Morgan wrote: > > Hi Marc, > > Thanks, I'm not trying to be intentionally confusing :) In an attempt > to clarify, I'm trying to create a new structured PDU format that could b= e > used to define PDU description languages (not a primary concern) as well = as > larger data structures like files or bytes in datagrams. > https://en.wikipedia.org/wiki/Protocol_data_unit > > Lets continue @ fdt@ietf.org ! > > Cheers, > Scott > > ---------- Forwarded message --------- > From: Marc Petit-Huguenin > Date: Fri, Jun 12, 2020 at 10:03 AM > Subject: Re: [Webtransport] Standards for protocol headers? > To: Scott Morgan , > > > Hi Scott, > > I still find your terminology confusing. I am not sure if you are > proposing to design a new PDU description language (ala ASN.1, ABNF, RBNF= , > CDDL, XML RELAX, etc..) or a new structured PDU format (ala DER, BER, XML= , > JSON, CBOR, etc...). If it is the former, I would suggest to resend your > email to fdt@ietf.org, where we discuss this kind of things. > > Thanks. > > On 6/12/20 7:25 AM, Scott Morgan wrote: > > Hi Marc, > > > > Thanks for responding! I meant 'protocol header' in the broadest > > sense. I have implemented some protocols in the past (Web Socket v13, > SMTP > > etc) and work a lot with JSON and XML as I mentioned previously. Here > are > > some general frustrations (i.e. problem statement) that I'm looking to > > overcome; > > > > 1) JSON and XML generally lack support for binary data (there are some > > workarounds but nothing is super great). > > 2) JSON and XML both now have the concept of a Schema > > Note I think the concept of a Schema is a good thing but also > feel > > that Schemas often don't cover all > > Metadata that needs to be covered. Perhaps the concept of a Schem= a > > needs to be enhanced by UsageMetadata information. > > Also note I am frustrated with JSON's inability to provide hum= an > > readable schemas (multi line text in the .json file (not /n)). > > I also have frustrations with XML schemas and XML (like everyo= ne > > else who now favors JSON over XML) > > 3) Protocol's often have Headers and other information which act in a > > similar fashion to Schemas (i.e. they describe / specify data structure= s) > > > > I'm wondering if it's time for a new markup language that can support > > binary data and assist in specifying protocol byte segments in addition > to > > more general purpose transport and storage data (like JSON & XML do). > > I'm thinking about calling it 'Classification Markup Notation'. > > > > I messaged this to the group just to throw the idea out there, to get > > feedback and also to find collaborators. > > > > > > On Thu, Jun 11, 2020 at 7:53 AM Marc Petit-Huguenin < > marc@petit-huguenin.org> > > wrote: > > > >> Hi, > >> > >> On 6/10/20 5:14 PM, Scott Morgan wrote: > >>> Hi All, > >>> > >>> I have been working with JSON, XML and some protocol headers > recently > >>> and I am wondering... > >>> Why are there no real standard text formats for protocol headers, or > am I > >>> missing something? > >>> > >>> It seems to me that a slightly more streamlined/optimal binary/markup > >>> standard could help protocols attain POCs and adoption much quicker a= nd > >>> help reduce some of the work defining protocols. > >>> > >>> Any thoughts on this topic? > >>> > >>> > >> > >> Can you please elaborate on what you mean by "protocol header"? My > >> understanding of that term is the fixed part at the beginning of a PDU= , > PDU > >> that also contains a variable length part after it (as in UDP Header, > TCP > >> Header, RTP Header, HTTP, SIP, SMTP etc...), but that definition does > not > >> seem to apply to JSON or XML (as a whole). > >> > > -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: https://marc.petit-huguenin.org > Profile: https://www.linkedin.com/in/petithug > > > > -- > Regards, > Scott Morgan > President & CEO > Adligo Inc > http://www.adligo.com > https://www.linkedin.com/in/scott-morgan-21739415 > A+ Better Business Bureau Rating > > https://github.com/adligo > > By Appointment Only: > 1-866-968-1893 Ex 101 > scott@adligo.com > skype:adligo1?call > Send Me Files Securely: > *https://www.sendthisfile.com/f.jsp?id=3DewOnyeFQM18IDRf7MMIdolfI > * > > > > -- > FDT mailing list > FDT@ietf.org > https://www.ietf.org/mailman/listinfo/fdt > > > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --000000000000ec47a005a823f23e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
you might be interested in structured field values=C2=A0fo= r http=C2=A0https://datatracker.ietf.org/doc/draft-ietf-httpbis-head= er-structure/

-P


On Sat, Jun 13, 2020= at 8:08 AM Stephen McQuistin <Stephen.McQuistin@glasgow.ac.uk> wrote:
Hi Scott,

We have a draft (draft-mcquistin-augmented-ascii-diagrams) that is loo= king to add tooling (e.g., to generate parser code) around =E2=80=9Ctraditi= onal=E2=80=9D packet header diagrams, by using a consistent format for both= the diagram and the text that accompanies it.=C2=A0

In terms of other PDU description languages, the recent QUIC drafts ha= ve replaced packet diagrams with a bespoke description language:=C2=A0https://tools.ietf.org/html/draft-ietf-quic-transport-29= #section-1.3.

These are both much simpler than the languages that Marc mentioned, an= d only deal with PDU description rather than data layout description more g= enerally, but might be worth a look.

Thanks,

Stephen

On 13 Jun 2020, at 01:53, Scott Morgan <scott@adligo.com> wrote:

Hi Marc,

=C2=A0 =C2=A0Thanks, I'm not trying to be intentionally confusing = :)=C2=A0 In an attempt to clarify, I'm trying to create a new structure= d PDU format that could be used to define PDU description languages (not a = primary concern) as well as larger data structures like files or bytes in=C2=A0datagrams.=C2=A0=C2=A0

Lets continue=C2=A0@ fdt@ietf.org !

Cheers,
Scott

---------- Forwarded message --------= -
From: Marc Petit-Huguenin <petithug@acm.org<= /a>>
Date: Fri, Jun 12, 2020 at 10:03 AM
Subject: Re: [Webtransport] Standards for protocol headers?
To: Scott Morgan <= scott@adligo.com>, <webtransport@ietf.org>


Hi Scott,

I still find your terminology confusing.=C2=A0 I am not sure if you are pro= posing to design a new PDU description language (ala ASN.1, ABNF, RBNF, CDD= L, XML RELAX, etc..) or a new structured PDU format (ala DER, BER, XML, JSO= N, CBOR, etc...).=C2=A0 If it is the former, I would suggest to resend your email to fdt@ietf.org, where we discuss this kind of things.

Thanks.

On 6/12/20 7:25 AM, Scott Morgan wrote:
> Hi Marc,
>
>=C2=A0 =C2=A0 Thanks for responding!=C2=A0 I meant 'protocol header= ' in the broadest
> sense.=C2=A0 I have implemented some protocols in the past (Web Socket= v13, SMTP
> etc) and work a lot with JSON and XML as I mentioned previously.=C2=A0= Here are
> some general frustrations (i.e. problem statement) that I'm lookin= g to
> overcome;
>
> 1) JSON and XML generally lack support for binary data (there are some=
> workarounds but nothing is super great).
> 2) JSON and XML both now have the concept of a Schema
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Note I think the concept of a Schema= is a good thing but also feel
> that Schemas often don't cover all
>=C2=A0 =C2=A0 =C2=A0 Metadata that needs to be covered.=C2=A0 Perhaps t= he concept of a Schema
> needs to be enhanced by UsageMetadata information.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Also note I am frustrated with JSON&= #39;s inability to provide human
> readable schemas (multi line text in the .json file (not /n)).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I also have frustrations with XML sc= hemas and XML (like everyone
> else who now favors JSON over XML)
> 3) Protocol's often have Headers and other information which act i= n a
> similar fashion to Schemas (i.e. they describe / specify data structur= es)
>
>=C2=A0 =C2=A0I'm wondering if it's time for a new markup langua= ge that can support
> binary data and assist in specifying protocol byte segments in additio= n to
> more general purpose transport and storage data (like JSON & XML d= o).
>=C2=A0 =C2=A0I'm thinking about calling it 'Classification Mark= up Notation'.
>
>=C2=A0 =C2=A0I messaged this to the group just to throw the idea out th= ere, to get
> feedback and also to find collaborators.
>
>
> On Thu, Jun 11, 2020 at 7:53 AM Marc Petit-Huguenin <marc@petit-huguenin.org&= gt;
> wrote:
>
>> Hi,
>>
>> On 6/10/20 5:14 PM, Scott Morgan wrote:
>>> Hi All,
>>>
>>>=C2=A0 =C2=A0 I have been working with JSON, XML and some proto= col headers recently
>>> and I am wondering...
>>> Why are there no real standard text formats for protocol heade= rs, or am I
>>> missing something?
>>>
>>> It seems to me that a slightly more streamlined/optimal binary= /markup
>>> standard could help protocols attain POCs and adoption much qu= icker and
>>> help reduce some of the work defining protocols.
>>>
>>> Any thoughts on this topic?
>>>
>>>
>>
>> Can you please elaborate on what you mean by "protocol header= "?=C2=A0 My
>> understanding of that term is the fixed part at the beginning of a= PDU, PDU
>> that also contains a variable length part after it (as in UDP Head= er, TCP
>> Header, RTP Header, HTTP, SIP, SMTP etc...), but that definition d= oes not
>> seem to apply to JSON or XML (as a whole).
>>

--
Marc Petit-Huguenin
Email: marc@pe= tit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug



--
<signat= ure.asc>--
FDT mailing list
FDT@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/fdt

--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--000000000000ec47a005a823f23e-- From nobody Tue Jun 16 09:43: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 8691D3A0366 for ; Tue, 16 Jun 2020 09:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 NeUt9d289S6u for ; Tue, 16 Jun 2020 09:43:28 -0700 (PDT) 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 CC2573A02C1 for ; Tue, 16 Jun 2020 09:43:27 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id s1so24404913ljo.0 for ; Tue, 16 Jun 2020 09:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RcSDPD9lruLaphlWCbrG9JO26/G+tKvDFYEdjDBQ8/I=; b=cJIcJyxHA14h7UAw4K41Lg3/7AzxYuj5xdyuv/2iAgO9KFLX/pv75d1rhlmuJVZafl 12qo1Xb1k6eCyrwT4XgFDoLNQXfGgqCucS9BfQqr3KwLTtakUzBv/eO6kBYAQq32X8nA Ysc4Hjp0lc97ogxNrqGY/cIp2aKDCS0KIIUylgIR4bbGGHme8/X64fLfIimN9TqhypBW ctBGgEQFR5TZHq8jSbbWqNwxDSSEogjf5KH94QtI9/pMTmvZpaOVKKD01ji27OvamBQQ c+Fq9Wz8TScIsvcezUjMqTqjSwUDcm7xg2jcZEepdUOPiKPlE/yBXf/LBxyohvsYN9YD R6fw== 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=RcSDPD9lruLaphlWCbrG9JO26/G+tKvDFYEdjDBQ8/I=; b=lBz9Tu96W0IsTVuExDva3sNszapxxbO4CHXECh8Xowdz1qztq/WymsyWAPVo4IzZ+M iWKnBZ155aQ6SSgQ0ulnplp/FMHXg9L+nJsusZJoXxG62gEowymLL3H8MVE3z8FPkToC or+O/b8PnTnzXqk//evcbEVR/ak1lfRL1z2h82nA7TRW16c5JwjpuKqkPlHfX9k5ZCbk 8JQnf9lviIyhcKdd4XOUYvMNNhuVuZ6IJ+cPmesv3Lu8mPKqsB78SJqjg+PXqPbNsua+ nzZmB2OfnTMNHs25MeRGJ+dHdwct/TuYFwBwXhbFOlaKPnC/sH2CzhuNyRPwsEBx1bY5 Hnyg== X-Gm-Message-State: AOAM532KVgMwlEVJ0xoEHlBeWXBnWctriU+aOaY5EfIXiq9WIgNsW/0I tdZWCMfaMyciRkW9GKJhZAxOs3veTcvW2u5wsmw= X-Google-Smtp-Source: ABdhPJygP7LsY+aZZ99/ZLBcNRhGdoEPSs9KpBQYpymJ2+E5CP4L9FHMLPdnX1I+ha5Oa/MZHiS3BBPCpaTuVbtKPCw= X-Received: by 2002:a05:651c:1199:: with SMTP id w25mr1973104ljo.301.1592325804840; Tue, 16 Jun 2020 09:43:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Tue, 16 Jun 2020 09:43:13 -0700 Message-ID: To: virat tara Cc: WebTransport Content-Type: multipart/alternative; boundary="000000000000f6e06105a8363df8" Archived-At: Subject: Re: [Webtransport] Demultiplexing in case of unreliable datagrams 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, 16 Jun 2020 16:43:30 -0000 --000000000000f6e06105a8363df8 Content-Type: text/plain; charset="UTF-8" Hi Virat, What are you trying to demultiplex? draft-vvv-webtransport-quic (as currently specified) will create a new QUIC connection per QuicTransport object, so there is no need to demultiplex between them. If you would like to demultiplex different flows of datagrams in your own application, then you can add a demultiplexing identifier of some kind at the start of your application payload. Hope this helps, David On Mon, Jun 15, 2020 at 10:52 AM virat tara wrote: > Hi, > > In *Section 6* "Transport Properties" there is a point mentioning Pooling > Support. In case of unreliable datagrams, how will demultiplexing be done > on the receiver end? Streams, on the other hand, have a unique stream ID. I > found a draft (draft-schinazi-quic-h3-datagram-03 > ) that > accomplishes this on HTTP/3 but since WebTransport will have its own > dedicated connection as mentioned in *Section 1.1 *"Background" how will > this be taken forward? > > Thanks, > Virat > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --000000000000f6e06105a8363df8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Virat,

What are you trying to demult= iplex?=C2=A0draft-vvv-webtransport-quic=C2=A0 (as currently specified) will= create a new QUIC connection per QuicTransport=C2=A0object, so there is no= need to demultiplex between them. If you would like to demultiplex differe= nt flows of datagrams in your own application, then you can add a demultipl= exing identifier of some kind at the=C2=A0start of your application payload= .

Hope this helps,
David

=
On Mon, Ju= n 15, 2020 at 10:52 AM virat tara <virattara@gmail.com> wrote:
Hi,

In Section 6 "Transport Properties" there is a point mentioning Pooling Supp= ort. In case of unreliable datagrams, how will demultiplexing be done on th= e receiver end? Streams, on the other hand, have a unique stream ID. I foun= d a draft (draft-schinazi-quic-h3-datagram-03) that a= ccomplishes this on HTTP/3 but since WebTransport will have its own dedicat= ed connection as mentioned in Section 1.1 "Background" how= will this be taken forward?

= Thanks,
Virat
--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--000000000000f6e06105a8363df8-- From nobody Tue Jun 16 11:47:59 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 0D57F3A1230 for ; Tue, 16 Jun 2020 11:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 mMJz9CTj7pkI for ; Tue, 16 Jun 2020 11:47:57 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 830463A1231 for ; Tue, 16 Jun 2020 11:47:57 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id v25so7271434uau.4 for ; Tue, 16 Jun 2020 11:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kyuVyxT8V6w6MSJQCyM9VA0TkwuL5fUDe11zoIJQLX0=; b=W1/X4Yody8WfpVkoaVCUq15k7k6AnL4y1pDhCmiKBKATqh0fmgWION+6hH0rvVJ2KA F4u+4okPJsz6o+gGBnwuM41AfYaDp/RXE+4IlbIGJXukwmrGkB6pOv3UXn+ewltOCStu WaBzJyWXpsAmyRT3g1cYiMbSHqntZaFDKQ6SN8toLklH0tjXeIiXCNohH2ahrLphk5l2 R3KfMR3kk/Cpc+8OLyt30n0fGaRAdD0i4MB024Mn24meUKKyvnG3F6PVXMYOxyOyA33D bB7YRoQ91DGSnCAp2ogeG/JN7iDKVmBzZAt5/BLTzNEi00LbGX7ix9HcbeCgc4otDTmI TcxA== 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=kyuVyxT8V6w6MSJQCyM9VA0TkwuL5fUDe11zoIJQLX0=; b=pszs7CBnt8B2Nn6PUjm0B8HlaPTMzlcn5xC3yA1/KrwG/usQ2RXZMzqyKcdCo6pvDy KJcFhQIUT8tOtOhje92Vrm2vXVSUV1hJVPLwubEPdj6JFDCzUwFhuYBVMkzK7C1ebhFh lI0+hcjJBm//lM4hJHFcEjyhs3mp9n07q4/wXxdymhvrcMzeqeu4cPcyVE4uMG+kNUZ2 SwvL///6+oT8p4zUNVJNajZ0SMwbe7hokyW9TOQXrjpP+N+BUJ4AzIKe50hh+BvozbIy C+oQZouXxm4p8lamprRkn5HAYeFm9NUx27pvHpFcoMRWE9I700p+tHtUEN2onYmeIog4 r9Ig== X-Gm-Message-State: AOAM531fZfRh7o4rVw9J7Jfxqh+a+tfy29nUySR51WbEwNwOFzhg2jPk aWDZ0lN/vonWbbm/R4/xlBDBIbp95qEKXUuYVAw= X-Google-Smtp-Source: ABdhPJwa+Sb8ZSwou8qt2/ORwRV/sHk7l/CbgADvboQUGhhbSU9nCU8EQfd+l8vxf9taaJZwiUMf/pnBifbFmpzN19E= X-Received: by 2002:a9f:22e1:: with SMTP id 88mr3241561uan.19.1592333276265; Tue, 16 Jun 2020 11:47:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: virat tara Date: Wed, 17 Jun 2020 00:17:43 +0530 Message-ID: To: David Schinazi Cc: WebTransport Content-Type: multipart/alternative; boundary="0000000000004bc6bb05a837fb30" Archived-At: Subject: Re: [Webtransport] Demultiplexing in case of unreliable datagrams 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, 16 Jun 2020 18:47:59 -0000 --0000000000004bc6bb05a837fb30 Content-Type: text/plain; charset="UTF-8" Hi David, Thanks for the reply, I was talking in the context of this draft draft-ietf-webtrans-overview-00 (sorry for not mentioning it earlier) which mentions pooling as a property of the WebTransport. Actually, I was studying the ongoing work in WebTransport but didn't go through draft-vvv-webtransport-quic since it was expired. But yeah I got it now. I found 4 drafts related to this work. 1. draft-ietf-webtrans-overview-00 2. draft-vvv-webtransport-quic-01 / draft-vvv-webtransport-http3-01 3. draft-kinnear-webtransport-http2-00 Where drafts under 2nd point are up for discussion as to which one to keep. Thanks, Virat On Tue, Jun 16, 2020 at 10:13 PM David Schinazi wrote: > Hi Virat, > > What are you trying to demultiplex? draft-vvv-webtransport-quic (as > currently specified) will create a new QUIC connection per > QuicTransport object, so there is no need to demultiplex between them. If > you would like to demultiplex different flows of datagrams in your own > application, then you can add a demultiplexing identifier of some kind at > the start of your application payload. > > Hope this helps, > David > > On Mon, Jun 15, 2020 at 10:52 AM virat tara wrote: > >> Hi, >> >> In *Section 6* "Transport Properties" there is a point mentioning >> Pooling Support. In case of unreliable datagrams, how will demultiplexing >> be done on the receiver end? Streams, on the other hand, have a unique >> stream ID. I found a draft (draft-schinazi-quic-h3-datagram-03 >> ) that >> accomplishes this on HTTP/3 but since WebTransport will have its own >> dedicated connection as mentioned in *Section 1.1 *"Background" how will >> this be taken forward? >> >> Thanks, >> Virat >> -- >> Webtransport mailing list >> Webtransport@ietf.org >> https://www.ietf.org/mailman/listinfo/webtransport >> > --0000000000004bc6bb05a837fb30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi David,

Thanks for the reply, I was talking= in the context of this draft=C2=A0draft-ietf-webtrans-overview-00=C2=A0(s= orry for not mentioning it earlier)=C2=A0which mentions pooling as a proper= ty of the WebTransport. Actually, I was studying the ongoing work in WebTra= nsport but didn't go through draft-vvv-webtransport-quic since it was e= xpired. But yeah I got it now.=C2=A0

I found 4 dra= fts related to this work.
1.=C2=A0draft-ietf-webtrans-overview-00
2.= =C2=A0draft-vvv-webtransport-quic-01 /=C2=A0draft-vvv-webtransport-http3-01=
3.=C2=A0draft-kinnear-webtransport-http2-00

Where drafts under 2nd point are up for dis= cussion as to which one to keep.

Thanks,
Virat

On Tue, Jun 16, 2020 at 10:13 PM David Schinazi <dschinazi.ietf@gmail.com> wrote:
H= i Virat,

What are you trying to demultiplex?=C2=A0draft-= vvv-webtransport-quic=C2=A0 (as currently specified) will create a new QUIC= connection per QuicTransport=C2=A0object, so there is no need to demultipl= ex between them. If you would like to demultiplex different flows of datagr= ams in your own application, then you can add a demultiplexing identifier o= f some kind at the=C2=A0start of your application payload.

Hope this helps,
David

On Mon, Jun 15, 2020 at 10:5= 2 AM virat tara <virattara@gmail.com> wrote:
Hi,

In Section 6 "Transport Properties" there is a point mentioning Pooling Supp= ort. In case of unreliable datagrams, how will demultiplexing be done on th= e receiver end? Streams, on the other hand, have a unique stream ID. I foun= d a draft (draft-schinazi-quic-h3-datagram-03) that a= ccomplishes this on HTTP/3 but since WebTransport will have its own dedicat= ed connection as mentioned in Section 1.1 "Background" how= will this be taken forward?

= Thanks,
Virat
--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--0000000000004bc6bb05a837fb30-- From nobody Tue Jun 16 14:04:01 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 5CDB63A060D for ; Tue, 16 Jun 2020 14:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 d1LQ7jYFtjNz for ; Tue, 16 Jun 2020 14:03:58 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 2B27D3A0602 for ; Tue, 16 Jun 2020 14:03:58 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id z206so12640722lfc.6 for ; Tue, 16 Jun 2020 14:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/ewBJc5JMvH5AA/Dr/g9STLI5/xh2IpZ+88T9ksfElw=; b=OXa9BARQ88cxc7pKPcJeBfOjUAKcb28+wBXj0j1UFuqxXozUOL8KHwG3FBAdWUJdMA 7gcfEyNmD2BaAVPNnlelGLL2ZMl7WQ9cMlOt/iXadwedTgdy/d+Rcb8UHeEDoelTx7tA iUQcnYZeufYhboP5R57ddSsrMr7cySqQ64ofwh+vhJYn0g5Hep9tgkZBMx4S6LwXevIA kT5QihO21yAHFYU3p5HkjSstjeU5CfqNyJ5bh4LQglp9Rd3Kf8ooNdgdHlR4HGhUlBYZ LtkyiBeXuYRCZ+i1eK4glQYLL5k6prxLucGU5WtmYLwx8pFGEP9bYPD02ogSHVXU+7Gz 8qmQ== 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=/ewBJc5JMvH5AA/Dr/g9STLI5/xh2IpZ+88T9ksfElw=; b=lWbb0I/VBP1a+IAkdsU/6pwz+fFnHvjSvBSr4qlOmrURtqU+2HkLXdSDf2DOojZke9 MDOpbm5BK3k6fPvz9CGNusQFLPaiR5c/Xm3LBitEJ3PpgZ9PE6/m92Bl3oIscn2FILsp 4t/mbdesZTEv5IUq+FA9hUJI5YWysrluLW/nQn8vmDPLhoHQYQ2hRu2M+gojkGWHaRTY lYCDd3CxqvEdbrVbrutIals5kDbKvu58FR51VJOUzUBMeH86XvjUSpjpd40EChkcEWvV 2SE3PeZW6wIgyangiJCTznNzY3p9OTBsVZZKMIOXK3xben4B097kxY8cipug4pkmsq7e 2qng== X-Gm-Message-State: AOAM530I/Jf96DWd72KTvUzeUtZUW6Px6ZdUYfnOS4Fli7THuwMroqOn 60ZIw9A5j55cf1VMiJrKmDXUCQwtab0ogVjizLs= X-Google-Smtp-Source: ABdhPJxlQ+pCNwnZ88jqbKQ+jwfNfzM6KpjwOvZcHda+mzFx+ONT6NDiDrB1BZ24Zmm4Pra5mmHrzF9j5Af60drLx+M= X-Received: by 2002:a19:5212:: with SMTP id m18mr2659953lfb.127.1592341436067; Tue, 16 Jun 2020 14:03:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bernard Aboba Date: Tue, 16 Jun 2020 14:03:45 -0700 Message-ID: To: virat tara Cc: David Schinazi , WebTransport Content-Type: multipart/alternative; boundary="000000000000a8743e05a839e1f7" Archived-At: Subject: Re: [Webtransport] Demultiplexing in case of unreliable datagrams 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, 16 Jun 2020 21:04:00 -0000 --000000000000a8743e05a839e1f7 Content-Type: text/plain; charset="UTF-8" Virat -- The Http3Transport would be used along with HTTP/3 datagrams, as described in https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram In Section 2 of that document, you will notice the addition of a flow identifier: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Identifier (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HTTP/3 Datagram Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Section 3 describes how the flow identifier is to be allocated: Implementations of HTTP/3 that support the DATAGRAM extension MUST provide a flow identifier allocation service. That service will allow applications co-located with HTTP/3 to request a unique flow identifier that they can subsequently use for their own purposes. The HTTP/3 implementation will then parse the flow identifier of incoming DATAGRAM frames and use it to deliver the frame to the appropriate application. So in the case of a pooled Http3Transport, the flow identifier would allow the datagrams to be de-multiplexed to the correct application. In the event that an individual application utilizes multiple datagrams flows, that application would need to include an additional identifier within the "Datagram Payload". Make sense? On Tue, Jun 16, 2020 at 11:48 AM virat tara wrote: > Hi David, > > Thanks for the reply, I was talking in the context of this draft > draft-ietf-webtrans-overview-00 > (sorry for > not mentioning it earlier) which mentions pooling as a property of the > WebTransport. Actually, I was studying the ongoing work in WebTransport but > didn't go through draft-vvv-webtransport-quic since it was expired. But > yeah I got it now. > > I found 4 drafts related to this work. > 1. draft-ietf-webtrans-overview-00 > 2. draft-vvv-webtransport-quic-01 / draft-vvv-webtransport-http3-01 > 3. draft-kinnear-webtransport-http2-00 > > Where drafts under 2nd point are up for discussion as to which one to keep. > > Thanks, > Virat > > On Tue, Jun 16, 2020 at 10:13 PM David Schinazi > wrote: > >> Hi Virat, >> >> What are you trying to demultiplex? draft-vvv-webtransport-quic (as >> currently specified) will create a new QUIC connection per >> QuicTransport object, so there is no need to demultiplex between them. If >> you would like to demultiplex different flows of datagrams in your own >> application, then you can add a demultiplexing identifier of some kind at >> the start of your application payload. >> >> Hope this helps, >> David >> >> On Mon, Jun 15, 2020 at 10:52 AM virat tara wrote: >> >>> Hi, >>> >>> In *Section 6* "Transport Properties" there is a point mentioning >>> Pooling Support. In case of unreliable datagrams, how will demultiplexing >>> be done on the receiver end? Streams, on the other hand, have a unique >>> stream ID. I found a draft (draft-schinazi-quic-h3-datagram-03 >>> ) that >>> accomplishes this on HTTP/3 but since WebTransport will have its own >>> dedicated connection as mentioned in *Section 1.1 *"Background" how >>> will this be taken forward? >>> >>> Thanks, >>> Virat >>> -- >>> 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 > --000000000000a8743e05a839e1f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Virat -= -

The Http3Transport=C2=A0would be used along with HTTP/= 3 datagrams, as described in=C2=A0https://tools.ietf.org/html/draft-schinazi-q= uic-h3-datagram

In Section 2 of that document, y= ou will notice the addition of a flow identifier:=C2=A0
    0      =
             1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Flow Identifier (i)                     ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 HTTP/3 Datagram Payload (*)                 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<= pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar= gin-bottom:0px;break-before:page;color:rgb(0,0,0)">
Section 3 describes how the flow iden=
tifier is to be allocated: 

   Implementations of HTTP/3 that support t=
he DATAGRAM extension MUST
   provide a flow identifier allocation service.  That service will
   allow applications co-located with HTTP/3 to request a unique flow
   identifier that they can subsequently use for their own purposes.
   The HTTP/3 implementation will then parse the flow identifier of
   incoming DATAGRAM frames and use it to deliver the frame to the
   appropriate application.

So in the case of a pooled Http3Trans=
port, the flow identifier would allow the datagrams to be de-multiplexed to=
 the correct application.

In the event that an individual applica=
tion utilizes multiple datagrams flows, that application would need to incl=
ude an additional identifier within the "Datagram Payload". 

Make sense?

On Tue, Jun 16, 2020= at 11:48 AM virat tara <virattar= a@gmail.com> wrote:
Hi David,

Thanks for the reply, I = was talking in the context of this draft=C2=A0draft-ietf-web= trans-overview-00=C2=A0(sorry for not mentioning it earlier)=C2=A0which= mentions pooling as a property of the WebTransport. Actually, I was studyi= ng the ongoing work in WebTransport but didn't go through draft-vvv-web= transport-quic since it was expired. But yeah I got it now.=C2=A0

I found 4 drafts related to this work.
1.=C2=A0draft-iet= f-webtrans-overview-00
2.=C2=A0draft-vvv-webtransport-quic-01 /=C2=A0dra= ft-vvv-webtransport-http3-01
3.=C2=A0draft-kinnear-webtransport-http2-00

Where drafts under 2nd point are up for dis= cussion as to which one to keep.

Thanks,
Virat

On Tue, Jun 16, 2020 at 10:13 PM David Schinazi <dschinazi.ietf@gmail.com= > wrote:
=
Hi Virat,

What are you trying to demult= iplex?=C2=A0draft-vvv-webtransport-quic=C2=A0 (as currently specified) will= create a new QUIC connection per QuicTransport=C2=A0object, so there is no= need to demultiplex between them. If you would like to demultiplex differe= nt flows of datagrams in your own application, then you can add a demultipl= exing identifier of some kind at the=C2=A0start of your application payload= .

Hope this helps,
David

=
On Mon, Ju= n 15, 2020 at 10:52 AM virat tara <virattara@gmail.com> wrote:
= Hi,

= In Section 6 "Transport Properties" there is a point menti= oning Pooling Support. In case of unreliable datagrams, how will demultiple= xing be done on the receiver end? Streams, on the other hand, have a unique= stream ID. I found a draft (draft-schinazi-quic-h3-datag= ram-03) that accomplishes this on HTTP/3 but since WebTransport will ha= ve its own dedicated connection as mentioned in Section 1.1 "Ba= ckground" how will this be taken forward?

<= div>Thanks,
Virat
=
--
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=
--000000000000a8743e05a839e1f7-- From nobody Wed Jun 17 01:07:05 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 3AE6E3A02BE for ; Wed, 17 Jun 2020 01:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 FRpI7y8ndYrc for ; Wed, 17 Jun 2020 01:07:02 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 528093A00D6 for ; Wed, 17 Jun 2020 01:07:02 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id y123so850955vsb.6 for ; Wed, 17 Jun 2020 01:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nB2XdUF9Uj1PhUDxXaChZ6+qdiR7xZhA5IaeS6JxhvQ=; b=XkcwftXoEmaMZqYxQoIcRAc+vDPPkbPOG2gaLcjaT/qBIiOQXlsdY9zSNgjhSzYJoX qZMj7rZto3jrIO7baWtoRhuFfjnjUyS/uKfaov1wjiocTlWTJGpEpXpxc5d7EmvHfKKa CsNSOdh5yN4KhCsxj/UxGKK0ams9Rc4cuoaBMpcA0RsvQgmTfRxIAdZf5/25rlXrazHq KfFGQOahXunC6NbdUqaNQ7VQ73l6v9Orq0PAAhNZ/evXfpBCy40cnBnsAs+b5vGQung3 KZ9QWEkNN/E4cpFA6t/UhUREaQu8zf9wi7v0Ck61odERmrfo8bOUOImTWAomaOQcSI4H 2GVA== 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=nB2XdUF9Uj1PhUDxXaChZ6+qdiR7xZhA5IaeS6JxhvQ=; b=YKoDGKWspF4mMc+L/CtM89vFDU38qZbuUc6ATfALYiuaA5YWOsJ4aNAhWcpeUKRUP/ y9kP/gATaeH01aZQsWQ+pdIIbvThc2VpiC4J7suzHfiVmTLOuapeSyL5uyr4QAyw4aWn dtQE8BGlxorDfF/Ce5+zJCFVKbPV8cNuC/hU+vzDZehU15VUtwDHsbfRihq6CFrdgjmQ weTBOa2fBJNpT1OTaRfZf3iCDz+M21TWFIpukoCUrFG5dlxlORGCwwS5NFAEMCACZPVj BqNQqvKxI2am2Xwi0pKq1cMcWTG8G+SXGMB80KmCVRQ3S8h81cO9JvJ4mPpVB6BgMl9J cl7A== X-Gm-Message-State: AOAM530ty9c+9T+/ErYFa7Y11n2w2LOSLsibcx8W7Ms/4rlBIYZbfuNh w/G1vB9rbXwHdrM7y91H7ejubFPkcGZ0xiA5MRw= X-Google-Smtp-Source: ABdhPJxZncUvjvVSRHGlNX3oh25JIIVUCWwLaXh2DzRLpWcdS1kuTB1FuSSt/VPT8PqnCZWvqtQzCdEoyR4aTFR8azI= X-Received: by 2002:a05:6102:36b:: with SMTP id f11mr4300041vsa.124.1592381221173; Wed, 17 Jun 2020 01:07:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: virat tara Date: Wed, 17 Jun 2020 13:36:49 +0530 Message-ID: To: Bernard Aboba Cc: David Schinazi , WebTransport Content-Type: multipart/alternative; boundary="00000000000008fe4d05a8432533" Archived-At: Subject: Re: [Webtransport] Demultiplexing in case of unreliable datagrams 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, 17 Jun 2020 08:07:04 -0000 --00000000000008fe4d05a8432533 Content-Type: text/plain; charset="UTF-8" Got it, thanks! On Wed, Jun 17, 2020 at 2:33 AM Bernard Aboba wrote: > Virat -- > > The Http3Transport would be used along with HTTP/3 datagrams, as described > in https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram > > In Section 2 of that document, you will notice the addition of a flow > identifier: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flow Identifier (i) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | HTTP/3 Datagram Payload (*) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Section 3 describes how the flow identifier is to be allocated: > > > Implementations of HTTP/3 that support the DATAGRAM extension MUST > provide a flow identifier allocation service. That service will > allow applications co-located with HTTP/3 to request a unique flow > identifier that they can subsequently use for their own purposes. > The HTTP/3 implementation will then parse the flow identifier of > incoming DATAGRAM frames and use it to deliver the frame to the > appropriate application. > > > So in the case of a pooled Http3Transport, the flow identifier would allow the datagrams to be de-multiplexed to the correct application. > > > In the event that an individual application utilizes multiple datagrams flows, that application would need to include an additional identifier within the "Datagram Payload". > > > Make sense? > > > On Tue, Jun 16, 2020 at 11:48 AM virat tara wrote: > >> Hi David, >> >> Thanks for the reply, I was talking in the context of this draft >> draft-ietf-webtrans-overview-00 >> (sorry for >> not mentioning it earlier) which mentions pooling as a property of the >> WebTransport. Actually, I was studying the ongoing work in WebTransport but >> didn't go through draft-vvv-webtransport-quic since it was expired. But >> yeah I got it now. >> >> I found 4 drafts related to this work. >> 1. draft-ietf-webtrans-overview-00 >> 2. draft-vvv-webtransport-quic-01 / draft-vvv-webtransport-http3-01 >> 3. draft-kinnear-webtransport-http2-00 >> >> Where drafts under 2nd point are up for discussion as to which one to >> keep. >> >> Thanks, >> Virat >> >> On Tue, Jun 16, 2020 at 10:13 PM David Schinazi >> wrote: >> >>> Hi Virat, >>> >>> What are you trying to demultiplex? draft-vvv-webtransport-quic (as >>> currently specified) will create a new QUIC connection per >>> QuicTransport object, so there is no need to demultiplex between them. If >>> you would like to demultiplex different flows of datagrams in your own >>> application, then you can add a demultiplexing identifier of some kind at >>> the start of your application payload. >>> >>> Hope this helps, >>> David >>> >>> On Mon, Jun 15, 2020 at 10:52 AM virat tara wrote: >>> >>>> Hi, >>>> >>>> In *Section 6* "Transport Properties" there is a point mentioning >>>> Pooling Support. In case of unreliable datagrams, how will demultiplexing >>>> be done on the receiver end? Streams, on the other hand, have a unique >>>> stream ID. I found a draft (draft-schinazi-quic-h3-datagram-03 >>>> ) that >>>> accomplishes this on HTTP/3 but since WebTransport will have its own >>>> dedicated connection as mentioned in *Section 1.1 *"Background" how >>>> will this be taken forward? >>>> >>>> Thanks, >>>> Virat >>>> -- >>>> 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 >> > --00000000000008fe4d05a8432533 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Got it, thanks!=C2=A0

On Wed, Jun 17, 2020 at 2:33 AM B= ernard Aboba <bernard.aboba@g= mail.com> wrote:
Virat --

The Http3Transport=C2=A0would be used along wi= th HTTP/3 datagrams, as described in=C2=A0https://tools.ietf= .org/html/draft-schinazi-quic-h3-datagram

In Sec= tion 2 of that document, you will notice the addition of a flow identifier:= =C2=A0

    0    =
               1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Flow Identifier (i)                     ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 HTTP/3 Datagram Payload (*)                 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<= pre style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-bef= ore:page;color:rgb(0,0,0)">
Section 3 =
describes how the flow identifier is to be allocated: 

   Implementa=
tions of HTTP/3 that support the DATAGRAM extension MUST
   provide a flow identifier allocation service.  That service will
   allow applications co-located with HTTP/3 to request a unique flow
   identifier that they can subsequently use for their own purposes.
   The HTTP/3 implementation will then parse the flow identifier of
   incoming DATAGRAM frames and use it to deliver the frame to the
   appropriate application.

So in the =
case of a pooled Http3Transport, the flow identifier would allow the datagr=
ams to be de-multiplexed to the correct application.

In the event that an individual application utilizes multipl=
e datagrams flows, that application would need to include an additional ide=
ntifier within the "Datagram Payload". 

Make sense?

On Tue, Jun 16, = 2020 at 11:48 AM virat tara <virattara@gmail.com> wrote:
Hi David,

Th= anks for the reply, I was talking in the context of this draft=C2=A0draft-ietf-webtrans-overview-00=C2=A0(sorry for not mentioning = it earlier)=C2=A0which mentions pooling as a property of the WebTransport. = Actually, I was studying the ongoing work in WebTransport but didn't go= through draft-vvv-webtransport-quic since it was expired. But yeah I got i= t now.=C2=A0

I found 4 drafts related to this work= .
1.=C2=A0draft-ietf-webtrans-overview-00
2.=C2=A0draft-vvv-webtransp= ort-quic-01 /=C2=A0draft-vvv-webtransport-http3-01
3.=C2=A0draft-kinnear= -webtransport-http2-00

Where drafts under 2nd point are up for dis= cussion as to which one to keep.

Thanks,
Virat

On Tue, Jun 16, 2020 at 10:13 PM David Schinazi <dschinazi.ietf@gmail.com= > wrote:
=
Hi Virat,

What are you trying to demult= iplex?=C2=A0draft-vvv-webtransport-quic=C2=A0 (as currently specified) will= create a new QUIC connection per QuicTransport=C2=A0object, so there is no= need to demultiplex between them. If you would like to demultiplex differe= nt flows of datagrams in your own application, then you can add a demultipl= exing identifier of some kind at the=C2=A0start of your application payload= .

Hope this helps,
David

=
On Mon, Ju= n 15, 2020 at 10:52 AM virat tara <virattara@gmail.com> wrote:
= Hi,

= In Section 6 "Transport Properties" there is a point menti= oning Pooling Support. In case of unreliable datagrams, how will demultiple= xing be done on the receiver end? Streams, on the other hand, have a unique= stream ID. I found a draft (draft-schinazi-quic-h3-datag= ram-03) that accomplishes this on HTTP/3 but since WebTransport will ha= ve its own dedicated connection as mentioned in Section 1.1 "Ba= ckground" how will this be taken forward?

<= div>Thanks,
Virat
=
--
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=
--00000000000008fe4d05a8432533-- From nobody Thu Jun 18 00:06: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 235493A0A41 for ; Thu, 18 Jun 2020 00:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 H1KXDJwCAxKQ for ; Thu, 18 Jun 2020 00:06:52 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 400253A0A13 for ; Thu, 18 Jun 2020 00:06:52 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id g139so2024400lfd.10 for ; Thu, 18 Jun 2020 00:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=YZWcoXLW7baXZtRRvyu7Kpy7FDxLBH/Mmiry16HbDbU=; b=uNoEK+OywqhUscjj7ng4UVwsb5jP3HNZ74lDm/SGSKiokstw7fqf6zAgBLjjFlybYd jk8ni8OSDEv3JO6hkOjJmoVM5k1Pdf8AbqPLKxScpXfaqG4gn3HMYddkP6KrJJm97kVq c7hKA/An9APO2RxVRzrtzR8gst5VVX36n1jbcay4xkEmXHScCEf51W8e3VLu/yS5JZkk o1j15xe5jUTj6mDoXWZ2DgpXsclSM40KJKwpJdV6zUomX1M13ah5ASAzZ+LcQnKvh2Ue hXZwtQ7x+SP4kF/kwq7eQh9U3Ki7QP/NP2nsivGraVAlOYbRu9kccecqgfNm0H36ojRG iF2Q== 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=YZWcoXLW7baXZtRRvyu7Kpy7FDxLBH/Mmiry16HbDbU=; b=iOnP9gG72HX14XX+RV9ROVXX15wfeIWGIjfe3qYIOeJF4EJtuBZHb9lgMYiHdxe47Y 14S0OampDzo2QfPc3dXBr4+BKjaWWvlXMmS9KPHCBYXQvnWbazaPSH9rXbCjqWeBrOxJ IvrnjVLnfCKtsaJHZXrTRCm5+6VK6VhTe+StMBGny6zUeg8NEBxx3RzRhEtngchcUWC0 fThB09ts8RKwXew93lUATDBf2Il3rgJyO8dE9uRUgaeUzmETjQffQ/M+op/wq5Y2biq0 9FFNouEQf1KMm1eNh24crf+dBfNgIy0zWpoE71TS3wf3KVVt9cyPmSegyu22XWejLMel 7r7w== X-Gm-Message-State: AOAM533yx4Uy/tWSh0Mcj1PhqdcvO4nQ4Rv04e2AnUEDGHeFDES0CL0f qmpqtWSs2TxSnQoFtZnW/SCB04mrcBswQsv8xNp8ALz0iyA= X-Google-Smtp-Source: ABdhPJyYnuQtVTpU6FOyktpxJsRZwjQlkbkubo9ip7fxCGxKNrE9iQgZVouXllbaozJR6X6Pjj7pu8DrUqRQT7upAWQ= X-Received: by 2002:a19:815:: with SMTP id 21mr1482285lfi.119.1592464009639; Thu, 18 Jun 2020 00:06:49 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Thu, 18 Jun 2020 00:06:38 -0700 Message-ID: To: WebTransport Content-Type: multipart/alternative; boundary="0000000000009cba8e05a8566b20" Archived-At: Subject: [Webtransport] WebTransport News... 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: Thu, 18 Jun 2020 07:06:54 -0000 --0000000000009cba8e05a8566b20 Content-Type: text/plain; charset="UTF-8" The W3C is now in the final phase of review for the WebTransport WG charter: https://w3c.github.io/webtransport-charter/charter.html The latest draft of the WebTransport API can be found here: https://wicg.github.io/web-transport/ If you would like to try out the WebTransport API via the QuicTransport protocol, you may do so via the QuicTransport Origin Trial in Chromium. Let us know if there is interest in exploring this further during the IETF 108 Hackathon. A sample web page is here: https://googlechrome.github.io/samples/quictransport/client.html If you want a QuicTransport server to point to, but don't have your own, you can try this one: quic-transport://webrtc.internaut.com:6161/counter Some pointers to help your experimentation go smoothly. To avoid QUIC version conflicts, please use an up-to-date version of Canary along with (for the server) the most recent build of aioquic (build 0.9.5 or later). References Documentation on the QuicTransport Trial is here: https://web.dev/quictransport/ The aioquic repo is here: https://github.com/aiortc/aioquic A discussion group is available here: https://groups.google.com/a/chromium.org/forum/#!forum/web-transport-dev A tracking bug is here: https://bugs.chromium.org/p/chromium/issues/detail?id=1011392 A copy of the sample client is here: https://webrtc.internaut.com/quic/trial.html --0000000000009cba8e05a8566b20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The W3C is now in the final phase of review for the WebTra= nsport WG charter:

The latest draft of the WebTransport API can be f= ound=C2=A0here:=C2=A0
https://wicg.github.io/web-transport/

If = you would like to try out the WebTransport API via the QuicTransport protoc= ol, you may do so via the QuicTransport Origin Trial in Chromium.=C2=A0 Let= us know=C2=A0if there is interest in exploring this further during the IET= F 108 Hackathon.=C2=A0

If you want a QuicTransport server to point to, but do= n't have your own, you can try this one:

Some pointers to help you= r experimentation go smoothly.=C2=A0

To avoid QUIC= version conflicts, please use an up-to-date version of Canary along with (= for the server) the most recent build of aioquic (build 0.9.5 or later).=C2= =A0

References

Docum= entation on the QuicTransport Trial is here:=C2=A0https://web.dev/quictransport/
The aioquic = repo is here:=C2=A0https://gi= thub.com/aiortc/aioquic
A tracking=C2=A0bug is here:=C2=A0<= a href=3D"https://bugs.chromium.org/p/chromium/issues/detail?id=3D1011392">= https://bugs.chromium.org/p/chromium/issues/detail?id=3D1011392

A copy of the sample client is here: https://webrtc.internaut.com/quic/tria= l.html


--0000000000009cba8e05a8566b20--