From nobody Mon Jun 3 09:27:07 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883421204B0; Mon, 3 Jun 2019 09:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwcl4VjSKGwD; Mon, 3 Jun 2019 09:27:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7B21204DA; Mon, 3 Jun 2019 09:27:00 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x53GQocU029357 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 3 Jun 2019 11:26:51 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1559579217; bh=TTdmEngTmBIFE9JDxF6elepn/F2LNFMvo8pHhmzHO8I=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=ReVFK62wEvW9xAdvIdJa539SeRQC6b7rg5YqtzliObqELDUNeck+h3KFxgs9y4V8G UsT+3ej0hlgEvMwt9TdquuWCYyt3VmtdGEORsttkBVKwO2v4AV7LCL+guwprwuUezR x2DhILV6Zel+WFzXTEMCWQ1zj0PjI2wdmHD5f2ug= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: <5400BA9D-68C6-4D05-97C4-13AE2F7830A0@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_9085D683-41C6-4BF8-8341-AD4E5D444142"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 3 Jun 2019 11:26:42 -0500 In-Reply-To: Cc: ART ADs , dispatch chairs , Mary Barnes To: DISPATCH References: <76708F20-14F5-4BAB-BD12-D104D3A100B5@ietf.org> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dispatch] BOF proposals due in 4 weeks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 16:27:06 -0000 --Apple-Mail=_9085D683-41C6-4BF8-8341-AD4E5D444142 Content-Type: multipart/alternative; boundary="Apple-Mail=_94853F3A-6FC1-4538-8DB7-1DEA645ED7EE" --Apple-Mail=_94853F3A-6FC1-4538-8DB7-1DEA645ED7EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just a reminder-reminder: We are one week from the date to notify the DISPATCH chairs and/or WG of = plans to submit a proposal/topic Thanks! Ben.. > On May 10, 2019, at 11:00 AM, Mary Barnes = wrote: >=20 > Hi all, >=20 > Just a reminder that the first deadline for IETF-105 is coming up in 4 = weeks. >=20 > The remaining deadlines that need to be considered for the DISPATCH WG = for IETF-105 are available on the wiki and summarized below: = https://trac.ietf.org/trac/dispatch/wiki/WikiStart = > June 10, 2019. Cutoff date to notify the chairs/DISPATCH WG of plans = to submit a proposal/topic. > June 17, 2019. Cutoff for proposals (i.e., problem statement and = proposed deliverables) for topics posted to the DISPATCH WG mailing = list. > June 24, 2019. Announcement of topics that have been dispatched for = IETF-105. > July 8, 2019. Draft submission deadline. > A complete list of deadlines for IETF-105 is available here: = https://datatracker.ietf.org/meeting/important-dates/ = > If you have a topic that you are interested in pursuing in the ART = area and are not sure the best way to get started, please contact the = DISPATCH WG chairs and/or the ADs using the above aliases. >=20 > Regards, >=20 > Mary >=20 > DISPATCH WG co-chair >=20 >=20 > ---------- Forwarded message --------- > From: IETF Chair > > Date: Fri, May 10, 2019 at 9:42 AM > Subject: BOF proposals due in 4 weeks > To: IETF-Announce > > Cc: IETF > >=20 >=20 > This is a friendly reminder that the deadline for submitting proposals = for "Birds of a Feather=E2=80=9D (BOF) sessions at IETF 105 is in 4 = weeks: June 7 at 23:59 UTC. Instructions for submitting your proposal = are available at https://ietf.org/iesg/bof-procedures.html = . Please also read = https://tools.ietf.org/html/rfc5434 = , Considerations for Having a = Successful Birds-of-a-Feather Session, if you are not familiar with it. >=20 > If you are working on a BOF request but you=E2=80=99re not quite ready = to submit it, please tell the IESG now by sending an email to = iesg@ietf.org to get advance help with the = request. We have a number of ways of bringing new work into the IETF and = BOFs are just one of them, so please talk to the IESG or an individual = area director (https://ietf.org/iesg/members.html = ) about your idea if you=E2=80=99re = thinking about proposing a BOF. >=20 > Thanks, > Alissa Cooper > IETF Chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_94853F3A-6FC1-4538-8DB7-1DEA645ED7EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Just = a reminder-reminder:

We are one week from the date to notify the DISPATCH chairs = and/or WG of plans to submit a proposal/topic

Thanks!

Ben..

On May 10, 2019, at 11:00 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

Hi all,

Just a reminder that the first deadline = for IETF-105 is coming up in 4 weeks.  
The remaining deadlines that need to = be considered for the DISPATCH WG for IETF-105 are available on the wiki = and summarized below:   https://trac.ietf.org/trac/dispatch/wiki/WikiStart
  • June= 10, 2019. Cutoff date to notify the chairs/DISPATCH WG of plans to = submit a proposal/topic.
  • June 17, 2019. Cutoff for proposals (i.e., problem statement = and proposed deliverables) for topics posted to the DISPATCH WG mailing = list.
  • June = 24, 2019. Announcement of topics that have been dispatched for = IETF-105.
  • July = 8, 2019. Draft submission deadline.

A complete list of deadlines for IETF-105 is available = here: https://datatracker.ietf.org/meeting/i= mportant-dates/

If you = have a topic that you are interested in pursuing in the ART area and are = not sure the best way to get started, please contact the DISPATCH WG = chairs and/or the ADs using the above aliases.

Regards,

Mary

DISPATCH WG co-chair


---------- Forwarded message ---------
From: IETF = Chair <chair@ietf.org>Date: Fri, May 10, 2019 at 9:42 AM
Subject: = BOF proposals due in 4 weeks
To: IETF-Announce <ietf-announce@ietf.org>
Cc: IETF <ietf@ietf.org>


This is a friendly = reminder that the deadline for submitting proposals for "Birds of a = Feather=E2=80=9D (BOF) sessions at IETF 105 is in 4 weeks: June 7 at = 23:59 UTC. Instructions for submitting your proposal are available = at https://ietf.org/iesg/bof-procedures.html. Please also = read https://tools.ietf.org/html/rfc5434, Considerations = for Having a Successful Birds-of-a-Feather Session, if you are not = familiar with it.

If you are working on a BOF request but you=E2=80=99re not = quite ready to submit it, please tell the IESG now by sending an email = to iesg@ietf.org to get advance help with the = request. We have a number of ways of bringing new work into the = IETF and BOFs are just one of them, so please talk to the IESG or an = individual area director (https://ietf.org/iesg/members.html) = about your idea if you=E2=80=99re thinking about proposing a = BOF.

Thanks,
Alissa Cooper
IETF Chair
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_94853F3A-6FC1-4538-8DB7-1DEA645ED7EE-- --Apple-Mail=_9085D683-41C6-4BF8-8341-AD4E5D444142 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlz1SkIACgkQgFZKbJXz 1A319A//aifrLQ4u8HcCHAvZnieC6ycsTtWzCGgnaFKjkqcGGGljr5w/UwSse/Vb Wn1tdgmjllRq1wwom3NofHBQjZ7prVllwqyLb+mY+O+JsTm9hlmVWU8aaIii5Uaz itY00jsxpq3Jllc4A5tvAFijlTDEFYBiYztar4ZiOh1sCuox2wTJgbDZu12Kp5uS B7nGXVPWvvDILesaajPzaHMIyAfbh3265xfOaXAGR62W3ckCgbyLEaj/EJS79UVF d/UyOmT5cuzSzIIqBnh170b2e4Jm4k7fkWr6JpNtqnkcMtIkiaSBGX9oyBSaaaOZ L3obp77t2zsOB1j7ChNTU0ftiex1ptZZwKeewJJBKdQjYThy4A+/u8cZdiKX+asG vDhFXkR8Ci5Nue9sNcj+6kRUIqleZlh40n4Sos+OmXpg2UZsLvKCHJbhTmcw5IWn dPfJ95tyNkxd+hvk/uwNFmdGYlLcKB6uIDmJsRjR3FYO4ThYk1sPxCcYzFY/GuLw SaH6OvkVzsV7uFu/AoQQhEXPbRZujf++PzKZr0pOu0P+XXQESK+EoH8ZREqC6C1n NeePGCp4yQ2JInklvCwu2AKCUhP9gyTE1a6C1jTI7jLO4+1xl3tFLZqypkq07D4h 2gmIzMZuYLH+hFIMVPzn2tnoNFm58fEXP43QxjanhCqkmbUjw5g= =WmLM -----END PGP SIGNATURE----- --Apple-Mail=_9085D683-41C6-4BF8-8341-AD4E5D444142-- From nobody Mon Jun 3 09:27:52 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6681204D4 for ; Mon, 3 Jun 2019 09:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sg9GXN-6W_LV for ; Mon, 3 Jun 2019 09:27:49 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE361204B0 for ; Mon, 3 Jun 2019 09:27:49 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x53GQocV029357 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 3 Jun 2019 11:27:48 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1559579269; bh=wRHEbdHxG5yJLvbYyQwbH5KFMSwC7Kk+6ksM8tWz4Hc=; h=From:Subject:References:To:Date; b=fLAQOBU+K1gs1ZXy3mx7BfdTUjXgnFNUPx6LG8F58XVbKbhrNLRSeXqyDiGPj5nPx 6e+wsDPsCF4LHQt259iZH6BHn3lDqDvC8q9KR69/UX0Q6UD8yl7qE7PQP7owGM1hiO XVxYMvmpatqCeScjhtbGeILfpMw0hVN/GXFSvIBU= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_0F74F471-DFAA-4323-89A6-3C0FD758EB90"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <8DDA2ED7-3025-400E-B4CC-D07CDA690C52@nostrum.com> References: <155957149163.24918.17790183556088037133.idtracker@ietfa.amsl.com> To: DISPATCH Date: Mon, 3 Jun 2019 11:27:47 -0500 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [dispatch] Fwd: [Recentattendees] Early Bird Registration Ends Today! X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 16:27:51 -0000 --Apple-Mail=_0F74F471-DFAA-4323-89A6-3C0FD758EB90 Content-Type: multipart/alternative; boundary="Apple-Mail=_BBD74BE2-B503-40AE-BDD9-B0BADFF1C027" --Apple-Mail=_BBD74BE2-B503-40AE-BDD9-B0BADFF1C027 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just in case anyone missed seeing this reminder elsewhere: Thanks! Ben. > Begin forwarded message: >=20 > From: IETF Secretariat > Subject: [Recentattendees] Early Bird Registration Ends Today! > Date: June 3, 2019 at 9:18:11 AM CDT > To: "IETF Announcement List" > Cc: recentattendees@ietf.org, 105all@ietf.org, ietf@ietf.org > Reply-To: agenda@ietf.org >=20 > IETF 105 > Montreal, Quebec, Canada > July 20-26, 2019 > Hosted By: Comcast NBCUniversal >=20 > Early Bird Deadline >=20 > REMINDER: The early bird deadline for registration is today, = Monday, June 3rd. > Be sure to register and pay before the deadline passes! > Register online at: https://ietf.org/how/meetings/register/ >=20 > NOTE: If you have started the registration process but not = completed > payment, your registration record will be deleted at UTC 23:59 = on > Monday, June 3. After June 03 at UTC 23:59 you will be required = to > re-enter your data and the registration fee will be $875 USD = until > the next registration deadline on July 8, at which the > registration fee will become $1,000 USD. >=20 > If you have any questions or need assistance, please do not hesitate = to > contact: ietf-registrar@ietf.org >=20 > _______________________________________________ > Recentattendees mailing list > Recentattendees@ietf.org > https://www.ietf.org/mailman/listinfo/recentattendees --Apple-Mail=_BBD74BE2-B503-40AE-BDD9-B0BADFF1C027 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just = in case anyone missed seeing this reminder elsewhere:

Thanks!

Ben.

Begin = forwarded message:

From: = IETF Secretariat <ietf-secretariat@ietf.org>
Subject: = [Recentattendees] = Early Bird Registration Ends Today!
Date: = June 3, 2019 at 9:18:11 AM = CDT
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Cc: recentattendees@ietf.org, 105all@ietf.org, ietf@ietf.org
Reply-To: = agenda@ietf.org

IETF 105
Montreal, Quebec, Canada
July 20-26, 2019
Hosted By: Comcast = NBCUniversal

Early Bird Deadline

     REMINDER: The = early bird deadline for registration is today, Monday, June 3rd.
     Be sure to register and pay = before the deadline passes!
=      Register online at: https://ietf.org/how/meetings/register/

= NOTE: If you have started the registration process but not = completed
payment, your registration record = will be deleted at UTC 23:59 on
Monday, = June 3. After June 03 at UTC 23:59 you will be required to
= re-enter your data and the registration fee will be $875 USD = until
the next registration deadline on = July 8, at which the
registration fee will become = $1,000 USD.

If you have any questions or = need assistance, please do not hesitate to
contact: ietf-registrar@ietf.org

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

= --Apple-Mail=_BBD74BE2-B503-40AE-BDD9-B0BADFF1C027-- --Apple-Mail=_0F74F471-DFAA-4323-89A6-3C0FD758EB90 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlz1SoMACgkQgFZKbJXz 1A0S+hAAvGfBYWi9n1Z17Tzm4ZSW3su8CFckGtZwCu7mdp6XFyxhb3s7VEv1CI1J BOrg1fteG9168fJw2X2IrwH836oWVDHpxUxdfKl3gqB/Pgv9tIn/snLE6n6Ahk/c 7B70Cagk9wOoIPQHLOAdssUAIKPf2F5btMMe+EFNutPpXpVPO/5+np9ZGtQmzNNr 7NQmguJtKfKKrtt8v/gxNBS/cFsJb+0om2mawQLG70QZK+4byszSBhZ+1BQuaTq5 I7xgbeGRAJMJSd/RSmnRD0zMlP/AQgxyZx6Iwgxlv7VED0W8L7ZE+dHf1ByVDMh/ hZY+7+x+Tro9H/77IrSefJ10CACEYWuVUAvdIRSjNCvpQ/1DhfSrEcFkKUXRn7wt +5FcMlq5kRfPj8roeKhGkj33kJa3D2MRQQlN/rTYQsWhglsVxVPN1hvJRB+jSc9i KG0iGNYamONAjjd1MOjODuK1YNsvQ4rCAkiPHyP/Lg1Npd4sd6f1AdfNr21o7oTI XgNKjWZBbNM6wkIT8KSc1fI3Z4Y1jA5uLrOn1GEbqeiSxOLW/3XdDlG3/D2P9Vac AwWYkQYoi8kXFcomKUUJwb879/+a6157aoBqHlv+V/wWb9biTWJ9QMSEhSV/S7mk dO/n3n2LGrTTdOHedclnydlIUssiz0f7eiaw+96zrk5j/Upk5Ss= =aQVT -----END PGP SIGNATURE----- --Apple-Mail=_0F74F471-DFAA-4323-89A6-3C0FD758EB90-- From nobody Wed Jun 5 11:25:00 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616A41201B0 for ; Wed, 5 Jun 2019 11:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fYHDqW1kUm5 for ; Wed, 5 Jun 2019 11:24:56 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 705881200D5 for ; Wed, 5 Jun 2019 11:24:56 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id f9so5752391wre.12 for ; Wed, 05 Jun 2019 11:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=D5EcgQLxVVmSWPm6xoKvF5v0cWZugG6/eg5aIcsAEwY=; b=nAIjrbsVyF6AfrisDQaXHC9Ue3Z5VcNf0p2BWh2I1Tsy6Co6O0xrJaqKSM/YpUGnXw wqiMu/n3G0sHWh3KPyQRU7LMuuaAlYbKClD0JzZa8mNFPiCfMPht4k3w9vVMaonktoRa tKQDZh/DD6hYbrXD62E2uIoHYh2/z9JnbMl90IkuEYnSaharqrJOccBzTV6Lwicspba4 wG7mMgcLTK/HORLd0zgeeHmJ3iuvgLOeqr3jygJZSvWZy2+uxtyqh6b5zI/brnokths7 MY4m59SA79p8WbHm7m+3yZ2COFIpplJK0AdrWxW8CgUgYTb3V2QwR5Cm2kUBXaCB00Ax 1kXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=D5EcgQLxVVmSWPm6xoKvF5v0cWZugG6/eg5aIcsAEwY=; b=rS3InFcYpyuZAJVIbjWlOKpIv/sfpaXZq5A/ywELvL20rbHbtP0oleG4yiPq4QI9Pu EbaG3CwW2718Ls94Sj/L0EvnE+uSNxZJ8Nx7gcOSGUwrHBHST4anxU8OnMXlKWF+XrRH NVcnCKcmm42BZrEFOEr7DTNorlIoOSQ21Q85Nr7SWq/AoyBqiJj2PbjWvaLe84x8JJ7p CfzXjzUgkfpaACVyO8Rye4Z2iLpE3eNpyR9Vq4mp/JoBWq/2eHXcnZJ8vLCBlaisQowB Pv/a01aa395T7aC4BAHAkb4TA/5hs/o3bMYIC1o0utEmeoqWRwaysOMqkenON7kAw35/ XuAg== X-Gm-Message-State: APjAAAUYR7R96SBH3O0Lb4cQaFKhGHjxumlhg17I8wda5Dv5gOsZtHBn MKcpVPq/XUj7TAqK7ZFK6QE= X-Google-Smtp-Source: APXvYqzPfaZC2+RQckoPfT4eT6mWyA4uyYIpKujj5/+DWD2U5Iihk8kIMhbEEQeY4boq4a0e1ibKPQ== X-Received: by 2002:adf:90e7:: with SMTP id i94mr11546668wri.213.1559759094960; Wed, 05 Jun 2019 11:24:54 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id d18sm7624233wrn.26.2019.06.05.11.24.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jun 2019 11:24:53 -0700 (PDT) From: Anders Rundgren To: DISPATCH Message-ID: Date: Wed, 5 Jun 2019 20:24:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [dispatch] JCS - Abandoning the DISPATCH path X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 18:24:58 -0000 Due to the lack interest ("active disinterest") we have been advised to not pursue JCS through DISPATCH. Personally I will continue with JCS in contexts like Open Banking since it obvious (based on existing practice) that Base64Url-encoding of business messages will continue to be a hard sell.  The ability simply taking a hash of a JSON object is also a pretty useful feature not supported by any IETF standard. For the authors, Anders Rundgren Current draft: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06 On-line lab combining JWS and JCS: https://mobilepki.org/jws-jcs/home IETF-104 report: https://cyberphone.github.io/ietf-json-canon/ietf-104-report.html From nobody Wed Jun 5 12:00:19 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F944120236 for ; Wed, 5 Jun 2019 12:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0UkQfvj1PM9 for ; Wed, 5 Jun 2019 12:00:11 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 713251202BA for ; Wed, 5 Jun 2019 12:00:11 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id w34so12882940pga.12 for ; Wed, 05 Jun 2019 12:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VJeevYE3xtOxUDaFeMDI90alaYq9LoPIgAA4OEVpfd8=; b=sw2M9k7Q5pMNCNFzz3/4wR7r+AKNdXQkcxobpIOyGJTcx4DZa9uW/PS4j/T/HcWfvD oKClJ4ds6MFsW9P4HejYzaSzrBkM6CB4r48DJARwccdchCZFMWyR/H6T/rGQN4VquNcS aw1T4x8DcpW5mT0OoqbPpI9o4jofwM/pxqIWH4G40+x4JVC/N0pdaarn8PuVpSNlDxsR Afeu9JIALSO4+op5e4IKfG2nft7NmncwitN32SNAv19Xcc06nigQkjoyAhJUWnL1N5Ji CMPOGo64blmiXSfshXCnB7CweMvfY8HMGFa7bfzgL+jsnyj5xfkDlAvnfBerD7dFnV05 q4yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VJeevYE3xtOxUDaFeMDI90alaYq9LoPIgAA4OEVpfd8=; b=rZj0EHXH1fao+NJzGh2mvmNV/hFDXjJp+maHDh1RRpa5tZwr7aoaxwRcOqtwJBvH+r dc9+eP4kj8pN3hZxLYxXgMLwCcLk6YBihXilgcnCsBdGtFOsRS0HM86o6OqR8PuTMQWJ t8UozOxvlYqTHG9UuVoKjXV8GkKX3Dzzfp8mK8OFJAaCWjNMVNpEBEAdH5A8m/HP2YPw xsdeZ+bbdhkkXnMD9ShvYvcdekHHzU7wX7GHaHM1ijului8yqOKY3VJIsCdnS5QRF8VL dF71/AxwRJX5dgEWeFeMUCM9bYRhcCeZIG9rULAZi1YaVJrn95dnCOiKk1nMDDYjlyhY j8QQ== X-Gm-Message-State: APjAAAUX+LnsUAVsYBv8VY2Kp7I4NLKgFOqyrBBKDcFyjMMOK3tlxfx8 /BfvIeotcVTv5ZEM4XnADzNFhTtV X-Google-Smtp-Source: APXvYqzvAum+DNwp8Q6qqnijvSYwVVKd0IF/PPd49EWb0D4Eq5o3FVfCTjwAf4Sh5Rx2MLmndmRNyg== X-Received: by 2002:a17:90a:71cb:: with SMTP id m11mr44498058pjs.40.1559761210904; Wed, 05 Jun 2019 12:00:10 -0700 (PDT) Received: from ?IPv6:2605:a601:a990:4d00:800b:7567:7713:a69f? ([2605:a601:a990:4d00:800b:7567:7713:a69f]) by smtp.gmail.com with ESMTPSA id v126sm4283297pfb.81.2019.06.05.12.00.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jun 2019 12:00:10 -0700 (PDT) From: Bret Jordan Message-Id: <57502C4F-01A2-4E1A-96DB-1B718F9F0FA7@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FDDED852-4DD5-4D78-AB27-E87B65B56E3C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 5 Jun 2019 13:00:06 -0600 In-Reply-To: Cc: DISPATCH To: Anders Rundgren References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dispatch] JCS - Abandoning the DISPATCH path X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 19:00:18 -0000 --Apple-Mail=_FDDED852-4DD5-4D78-AB27-E87B65B56E3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is really sad and a loss for the IETF. I would like to know how = much interest needs to be given for an idea for it to be accepted and = worked on. Is it 5, 10, 20, 50, 100, ?? People? And how is consensus = achieved, meaning what percentage of people need to be against the work = to prevent it? =20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Jun 5, 2019, at 12:24 PM, Anders Rundgren = wrote: >=20 > Due to the lack interest ("active disinterest") we have been advised = to not pursue JCS through DISPATCH. >=20 > Personally I will continue with JCS in contexts like Open Banking = since it obvious (based on existing practice) that Base64Url-encoding of = business messages will continue to be a hard sell. The ability simply = taking a hash of a JSON object is also a pretty useful feature not = supported by any IETF standard. >=20 > For the authors, > Anders Rundgren >=20 > Current draft: = https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06= > On-line lab combining JWS and JCS: https://mobilepki.org/jws-jcs/home > IETF-104 report: = https://cyberphone.github.io/ietf-json-canon/ietf-104-report.html >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_FDDED852-4DD5-4D78-AB27-E87B65B56E3C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = is really sad and a loss for the IETF.  I would like to know how = much interest needs to be given for an idea for it to be accepted and = worked on.  Is it 5, 10, 20, 50, 100, ?? People?  And how is = consensus achieved, meaning what percentage of people need to be against = the work to prevent it?   


Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Jun 5, 2019, at 12:24 PM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

Due = to the lack interest ("active disinterest") we have been advised to not = pursue JCS through DISPATCH.

Personally I = will continue with JCS in contexts like Open Banking since it obvious = (based on existing practice) that Base64Url-encoding of business = messages will continue to be a hard sell.  The ability simply = taking a hash of a JSON object is also a pretty useful feature not = supported by any IETF standard.

For the = authors,
Anders Rundgren

Current draft: https://tools.ietf.org/html/draft-rundgren-json-canonicalizatio= n-scheme-06
On-line lab combining JWS and JCS: https://mobilepki.org/jws-jcs/home
IETF-104 = report: https://cyberphone.github.io/ietf-json-canon/ietf-104-report.ht= ml

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

= --Apple-Mail=_FDDED852-4DD5-4D78-AB27-E87B65B56E3C-- From nobody Fri Jun 7 04:07:17 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5822120247 for ; Fri, 7 Jun 2019 04:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FILL_THIS_FORM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=Pt6KkV6C; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Yo/jJK/E 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 khmT36Iw69WA for ; Fri, 7 Jun 2019 04:07:13 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC20712026E for ; Fri, 7 Jun 2019 04:06:59 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2103F5E9 for ; Fri, 7 Jun 2019 07:06:59 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Fri, 07 Jun 2019 07:06:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=Yd4qIjDMuYh9Z65DjygBrCu9Fjmwd5zpg5NwFfZ 00Tk=; b=Pt6KkV6C1ywpYUlcd3FxfzvPTy8rXilsaQZ9u+h4T9wODLU2g0guBIR jjXwtDLf95rOtWtxtt5SuJeW5OSNBvpbcrVtb54VWcSlpMiZyNrACBr60yuYBHFI Xra2LUUgVYj+pp4IEaVMd//X+PjusWjyn2QBMga+Kxn7cLjmZzZwwyE2WJs6ADT2 4tWfbm0BJkLJDXTefY0Emb45qFumKn1QH3z3kDsiRRfsE4mWBTnyvXkkVEsVuC2z 5fD2PrRL2K+a0gnjvhmhQPzX36HGan0BBku8G8u+OoSQzYwla1YckNkg7HwJf1x9 MUd338sd7POONOqvZvaQKOnsiZkfkLw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=Yd4qIjDMuYh9Z65DjygBrCu9Fjmwd 5zpg5NwFfZ00Tk=; b=Yo/jJK/EH3BmNymN/esMzpaH1hjU1JBgqrBDnaJ+BmYmN Vp6uJJyRI0xZrgzpuL/8TkwJh5pOLkwiSDy6cZ0keA9h+A1JFTM+VNEb/W5xWEES 1siMjImKlz0vGajSDP+vII2r5g8+++JfRmMVdK7IDlz8ESZQ9X7VOKXga9a1EdCS HTgyq5mM6Oqky2XtUtMkgXcMgGWt0EtuRqf7g3ejjiZJnQjFwFkKfDPuYZdyThrx +VzL8lO7HSTBd15lAKQoChJvlzlpTRJSWY63OdDdtpL9y9R0D7rKr1YIHmTvuzdy gMkImZweMeD094sSrWCzC7dyBh1EaMAb+wEijefxQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudegiedgfeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthhosehf rghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenuc frrghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrghilhhtvggrmhdrtgho mhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 296DD180256; Fri, 7 Jun 2019 07:06:58 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-663-gf46ad30-fmstable-20190607v1 Mime-Version: 1.0 Message-Id: <96bef250-7821-4a85-85f5-f9df8128e96a@www.fastmail.com> Date: Fri, 07 Jun 2019 12:06:57 +0100 From: "Robert Stepanek" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=aa10710a65b042c8a677bfcc49a31b12 Archived-At: Subject: [dispatch] JSCalendar: Updated to draft version 01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 11:07:16 -0000 --aa10710a65b042c8a677bfcc49a31b12 Content-Type: text/plain Hi all, I've submitted draft version 01 of draft-stepanek-jscontact: https://tools.ietf.org/html/draft-stepanek-jscontact This version is includes some, but not yet all of the feedback of individual reviewers as well as the CalConnect XLV meeting this week. Changes: - Added a new property for full names. - Changed the single-string name component fields to arrays. - Added a kind property, similar to VCARD KIND. - Added a ISO-3166-1 country code property to Address. - Added a full address property to Address. - Added preferredContactMethod property. - Added geo URI and time zone properties to Address. - Added a role property. There following feedback needs further consideration and I'm happy about any input: Names: - Learn more about the findings of ISO/TC 37/SC4 on naming schemes, and probably reuse it for JSContact. - Current vendors such as Google and Apple already make use of X-PHONETIC-{FIRST,LAST}-NAME properties for phonetic names. It's similar to https://tools.ietf.org/html/draft-fukuda-vcarddav-phonetic-transcription-03 Contact: - Support more than one company, and consider renaming it to affiliations or organizations. - Allow for a similar property such as SORT-AS in VCARD4. - Add categories and keywords properties, similar to JSCalendar. - Allow for hierarchies? (group includes group? contact includes contact?) ContactInformation: - Add a unique id to each ContactInformation, so that sync conflicts can be better resolved. (might want to change the contact information lists to JMAP-style maps, where the id is the map key). ContactGroup: - List contact objects in a group, rather than their uids. If only uid is of interest, the embedded contact could just define that property. - Allow to override properties for a contact within a group. E.g. a contact might override its "role" for a group that defines a project. Could use JSCalendar PatchObject in a property called contactOverrides. Address: - consider renaming it to Location - Learn more about ISO19160-6 for international address profiles. Other: - Localization most probably will be only required for names and address. - Rename either the RFC or the Contact object to JSCard for disambiguation? Cheers, Robert --aa10710a65b042c8a677bfcc49a31b12 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

There following feedback needs further consideration and I'm happ= y about
any input:

Names:
=
- Learn more about the findings of ISO/TC 37/SC4 on naming sc= hemes, and
  probably reuse it for JSContact.
- Current vendors such as Google and Apple already make use of
  X-PHONETIC-{FIRST,LAST}-NAME properties for phonetic = names.
  It's similar to https://tool= s.ietf.org/html/draft-fukuda-vcarddav-phonetic-transcription-03
<= /div>

Contact:
- Support more than one = company, and consider renaming it to affiliations or
 = ; organizations.
- Allow for a similar property such as SO= RT-AS in VCARD4.
- Add categories and keywords properties,= similar to JSCalendar.
- Allow for hierarchies? (group in= cludes group? contact includes contact?)

Co= ntactInformation:
- Add a unique id to each ContactInforma= tion, so that sync conflicts can be
  better resolved= . (might want to change the contact information lists to
&= nbsp; JMAP-style maps, where the id is the map key).

<= /div>
ContactGroup:
- List contact objects in a group,= rather than their uids. If only uid is of
  interest= , the embedded contact could just define that property.
- = Allow to override properties for a contact within a group. E.g. a contac= t
  might override its "role" for a group that define= s a project. Could use
  JSCalendar PatchObject in a = property called contactOverrides.

Address:<= br>
- consider renaming it to Location
- Learn m= ore about ISO19160-6 for international address
  prof= iles.

Other:
- Localization m= ost probably will be only required for names and address.
= - Rename either the RFC or the Contact object to JSCard for disambiguati= on?

Cheers,
Robert
<= /body> --aa10710a65b042c8a677bfcc49a31b12-- From nobody Fri Jun 7 11:09:23 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A3E12022E for ; Fri, 7 Jun 2019 11:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyiSY7dqbQCP for ; Fri, 7 Jun 2019 11:09:01 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 895FA12023F for ; Fri, 7 Jun 2019 11:09:00 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id y198so2315327lfa.1 for ; Fri, 07 Jun 2019 11:09:00 -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=qnLUVmFJ35hy4TleI/y/sDIccd/KH2kUkMRiRe2OQYY=; b=sq/JVeOTMHQISlpHdeuH6V/Pu2DAINlSLxhypoLPvvgXslbjOeU5HdowoWaTA04MVz 6zGYshzk6xYv6StlmVtxUNNHQ7qw7OvAog7C4y4rMdR9dQHpc0FuIGeqyEfLtSvWjtZg Yy9Fybj95LwaVwOFOxqItp3bb7vUaFc2vZ4lOlDHP5iuz/5nvopcdhkW3QZQsrMV/XbW pn76TvUFLQ2VO3inc/2VxlT2/UyAQxfEKh7ccxQpRT2i+H3qGsxlA7bhYGBRZvVMBgOp dcBZ+gBzF9yblng4241EQWofYPwfG3Qp1PypGhhYwBMkD8nFBoHq54+Li9XFHkDvUn37 od5Q== 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=qnLUVmFJ35hy4TleI/y/sDIccd/KH2kUkMRiRe2OQYY=; b=UoLZkDXcONvzZTubLAHVtFgst5eu2c5h/FXCn2l7bealrCWym/xnLBbxwnhVBKv48b hRWfM4eLVIqFzek8d5EjlPCnw2YVUx2cscTEL7dDkE7E1jFpr1z4dB1bzM0x3drE238i uBIpDMBXRZsQSID1d0HHcIV0sKayc45wxkXCgwSffaHaISCs0h13ddH8wMloQm442EOc WXI1OcC9kOrLtNfkIUz2tx2DQdyAJN2fWqzlfNd067+27LTmTorL14+s0dyGivH33LeN sZwCKuO391cfHKS82CI5XO+ju+4haH900rCdUa8jFNnG2UwpeSJFFnZ38+hqW5SsUySI 6zCg== X-Gm-Message-State: APjAAAWHOA4RgE7RupihntkIt+WOAifMYT9Af8g9qkye2yrc/Dn/W+5E 7k1w5Us8y6xdO0vgbZHoW6Y2P+YFWU8jYIzuzV8= X-Google-Smtp-Source: APXvYqzzcBt5l7HVf9VKlA7gF3yY2PXA038k6eM4eUqxGdt28g5NTd9mR4f+EWRdLLcgTFFlX/+cODjBA22KPYLNjpo= X-Received: by 2002:ac2:495e:: with SMTP id o30mr27815762lfi.140.1559930938826; Fri, 07 Jun 2019 11:08:58 -0700 (PDT) MIME-Version: 1.0 References: <57502C4F-01A2-4E1A-96DB-1B718F9F0FA7@gmail.com> In-Reply-To: <57502C4F-01A2-4E1A-96DB-1B718F9F0FA7@gmail.com> From: Mary Barnes Date: Fri, 7 Jun 2019 13:08:46 -0500 Message-ID: To: Bret Jordan Cc: Anders Rundgren , DISPATCH Content-Type: multipart/alternative; boundary="0000000000007ba8e5058abfb90f" Archived-At: Subject: Re: [dispatch] JCS - Abandoning the DISPATCH path X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 18:09:17 -0000 --0000000000007ba8e5058abfb90f Content-Type: text/plain; charset="UTF-8" Hi Bret, In IETF, we don't do counts per se. We have the notion of rough consensus. The method that WG chairs use has some very basic guidelines, but there is a lot that's left to the discretion of the chairs. Here's a document that describes some of this: https://tools.ietf.org/html/rfc7282 I think a key point from that document is around the notion that consensus can be gained if there objections, if all those can be addressed in some way. With this topic, that does not seem possible given the nature of the meeting and mailing list discussions. As a chair, what I took away from the discussions were very strong disagreements about the value of this work. There were indeed a few supporters. But, there did not appear to be broad interest such that this is something the IETF should take on. And, If we were to decide to progress this work in IETF, it is very, very likely that those that disagree with it right now, would continue to raise the same concerns (per the point about objections being addressed if you want consensus) and ultimately it's the IESG that judges whether a WG has consensus. Our AD, Barry Leiba has already stated his position on this. And, you do have an alternative publication path via the ISE. Regards, Mary DISPATCH WG co-chair On Wed, Jun 5, 2019 at 2:01 PM Bret Jordan wrote: > This is really sad and a loss for the IETF. I would like to know how much > interest needs to be given for an idea for it to be accepted and worked > on. Is it 5, 10, 20, 50, 100, ?? People? And how is consensus achieved, > meaning what percentage of people need to be against the work to prevent > it? > > > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that > can not be unscrambled is an egg." > > On Jun 5, 2019, at 12:24 PM, Anders Rundgren < > anders.rundgren.net@gmail.com> wrote: > > Due to the lack interest ("active disinterest") we have been advised to > not pursue JCS through DISPATCH. > > Personally I will continue with JCS in contexts like Open Banking since it > obvious (based on existing practice) that Base64Url-encoding of business > messages will continue to be a hard sell. The ability simply taking a hash > of a JSON object is also a pretty useful feature not supported by any IETF > standard. > > For the authors, > Anders Rundgren > > Current draft: > https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06 > On-line lab combining JWS and JCS: https://mobilepki.org/jws-jcs/home > IETF-104 report: > https://cyberphone.github.io/ietf-json-canon/ietf-104-report.html > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0000000000007ba8e5058abfb90f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bret,

In IETF, we d= on't do counts per se. We have the notion of rough consensus.=C2=A0 The= method that WG chairs use has some very basic guidelines, but there is a l= ot that's left to the discretion of the chairs.=C2=A0 =C2=A0Here's = a document that describes some of this:=C2=A0=C2=A0https://tools.ietf.org/html/rfc7282=C2=A0 I thi= nk a key point from that document is around the notion that consensus can b= e gained if there objections, if all those can be addressed in some way.=C2= =A0 With this topic, that does not seem possible given the nature of the me= eting and mailing list discussions.=C2=A0

As a cha= ir, what I took away from the discussions were very strong disagreements ab= out the value of this work.=C2=A0 There were indeed a few supporters. But, = there did not appear to be broad interest such that this is something the I= ETF should take on.=C2=A0 =C2=A0And, If we were to decide to progress this = work in IETF, it is very, very likely that those that disagree with it righ= t now, would continue to raise the same concerns (per the point about objec= tions being addressed if you want consensus) and ultimately it's the IE= SG that judges whether a WG has consensus.=C2=A0 Our AD, Barry Leiba has al= ready stated his position on this.=C2=A0 And, you do have an alternative pu= blication path via the ISE.=C2=A0=C2=A0

Regards,
Mary=C2=A0
DISPATCH WG co-chair


On W= ed, Jun 5, 2019 at 2:01 PM Bret Jordan <jordan.ietf@gmail.com> wrote:
Thi= s is really sad and a loss for the IETF.=C2=A0 I would like to know how muc= h interest needs to be given for an idea for it to be accepted and worked o= n.=C2=A0 Is it 5, 10, 20, 50, 100, ?? People?=C2=A0 And how is consensus ac= hieved, meaning what percentage of people need to be against the work to pr= event it? =C2=A0=C2=A0


Thanks,
Bret
= PGP Fingerprint:=C2=A063B4 FC53 680A 6B7D 1447 =C2=A0F2C0 74F8 ACAE 7415 00= 50
&qu= ot;Without cryptography vihv vivc ce xhrnrw, however, the only thing that c= an not be unscrambled is an egg."

On Jun 5, 2019, at 12:24 PM, Anders= Rundgren <anders.rundgren.net@gmail.com> wrote:

Due to the lack = interest ("active disinterest") we have been advised to not pursu= e JCS through DISPATCH.

Personally I will continue with JCS in conte= xts like Open Banking since it obvious (based on existing practice) that Ba= se64Url-encoding of business messages will continue to be a hard sell.=C2= =A0 The ability simply taking a hash of a JSON object is also a pretty usef= ul feature not supported by any IETF standard.

For the authors,
A= nders Rundgren

Current draft: https://= tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06
O= n-line lab combining JWS and JCS: https://mobilepki.org/jws-jcs/home
IETF-104 = report: https://cyberphone.github.io/ietf-json-canon/i= etf-104-report.html

____________________________________________= ___
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinf= o/dispatch

__________= _____________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--0000000000007ba8e5058abfb90f-- From nobody Sat Jun 8 00:28:50 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E494C120108 for ; Sat, 8 Jun 2019 00:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkeyQhmLiaPd for ; Sat, 8 Jun 2019 00:28:46 -0700 (PDT) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 E966F1200E9 for ; Sat, 8 Jun 2019 00:28:45 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id n4so4182860wrw.13 for ; Sat, 08 Jun 2019 00:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=omeyld6IhoXicRTEnUoWyRpvMCpWqPPR8qc6XDPCgVM=; b=ODUIeH8s7PXfEay0hU1wlPyzzMmwEKvVb83Hd3Be2OFq58cyHNudtC5+DVuDNCQkrR Kdnfjh9N6scaURdf8nsUsQr66oPCPr5hPBVkGtRA+/Z7+/HpDvoNOwusGgM9zY3I9dc5 PQKdi4Wen7/fMlSODrvUc1t58g312+C62DHagvE2KA/hxpTyRRcseYN+VYZcCjX8Ynbl Ui3I04sEmEe7kKkNsxkgpcA7z0hkh/v6IxyVWrojUrtTcbpaBe+O+Ej/A2+uR/bbfa5z s1g0n/s/57RVo+CBMkmcRoK3o+RxpEeT3uOB8o1w83AgmqIBxi2ejo2uNmdAHQx692KM YySA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=omeyld6IhoXicRTEnUoWyRpvMCpWqPPR8qc6XDPCgVM=; b=sgt5iS4of2k2MeiMX3VmqRB06PPdx6f1cdXnKmh+Gbnv57SEpUGXQanT3aS/4sNa6T iWFyB5IUeg0dCd7cV+SsWmweGXUDnqKq5s5uL2K3CnjumjFmQ5F2ffvJoGaOjIre4ioh 89Cpe5PGw5SM0rigR48/3ibCVu5BZHIRuc2UGRizousdxZDhKPlLBJYtKpqQq331i7Nq 7F9p++nLkYAwDVWcZPA8aKv2M6146X+AEvVcHqCsqKq8/WJKNRYrP66h0JjSYUd1/RkO yTT7jJDyRiGC4M64tHhs0ejZSAUpalTYnRv6voi5haCfln16Mc8W7yw2mXLLtEGpMZVN ZJrA== X-Gm-Message-State: APjAAAVYgeIaTDTvrIH5nolsjyl2CtJjQ3tzWrnalnYHDj1r0yNcSaWu u1pOuiq/2k/TPhiWPezVaEw= X-Google-Smtp-Source: APXvYqyZ7F7Bcddaa7w1OEld40BO/2Hh5rJsG/Pumehw6UgKg0fdYWeNzcm7DJjUxoWYT2Qf3PXjWg== X-Received: by 2002:adf:efcb:: with SMTP id i11mr37953178wrp.188.1559978924405; Sat, 08 Jun 2019 00:28:44 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id 11sm4324131wmd.23.2019.06.08.00.28.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jun 2019 00:28:43 -0700 (PDT) From: Anders Rundgren To: Mary Barnes Cc: Michael Jones , DISPATCH , Anders Rundgren References: <57502C4F-01A2-4E1A-96DB-1B718F9F0FA7@gmail.com> Message-ID: <525fc19f-79d1-bf47-e6c4-e7b292e3b276@gmail.com> Date: Sat, 8 Jun 2019 09:28:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] JCS - Abandoning the DISPATCH path X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2019 07:28:48 -0000 Hi Mary, We are apparently forced taking another path although there are no documented technical issues (except for the constraints declared in the draft) and the intended use cases are anything but marginal. Possibly my assertion that one of the most high-profile IT-projects ever (Open Banking), without exception rejected the "right" solution made a bunch of well-known IETF profiles step out of their engineering role and rather turn to politics. In politics there is hardly ever consensus. BTW, VmWare have patented the core idea: https://patentimages.storage.googleapis.com/68/be/70/582930ff11703d/US20150341176A1.pdf However, in this particular case the critics' references to XML are indeed applicable; namely as "prior art" indicators. Other comparisons with XML is mostly unverifiable "noise" since JCS [deliberately] is much more limited. There must also be major misunderstandings how JCS actually works. Microsoft's Mike Jones co-authored a precursor to JCS https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01 but rejected JCS although the change only involved a trivial sorting mechanism. The sorting suddenly made it possible creating compatible implementations for just about any platform with ease while the original design would have forced "a total rewrite of everything". This revision as well as well as other fundamental parts of JCS were initially proposed by other IETFers. Regards, Anders On 2019-06-07 20:08, Mary Barnes wrote: > Hi Bret, > > In IETF, we don't do counts per se. We have the notion of rough consensus.  The method that WG chairs use has some very basic guidelines, but there is a lot that's left to the discretion of the chairs.   Here's a document that describes some of this: https://tools.ietf.org/html/rfc7282  I think a key point from that document is around the notion that consensus can be gained if there objections, if all those can be addressed in some way.  With this topic, that does not seem possible given the nature of the meeting and mailing list discussions. > > As a chair, what I took away from the discussions were very strong disagreements about the value of this work.  There were indeed a few supporters. But, there did not appear to be broad interest such that this is something the IETF should take on.   And, If we were to decide to progress this work in IETF, it is very, very likely that those that disagree with it right now, would continue to raise the same concerns (per the point about objections being addressed if you want consensus) and ultimately it's the IESG that judges whether a WG has consensus.  Our AD, Barry Leiba has already stated his position on this.  And, you do have an alternative publication path via the ISE. > > Regards, > Mary > DISPATCH WG co-chair > > > On Wed, Jun 5, 2019 at 2:01 PM Bret Jordan > wrote: > > This is really sad and a loss for the IETF.  I would like to know how much interest needs to be given for an idea for it to be accepted and worked on.  Is it 5, 10, 20, 50, 100, ?? People?  And how is consensus achieved, meaning what percentage of people need to be against the work to prevent it? > > > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." > >> On Jun 5, 2019, at 12:24 PM, Anders Rundgren > wrote: >> >> Due to the lack interest ("active disinterest") we have been advised to not pursue JCS through DISPATCH. >> >> Personally I will continue with JCS in contexts like Open Banking since it obvious (based on existing practice) that Base64Url-encoding of business messages will continue to be a hard sell.  The ability simply taking a hash of a JSON object is also a pretty useful feature not supported by any IETF standard. >> >> For the authors, >> Anders Rundgren >> >> Current draft: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06 >> On-line lab combining JWS and JCS: https://mobilepki.org/jws-jcs/home >> IETF-104 report: https://cyberphone.github.io/ietf-json-canon/ietf-104-report.html >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Wed Jun 12 07:36:52 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864D21200B3; Wed, 12 Jun 2019 07:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iB31CMyebLT; Wed, 12 Jun 2019 07:36:47 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 82AF0120123; Wed, 12 Jun 2019 07:36:35 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id p24so12315139lfo.6; Wed, 12 Jun 2019 07:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=kco3H55qhQq+8/WzjragoVYQm1HtuwfsyxhIs8swn8w=; b=ten/79R6hEdkX34YQ/rEjCn9Acpx+X9lPBwqTwvn9Vu6i7bj/AqIufVvcpduBs/874 i5W2mDiQIygcowKPrFhtt4eaPR4Y5C8Z/F7gfdutepmOuGKIKZbxup8FEV07dblTPAIS sHWBrN7lWB/jPxGJ73snX2TJdOgwlBOKaGM4qAX+4dwUlE5tQAbaq3EjQf9E5ez3MDD9 /x7bAznJZtIKeIxgDDdw5joFgymhqidOHDroxVPlxJQ8dgqmBhfzhKqsLpbhQ/QBsQn7 SI7mCLe3LagZi0V/cPXEKT+Q2y7OkCyGbdhivgKZy9xawrDaqCPPfIdtmm/BbnP1fktl HHpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=kco3H55qhQq+8/WzjragoVYQm1HtuwfsyxhIs8swn8w=; b=r2ptt3ayPcu/Exqgc2vIxroSMDdDspL7kTp+mAiO7+bCTmjAYkIOYvtuAAbhXs5tL2 L941I7Q0PA4kurhasxgNARq4eX9EetZ/YtJzGqhbPO621B873u3kLUotRsFujymK2a/j dawpRYxVqiCR19H7Zs3Khc4cPvFbhmpWYqTMl/VLjeywCBUhBbyU2CnZBGGuJd23lkCU vGjj17COMZWF/rYlGht2qp0+y9vWo6CqZXNhp4Sjos/sIdNGyjKuJHX8EXlHXcFDNt/w gwlHHc9QqWLlxOKcS50apWEilRiPdkSZ4nKzDXF9rwPdtO9GUGGO1+sW7OAn4pu6m4NY 9j3g== X-Gm-Message-State: APjAAAXwQB6bR4nrnJHFdHC+G6uAL5OkGFJEVacLFpiK58r+GSizehx0 5k1zsiezJ9+wm/H+OO6FShzzVidR7aIg/jDdcHe1eEwu X-Google-Smtp-Source: APXvYqxOMI5IV4M5KpfbQB2E/Fhf30W6v48yNPDjCnDMVFFIqXYKrXLVsw2qoWDwJ17dOvo5aFnon3gB+pBtBYQnW/I= X-Received: by 2002:ac2:4904:: with SMTP id n4mr83701lfi.53.1560350193503; Wed, 12 Jun 2019 07:36:33 -0700 (PDT) MIME-Version: 1.0 From: Mary Barnes Date: Wed, 12 Jun 2019 09:36:22 -0500 Message-ID: To: draft-ietf-dispatch-javascript-mjs@ietf.org, DISPATCH Content-Type: multipart/alternative; boundary="000000000000025139058b2157f2" Archived-At: Subject: [dispatch] Shepherd review of draft-ietf-dispatch-javascript-mjs X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 14:36:51 -0000 --000000000000025139058b2157f2 Content-Type: text/plain; charset="UTF-8" I have reviewed the document in anticipation of forwarding to IESG for publication. There is still one outstanding issue and once that's resolved I will ask the AD to request publication. https://mailarchive.ietf.org/arch/msg/dispatch/bHeezFbph08KIfXGvghHbqKWe14 I have just two minor comments with regards to the "Note to Readers" section in the front of the document, and the URI section. Those sections reference a github repository for the document. Since that repository isn't necessarily stable and not associated with the IETF, I would suggest to remove those sections OR add a "Note to the RFC editor" to remove those sections prior to publication. Regards, Mary --000000000000025139058b2157f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed the document in anticipation of forwa= rding to IESG for publication.=C2=A0 There is still one outstanding issue a= nd once that's resolved I will ask the AD to request publication.
=

https://mailarchive.ietf.org/arch/msg/dispatch/b= HeezFbph08KIfXGvghHbqKWe14

I have just two minor= comments with regards to the "Note to Readers" section in the fr= ont of the document, and the URI section.=C2=A0 Those sections reference a = github repository for the document.=C2=A0 Since that repository isn't n= ecessarily stable and not associated with the IETF, I would suggest to remo= ve those sections OR add a "Note to the RFC editor" to remove tho= se sections prior to publication.=C2=A0=C2=A0

Rega= rds,
Mary


--000000000000025139058b2157f2-- From nobody Mon Jun 17 06:35:58 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5125712013A for ; Mon, 17 Jun 2019 06:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id al7BmyTQCsbe for ; Mon, 17 Jun 2019 06:35:53 -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 5B02B120114 for ; Mon, 17 Jun 2019 06:35:52 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id j29so6507195lfk.10 for ; Mon, 17 Jun 2019 06:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4Ekv5qFlUAn2KAyv+zY8OtufRzVlYgAuCKH3Nsdlt+E=; b=vBOo0KqIuSiobLL0PWreAhcouKyXBJ6tdi7z0v5HI76PwJPOEjCwhi67zBu+3D//Pj 4rRARumRVxaxqOTMwX7UHz9vsYPqWLG1Z+Q69bz4gV8iv6WuRxmV+SQm871JaW6Cd/7d DuJZAzDNSjO9BBR0tmiyRUgo+N1Xr06mLfJEO7ZbCyLgUBhidP5L1mZMk5xODSjxE2OP 1sNB3SAznydjiDsJyVxbQGMRYi4J6YiAw50b9omtufqA889Mo/YnEVaLqeS3+rxTxK1I EnQDIWntIsj7yRADEmMn37IBclM1FCqCWVhGQwuB9O1LLKox8B5uFY586vmUjpZniU5i D3gw== 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=4Ekv5qFlUAn2KAyv+zY8OtufRzVlYgAuCKH3Nsdlt+E=; b=Mg+kLrzetbKcEK6MQpBaYD0bnAKphTZDFrXDdPbYQ93nckmWZVD/O1tQPbVG6iz8mF aBTQ2rqr3rMygCHBuYAWONTWVuJADUKLd9L4DIwRTQcZHDkdzsTpIOf4WGg22fZ+oor3 cmpAZIloDHlAU9U4gKTBAQU0jp98gOTH7m9RGVJ4wANlLt4BFaeiQemc4QKK4qZSJMYw lpe9d69WL0IH0Dogv0Q0b7iWrtUOtLvzc70KW95J/Loo7xEqF/cqpM0GoBbCR4Z61YWW So8i+rAEONVaugRlxNIzcdr9OGMAqwHZDaVokI4G2sEPS+s3od3sslZAlOMvfsnMbNfu hNJA== X-Gm-Message-State: APjAAAU94v8JhORsSp7+XnsJ1bxkmuwMnVMU14nxOrAuabGDeq4alXHq qtlUgk+6yIqUsTS7wRd+F/Nd4TSjrZXtsXuJBSpkRa0YSSeJjA== X-Google-Smtp-Source: APXvYqxmGBmOYXr0aKrP1cvren3CqOp9LHx7vhPDM4QfjMrYlTU8Ndrx79jh/54S4aLfDs89MBbY2kpp4gSW+vkqN4Y= X-Received: by 2002:ac2:446b:: with SMTP id y11mr50345363lfl.158.1560778549596; Mon, 17 Jun 2019 06:35:49 -0700 (PDT) MIME-Version: 1.0 From: Victor Vasiliev Date: Mon, 17 Jun 2019 09:35:37 -0400 Message-ID: To: dispatch@ietf.org Content-Type: multipart/alternative; boundary="00000000000005fb49058b851302" Archived-At: Subject: [dispatch] Dispatching WebTransport X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 13:35:56 -0000 --00000000000005fb49058b851302 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello friendly IETF dispatchers, I am writing about new work I want to bring to IETF. The proposal is called WebTransport. It=E2=80=99s a combination of a Web API currently und= er development in W3C WICG [0], a protocol framework and some protocols that fit into that framework. Combined, they would allow web applications to establish WebSocket-like connections that instead of ordered reliable messages use multiple streams and datagrams (datagrams are unreliable and streams do not have head-of-line blocking). This is highly useful for real-time and other latency sensitive applications. # Background Historically, the only networking operations available to the Web applications were sending HTTP requests and receiving HTTP responses. That model does not fit all applications well, so over time, more mechanisms were added. The two most relevant here are WebSockets (RFC 6455) and RTC Data Channels (draft-ietf-rtcweb-data-channel). WebSockets are a way for Web applications to do bidirectional communication over a TCP connection; they work great if TCP fits your transport needs, but perform poorly if your application is latency sensitive and would, in non-Web context, use a UDP-based protocol. There are many different kinds of applications like that, but I would like to highlight two major categories which I to some extent surveyed when coming up with this proposal: 1. Custom client-server chat/multimedia protocols (faster-than-DASH video streaming, game streaming, etc). Those are usually developed by teams with a good amount of resources, and they are interested in tailor= ing the setup for their use case. 2. Game developers. Online games are commonly real-time in nature and benefit dramatically from ability to give up on transmitting old information. They usually use some in-house UDP-based protocol, and oft= en need to run on unusual platforms. WebRTC Data Channels are a mechanism that provides a WebSocket-like interface with unreliable delivery features. On the wire, it=E2=80=99s SCTP-over-DTLS, established using ICE and SDP. In theory, this provides users with enough functionality to build anything they need, since SCTP messages can be unreliable and unordered. In practice, while RtcDataChannel is fairly straightforward to use for browser-to-browser peer-to-peer communication, it has seen much lower adoption than WebSockets in the client-server scenario, even considering the fact that its use cases is naturally more niche. The main reason for this is the incredible complexity of the WebRTC stack. WebSockets are a fairly straightforward overlay on top of TCP and TLS; there is a wide variety of implementations out there, and it's fairly easy to write a new one (I wrote on myself in less than 1,000 lines of C++). With data channels, however, once there is no browser to abstract all of the complexity away, the web developers are required to understand and implement (or at least integrate) SDP, ICE, STUN, DTLS and userspace SCTP. While a lot of those have simplifications for this use case (ICE Lite) and some protocols listed have a variety of implementations widely available (DTLS), the entire system still requires going through hundreds of pages of RFCs in order to understand it well enough to implement. This complexity barrier has precluded Data Channel adoption by communities of smaller developers who don=E2=80=99t have resources to implement them, notably game developers (see [1] and [2] for some discussion). Even among the people who got past the complexity barrier, the feedback I heard almost universally is that WebRTC Data Channels are hard to work with. From the feedback I gathered, the main problem is usually around the transport protocol itself. Userspace SCTP is essentially a monoculture: virtually all implementations use libusrsctp, a 80,000-line adaptation of FreeBSD SCTP implementation. This lack of tool choice is fairly painful since latency-sensitive real-time applications often require quite a bit of tuning on the transport side to get the best performance (custom congestion control, etc). In addition, the limitations on the message size stemming from both the API itself and the lack of widespread support for message interleaving (RFC 8260) means that the developers have to roll their own framing on top of SCTP messages if they want to avoid head-of-line-blocking (this is particularly bad because the framing overhead in data channels is already large as-is). In summary, we have a system that technically provides what everyone wants, but that nobody is happy with, and that is not usable by all but the most well-resourced users. # Proposal Our initial idea for fixing this was to take QUIC and do what WebSocket did to TCP: add security features that would make it safe to expose on the Web (by adding origin checks, etc), but otherwise expose it as-is. This would get us out of libusrsctp monoculture (QUIC is not yet finished, but it already has a fairly diverse implementation ecosystem, see [3]), and remove all P2P-related complexity involving SDP and ICE. The original proposal for that was called QuicTransport; we showed it to various people, and the feedback we got is that (1) the API should not be tied to a particular transport (since we already switched once from SCTP to QUIC, tying it to QUIC specificially would not be wise), and (2) it shouldn=E2=80= =99t fail hard when QUIC is unavailable. As a result of that feedback, we abstracted it into a general-purpose framework called WebTransport. The overview draft, https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 describes the framework itself, mainly the requirements the transport protocols have to satisfy to be usable on the web through the API. Within this framework, we propose the following protocols: - QuicTransport -- a simple WebSocket-like adaptation of QUIC, described in https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 - Http3Transport -- a mechanism that allows creating custom non-HTTP streams within an HTTP/3 session, described in https://tools.ietf.org/html/draft-vvv-webtransport-http3-00. This is sort of a version of RFC 8441 for QuicTransport. - FallbackTransport -- a TCP-based transport with multiplexed streams that can be used when QUIC is not available (e.g. on network that requir= e CONNECT proxy). We don=E2=80=99t have a draft specifically for this, an= d there are at least two approaches we could take here: either reusing HTTP/2 as a transport (i.e. just use draft-kinnear-httpbis-http2-transport), or building a protocol with QUIC-like semantics on top of WebSockest. The earlier is a more straightforward way; the latter has the advantage of being fully polyfillable in JavaScript. # Discussion At this point, I am fairly certain that there is a problem here that needs to be addressed. I am formally requesting ART area to take this problem on= . I believe the drafts above would be a good starting point for discussion. The design that they describe went through several iterations based on the feedback I got when I discussed this work within a more narrow audience (mostly people in QUIC working group), so we=E2=80=99re hopefully at least = looking in the right direction here. I am requesting feedback on this proposal, both on the overall plan and the specifics described in the drafts. I hope to discuss this in depth in Montreal, both at dispatch and (in more depth) at a side-meeting. Thanks, Victor. [0] https://github.com/WICG/web-transport [1] https://discourse.wicg.io/t/webtransport-proposal/3508/9 [2] https://news.ycombinator.com/item?id=3D13266692 [3] https://github.com/quicwg/base-drafts/wiki/Implementations --00000000000005fb49058b851302 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello friendly IETF dispatchers,

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

# Background

Historica= lly, the only networking operations available to the Web applications were = sending HTTP requests and receiving HTTP responses.=C2=A0 That model does n= ot fit all applications well, so over time, more mechanisms were added.=C2= =A0 The two most relevant here are WebSockets (RFC 6455) and RTC Data Chann= els (draft-ietf-rtcweb-data-channel).=C2=A0 WebSockets are a way for Web ap= plications to do bidirectional communication over a TCP connection; they wo= rk great if TCP fits your transport needs, but perform poorly if your appli= cation is latency sensitive and would, in non-Web context, use a UDP-based = protocol.=C2=A0 There are many different kinds of applications like that, b= ut I would like to highlight two major categories which I to some extent su= rveyed when coming up with this proposal:
  1. Custom client-server c= hat/multimedia protocols (faster-than-DASH video streaming, game streaming,= etc).=C2=A0 Those are usually developed by teams with a good amount of res= ources, and they are interested in tailoring the setup for their use case.<= /li>
  2. Game developers.=C2=A0 Online games are commonly real-time in natur= e and benefit dramatically from ability to give up on transmitting old info= rmation.=C2=A0 They usually use some in-house UDP-based protocol, and often= need to run on unusual platforms.=C2=A0=C2=A0
WebRTC Data Channel= s are a mechanism that provides a WebSocket-like interface with unreliable = delivery features.=C2=A0 On the wire, it=E2=80=99s SCTP-over-DTLS, establis= hed using ICE and SDP.=C2=A0 In theory, this provides users with enough fun= ctionality to build anything they need, since SCTP messages can be unreliab= le and unordered.=C2=A0 In practice, while RtcDataChannel is fairly straigh= tforward to use for browser-to-browser peer-to-peer communication, it has s= een much lower adoption than WebSockets in the client-server scenario, even= considering the fact that its use cases is naturally more niche.

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

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

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

# Proposa= l

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

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

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

describes the framework itsel= f, mainly the requirements the transport protocols have to satisfy to be us= able on the web through the API.=C2=A0 Within this framework, we propose th= e following protocols:
  • QuicTransport -- a simple WebSocket-like = adaptation of QUIC, described in https://tools.ietf.org/html/draft-vvv-webtrans= port-quic-00
  • Http3Transport -- a mechanism that allows creating= custom non-HTTP streams within an HTTP/3 session, described in https://tools.= ietf.org/html/draft-vvv-webtransport-http3-00.=C2=A0 This is sort of a = version of RFC 8441 for QuicTransport.
  • FallbackTransport -- a TCP-b= ased transport with multiplexed streams that can be used when QUIC is not a= vailable (e.g. on network that require CONNECT proxy).=C2=A0 We don=E2=80= =99t have a draft specifically for this, and there are at least two approac= hes we could take here: either reusing HTTP/2 as a transport (i.e. just use= draft-kinnear-httpbis-http2-transport), or building a protocol with QUIC-l= ike semantics on top of WebSockest.=C2=A0 The earlier is a more straightfor= ward way; the latter has the advantage of being fully polyfillable in JavaS= cript.

# Discussion

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

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

Thanks,
=C2=A0 Victor.

[0] https://github.com/WICG/web-transport
--00000000000005fb49058b851302-- From nobody Mon Jun 17 07:13:07 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F93120127 for ; Mon, 17 Jun 2019 07:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ooi6hsHyeBpC for ; Mon, 17 Jun 2019 07:13:00 -0700 (PDT) Received: from smtp001-out2.apm-internet.net (smtp001-out2.apm-internet.net [85.119.248.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38DC312011C for ; Mon, 17 Jun 2019 07:13:00 -0700 (PDT) Received: (qmail 96014 invoked from network); 17 Jun 2019 14:12:58 -0000 X-APM-Out-ID: 15607807789601 X-APM-Authkey: 255286/0(159927/0) 1247 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 17 Jun 2019 14:12:58 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 5F3C218A11B3; Mon, 17 Jun 2019 15:12:58 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QsU4gYwa1KOu; Mon, 17 Jun 2019 15:12:58 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id CFB9118A0C3B; Mon, 17 Jun 2019 15:12:57 +0100 (BST) From: T H Panton Message-Id: <98EF12E4-4BF2-4FBC-852B-776A0E0118BE@westhawk.co.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_956096E2-55CB-4EE5-B45E-43CE45FB1053" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 17 Jun 2019 15:12:56 +0100 In-Reply-To: Cc: dispatch@ietf.org To: Victor Vasiliev References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dispatch] Dispatching WebTransport X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 14:13:05 -0000 --Apple-Mail=_956096E2-55CB-4EE5-B45E-43CE45FB1053 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 Jun 2019, at 14:35, Victor Vasiliev = wrote: >=20 > Hello friendly IETF dispatchers, >=20 > I am writing about new work I want to bring to IETF. The proposal is = called WebTransport. It=E2=80=99s a combination of a Web API currently = under development in W3C WICG [0], a protocol framework and some = protocols that fit into that framework. Combined, they would allow web = applications to establish WebSocket-like connections that instead of = ordered reliable messages use multiple streams and datagrams (datagrams = are unreliable and streams do not have head-of-line blocking). This is = highly useful for real-time and other latency sensitive applications. Establish connections to where ? Between eachother P2P ? Or to any = server? Or just to the originating server only?=20 >=20 > # Background >=20 > Historically, the only networking operations available to the Web = applications were sending HTTP requests and receiving HTTP responses. = That model does not fit all applications well, so over time, more = mechanisms were added. The two most relevant here are WebSockets (RFC = 6455) and RTC Data Channels (draft-ietf-rtcweb-data-channel). = WebSockets are a way for Web applications to do bidirectional = communication over a TCP connection; they work great if TCP fits your = transport needs, but perform poorly if your application is latency = sensitive and would, in non-Web context, use a UDP-based protocol. = There are many different kinds of applications like that, but I would = like to highlight two major categories which I to some extent surveyed = when coming up with this proposal: > Custom client-server chat/multimedia protocols (faster-than-DASH video = streaming, game streaming, etc). Those are usually developed by teams = with a good amount of resources, and they are interested in tailoring = the setup for their use case. > Game developers. Online games are commonly real-time in nature and = benefit dramatically from ability to give up on transmitting old = information. They usually use some in-house UDP-based protocol, and = often need to run on unusual platforms. =20 > WebRTC Data Channels are a mechanism that provides a WebSocket-like = interface with unreliable delivery features. On the wire, it=E2=80=99s = SCTP-over-DTLS, established using ICE and SDP. In theory, this provides = users with enough functionality to build anything they need, since SCTP = messages can be unreliable and unordered. In practice, while = RtcDataChannel is fairly straightforward to use for browser-to-browser = peer-to-peer communication, it has seen much lower adoption than = WebSockets in the client-server scenario, even considering the fact that = its use cases is naturally more niche. >=20 > The main reason for this is the incredible complexity of the WebRTC = stack. WebSockets are a fairly straightforward overlay on top of TCP = and TLS; there is a wide variety of implementations out there, and it's = fairly easy to write a new one (I wrote on myself in less than 1,000 = lines of C++). With data channels, however, once there is no browser to = abstract all of the complexity away, the web developers are required to = understand and implement (or at least integrate) SDP, ICE, STUN, DTLS = and userspace SCTP. While a lot of those have simplifications for this = use case (ICE Lite) and some protocols listed have a variety of = implementations widely available (DTLS), the entire system still = requires going through hundreds of pages of RFCs in order to understand = it well enough to implement. This complexity barrier has precluded Data = Channel adoption by communities of smaller developers who don=E2=80=99t = have resources to implement them, notably game developers (see [1] and = [2] for some discussion). Much, but not all, of the complexity of the webRTC stack is due to the = NAT traversal and security commitments you need to do P2P. If you = exclude the need to do NAT traversal and P2P then it _could_ be much simpler. But it also gives you E2E encryption = and low latency as side effects! Work is in progress decoupling the APIs from the (dreaded) SDP and = simplifying the developer experience. That said, it is by no means un-managable - I've implemented pretty much = the whole stack from scratch for small devices and I know of 2 other = implementations which don't use libusrsctp=20 >=20 > Even among the people who got past the complexity barrier, the = feedback I heard almost universally is that WebRTC Data Channels are = hard to work with. =46rom the feedback I gathered, the main problem is = usually around the transport protocol itself. Userspace SCTP is = essentially a monoculture: virtually all implementations use libusrsctp, = a 80,000-line adaptation of FreeBSD SCTP implementation. This lack of = tool choice is fairly painful since latency-sensitive real-time = applications often require quite a bit of tuning on the transport side = to get the best performance (custom congestion control, etc). In = addition, the limitations on the message size stemming from both the API = itself and the lack of widespread support for message interleaving (RFC = 8260) means that the developers have to roll their own framing on top of = SCTP messages if they want to avoid head-of-line-blocking (this is = particularly bad because the framing overhead in data channels is = already large as-is). SCTP is well defined nice protocol that suffers (IMHO) from a lack of = 'coolness' due to being used by the telcos for most of it's life. The head-of-line issue is a problem, but entirely fixable with small = tweaks to SCTP protocol. (read it wasn't in the original requirements - = so it doesn't do it). >=20 > In summary, we have a system that technically provides what everyone = wants, but that nobody is happy with, and that is not usable by all but = the most well-resourced users. I'd point out that 2.5bn endpoints support it right now - including = _every_ smartphone shipped in the last 2 years. Last I heard DataChannel = traffic was 0.1% of chrome's traffic=20 which is _astonishingly_ high >=20 > # Proposal >=20 > Our initial idea for fixing this was to take QUIC and do what = WebSocket did to TCP: add security features that would make it safe to = expose on the Web (by adding origin checks, etc), but otherwise expose = it as-is. This would get us out of libusrsctp monoculture (QUIC is not = yet finished, but it already has a fairly diverse implementation = ecosystem, see [3]), and remove all P2P-related complexity involving SDP = and ICE. The original proposal for that was called QuicTransport; we = showed it to various people, and the feedback we got is that (1) the API = should not be tied to a particular transport (since we already switched = once from SCTP to QUIC, tying it to QUIC specificially would not be = wise), and (2) it shouldn=E2=80=99t fail hard when QUIC is unavailable. >=20 It would be _great_ if that abstraction could _also_ work over SCTP data = channels. That way you could cover the P2P use cases too. > As a result of that feedback, we abstracted it into a general-purpose = framework called WebTransport. The overview draft, >=20 > https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 = >=20 > describes the framework itself, mainly the requirements the transport = protocols have to satisfy to be usable on the web through the API. = Within this framework, we propose the following protocols: > QuicTransport -- a simple WebSocket-like adaptation of QUIC, described = in https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 = > Http3Transport -- a mechanism that allows creating custom non-HTTP = streams within an HTTP/3 session, described in = https://tools.ietf.org/html/draft-vvv-webtransport-http3-00 = . This is = sort of a version of RFC 8441 for QuicTransport. > FallbackTransport -- a TCP-based transport with multiplexed streams = that can be used when QUIC is not available (e.g. on network that = require CONNECT proxy). We don=E2=80=99t have a draft specifically for = this, and there are at least two approaches we could take here: either = reusing HTTP/2 as a transport (i.e. just use = draft-kinnear-httpbis-http2-transport), or building a protocol with = QUIC-like semantics on top of WebSockest. The earlier is a more = straightforward way; the latter has the advantage of being fully = polyfillable in JavaScript. >=20 > # Discussion >=20 > At this point, I am fairly certain that there is a problem here that = needs to be addressed. I am formally requesting ART area to take this = problem on. I'd really like to be clear what that problem is.=20 >=20 > I believe the drafts above would be a good starting point for = discussion. The design that they describe went through several = iterations based on the feedback I got when I discussed this work within = a more narrow audience (mostly people in QUIC working group), so we=E2=80=99= re hopefully at least looking in the right direction here. I am = requesting feedback on this proposal, both on the overall plan and the = specifics described in the drafts. I hope to discuss this in depth in = Montreal, both at dispatch and (in more depth) at a side-meeting. Tim. >=20 > Thanks, > Victor. >=20 > [0] https://github.com/WICG/web-transport = > [1] https://discourse.wicg.io/t/webtransport-proposal/3508/9 = > [2] https://news.ycombinator.com/item?id=3D13266692 = > [3] https://github.com/quicwg/base-drafts/wiki/Implementations = > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_956096E2-55CB-4EE5-B45E-43CE45FB1053 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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

Hello friendly IETF dispatchers,

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

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


# Background

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

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

Much, = but not all, of the complexity of the webRTC stack is due to the NAT = traversal and security commitments you need to do P2P. If you exclude = the need to do NAT traversal and P2P
then it _could_ be much = simpler. But it also gives you E2E encryption and low latency as side = effects!

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

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



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

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


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

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


# Proposal

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


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

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

  https://tools.ietf.org/html/draft-vvv-webtransport-overview-00<= /a>

describes the framework itself, mainly = the requirements the transport protocols have to satisfy to be usable on = the web through the API.  Within this framework, we propose the = following protocols:

# Discussion

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

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


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

Tim.


Thanks,
  Victor.

[0] https://github.com/WICG/web-transport
[1] = https://discourse.wicg.io/t/webtransport-proposal/3508/9[2] https://news.ycombinator.com/item?id=3D13266692
[3] https://github.com/quicwg/base-drafts/wiki/Implementations<= br class=3D"">
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_956096E2-55CB-4EE5-B45E-43CE45FB1053-- From nobody Mon Jun 17 07:14:40 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE82120114 for ; Mon, 17 Jun 2019 07:14:39 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rsNcW0jAaQI for ; Mon, 17 Jun 2019 07:14:36 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 6CDBD120059 for ; Mon, 17 Jun 2019 07:14:36 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id r185so15521544iod.6 for ; Mon, 17 Jun 2019 07:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cCBAbYXqxzGjud2hN4l32BvGF9xg92mHi3pXMwg/ROg=; b=MOgdXTuXlJpG66mr5VzWheEmER3MFurmsuO8Fkj2kSiujRbNdEG8/Yh+8GwE0/ntyp Vh2UVf0yEj6XUEJDa7wdtRMhMFzGrprN8DFC1ndLKNDcquV9snpGOaLsxeaupT3g1xP6 tOMgOYxX03wN5cKiHDpVS8dcxU/dOYO/RzHzw5RocqgQGeSojHThoXoREfukgQ7D3QZk K4Dq3JPPEE5lHP9EkMpUZPVGS/PEl0ES33D58fm53+VjZp/SZeXsy36u020yFmaFMiSI dwLyUEPx7AiNeq65ylmz9JGTQPYCwwwKFdupupWqC0sHwPWZqtyvEuM5ptFPmGwPn35K grKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=cCBAbYXqxzGjud2hN4l32BvGF9xg92mHi3pXMwg/ROg=; b=SxuxGbyetBHK1OnPW98bl8Rtmr/xQVAiRj6WhziNoVl5OUnCy6PydpCkz2PGW1qpPj GXWbzRbJFsacpEgM1U7JIxtR5ts/JA2sxfdf3C3LCL7WjCKs0SjZIa1SXXoIfEnj/IXF hAorm5vqSBe4Hj6eSEWGVvVe+2/ssRJitl67ABCmsZp+Wwf1xqdF2R/TK96FAWWsWDxi pAC7OhvMz4+U5cB+GDcnCyTfzZBK6OqzcYygYn+sSFxdWzBsPyit+lvWIE38qHBGvhJS wkvSy9yylucRVnOoEVn8eZkF4Fq4PfYuSR6vI/nJtokn4U6uhDUOKEmFcpHqzCMpey7z cVBA== X-Gm-Message-State: APjAAAUo9xuiRk1BTQojxG3BgkFdXUGu1OfWgYChiMqJ2QkZTdBzisZw ngmd42FvbkYzCLVkH4ieqgPNNskrmVg= X-Google-Smtp-Source: APXvYqwO1fURih1FhGe/1eIfU5+B0f6aXr+8xyLnG3w/5oLReJB2goZpAq5X6RXjAbxQd5iGWb+Siw== X-Received: by 2002:a02:950a:: with SMTP id y10mr19069608jah.26.1560780875367; Mon, 17 Jun 2019 07:14:35 -0700 (PDT) Received: from mmiller-44677.local (63-238-229-145.dia.static.qwest.net. [63.238.229.145]) by smtp.gmail.com with ESMTPSA id k22sm9155371ior.52.2019.06.17.07.14.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jun 2019 07:14:34 -0700 (PDT) Sender: Matthew Miller To: Mary Barnes , draft-ietf-dispatch-javascript-mjs@ietf.org, DISPATCH References: From: "Matthew A. Miller" Openpgp: preference=signencrypt Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBPQQTAQoAJwUCWKsJ1AIbAwUJC8ckMQULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRDs 9HJOEJ4Fu1iBCADAcW06d/7GTlBjTlYuMGgjzDBoWeQ9/zxgMnSrgNb6yO7wHzE65CeFs6OI 6LQ4A34CNM3hhcWDIzlqrV25fVyy7qCh6bCNMs1pOT63+Od4kcjHtUnGGTONT5fXSGY7mCtl XJFjb3TwyLUZXQCifhCIaUdF/4SVoGk96W9ssbDKN+5xq7B7gyVkwB0WM67zxt/kC6TPcXXL 5m7jsNRpRmFQqOlIF+HrQAcSr1lKRWgetb1VHfXCgcmDaTKn1QC7s0Ml+27dc0SoIkBI8cnv inJ4oFYWrvnTlOvv+v8AFXZnPrxZ/JYvnVD/y5PX7v08Z8RFXm1AmVxIWjXPI6TySkGvuQEN BFJoAooBCADA/ruHwYlQ7pdjJY6twkZcMmedkQNL6r5tNBeQkwVrvitUjHTKKipjxB2kEkUZ oxPgMI1h7/enDrVlMMMqq6RIJ86H+yx13zNIZNBlJfmVHgHj7TT8spa6A/qIccdiIRNsFVvl vFxpH8sTjVbHfPYexbdOR5kHpZWTzYxNyVLXMK5jen0B4K+vjbgFJAvsoLfzLZ5Bz3kb6dpu xUNzqhDyhk5/UPaCIFvZWBtiRKmkqPwEq8G2aMJq5Z4Sr8CRkpoMB25rxCPS8R+ByiHxpq+U 8mKuqPVg1LJzcA7hHmms8aBN6lxSlbyKnzEg8AWgld+6+xlJXu5U/fqDAClTj5mfABEBAAGJ ATwEGAEKACYCGwwWIQQx11iN7JBpDWvMmODs9HJOEJ4FuwUCWm+kiwUJC8tagQAKCRDs9HJO EJ4Fu40cB/9xyEnuQegivmL6OBVG5HvUAaXGUxtWiWdLm3NrduL0h7rctF060xQTekNRCjbl xZ1w/unPDBEEIMPYbF8i7IwJZoRLTG1B1MjI04AUU60G0IU6uw0ST6IsC7oYGvhDNJApbVBb j9u9x+kzaktCftl3qdpSKgRh9McIyZgevuFBdo80RDtX8niktUA3xsfJWBD1yJA33UNSzqOe 54wFRbsM2+4erREPMD659h2lACPCXjPW/6ucnv0/cdPF8V2JNMCT0yPJVCSUfFLTrtyYtiRI 6S52cI4eEOZIXCQp30TA4E27O2mMLOYzlKA5P5T+Icf4gz8e/puNUKIBDlY6KF7p Message-ID: <69e52de0-6f80-c5d6-de24-05cce84d011f@outer-planes.net> Date: Mon, 17 Jun 2019 08:14:34 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] Shepherd review of draft-ietf-dispatch-javascript-mjs X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 14:14:39 -0000 Thanks for the review comments, Mary. The authors believe we will have addressed the outstanding issue and will have the shepherd concerns addressed in the next revision; will submit that before the week is over. - m&m Matthew A. Miller On 19/06/12 08:36, Mary Barnes wrote: > I have reviewed the document in anticipation of forwarding to IESG for > publication.  There is still one outstanding issue and once that's > resolved I will ask the AD to request publication. > > https://mailarchive.ietf.org/arch/msg/dispatch/bHeezFbph08KIfXGvghHbqKWe14 > > I have just two minor comments with regards to the "Note to Readers" > section in the front of the document, and the URI section.  Those > sections reference a github repository for the document.  Since that > repository isn't necessarily stable and not associated with the IETF, I > would suggest to remove those sections OR add a "Note to the RFC editor" > to remove those sections prior to publication.   > > Regards, > Mary > > From nobody Mon Jun 17 07:34:02 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CCE120110 for ; Mon, 17 Jun 2019 07:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koRkP5RVJzyI for ; Mon, 17 Jun 2019 07:33:58 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (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 6712612008A for ; Mon, 17 Jun 2019 07:33:58 -0700 (PDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x5HEXt7l026744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 17 Jun 2019 10:33:56 -0400 To: dispatch@ietf.org References: From: Paul Kyzivat Message-ID: Date: Mon, 17 Jun 2019 10:33:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] Dispatching WebTransport X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 14:34:01 -0000 ISTM that your problem description below boils down to: There isn't a suitable library that provides a convenient interface to use data channels. So why don't you concentrate on creating such a library? Thanks, Paul On 6/17/19 9:35 AM, Victor Vasiliev wrote: > Hello friendly IETF dispatchers, > > I am writing about new work I want to bring to IETF.  The proposal is > called WebTransport.  It’s a combination of a Web API currently under > development in W3C WICG [0], a protocol framework and some protocols > that fit into that framework.  Combined, they would allow web > applications to establish WebSocket-like connections that instead of > ordered reliable messages use multiple streams and datagrams (datagrams > are unreliable and streams do not have head-of-line blocking).  This is > highly useful for real-time and other latency sensitive applications. > > # Background > > Historically, the only networking operations available to the Web > applications were sending HTTP requests and receiving HTTP responses. > That model does not fit all applications well, so over time, more > mechanisms were added.  The two most relevant here are WebSockets (RFC > 6455) and RTC Data Channels (draft-ietf-rtcweb-data-channel). > WebSockets are a way for Web applications to do bidirectional > communication over a TCP connection; they work great if TCP fits your > transport needs, but perform poorly if your application is latency > sensitive and would, in non-Web context, use a UDP-based protocol. > There are many different kinds of applications like that, but I would > like to highlight two major categories which I to some extent surveyed > when coming up with this proposal: > > 1. Custom client-server chat/multimedia protocols (faster-than-DASH > video streaming, game streaming, etc).  Those are usually developed > by teams with a good amount of resources, and they are interested in > tailoring the setup for their use case. > 2. Game developers.  Online games are commonly real-time in nature and > benefit dramatically from ability to give up on transmitting old > information.  They usually use some in-house UDP-based protocol, and > often need to run on unusual platforms. > > WebRTC Data Channels are a mechanism that provides a WebSocket-like > interface with unreliable delivery features.  On the wire, it’s > SCTP-over-DTLS, established using ICE and SDP.  In theory, this provides > users with enough functionality to build anything they need, since SCTP > messages can be unreliable and unordered.  In practice, while > RtcDataChannel is fairly straightforward to use for browser-to-browser > peer-to-peer communication, it has seen much lower adoption than > WebSockets in the client-server scenario, even considering the fact that > its use cases is naturally more niche. > > The main reason for this is the incredible complexity of the WebRTC > stack.  WebSockets are a fairly straightforward overlay on top of TCP > and TLS; there is a wide variety of implementations out there, and it's > fairly easy to write a new one (I wrote on myself in less than 1,000 > lines of C++).  With data channels, however, once there is no browser to > abstract all of the complexity away, the web developers are required to > understand and implement (or at least integrate) SDP, ICE, STUN, DTLS > and userspace SCTP.  While a lot of those have simplifications for this > use case (ICE Lite) and some protocols listed have a variety of > implementations widely available (DTLS), the entire system still > requires going through hundreds of pages of RFCs in order to understand > it well enough to implement.  This complexity barrier has precluded Data > Channel adoption by communities of smaller developers who don’t have > resources to implement them, notably game developers (see [1] and [2] > for some discussion). > > Even among the people who got past the complexity barrier, the feedback > I heard almost universally is that WebRTC Data Channels are hard to work > with.  From the feedback I gathered, the main problem is usually around > the transport protocol itself.  Userspace SCTP is essentially a > monoculture: virtually all implementations use libusrsctp, a 80,000-line > adaptation of FreeBSD SCTP implementation.  This lack of tool choice is > fairly painful since latency-sensitive real-time applications often > require quite a bit of tuning on the transport side to get the best > performance (custom congestion control, etc).  In addition, the > limitations on the message size stemming from both the API itself and > the lack of widespread support for message interleaving (RFC 8260) means > that the developers have to roll their own framing on top of SCTP > messages if they want to avoid head-of-line-blocking (this is > particularly bad because the framing overhead in data channels is > already large as-is). > > In summary, we have a system that technically provides what everyone > wants, but that nobody is happy with, and that is not usable by all but > the most well-resourced users. > > # Proposal > > Our initial idea for fixing this was to take QUIC and do what WebSocket > did to TCP: add security features that would make it safe to expose on > the Web (by adding origin checks, etc), but otherwise expose it as-is. > This would get us out of libusrsctp monoculture (QUIC is not yet > finished, but  it already has a fairly diverse implementation ecosystem, > see [3]), and remove all P2P-related complexity involving SDP and ICE. > The original proposal for that was called QuicTransport; we showed it to > various people, and the feedback we got is that (1) the API should not > be tied to a particular transport (since we already switched once from > SCTP to QUIC, tying it to QUIC specificially would not be wise), and (2) > it shouldn’t fail hard when QUIC is unavailable. > > As a result of that feedback, we abstracted it into a general-purpose > framework called WebTransport.  The overview draft, > > https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 > > describes the framework itself, mainly the requirements the transport > protocols have to satisfy to be usable on the web through the API. > Within this framework, we propose the following protocols: > > * QuicTransport -- a simple WebSocket-like adaptation of QUIC, > described in https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 > * Http3Transport -- a mechanism that allows creating custom non-HTTP > streams within an HTTP/3 session, described in > https://tools.ietf.org/html/draft-vvv-webtransport-http3-00.  This > is sort of a version of RFC 8441 for QuicTransport. > * FallbackTransport -- a TCP-based transport with multiplexed streams > that can be used when QUIC is not available (e.g. on network that > require CONNECT proxy).  We don’t have a draft specifically for > this, and there are at least two approaches we could take here: > either reusing HTTP/2 as a transport (i.e. just use > draft-kinnear-httpbis-http2-transport), or building a protocol with > QUIC-like semantics on top of WebSockest.  The earlier is a more > straightforward way; the latter has the advantage of being fully > polyfillable in JavaScript. > > > # Discussion > > At this point, I am fairly certain that there is a problem here that > needs to be addressed.  I am formally requesting ART area to take this > problem on. > > I believe the drafts above would be a good starting point for > discussion.  The design that they describe went through several > iterations based on the feedback I got when I discussed this work within > a more narrow audience (mostly people in QUIC working group), so we’re > hopefully at least looking in the right direction here.  I am requesting > feedback on this proposal, both on the overall plan and the specifics > described in the drafts.  I hope to discuss this in depth in Montreal, > both at dispatch and (in more depth) at a side-meeting. > > Thanks, >   Victor. > > [0] https://github.com/WICG/web-transport > [1] https://discourse.wicg.io/t/webtransport-proposal/3508/9 > [2] https://news.ycombinator.com/item?id=13266692 > [3] https://github.com/quicwg/base-drafts/wiki/Implementations > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Mon Jun 17 07:52:48 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529A51200C5 for ; Mon, 17 Jun 2019 07:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-GcvHp8_8v6 for ; Mon, 17 Jun 2019 07:52:42 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 42205120114 for ; Mon, 17 Jun 2019 07:52:42 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id s49so16622137edb.1 for ; Mon, 17 Jun 2019 07:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Szat7g1wAygEXtkPl1Sb69v9mNalVQ6pGtXvkY4mt0o=; b=hFxwsGtyKudNP23WSHoBtto/PoKtLZ+hvTsgSQFJcU6IyJnqzd/rTBnVeGW3FyA4gl fUtty7hDEqg40jFL5uAz1Mchsf2lkYPszSa+iRhPQlgZUC4786bXobdKXKysPr3zKWnp 9OPfMwze1/rQGFbkCfTthI5FM9Xuex578i2wKQbArUA4QPYuUwxm9VwOS7335bCICQxL WmICCYSYKnzFDYfBmFnUXr60m4Ic/qcVexgGscHvvandJq6MopNTzzBEnO92byOFbQQS 7BsSc1jn03pxku3SRkrV8Ix/vY3lhL7RdmidoQ+B+9oAmSUjE2tAB9KggdNYRIfA1zlE tRpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Szat7g1wAygEXtkPl1Sb69v9mNalVQ6pGtXvkY4mt0o=; b=JdgmknIefeG3K1A2hxH9MZOxzdipY1ZWPKcy1X3vogb7KmvD3L+9pGfHPcJLKRN4yr u87IglsfcFOldGyJvwTEpFRSX6/A6fwqrpefXtXjINukv2n5bFg0c4qV6tfsPxSG6TP6 QDHDstv5xGy8yMN33Q5Fu26hdgXu8Q7UaxfAFQw3utKBF3T0WzDRM/gTrh1O4lcDkX2E dCrLNMBhLWiIkSFU6+md1U4cPLRYWEEwpKzfBZKdu2uWAyCCdIlpU3fedbRCMfuG/uMc W/iIEsr0TWdvRjXlxpsx7l3jeocmaGzoUZ2hqxybqpTs523jfROC0K5zLUsFQheFffmG tWPA== X-Gm-Message-State: APjAAAW2jsGyjmTSsYlV5jAt53erj8qUjKoSACjn4OfJqYd9MbT3iJGA zSDQRGc8Xj/rgXpEqS+IXFaNWpxTXWU= X-Google-Smtp-Source: APXvYqyVqCtUj0uIREjNLnJRAx+mRpfbMVYdspTYjvncbLhol+H15X5J39y85pM4BdZ2a0bJCexzjQ== X-Received: by 2002:a17:906:b7d8:: with SMTP id fy24mr29804233ejb.230.1560783160545; Mon, 17 Jun 2019 07:52:40 -0700 (PDT) Received: from [10.255.3.20] (82.red-80-38-205.staticip.rima-tde.net. [80.38.205.82]) by smtp.googlemail.com with ESMTPSA id m31sm3857686edd.42.2019.06.17.07.52.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jun 2019 07:52:39 -0700 (PDT) To: dispatch@ietf.org References: From: Sergio Garcia Murillo Message-ID: Date: Mon, 17 Jun 2019 16:52:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D20E38983A6B742CA3BEA8F3" Content-Language: en-US Archived-At: Subject: Re: [dispatch] Dispatching WebTransport X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 14:52:47 -0000 This is a multi-part message in MIME format. --------------D20E38983A6B742CA3BEA8F3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit From the draft: WebTransport [OVERVIEW ] is a protocol framework that enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. Although while I agree with your analysis regarding current webrtc dc and sctp status, if this is a pure client-to-server transport, why is webrtc mentioned in the background at all? shouldn't this be a replacement of websockets and NOT of the webrtc datachannels? Best regards Sergio On 17/06/2019 15:35, Victor Vasiliev wrote: > Hello friendly IETF dispatchers, > > I am writing about new work I want to bring to IETF.  The proposal is > called WebTransport.  It’s a combination of a Web API currently under > development in W3C WICG [0], a protocol framework and some protocols > that fit into that framework. Combined, they would allow web > applications to establish WebSocket-like connections that instead of > ordered reliable messages use multiple streams and datagrams > (datagrams are unreliable and streams do not have head-of-line > blocking).  This is highly useful for real-time and other latency > sensitive applications. > > # Background > > Historically, the only networking operations available to the Web > applications were sending HTTP requests and receiving HTTP responses.  > That model does not fit all applications well, so over time, more > mechanisms were added.  The two most relevant here are WebSockets (RFC > 6455) and RTC Data Channels (draft-ietf-rtcweb-data-channel).  > WebSockets are a way for Web applications to do bidirectional > communication over a TCP connection; they work great if TCP fits your > transport needs, but perform poorly if your application is latency > sensitive and would, in non-Web context, use a UDP-based protocol.  > There are many different kinds of applications like that, but I would > like to highlight two major categories which I to some extent surveyed > when coming up with this proposal: > > 1. Custom client-server chat/multimedia protocols (faster-than-DASH > video streaming, game streaming, etc). Those are usually developed > by teams with a good amount of resources, and they are interested > in tailoring the setup for their use case. > 2. Game developers.  Online games are commonly real-time in nature > and benefit dramatically from ability to give up on transmitting > old information.  They usually use some in-house UDP-based > protocol, and often need to run on unusual platforms. > > WebRTC Data Channels are a mechanism that provides a WebSocket-like > interface with unreliable delivery features.  On the wire, it’s > SCTP-over-DTLS, established using ICE and SDP. In theory, this > provides users with enough functionality to build anything they need, > since SCTP messages can be unreliable and unordered.  In practice, > while RtcDataChannel is fairly straightforward to use for > browser-to-browser peer-to-peer communication, it has seen much lower > adoption than WebSockets in the client-server scenario, even > considering the fact that its use cases is naturally more niche. > > The main reason for this is the incredible complexity of the WebRTC > stack.  WebSockets are a fairly straightforward overlay on top of TCP > and TLS; there is a wide variety of implementations out there, and > it's fairly easy to write a new one (I wrote on myself in less than > 1,000 lines of C++).  With data channels, however, once there is no > browser to abstract all of the complexity away, the web developers are > required to understand and implement (or at least integrate) SDP, ICE, > STUN, DTLS and userspace SCTP.  While a lot of those have > simplifications for this use case (ICE Lite) and some protocols listed > have a variety of implementations widely available (DTLS), the entire > system still requires going through hundreds of pages of RFCs in order > to understand it well enough to implement.  This complexity barrier > has precluded Data Channel adoption by communities of smaller > developers who don’t have resources to implement them, notably game > developers (see [1] and [2] for some discussion). > > Even among the people who got past the complexity barrier, the > feedback I heard almost universally is that WebRTC Data Channels are > hard to work with.  From the feedback I gathered, the main problem is > usually around the transport protocol itself. Userspace SCTP is > essentially a monoculture: virtually all implementations use > libusrsctp, a 80,000-line adaptation of FreeBSD SCTP implementation.  > This lack of tool choice is fairly painful since latency-sensitive > real-time applications often require quite a bit of tuning on the > transport side to get the best performance (custom congestion control, > etc).  In addition, the limitations on the message size stemming from > both the API itself and the lack of widespread support for message > interleaving (RFC 8260) means that the developers have to roll their > own framing on top of SCTP messages if they want to avoid > head-of-line-blocking (this is particularly bad because the framing > overhead in data channels is already large as-is). > > In summary, we have a system that technically provides what everyone > wants, but that nobody is happy with, and that is not usable by all > but the most well-resourced users. > > # Proposal > > Our initial idea for fixing this was to take QUIC and do what > WebSocket did to TCP: add security features that would make it safe to > expose on the Web (by adding origin checks, etc), but otherwise expose > it as-is.  This would get us out of libusrsctp monoculture (QUIC is > not yet finished, but  it already has a fairly diverse implementation > ecosystem, see [3]), and remove all P2P-related complexity involving > SDP and ICE.  The original proposal for that was called QuicTransport; > we showed it to various people, and the feedback we got is that (1) > the API should not be tied to a particular transport (since we already > switched once from SCTP to QUIC, tying it to QUIC specificially would > not be wise), and (2) it shouldn’t fail hard when QUIC is unavailable. > > As a result of that feedback, we abstracted it into a general-purpose > framework called WebTransport.  The overview draft, > > https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 > > describes the framework itself, mainly the requirements the transport > protocols have to satisfy to be usable on the web through the API.  > Within this framework, we propose the following protocols: > > * QuicTransport -- a simple WebSocket-like adaptation of QUIC, > described in > https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 > * Http3Transport -- a mechanism that allows creating custom non-HTTP > streams within an HTTP/3 session, described in > https://tools.ietf.org/html/draft-vvv-webtransport-http3-00. This > is sort of a version of RFC 8441 for QuicTransport. > * FallbackTransport -- a TCP-based transport with multiplexed > streams that can be used when QUIC is not available (e.g. on > network that require CONNECT proxy).  We don’t have a draft > specifically for this, and there are at least two approaches we > could take here: either reusing HTTP/2 as a transport (i.e. just > use draft-kinnear-httpbis-http2-transport), or building a protocol > with QUIC-like semantics on top of WebSockest.  The earlier is a > more straightforward way; the latter has the advantage of being > fully polyfillable in JavaScript. > > > # Discussion > > At this point, I am fairly certain that there is a problem here that > needs to be addressed.  I am formally requesting ART area to take this > problem on. > > I believe the drafts above would be a good starting point for > discussion.  The design that they describe went through several > iterations based on the feedback I got when I discussed this work > within a more narrow audience (mostly people in QUIC working group), > so we’re hopefully at least looking in the right direction here.  I am > requesting feedback on this proposal, both on the overall plan and the > specifics described in the drafts. I hope to discuss this in depth in > Montreal, both at dispatch and (in more depth) at a side-meeting. > > Thanks, >   Victor. > > [0] https://github.com/WICG/web-transport > [1] https://discourse.wicg.io/t/webtransport-proposal/3508/9 > [2] https://news.ycombinator.com/item?id=13266692 > [3] https://github.com/quicwg/base-drafts/wiki/Implementations > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------D20E38983A6B742CA3BEA8F3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
From the draft:

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

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

Best regards
Sergio


On 17/06/2019 15:35, Victor Vasiliev wrote:
Hello friendly IETF dispatchers,

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

# Background

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

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

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

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

# Proposal

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

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

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

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

# Discussion

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

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

Thanks,
  Victor.

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

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


--------------D20E38983A6B742CA3BEA8F3-- From nobody Mon Jun 17 08:01:51 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940CE120147 for ; Mon, 17 Jun 2019 08:01:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m14MK2gb4gIi for ; Mon, 17 Jun 2019 08:01:47 -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 1BB7F12014A for ; Mon, 17 Jun 2019 08:01:47 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id u124so6323687vsu.2 for ; Mon, 17 Jun 2019 08:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=L3UpoCpHhzAzoqkYzmc7SKePPhF9pPpybue4fCwLXSQ=; b=FYaPW9kUSqtFuuK7lD0OixX/3fRICXyCF4FKK5+6GkxX5JvV4N5dA/tHMPmDmI1nqA NQ2u+KEstjJRYWXGuDjeKDJJAKo/9AP45fbHXYi6WwMQEmCxkO1F6T1BY8BBmB4KUxW7 etnOgBtve211AKqZNKSnzBfB2Fls6QA/+Vijt6z5eqPlrBJMGjynLmql/XWLX+OSJQ/U iuf9NzZSGB6BrhXgeuV0geC3cQ+XIgQ49bUTH+kfRQWeCjjtZICvajBX+ruoyezNKGpS BNYf5tVy3S5fg1KzVw5qRYFmgi5jLkWlnZTFGW7rtzzwUTNySGaKPk+1YN9yx9zl+6o2 xXjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=L3UpoCpHhzAzoqkYzmc7SKePPhF9pPpybue4fCwLXSQ=; b=ZDM0qVUfI94rGI+fzWXmHAWCcUIVn78bl9V7Xorb9/Q8AeE9DEwJgRc3/VZmL1LFty 6QJEy4IDtFdPMzcHtF1qryAA8sOc12kHMMaR0MqOY1xKrEFfruHTRKHOps9tnzxXCXVg sLutrfZ4i38/VnRr27/0WMMT2J3Gru5z4616fEeQwLTefzOQEtQ+mlFPyneGZgT/47dU PBrvXX10Mjx2YKafCfQyr0RqN3B3XugW+Jq8Yq1Df3acVnNbgkgnVFFMURv4Hc6X71pn a8btcg0iGvskADdMd8qKbJxOZ1/xxdu++P6MlRhtNsd/prV9wv9X3Xs8ijhQDAETre4c LbdA== X-Gm-Message-State: APjAAAX2afNGDm77GhcTJPfm4gOK0Bf8cXU50Uil6YZWSTfD1vsHywis xQhHZr/rIEGWsVUQWzewkqGZ1thwe45e3IzYsynU1t74 X-Google-Smtp-Source: APXvYqy9rGV3C9zu4sz3hmgoMokxeIMX6gL3q7kUwD8KOjGYi0pQHIa4AvUZX5WFeaFHgWGy0fJ2iu/TPfVKdem9vv8= X-Received: by 2002:a67:c419:: with SMTP id c25mr47296662vsk.136.1560783705788; Mon, 17 Jun 2019 08:01:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 17 Jun 2019 17:01:34 +0200 Message-ID: To: Sergio Garcia Murillo Cc: dispatch@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dispatch] Dispatching WebTransport X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 15:01:50 -0000 On Mon, 17 Jun 2019 at 16:52, Sergio Garcia Murillo wrote: > > From the draft: > > WebTransport [OVERVIEW] is a protocol framework that enables clients > constrained by the Web security model to communicate with a remote > server using a secure multiplexed transport. > > > Although while I agree with your analysis regarding current webrtc dc and= sctp status, if this is a pure client-to-server transport, why is webrtc m= entioned in the background at all? shouldn't this be a replacement of webso= ckets and NOT of the webrtc datachannels? I assume WebRTC is mentioned there because currently it's the only way to have P2P data messaging in the Web. With QUIC + RTCIceTransport we have RTCQuicTransport, which can be used for P2P data messaging between browsers without depending on a WebRTC PeerConnection. So if I'm not wrong, WebTransport will provide: 1) QuicTransport, which is a QUIC based communication between the browser and a server. It may use streaming or datagram based messaging (if QUIC-datagram spec becomes real). It does not use ICE at all and. 2) RTCQuicTransport, which is a QuicTransport created with a RTCIceTransport, so suitable for two browsers to communicate in P2P fashion. And the same: QUIC streaming or datagrams. No PeerConnection here. Whether SCTP can be used or not in this new model is unclear for me. SCTP does not provide security/encryption, so SCTP packets should be put on top of DTLS (as we do in WebRTC) or on top of QUIC (so it should be QUIC-datagram to properly frame those packets) which does not make any sense since it provides nothing that QUIC-datagram already provides. --=20 I=C3=B1aki Baz Castillo From nobody Mon Jun 17 15:25:08 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E6E120094 for ; Mon, 17 Jun 2019 15:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org 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 PcZdtKHU3GHJ for ; Mon, 17 Jun 2019 15:25:03 -0700 (PDT) Received: from mailrelay1-1.pub.mailoutpod1-cph3.one.com (mailrelay1-1.pub.mailoutpod1-cph3.one.com [46.30.210.182]) (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 6CDF112004D for ; Mon, 17 Jun 2019 15:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20140924; h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=+zGj93j/EyJ4X8Eu9yHjha369xdBcujCBpT9xbLKWGc=; b=tLdBKmOq7b2Vxn9D+tJWE3IaKzXqbr/SQYeyULCK8a/hkW8KC+2x6WH/m44lapAIprfQNpwnmSfKB EXK9qj2Y8COb06/cL4NuWf1OxBaeD5Wr36NSGD8IOmDS/lgY5usVgX0HS3ZipC22g3Uzf1VSFnRVaz ZgJFAw7AdJiTmn+4= X-HalOne-Cookie: f5a728e9ecd2bccadd29708ac88708487203f378 X-HalOne-ID: be629f80-914e-11e9-bc2c-d0431ea8a283 Received: from smtp.dmfs.org (unknown [2003:5f:6e14:3c00:201:2eff:fe40:2624]) by mailrelay1.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id be629f80-914e-11e9-bc2c-d0431ea8a283; Mon, 17 Jun 2019 22:25:00 +0000 (UTC) Received: from boss.localdomain (p548B1ED8.dip0.t-ipconnect.de [84.139.30.216]) by smtp.dmfs.org (Postfix) with ESMTPSA id B55C329B for ; Tue, 18 Jun 2019 00:24:59 +0200 (CEST) To: dispatch@ietf.org References: <96bef250-7821-4a85-85f5-f9df8128e96a@www.fastmail.com> From: Marten Gajda Message-ID: <8af1f5e8-3799-7358-cc78-06c4afaaa7db@dmfs.org> Date: Tue, 18 Jun 2019 00:24:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <96bef250-7821-4a85-85f5-f9df8128e96a@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------125E05F662C0EF65EA1D6C7D" Content-Language: en-US Archived-At: Subject: Re: [dispatch] JSCalendar: Updated to draft version 01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 22:25:06 -0000 This is a multi-part message in MIME format. --------------125E05F662C0EF65EA1D6C7D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Robert, here are a few more ideas for consideration: * instead of making name components top level elements introduce an object called "structuredName" { firstName, lastName, middleName, prefix, suffix ...}. * ContactInformation -> use URIs instead of plain strings? e.g. vCard 4 prefers "tel:" URIs. Not sure if that's a good idea though. They are machine readable, but not necessarily user friendly. * Add additional kind "Resource" (i.e. projector, car …). Few years back, we had a TC Resource, not sure whether the results have been published somewhere though * Support other kinds of events (i.e. see https://tools.ietf.org/html/rfc6474, also specifies additional location types: place of birth, place of death) * Relationships (manager of, spouse of, etc), ideally linked via UID, I guess Cheers, Marten Am 07.06.19 um 13:06 schrieb Robert Stepanek: > Hi all, > > I've submitted draft version 01 of draft-stepanek-jscontact: > https://tools.ietf.org/html/draft-stepanek-jscontact > > This version is includes some, but not yet all of the feedback of > individual > reviewers as well as the CalConnect XLV meeting this week. > > Changes: > - Added a new property for full names. > - Changed the single-string name component fields to arrays. > - Added a kind property, similar to VCARD KIND. > - Added a ISO-3166-1 country code property to Address. > - Added a full address property to Address. > - Added preferredContactMethod property. > - Added geo URI and time zone properties to Address. > - Added a role property. > > There following feedback needs further consideration and I'm happy about > any input: > > Names: > - Learn more about the findings of ISO/TC 37/SC4 on naming schemes, and >   probably reuse it for JSContact. > - Current vendors such as Google and Apple already make use of >   X-PHONETIC-{FIRST,LAST}-NAME properties for phonetic names. >   It's similar to > https://tools.ietf.org/html/draft-fukuda-vcarddav-phonetic-transcription-03 > > Contact: > - Support more than one company, and consider renaming it to > affiliations or >   organizations. > - Allow for a similar property such as SORT-AS in VCARD4. > - Add categories and keywords properties, similar to JSCalendar. > - Allow for hierarchies? (group includes group? contact includes contact?) > > ContactInformation: > - Add a unique id to each ContactInformation, so that sync conflicts > can be >   better resolved.. (might want to change the contact information lists to >   JMAP-style maps, where the id is the map key). > > ContactGroup: > - List contact objects in a group, rather than their uids. If only uid > is of >   interest, the embedded contact could just define that property. > - Allow to override properties for a contact within a group. E.g. a > contact >   might override its "role" for a group that defines a project. Could use >   JSCalendar PatchObject in a property called contactOverrides. > > Address: > - consider renaming it to Location > - Learn more about ISO19160-6 for international address >   profiles. > > Other: > - Localization most probably will be only required for names and address. > - Rename either the RFC or the Contact object to JSCard for > disambiguation? > > Cheers, > Robert > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------125E05F662C0EF65EA1D6C7D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Robert,

here are a few more ideas for consideration:

* instead of making name components top level elements introduce an object called "structuredName" { firstName, lastName, middleName, prefix, suffix ...}.

* ContactInformation -> use URIs instead of plain strings? e.g. vCard 4 prefers "tel:" URIs. Not sure if that's a good idea though. They are machine readable, but not necessarily user friendly.

* Add additional kind "Resource" (i.e. projector, car …). Few years back, we had a TC Resource, not sure whether the results have been published somewhere though

* Support other kinds of events (i.e. see https://tools.ietf.org/html/rfc6474, also specifies additional location types: place of birth, place of death)

* Relationships (manager of, spouse of, etc), ideally linked via UID, I guess

Cheers,

Marten

Am 07.06.19 um 13:06 schrieb Robert Stepanek:
Hi all,

I've submitted draft version 01 of draft-stepanek-jscontact:

This version is includes some, but not yet all of the feedback of individual
reviewers as well as the CalConnect XLV meeting this week.

Changes:
- Added a new property for full names.
- Changed the single-string name component fields to arrays.
- Added a kind property, similar to VCARD KIND.
- Added a ISO-3166-1 country code property to Address.
- Added a full address property to Address.
- Added preferredContactMethod property.
- Added geo URI and time zone properties to Address.
- Added a role property.

There following feedback needs further consideration and I'm happy about
any input:

Names:
- Learn more about the findings of ISO/TC 37/SC4 on naming schemes, and
  probably reuse it for JSContact.
- Current vendors such as Google and Apple already make use of
  X-PHONETIC-{FIRST,LAST}-NAME properties for phonetic names.

Contact:
- Support more than one company, and consider renaming it to affiliations or
  organizations.
- Allow for a similar property such as SORT-AS in VCARD4.
- Add categories and keywords properties, similar to JSCalendar.
- Allow for hierarchies? (group includes group? contact includes contact?)

ContactInformation:
- Add a unique id to each ContactInformation, so that sync conflicts can be
  better resolved.. (might want to change the contact information lists to
  JMAP-style maps, where the id is the map key).

ContactGroup:
- List contact objects in a group, rather than their uids. If only uid is of
  interest, the embedded contact could just define that property.
- Allow to override properties for a contact within a group. E.g. a contact
  might override its "role" for a group that defines a project. Could use
  JSCalendar PatchObject in a property called contactOverrides.

Address:
- consider renaming it to Location
- Learn more about ISO19160-6 for international address
  profiles.

Other:
- Localization most probably will be only required for names and address.
- Rename either the RFC or the Contact object to JSCard for disambiguation?

Cheers,
Robert

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

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
--------------125E05F662C0EF65EA1D6C7D-- From nobody Tue Jun 18 07:09:35 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E6D120059 for ; Tue, 18 Jun 2019 07:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=ixPpswyo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oK/bT1ku 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 gKs_HIH00OwD for ; Tue, 18 Jun 2019 07:09:31 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F66A120046 for ; Tue, 18 Jun 2019 07:09:31 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 21A842249A for ; Tue, 18 Jun 2019 10:09:30 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 18 Jun 2019 10:09:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=flMoWLu NnItWy90TiEQRPIlCYQrGesbxer7zHSNHUjw=; b=ixPpswyo9nNrqmXW442pHfw o053prJwA0dI9YBaZcMEnYhLdFeIQlJ/wUQ8AgV8UsEdGYP2a5RQ6NZf0RJp4vEc h3vUP+z1vdQUFkGzliSxLzYOy1DOneNgiDj5pgjCEeTHvza0YkY9hJA6gzRc0A5M tphSTjq4krEY4UI0mvRORWc2Xyrm7kXqbXo/fTlGAcZY2Fn0l+L2x0WKQRggVkRV +xbEwz5y8C32h+EiCoY/yShbK6n8MJSSSJjiV9nDhDhyamNLwnCS6nMRe9LKKlX3 VphIap+5bGAn1rUg6TysqaNr/PwHUaqupElqnRqjVNIplTc3/WjUxcEQuVBv4Rg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=flMoWL uNnItWy90TiEQRPIlCYQrGesbxer7zHSNHUjw=; b=oK/bT1kuW2CuBIyqqTIFns qioG0RSrnVWFk1KamlZgj9YzKTr67O/EwB+qHsal3Ow8TBxkze26nXNKRNCfO22v Wg9u/8NrdGelQyvBLH5aU8BCsUzI0r0QzoTnm0RsHX43pvOv5pmnq+V8yu5ZNBaU 1z+UoKdBVg0dAKeHrLftJhelFdZoWraN29G3VsD16hHXPA/G7zFZOUjJJ6lFMGLP vFUohtUtrGqrNLXVkRXON2YwWaiuWZ3CjehkTnEAAMxcWnn5BE32snuyWzOjpGLT v6rvYudbyXNFZBW3JX0ap2otbBQ5QD9rDG4ii7456IPce1ZV1IcSpmx8am0e47wQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrtddtgdegvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgne curfgrrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9A8FA180784; Tue, 18 Jun 2019 10:09:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-666-gb2312fa-fmstable-20190614v4 Mime-Version: 1.0 Message-Id: <6ed41ace-0198-4e7a-8258-ca8ab06b020e@www.fastmail.com> In-Reply-To: <8af1f5e8-3799-7358-cc78-06c4afaaa7db@dmfs.org> References: <96bef250-7821-4a85-85f5-f9df8128e96a@www.fastmail.com> <8af1f5e8-3799-7358-cc78-06c4afaaa7db@dmfs.org> Date: Tue, 18 Jun 2019 16:09:29 +0200 From: "Robert Stepanek" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=d6215d3b2b554addbec340bfeebf3fb7 Archived-At: Subject: Re: [dispatch] JSCalendar: Updated to draft version 01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 14:09:34 -0000 --d6215d3b2b554addbec340bfeebf3fb7 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Marten, thanks for your input. On Tue, Jun 18, 2019, at 12:25 AM, Marten Gajda wrote: > here are a few more ideas for consideration: > * instead of making name components top level elements introduce an ob= ject called "structuredName" { firstName, lastName, middleName, prefix, = suffix ...}.=20 The reason I kept it top-level is because I deemed names as "too import= ant" for a nested property, and N properties can occur at most once in V= CARD4 (RFC6474). But checking VCARD3 (RFC 2426), I see no restriction on= cardinality. Any insight if N is safe to assume to occur only once? An = array of StructuredName that consists of string array properties would s= eem to be unnecessarily complex for the majority of uses. What would you= gain in your use cases from a StructuredName type? Mario Loffredo also pointed out to me that FN can occur more than once i= n VCARD, so fullName might also need to become an array. > * ContactInformation -> use URIs instead of plain strings? e.g. vCard = 4 prefers "tel:" URIs. Not sure if that's a good idea though. They are m= achine readable, but not necessarily user friendly. I'd rather keep plain strings, and restrict them to URIs for certain Con= tactInformation "type" and "label" combinations. > * Add additional kind "Resource" (i.e. projector, car =E2=80=A6). Few = years back, we had a TC Resource, not sure whether the results have been= published somewhere though Mario also pointed me to the "application" and "device" kinds (RFC 6473,= RFC 6869). > * Support other kinds of events (i.e. see https://tools.ietf.org/html/= rfc6474, also specifies additional location types: place of birth, place= of death) There's also death date for it. Which brings up another topic: VCARD BDA= Y and DEATHDAY allow all of the following values: BDAY:19960415 BDAY:--0415 BDAY;19531015T231000Z BDAY;VALUE=3Dtext:circa 1800 in JSCalendar we require them to be formatted as "YYYY-MM-DD" where any = part may be 0s for unknowns. We could at least allow "YYYY-MM-DD" and "Y= YYY-MM-DDTHH:MM:SSZ" where any date part can be 0 for unknowns, and the = time part omitted, if unknown. > * Relationships (manager of, spouse of, etc), ideally linked via UID, = I guess Yes, we could use a structured similar to the JSCalendar "relatedTo" pro= perty (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-14#secti= on-4.1.3) Cheers, Robert --d6215d3b2b554addbec340bfeebf3fb7 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Marten,=

thanks for your input.

<= /div>
On Tue, Jun 18, 2019, at 12:25 AM, Marten Gajda wrote:

here are a few more ideas for c= onsideration:

* instead of making name components top level el= ements introduce an object called "structuredName" { firstName, lastName, middleName, prefix, suffix ...}.


The reason I kept it top-level is because I deemed names as "to= o important" for a nested property, and  N properties can occur at = most once in VCARD4 (RFC6474). But checking VCARD3 (RFC 2426), I see no = restriction on cardinality. Any insight if N is safe to assume to occur = only once? An array of StructuredName that consists of string array prop= erties would seem to be unnecessarily complex for the majority of uses. = What would you gain in your use cases from a StructuredName type?

Mario Loffredo also pointed out to me that FN can= occur more than once in VCARD, so fullName might also need to become an= array.

*= ContactInformation -> use URIs instead of plain strings? e.g. vCard 4 prefers "tel:" URIs. Not sure if that's a good idea though. They are machine readable, but not necessarily user friendly.


I'd rather keep = plain strings, and restrict them to URIs for certain ContactInformation = "type" and "label" combinations.

* Add additional kind "Resource" (i.e. projector= , car =E2=80=A6). Few years back, we had a TC Resource, not sure whether the results have been published somewhere though


=
Mario also pointed me to the "application" and "device" kinds= (RFC 6473, RFC 6869).

* Support other kinds of events (i.e. see https= ://tools.ietf.org/html/rfc6474, also specifies additional location types: place of birth, place of death)


There's also death date for it. Which brings up an= other topic: VCARD BDAY and DEATHDAY allow all of the following values:<= br>

       &= nbsp;     BDAY:19960415
  &n= bsp;          BDAY:--0415
          = ;   BDAY;19531015T231000Z
   &nbs= p;         BDAY;VALUE=3Dtext:cir= ca 1800

in JSCalendar we require them to be= formatted as "YYYY-MM-DD" where any part may be 0s for unknowns. We cou= ld at least allow "YYYY-MM-DD" and "YYYY-MM-DDTHH:MM:SSZ" where any date= part can be 0 for unknowns, and the time part omitted, if unknown.
<= /div>

* Relationshi= ps (manager of, spouse of, etc), ideally linked via UID, I guess


Yes, we could= use a structured similar to the JSCalendar "relatedTo" property (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-14#sect= ion-4.1.3)

Cheers,
Robert=
--d6215d3b2b554addbec340bfeebf3fb7-- From nobody Tue Jun 18 15:04:27 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDF71202E8 for ; Tue, 18 Jun 2019 15:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.508 X-Spam-Level: X-Spam-Status: No, score=-17.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxykYFbTDoki for ; Tue, 18 Jun 2019 15:04:22 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D561202D4 for ; Tue, 18 Jun 2019 15:04:21 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id s21so1114886lji.8 for ; Tue, 18 Jun 2019 15:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ol0q4l1MBHNWsSjPwnm+06s2hxtrsOP7X9ZzYbFT+4A=; b=s5+1UYwKJjf7gNlzI2NA2BEnJ0ICmgV6gRwk+i1TOBj5IKR5A+cSzhbPQzJhCotG/v qgbfDSk37RccDoo1yiX72qeaBvaZnA+CBmHcaQSaiLxLg9UkYPZY9Sqz2No6dwOzhXeU 2SUcReRulXwyAKZtBNBbitiQCkrr5ChNTkpp36G2LqypGG54EBTToBqB9/UkwTu8CPQb FcRPJZWjwghrK9fZUE5Fw2ljxgs8//zqL6kEU7xicQNbUAXZsCcs41fxdxeoDrKPSZ6j lTQMxNtAidqUKqf1AGDAdOj3EJYBb7q9qimoD8DjokOas56NtIPA6JA1if7BKXEZpOa9 FHGw== 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=ol0q4l1MBHNWsSjPwnm+06s2hxtrsOP7X9ZzYbFT+4A=; b=d7W+xr8f+Sy4XnZxXLqVkoplzjQEEmkoAqHY3RtGtLDmuJ9cK7DX18QCWqYHySKq1I HA1D0fNsdBRyXqMnzywqI2PZ/M2S6FJtBnK3pnn+icUh6+3GGcrBjAvcYDjj67mm1mWk CSJNJTMxBgxrMam0GwiubiTnynX9Bggrwt6+YaI52EA3zqXPNWYScc9NdiZ/ld8CYF+h CueRjB15KemxY+QfNWd5FugTGhwLcklKU8tlpcpHFChvQW0W03mPqZlprSrIdQU24rMj 4cC/k13rjX0GKSTVm6mpfzBAYUVAyUmQHSZDgzycwp8BjDCYynNbDq53+uQpNIMzl2Rd Maqg== X-Gm-Message-State: APjAAAXwV6C6WwpSx4weO/+DWlwmFyqQB7778QyyF/F07lPNP/pRQSGT kPQ/hPqZqkjTRDNG/vSY5aPwcO6S+HezJrCS03U9yg== X-Google-Smtp-Source: APXvYqzPgGKokmU1EvRF4nwGdmAWtESp01id2HokRZVPEcOM1GRfeForI3lDOB6B4bXPdxdrsELcEC5n3j1pPAX2Iyw= X-Received: by 2002:a2e:80d6:: with SMTP id r22mr2054794ljg.83.1560895459264; Tue, 18 Jun 2019 15:04:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Victor Vasiliev Date: Tue, 18 Jun 2019 18:04:07 -0400 Message-ID: To: Paul Kyzivat Cc: dispatch@ietf.org Content-Type: multipart/alternative; boundary="00000000000061d445058ba04b17" Archived-At: Subject: Re: [dispatch] Dispatching WebTransport X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 22:04:26 -0000 --00000000000061d445058ba04b17 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That is definitely one of the things at the core of the problem; however, that is a symptom, rather than a root cause. The question here is not about existence of any single library, but rather about a viable ecosystem. WebSocket definitely has one ([0], [1]), and RtcDataChannel does not, nor it appears on track of getting one any time soon. The hope here is that WebTransport will get one by virtue of removing a whole bunch of complexity not required in the client-server case (SDP and ICE), and piggybacking on the QUIC ecosystem for the rest. [0] https://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations [1] https://github.com/facundofarias/awesome-websockets On Mon, Jun 17, 2019 at 10:34 AM Paul Kyzivat wrote= : > ISTM that your problem description below boils down to: > > There isn't a suitable library that provides a convenient interface to > use data channels. > > So why don't you concentrate on creating such a library? > > Thanks, > Paul > > On 6/17/19 9:35 AM, Victor Vasiliev wrote: > > Hello friendly IETF dispatchers, > > > > I am writing about new work I want to bring to IETF. The proposal is > > called WebTransport. It=E2=80=99s a combination of a Web API currently= under > > development in W3C WICG [0], a protocol framework and some protocols > > that fit into that framework. Combined, they would allow web > > applications to establish WebSocket-like connections that instead of > > ordered reliable messages use multiple streams and datagrams (datagrams > > are unreliable and streams do not have head-of-line blocking). This is > > highly useful for real-time and other latency sensitive applications. > > > > # Background > > > > Historically, the only networking operations available to the Web > > applications were sending HTTP requests and receiving HTTP responses. > > That model does not fit all applications well, so over time, more > > mechanisms were added. The two most relevant here are WebSockets (RFC > > 6455) and RTC Data Channels (draft-ietf-rtcweb-data-channel). > > WebSockets are a way for Web applications to do bidirectional > > communication over a TCP connection; they work great if TCP fits your > > transport needs, but perform poorly if your application is latency > > sensitive and would, in non-Web context, use a UDP-based protocol. > > There are many different kinds of applications like that, but I would > > like to highlight two major categories which I to some extent surveyed > > when coming up with this proposal: > > > > 1. Custom client-server chat/multimedia protocols (faster-than-DASH > > video streaming, game streaming, etc). Those are usually developed > > by teams with a good amount of resources, and they are interested i= n > > tailoring the setup for their use case. > > 2. Game developers. Online games are commonly real-time in nature and > > benefit dramatically from ability to give up on transmitting old > > information. They usually use some in-house UDP-based protocol, an= d > > often need to run on unusual platforms. > > > > WebRTC Data Channels are a mechanism that provides a WebSocket-like > > interface with unreliable delivery features. On the wire, it=E2=80=99s > > SCTP-over-DTLS, established using ICE and SDP. In theory, this provide= s > > users with enough functionality to build anything they need, since SCTP > > messages can be unreliable and unordered. In practice, while > > RtcDataChannel is fairly straightforward to use for browser-to-browser > > peer-to-peer communication, it has seen much lower adoption than > > WebSockets in the client-server scenario, even considering the fact tha= t > > its use cases is naturally more niche. > > > > The main reason for this is the incredible complexity of the WebRTC > > stack. WebSockets are a fairly straightforward overlay on top of TCP > > and TLS; there is a wide variety of implementations out there, and it's > > fairly easy to write a new one (I wrote on myself in less than 1,000 > > lines of C++). With data channels, however, once there is no browser t= o > > abstract all of the complexity away, the web developers are required to > > understand and implement (or at least integrate) SDP, ICE, STUN, DTLS > > and userspace SCTP. While a lot of those have simplifications for this > > use case (ICE Lite) and some protocols listed have a variety of > > implementations widely available (DTLS), the entire system still > > requires going through hundreds of pages of RFCs in order to understand > > it well enough to implement. This complexity barrier has precluded Dat= a > > Channel adoption by communities of smaller developers who don=E2=80=99t= have > > resources to implement them, notably game developers (see [1] and [2] > > for some discussion). > > > > Even among the people who got past the complexity barrier, the feedback > > I heard almost universally is that WebRTC Data Channels are hard to wor= k > > with. From the feedback I gathered, the main problem is usually around > > the transport protocol itself. Userspace SCTP is essentially a > > monoculture: virtually all implementations use libusrsctp, a 80,000-lin= e > > adaptation of FreeBSD SCTP implementation. This lack of tool choice is > > fairly painful since latency-sensitive real-time applications often > > require quite a bit of tuning on the transport side to get the best > > performance (custom congestion control, etc). In addition, the > > limitations on the message size stemming from both the API itself and > > the lack of widespread support for message interleaving (RFC 8260) mean= s > > that the developers have to roll their own framing on top of SCTP > > messages if they want to avoid head-of-line-blocking (this is > > particularly bad because the framing overhead in data channels is > > already large as-is). > > > > In summary, we have a system that technically provides what everyone > > wants, but that nobody is happy with, and that is not usable by all but > > the most well-resourced users. > > > > # Proposal > > > > Our initial idea for fixing this was to take QUIC and do what WebSocket > > did to TCP: add security features that would make it safe to expose on > > the Web (by adding origin checks, etc), but otherwise expose it as-is. > > This would get us out of libusrsctp monoculture (QUIC is not yet > > finished, but it already has a fairly diverse implementation ecosystem= , > > see [3]), and remove all P2P-related complexity involving SDP and ICE. > > The original proposal for that was called QuicTransport; we showed it t= o > > various people, and the feedback we got is that (1) the API should not > > be tied to a particular transport (since we already switched once from > > SCTP to QUIC, tying it to QUIC specificially would not be wise), and (2= ) > > it shouldn=E2=80=99t fail hard when QUIC is unavailable. > > > > As a result of that feedback, we abstracted it into a general-purpose > > framework called WebTransport. The overview draft, > > > > https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 > > > > describes the framework itself, mainly the requirements the transport > > protocols have to satisfy to be usable on the web through the API. > > Within this framework, we propose the following protocols: > > > > * QuicTransport -- a simple WebSocket-like adaptation of QUIC, > > described in > https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 > > * Http3Transport -- a mechanism that allows creating custom non-HTTP > > streams within an HTTP/3 session, described in > > https://tools.ietf.org/html/draft-vvv-webtransport-http3-00. This > > is sort of a version of RFC 8441 for QuicTransport. > > * FallbackTransport -- a TCP-based transport with multiplexed streams > > that can be used when QUIC is not available (e.g. on network that > > require CONNECT proxy). We don=E2=80=99t have a draft specifically= for > > this, and there are at least two approaches we could take here: > > either reusing HTTP/2 as a transport (i.e. just use > > draft-kinnear-httpbis-http2-transport), or building a protocol with > > QUIC-like semantics on top of WebSockest. The earlier is a more > > straightforward way; the latter has the advantage of being fully > > polyfillable in JavaScript. > > > > > > # Discussion > > > > At this point, I am fairly certain that there is a problem here that > > needs to be addressed. I am formally requesting ART area to take this > > problem on. > > > > I believe the drafts above would be a good starting point for > > discussion. The design that they describe went through several > > iterations based on the feedback I got when I discussed this work withi= n > > a more narrow audience (mostly people in QUIC working group), so we=E2= =80=99re > > hopefully at least looking in the right direction here. I am requestin= g > > feedback on this proposal, both on the overall plan and the specifics > > described in the drafts. I hope to discuss this in depth in Montreal, > > both at dispatch and (in more depth) at a side-meeting. > > > > Thanks, > > Victor. > > > > [0] https://github.com/WICG/web-transport > > [1] https://discourse.wicg.io/t/webtransport-proposal/3508/9 > > [2] https://news.ycombinator.com/item?id=3D13266692 > > [3] https://github.com/quicwg/base-drafts/wiki/Implementations > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000061d445058ba04b17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That is definitely one of the things at the core of the pr= oblem; however, that is a symptom, rather than a root cause.

=
The question here is not about existence of any single library, but ra= ther about a viable ecosystem.=C2=A0 WebSocket definitely has one ([0], [1]= ), and RtcDataChannel does not, nor it appears on track of getting one any = time soon.=C2=A0 The hope here is that WebTransport will get one by virtue = of removing a whole bunch of complexity not required in the client-server c= ase (SDP and ICE), and piggybacking on the=C2=A0QUIC ecosystem for the rest= .


On Mon, Jun 17, 2019 at 10:34 AM Paul K= yzivat <pkyzivat@alum.mit.edu> wrote:
IS= TM that your problem description below boils down to:

There isn't a suitable library that provides a convenient interface to =
use data channels.

So why don't you concentrate on creating such a library?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

On 6/17/19 9:35 AM, Victor Vasiliev wrote:
> Hello friendly IETF dispatchers,
>
> I am writing about new work I want to bring to IETF.=C2=A0 The proposa= l is
> called WebTransport.=C2=A0 It=E2=80=99s a combination of a Web API cur= rently under
> development in W3C WICG [0], a protocol framework and some protocols <= br> > that fit into that framework.=C2=A0 Combined, they would allow web > applications to establish WebSocket-like connections that instead of <= br> > ordered reliable messages use multiple streams and datagrams (datagram= s
> are unreliable and streams do not have head-of-line blocking).=C2=A0 T= his is
> highly useful for real-time and other latency sensitive applications.<= br> >
> # Background
>
> Historically, the only networking operations available to the Web
> applications were sending HTTP requests and receiving HTTP responses.= =C2=A0
> That model does not fit all applications well, so over time, more
> mechanisms were added.=C2=A0 The two most relevant here are WebSockets= (RFC
> 6455) and RTC Data Channels (draft-ietf-rtcweb-data-channel).=C2=A0 > WebSockets are a way for Web applications to do bidirectional
> communication over a TCP connection; they work great if TCP fits your =
> transport needs, but perform poorly if your application is latency > sensitive and would, in non-Web context, use a UDP-based protocol.=C2= =A0
> There are many different kinds of applications like that, but I would =
> like to highlight two major categories which I to some extent surveyed=
> when coming up with this proposal:
>
>=C2=A0 1. Custom client-server chat/multimedia protocols (faster-than-D= ASH
>=C2=A0 =C2=A0 =C2=A0video streaming, game streaming, etc).=C2=A0 Those = are usually developed
>=C2=A0 =C2=A0 =C2=A0by teams with a good amount of resources, and they = are interested in
>=C2=A0 =C2=A0 =C2=A0tailoring the setup for their use case.
>=C2=A0 2. Game developers.=C2=A0 Online games are commonly real-time in= nature and
>=C2=A0 =C2=A0 =C2=A0benefit dramatically from ability to give up on tra= nsmitting old
>=C2=A0 =C2=A0 =C2=A0information.=C2=A0 They usually use some in-house U= DP-based protocol, and
>=C2=A0 =C2=A0 =C2=A0often need to run on unusual platforms.
>
> WebRTC Data Channels are a mechanism that provides a WebSocket-like > interface with unreliable delivery features.=C2=A0 On the wire, it=E2= =80=99s
> SCTP-over-DTLS, established using ICE and SDP.=C2=A0 In theory, this p= rovides
> users with enough functionality to build anything they need, since SCT= P
> messages can be unreliable and unordered.=C2=A0 In practice, while > RtcDataChannel is fairly straightforward to use for browser-to-browser=
> peer-to-peer communication, it has seen much lower adoption than
> WebSockets in the client-server scenario, even considering the fact th= at
> its use cases is naturally more niche.
>
> The main reason for this is the incredible complexity of the WebRTC > stack.=C2=A0 WebSockets are a fairly straightforward overlay on top of= TCP
> and TLS; there is a wide variety of implementations out there, and it&= #39;s
> fairly=C2=A0easy to write a new one (I wrote on myself in less than 1,= 000
> lines of C++).=C2=A0 With data channels, however, once there is no bro= wser to
> abstract all of the complexity away, the web developers are required t= o
> understand and implement (or at least integrate) SDP, ICE, STUN, DTLS =
> and userspace SCTP.=C2=A0 While a lot of those have simplifications fo= r this
> use case (ICE Lite) and some protocols listed have a variety of
> implementations widely available (DTLS), the entire system still
> requires going through hundreds of pages of RFCs in order to understan= d
> it well enough to implement.=C2=A0 This complexity barrier has preclud= ed Data
> Channel adoption by communities of smaller developers who don=E2=80=99= t have
> resources to implement them, notably game developers (see [1] and [2] =
> for some discussion).
>
> Even among the people who got past the complexity barrier, the feedbac= k
> I heard almost universally=C2=A0is that WebRTC Data Channels are hard = to work
> with.=C2=A0 From the feedback I gathered, the main problem is usually = around
> the transport protocol itself.=C2=A0 Userspace SCTP is essentially a <= br> > monoculture: virtually all implementations use libusrsctp, a 80,000-li= ne
> adaptation of FreeBSD SCTP implementation.=C2=A0 This lack of tool cho= ice is
> fairly painful since latency-sensitive real-time applications often > require quite a bit of tuning on the transport side to get the best > performance (custom congestion control, etc).=C2=A0 In addition, the <= br> > limitations on the message size stemming from both the API itself and =
> the lack of widespread support for message interleaving (RFC 8260) mea= ns
> that the developers have to roll their own framing on top of SCTP
> messages if they want to avoid head-of-line-blocking (this is
> particularly bad because the framing overhead in data channels is
> already large as-is).
>
> In summary, we have a system that technically provides what everyone <= br> > wants, but that nobody is happy with, and that is not usable by all bu= t
> the most well-resourced users.
>
> # Proposal
>
> Our initial idea for fixing this was to take QUIC and do what WebSocke= t
> did to TCP: add security features that would make it safe to expose on=
> the Web (by adding origin checks, etc), but otherwise expose it as-is.= =C2=A0
> This would get us out of libusrsctp monoculture (QUIC is not yet
> finished, but=C2=A0 it=C2=A0already has a fairly diverse implementatio= n ecosystem,
> see [3]), and remove all P2P-related complexity involving SDP and ICE.= =C2=A0
> The original proposal for that was called QuicTransport; we showed it = to
> various people, and the feedback we got is that (1) the API should not=
> be tied to a particular transport (since we already switched once from=
> SCTP to QUIC, tying it to QUIC specificially would not be wise), and (= 2)
> it shouldn=E2=80=99t fail hard when QUIC is unavailable.
>
> As a result of that feedback, we abstracted it into a general-purpose =
> framework called WebTransport.=C2=A0 The overview draft,
>
> https://tools.ietf.org/html/draft= -vvv-webtransport-overview-00
>
> describes the framework itself, mainly the requirements the transport =
> protocols have to satisfy to be usable on the web through the API.=C2= =A0
> Within this framework, we propose the following protocols:
>
>=C2=A0 =C2=A0* QuicTransport -- a simple WebSocket-like adaptation of Q= UIC,
>=C2=A0 =C2=A0 =C2=A0described in https= ://tools.ietf.org/html/draft-vvv-webtransport-quic-00
>=C2=A0 =C2=A0* Http3Transport -- a mechanism that allows creating custo= m non-HTTP
>=C2=A0 =C2=A0 =C2=A0streams within an HTTP/3 session, described in
>=C2=A0 =C2=A0 =C2=A0https://tools.iet= f.org/html/draft-vvv-webtransport-http3-00.=C2=A0 This
>=C2=A0 =C2=A0 =C2=A0is sort of a version of RFC 8441 for QuicTransport.=
>=C2=A0 =C2=A0* FallbackTransport -- a TCP-based transport with multiple= xed streams
>=C2=A0 =C2=A0 =C2=A0that can be used when QUIC is not available (e.g. o= n network that
>=C2=A0 =C2=A0 =C2=A0require CONNECT proxy).=C2=A0 We don=E2=80=99t have= a draft specifically for
>=C2=A0 =C2=A0 =C2=A0this, and there are at least two approaches we coul= d take here:
>=C2=A0 =C2=A0 =C2=A0either reusing HTTP/2 as a transport (i.e. just use=
>=C2=A0 =C2=A0 =C2=A0draft-kinnear-httpbis-http2-transport), or building= a protocol with
>=C2=A0 =C2=A0 =C2=A0QUIC-like semantics on top of WebSockest.=C2=A0 The= earlier is a more
>=C2=A0 =C2=A0 =C2=A0straightforward way; the latter has the advantage o= f being fully
>=C2=A0 =C2=A0 =C2=A0polyfillable in JavaScript.
>
>
> # Discussion
>
> At this point, I am fairly certain that there is a problem here that <= br> > needs to be addressed.=C2=A0 I am formally requesting ART area to take= this
> problem on.
>
> I believe the drafts above would be a good starting point for
> discussion.=C2=A0 The design that they describe went through several <= br> > iterations based on the feedback I got when I discussed this work with= in
> a more narrow audience (mostly people in QUIC working group), so we=E2= =80=99re
> hopefully at least looking in the right direction here.=C2=A0 I am req= uesting
> feedback on this proposal, both on the overall plan and the specifics =
> described in the drafts.=C2=A0 I hope to discuss this in depth in Mont= real,
> both at dispatch and (in more depth) at a side-meeting.
>
> Thanks,
>=C2=A0 =C2=A0 Victor.
>
> [0] https://github.com/WICG/web-transport
> [1] https://discourse.wicg.io/t/webtran= sport-proposal/3508/9
> [2] https://news.ycombinator.com/item?id=3D13266= 692
> [3] https://github.com/quicwg/base-dr= afts/wiki/Implementations
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000061d445058ba04b17-- From nobody Tue Jun 18 15:04:41 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD38A120457 for ; Tue, 18 Jun 2019 15:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=dmfs.org 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 KlYHcn9cWNO6 for ; Tue, 18 Jun 2019 15:04:30 -0700 (PDT) Received: from mailrelay2-1.pub.mailoutpod1-cph3.one.com (mailrelay2-1.pub.mailoutpod1-cph3.one.com [46.30.210.183]) (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 892B512042F for ; Tue, 18 Jun 2019 15:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20140924; h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=0qvY/eRsv+rgUkPrmtInA3rUNFggwWflM+XXZVZBP0M=; b=FoGJ8pmaob47cXU5ZjXgjjt/xgWaCQjQDVO/z6kIWxrWABHBW84MZfgx+caZLJvFgDuyJFKvlDU9o +KhdWarA2VKA7wLHJAoCF7sl+vihozIUEZr3j2n/qYKP0LXMNT6kejTGTHl2KfCNHOSX6+jPWfzBqs jRLWCYrRTMeB3hiE= X-HalOne-Cookie: e843e4ae66ba164a51a114bdc8092c859d3f8876 X-HalOne-ID: 09094523-9215-11e9-b9a7-d0431ea8a290 Received: from smtp.dmfs.org (unknown [2003:5f:6e14:3c00:201:2eff:fe40:2624]) by mailrelay2.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 09094523-9215-11e9-b9a7-d0431ea8a290; Tue, 18 Jun 2019 22:04:25 +0000 (UTC) Received: from boss.localdomain (p548B1ED8.dip0.t-ipconnect.de [84.139.30.216]) by smtp.dmfs.org (Postfix) with ESMTPSA id 5891B377 for ; Wed, 19 Jun 2019 00:04:25 +0200 (CEST) To: dispatch@ietf.org References: <96bef250-7821-4a85-85f5-f9df8128e96a@www.fastmail.com> <8af1f5e8-3799-7358-cc78-06c4afaaa7db@dmfs.org> <6ed41ace-0198-4e7a-8258-ca8ab06b020e@www.fastmail.com> From: Marten Gajda Message-ID: <8d11eb06-07cb-2de6-3d43-e2f0d6c3b1ac@dmfs.org> Date: Wed, 19 Jun 2019 00:04:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <6ed41ace-0198-4e7a-8258-ca8ab06b020e@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------386C79B2E1BA4F06E7839011" Content-Language: en-US Archived-At: Subject: Re: [dispatch] JSCalendar: Updated to draft version 01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 22:04:39 -0000 This is a multi-part message in MIME format. --------------386C79B2E1BA4F06E7839011 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Am 18.06.19 um 16:09 schrieb Robert Stepanek: > What would you gain in your use cases from a StructuredName type? Mostly a cleaner data model. > > Mario Loffredo also pointed out to me that FN can occur more than once > in VCARD, so fullName might also need to become an array. I've never seen a vCard with more than one N or FN property. Since a single FN is the normal case we could use a plain string for the name and put only the additional names into an array: {     "name": "default formatted name goes here",     "additionalNames": ["other formatted names", "go into this array"],     … } or maybe join this with the nickname fields and give the names a label {     "name": "default formatted name goes here",     "aliases": {         "formatted": "other formatted name",         "nickname": "nick"     },     … } Just thinking out loud here > >> * ContactInformation -> use URIs instead of plain strings? e.g. vCard >> 4 prefers "tel:" URIs. Not sure if that's a good idea though. They >> are machine readable, but not necessarily user friendly. >> > > I'd rather keep plain strings, and restrict them to URIs for certain > ContactInformation "type" and "label" combinations. how about supporting both? {     "name": "John Doe",     "phones": [{         "type": "home",         "value": "+1234567890",         "href": "tel:+1-234-567-890"     }] } A client which doesn't support both is supposed to remove the other one when it updates either. Cheers, Marten > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------386C79B2E1BA4F06E7839011 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Am 18.06.19 um 16:09 schrieb Robert Stepanek:
What would you gain in your use cases from a StructuredName type?
Mostly a cleaner data model.

Mario Loffredo also pointed out to me that FN can occur more than once in VCARD, so fullName might also need to become an array.

I've never seen a vCard with more than one N or FN property. Since a single FN is the normal case we could use a plain string for the name and put only the additional names into an array:

{
    "name": "default formatted name goes here",
    "additionalNames": ["other formatted names", "go into this array"],
    …
}

or maybe join this with the nickname fields and give the names a label

{
    "name": "default formatted name goes here",
    "aliases": {
        "formatted": "other formatted name",
        "nickname": "nick"
    },
    …
}

Just thinking out loud here


* ContactInformation -> use URIs instead of plain strings? e.g. vCard 4 prefers "tel:" URIs. Not sure if that's a good idea though. They are machine readable, but not necessarily user friendly.


I'd rather keep plain strings, and restrict them to URIs for certain ContactInformation "type" and "label" combinations.

how about supporting both?

{
    "name": "John Doe",
    "phones": [{
        "type": "home",
        "value": "+1234567890",
        "href": "tel:+1-234-567-890"
    }]
}

A client which doesn't support both is supposed to remove the other one when it updates either.

Cheers,

Marten

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

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
--------------386C79B2E1BA4F06E7839011-- From nobody Wed Jun 19 01:03:14 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2C91200F1 for ; Wed, 19 Jun 2019 01:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 DkrUbmEJIGy5 for ; Wed, 19 Jun 2019 01:03:09 -0700 (PDT) Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.98.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BCB1200FA for ; Wed, 19 Jun 2019 01:03:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 30CB8B8051D; Wed, 19 Jun 2019 10:03:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mx4.iit.cnr.it Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx4.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX286cMdNUGt; Wed, 19 Jun 2019 10:03:03 +0200 (CEST) Received: from [192.12.193.108] (pc-loffredo.nic.it [192.12.193.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id 0A2A0B801F5; Wed, 19 Jun 2019 10:03:03 +0200 (CEST) To: Marten Gajda , dispatch@ietf.org References: <96bef250-7821-4a85-85f5-f9df8128e96a@www.fastmail.com> <8af1f5e8-3799-7358-cc78-06c4afaaa7db@dmfs.org> <6ed41ace-0198-4e7a-8258-ca8ab06b020e@www.fastmail.com> <8d11eb06-07cb-2de6-3d43-e2f0d6c3b1ac@dmfs.org> From: Mario Loffredo Message-ID: <7877562f-55fc-3fa4-00af-01170c3db993@iit.cnr.it> Date: Wed, 19 Jun 2019 10:02:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <8d11eb06-07cb-2de6-3d43-e2f0d6c3b1ac@dmfs.org> Content-Type: multipart/alternative; boundary="------------7EE48B250E400B9FC6B7083C" Content-Language: it Archived-At: Subject: Re: [dispatch] JSCalendar: Updated to draft version 01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 08:03:12 -0000 This is a multi-part message in MIME format. --------------7EE48B250E400B9FC6B7083C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Marten, Il 19/06/2019 00:04, Marten Gajda ha scritto: > > > Am 18.06.19 um 16:09 schrieb Robert Stepanek: >> What would you gain in your use cases from a StructuredName type? > Mostly a cleaner data model. >> >> Mario Loffredo also pointed out to me that FN can occur more than >> once in VCARD, so fullName might also need to become an array. > > I've never seen a vCard with more than one N or FN property. Since a > single FN is the normal case we could use a plain string for the name > and put only the additional names into an array: > > { >     "name": "default formatted name goes here", >     "additionalNames": ["other formatted names", "go into this array"], >     … > } > This case is not unusual in the context of both Domain Name Registries and Regional Internet Registries. The contact information about name and address can be either structured or unstructured and can be provided in multilingual form. In jCard, it is possible to do that. In my opinion, jscontact should do likewise. Cheers, mario > or maybe join this with the nickname fields and give the names a label > > { >     "name": "default formatted name goes here", >     "aliases": { >         "formatted": "other formatted name", >         "nickname": "nick" >     }, >     … > } > > Just thinking out loud here > >> >>> * ContactInformation -> use URIs instead of plain strings? e.g. >>> vCard 4 prefers "tel:" URIs. Not sure if that's a good idea though. >>> They are machine readable, but not necessarily user friendly. >>> >> >> I'd rather keep plain strings, and restrict them to URIs for certain >> ContactInformation "type" and "label" combinations. > > how about supporting both? > > { >     "name": "John Doe", >     "phones": [{ >         "type": "home", >         "value": "+1234567890", >         "href": "tel:+1-234-567-890" >     }] > } > > A client which doesn't support both is supposed to remove the other > one when it updates either. > > Cheers, > > Marten > >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > -- > Marten Gajda > CEO > > dmfs GmbH > Schandauer Straße 34 > 01309 Dresden > GERMANY > > phone: +49 177 4427167 > email:marten@dmfs.org > > Managing Director: Marten Gajda > Registered address: Dresden > Registered No.: AG Dresden HRB 34881 > VAT Reg. No.: DE303248743 > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Dr. Mario Loffredo Servizi Internet e Sviluppo Tecnologico CNR - Istituto di Informatica e Telematica via G. Moruzzi 1, I-56124 PISA, Italy E-Mail: mario.loffredo@iit.cnr.it Phone: +39.0503153497 Web: http://www.iit.cnr.it/mario.loffredo --------------7EE48B250E400B9FC6B7083C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Marten,


Il 19/06/2019 00:04, Marten Gajda ha scritto:


Am 18.06.19 um 16:09 schrieb Robert Stepanek:
What would you gain in your use cases from a StructuredName type?
Mostly a cleaner data model.

Mario Loffredo also pointed out to me that FN can occur more than once in VCARD, so fullName might also need to become an array.

I've never seen a vCard with more than one N or FN property. Since a single FN is the normal case we could use a plain string for the name and put only the additional names into an array:

{
    "name": "default formatted name goes here",
    "additionalNames": ["other formatted names", "go into this array"],
    …
}

This case is not unusual in the context of both Domain Name Registries and Regional Internet Registries. The contact information about name and address can be either structured or unstructured and can be provided in multilingual form.

In jCard, it is possible to do that. In my opinion, jscontact should do likewise.


Cheers,

mario

or maybe join this with the nickname fields and give the names a label

{
    "name": "default formatted name goes here",
    "aliases": {
        "formatted": "other formatted name",
        "nickname": "nick"
    },
    …
}

Just thinking out loud here


* ContactInformation -> use URIs instead of plain strings? e.g. vCard 4 prefers "tel:" URIs. Not sure if that's a good idea though. They are machine readable, but not necessarily user friendly.


I'd rather keep plain strings, and restrict them to URIs for certain ContactInformation "type" and "label" combinations.

how about supporting both?

{
    "name": "John Doe",
    "phones": [{
        "type": "home",
        "value": "+1234567890",
        "href": "tel:+1-234-567-890"
    }]
}

A client which doesn't support both is supposed to remove the other one when it updates either.

Cheers,

Marten

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

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743

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

-- 
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: mario.loffredo@iit.cnr.it
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
--------------7EE48B250E400B9FC6B7083C-- From nobody Wed Jun 19 07:37:06 2019 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0741205FB; Wed, 19 Jun 2019 07:36:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dispatch@ietf.org Message-ID: <156095501837.12249.8273572558395598316@ietfa.amsl.com> Date: Wed, 19 Jun 2019 07:36:58 -0700 Archived-At: Subject: [dispatch] I-D Action: draft-ietf-dispatch-javascript-mjs-04.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 14:36:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dispatch WG of the IETF. Title : ECMAScript Media Types Updates Authors : Myles Borins Mathias Bynens Matthew A. Miller Bradley Farias Filename : draft-ietf-dispatch-javascript-mjs-04.txt Pages : 20 Date : 2019-06-19 Abstract: This document proposes updates to the ECMAScript media types, superseding the existing registrations for "application/javascript" and "text/javascript" by adding an additional extension and removing usage warnings. This document updates RFC4329, "Scripting Media Types". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dispatch-javascript-mjs-04 https://datatracker.ietf.org/doc/html/draft-ietf-dispatch-javascript-mjs-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dispatch-javascript-mjs-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 19 07:42:45 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9901A120046 for ; Wed, 19 Jun 2019 07:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVSUP83nSz82 for ; Wed, 19 Jun 2019 07:42:40 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 8368C120041 for ; Wed, 19 Jun 2019 07:42:40 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id i34so14875665qta.6 for ; Wed, 19 Jun 2019 07:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PlitUYfomupR8nY88Bqq+/l1o/TJFArxdn3nPBwy2X8=; b=hUYPtP/JGHO//O4Y8Q091B0f4bbqB8qzB+0La5Z3ESHCUH5N3dkCV28614eRyO1H2T OMk5ULfph9wJjcXaugpyQE2ovBRxfw+LC5r7yNO/yIl77HRNFt8ZYKG7MBKnF4wfOuwF N6XOvYRVP1fhepW/bZEuuoDP/g8KKrWaTT40H0no93kvlEC85sh+XbgwvA3XioKxfeA5 wQjY83op6sahB8J7McKMRUUvm3Gae8fsvvgLnBatqeqfsGK6Rv54VSiddQTxng5QMnHk wg3sCg0RwVYC3iZLM7um+2FmlTOer7vXYTcFZ6HGOU6Pq7cUWLmSbyklc8l794uy4Zpp SLVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PlitUYfomupR8nY88Bqq+/l1o/TJFArxdn3nPBwy2X8=; b=UwhLMBHTPcWLbCoJisXPyWIweDwqVr/VA7IE6pS/XBAYefbmEMEBPykOwLZEb8SiOL lpezqxxW0YZXtoiwqFL7uFZmkjS0e77saRCbKR6dSrI4naZ1EMicLSnra8jMiJFYfgn2 VKbUFRGKH/uiST47d6n0sXH6u98lW+ZDZFkWztVKuYxyXz/7FEEW+40/LUENFZUkhKwh ahnyrXAFam5KLv0tI3FxDWIMwh2PramuFcvFjqdmyQIotRsDefniH+O73oFMOsO9YZ2x iuUxlccOM2KIwyJf9PNwKtMEhHdCTcFznF0s+fFAh+qUzCYW14o47de5v7eh1NMinnE6 fTnQ== X-Gm-Message-State: APjAAAVRw23/eC1vxx8e2Gn4/b4y3mpqOje8Io28greBT5pFyl88uriM 2xpQBMEGc+b6wNHfJ+gxvtKhWA== X-Google-Smtp-Source: APXvYqwN1MrD5cJqeHfSzxp+n99mWOpnNDjHO7IOiianI/T1CgJ34bW75Gpf4iaEwMyd1s6kThDIsg== X-Received: by 2002:a0c:acab:: with SMTP id m40mr17558889qvc.52.1560955359090; Wed, 19 Jun 2019 07:42:39 -0700 (PDT) Received: from ?IPv6:2604:2000:1403:8807:4d01:9921:31b:189b? ([2604:2000:1403:8807:4d01:9921:31b:189b]) by smtp.gmail.com with ESMTPSA id x7sm11183718qth.37.2019.06.19.07.42.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jun 2019 07:42:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Myles Borins In-Reply-To: <69e52de0-6f80-c5d6-de24-05cce84d011f@outer-planes.net> Date: Wed, 19 Jun 2019 10:42:36 -0400 Cc: Mary Barnes , draft-ietf-dispatch-javascript-mjs@ietf.org, DISPATCH Content-Transfer-Encoding: quoted-printable Message-Id: <6F0FB972-0443-41AB-96CF-1D8B060D61A8@google.com> References: <69e52de0-6f80-c5d6-de24-05cce84d011f@outer-planes.net> To: "Matthew A. Miller" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dispatch] Shepherd review of draft-ietf-dispatch-javascript-mjs X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 14:42:44 -0000 Hey All, We=E2=80=99ve submitted the most recent draft and believe it is ready = for publication. Best, Myles > On Jun 17, 2019, at 10:14 AM, Matthew A. Miller = wrote: >=20 > Thanks for the review comments, Mary. >=20 > The authors believe we will have addressed the outstanding issue and > will have the shepherd concerns addressed in the next revision; will > submit that before the week is over. >=20 >=20 > - m&m >=20 > Matthew A. Miller >=20 > On 19/06/12 08:36, Mary Barnes wrote: >> I have reviewed the document in anticipation of forwarding to IESG = for >> publication. There is still one outstanding issue and once that's >> resolved I will ask the AD to request publication. >>=20 >> = https://mailarchive.ietf.org/arch/msg/dispatch/bHeezFbph08KIfXGvghHbqKWe14= >>=20 >> I have just two minor comments with regards to the "Note to Readers" >> section in the front of the document, and the URI section. Those >> sections reference a github repository for the document. Since that >> repository isn't necessarily stable and not associated with the IETF, = I >> would suggest to remove those sections OR add a "Note to the RFC = editor" >> to remove those sections prior to publication. =20 >>=20 >> Regards, >> Mary >>=20 >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Jun 19 11:20:38 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC50120814 for ; Wed, 19 Jun 2019 11:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_FILL_THIS_FORM_SHORT=0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnCQ17B2l86E for ; Wed, 19 Jun 2019 11:20:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623DF12083D for ; Wed, 19 Jun 2019 11:20:16 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x5JIK7eu060003 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 19 Jun 2019 13:20:09 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1560968409; bh=lHNCil3wjmQ3xXdiht93P34+EcLCKODK7YP/EmM9pZs=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=P6UTACHozIDuqlFcjYlNnbAAJGoafycSKWyyHwu/2n3gss/8xnpf3/Ijjva7O+U4z trqCIPdnr9MdtxIPwesSb8S/0xANmVVYXSj+IDPpSYpl7v23tOtuP4vs1KoTIlcjJi etf/YfKympKbBIuQ0I0NWvuSY04+QFfiXN+YzWEE= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0C4E8AD2-DBEE-4D09-B4EB-E0E707791857"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 19 Jun 2019 13:20:02 -0500 In-Reply-To: <96bef250-7821-4a85-85f5-f9df8128e96a@www.fastmail.com> To: DISPATCH References: <96bef250-7821-4a85-85f5-f9df8128e96a@www.fastmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [dispatch] JSContact Updated (was Re: JSCalendar: Updated to draft version 01) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 18:20:37 -0000 --Apple-Mail=_0C4E8AD2-DBEE-4D09-B4EB-E0E707791857 Content-Type: multipart/alternative; boundary="Apple-Mail=_D932604C-21A2-481C-BC70-253FD2DB5547" --Apple-Mail=_D932604C-21A2-481C-BC70-253FD2DB5547 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If anyone else is confused by the subject header (as I was), the topic = is =E2=80=9CJSContact=E2=80=9D, not =E2=80=9CJSCalendar=E2=80=9D. Thanks! Ben. > On Jun 7, 2019, at 6:06 AM, Robert Stepanek = wrote: >=20 > Hi all, >=20 > I've submitted draft version 01 of draft-stepanek-jscontact: > https://tools.ietf.org/html/draft-stepanek-jscontact = >=20 > This version is includes some, but not yet all of the feedback of = individual > reviewers as well as the CalConnect XLV meeting this week. >=20 > Changes: > - Added a new property for full names. > - Changed the single-string name component fields to arrays. > - Added a kind property, similar to VCARD KIND. > - Added a ISO-3166-1 country code property to Address. > - Added a full address property to Address. > - Added preferredContactMethod property. > - Added geo URI and time zone properties to Address. > - Added a role property. >=20 > There following feedback needs further consideration and I'm happy = about > any input: >=20 > Names: > - Learn more about the findings of ISO/TC 37/SC4 on naming schemes, = and > probably reuse it for JSContact. > - Current vendors such as Google and Apple already make use of > X-PHONETIC-{FIRST,LAST}-NAME properties for phonetic names. > It's similar to = https://tools.ietf.org/html/draft-fukuda-vcarddav-phonetic-transcription-0= 3 = >=20 > Contact: > - Support more than one company, and consider renaming it to = affiliations or > organizations. > - Allow for a similar property such as SORT-AS in VCARD4. > - Add categories and keywords properties, similar to JSCalendar. > - Allow for hierarchies? (group includes group? contact includes = contact?) >=20 > ContactInformation: > - Add a unique id to each ContactInformation, so that sync conflicts = can be > better resolved.. (might want to change the contact information = lists to > JMAP-style maps, where the id is the map key). >=20 > ContactGroup: > - List contact objects in a group, rather than their uids. If only uid = is of > interest, the embedded contact could just define that property. > - Allow to override properties for a contact within a group. E.g. a = contact > might override its "role" for a group that defines a project. Could = use > JSCalendar PatchObject in a property called contactOverrides. >=20 > Address: > - consider renaming it to Location > - Learn more about ISO19160-6 for international address > profiles. >=20 > Other: > - Localization most probably will be only required for names and = address. > - Rename either the RFC or the Contact object to JSCard for = disambiguation? >=20 > Cheers, > Robert > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_D932604C-21A2-481C-BC70-253FD2DB5547 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If = anyone else is confused by the subject header (as I was), the topic is = =E2=80=9CJSContact=E2=80=9D, not =E2=80=9CJSCalendar=E2=80=9D.

Thanks!

Ben.

On Jun 7, 2019, at 6:06 AM, Robert Stepanek <rsto@fastmailteam.com> wrote:

Hi all,
I've submitted draft version 01 of = draft-stepanek-jscontact:
https://tools.ietf.org/html/draft-stepanek-jscontact

This= version is includes some, but not yet all of the feedback of = individual
reviewers as well as the = CalConnect XLV meeting this week.

Changes:
- Added a new property for full names.
- Changed the single-string name component fields to = arrays.
- Added a kind property, = similar to VCARD KIND.
- Added a = ISO-3166-1 country code property to Address.
- Added a full address property to Address.
- Added preferredContactMethod = property.
- Added geo URI and time = zone properties to Address.
- Added = a role property.

There following feedback needs further = consideration and I'm happy about
any = input:

Names:
- Learn more about = the findings of ISO/TC 37/SC4 on naming schemes, and
  probably reuse it for = JSContact.
- Current vendors such as = Google and Apple already make use of
  X-PHONETIC-{FIRST,LAST}-NAME properties for phonetic = names.
  It's similar to https://tools.ietf.org/html/draft-fukuda-vcarddav-phonetic-tran= scription-03

Contact:
- Support more than one company, and consider renaming it to = affiliations or
  = organizations.
- Allow for a similar = property such as SORT-AS in VCARD4.
- = Add categories and keywords properties, similar to JSCalendar.
- Allow for hierarchies? (group = includes group? contact includes contact?)

ContactInformation:
- Add a unique id to each = ContactInformation, so that sync conflicts can be
  better resolved.. (might want to change the contact = information lists to
  = JMAP-style maps, where the id is the map key).

ContactGroup:
- List contact objects in a group, = rather than their uids. If only uid is of
  interest, the embedded contact could just define that = property.
- Allow to override = properties for a contact within a group. E.g. a contact
  might override its "role" for a = group that defines a project. Could use
  JSCalendar PatchObject in a property called = contactOverrides.

Address:
- consider renaming it to Location
- Learn more about ISO19160-6 for international address
  profiles.

Other:
- Localization most probably will be = only required for names and address.
-= Rename either the RFC or the Contact object to JSCard for = disambiguation?

Cheers,
Robert
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_D932604C-21A2-481C-BC70-253FD2DB5547-- --Apple-Mail=_0C4E8AD2-DBEE-4D09-B4EB-E0E707791857 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAl0KfNIACgkQgFZKbJXz 1A0stBAAx/KE1BTJ0+q+ZlwHAQpbI+VVFI17gV2bpszig/DC19LtJounBS2nCNpw MCdhdKNDZnsp16SpPntG/GNbhxMJfxB0BmOJup4zNhMLacQFLn5sso2hNoY+U0df X2enwxrMZPEVIVaupxOiQOG5GRiQgT8lHtHoww/lu7WiOzymbzF0NXzITaIvOHRk Bi7p4ECAEp/43YBaoXRuRNTXgIwSAUsI+wFOowPyyrFGasCsnsmRg6NU6laegQjK B4xiLGk+mOIqIaQsgxYqR4rVqbZb8NRroLRQphdI/wfJXy24gCwtKNvV10drdAx9 4lMeZAFnBP1KzUJp3rVtMNw5efLxdh/rokB8fD6U7PfU/Ds4wThOxL0kPzJ3XLww pagIjB7OKTt8cWjnZrLerpWJ4UMC3ZJwHh2g6G69VljmHpgmTJxQ8V7QVMML+jP8 Hdhd80PeJ9C9tE7iho/BkVWvgADxae0LVpu5Mis5p+gfZNerQdmE/J4Ax77L3x4u wIEtUlIkZj6hzF3ujq+/RZB5T0QgRueCP2EvRxnlcpIADAJ5QEuSp5HPuNgcirac RY5QqVYVcRJ8bfZ3EJjKdykFf3ZP/V9zDQZXFAoO4N6Rya0ZOkoCK8zem4gym1fs 1NoELaMGCWz+cxRcyuK/LEbx/bKpjqbBI7ZHmt5GXkGlOfwZWec= =9j01 -----END PGP SIGNATURE----- --Apple-Mail=_0C4E8AD2-DBEE-4D09-B4EB-E0E707791857-- From nobody Thu Jun 20 03:09:26 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDE1120122 for ; Thu, 20 Jun 2019 03:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=uSgtz+sE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NZHzfxiI 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 CmvEH_BBMo1J for ; Thu, 20 Jun 2019 03:09:22 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BF412003F for ; Thu, 20 Jun 2019 03:09:21 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BBA26223C3; Thu, 20 Jun 2019 06:09:20 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Thu, 20 Jun 2019 06:09:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=l/a2NvJ Mw6pd1WE71joB44wGcEEtvc6yOZSLHMRKQM0=; b=uSgtz+sEAlzp9ST4aX+BfX7 SzhsCyKKyfqqtW84K72mtvZltn6+YkncsmCrinRJpOQpSY+ravwVFlXbeHlUScVT 7zkLNR9Hgyosa9IYh5dr9RHUju0p0a7hqG+WhTBajMnaWPti9mZCvAeEZW46tG4v tmLKBIHW0M9gblUpqoAnPz+2ZYJRzIWgZV618XzDYWJfjAv3nhWGpp7e/XISD7vN TY6oR4HOu1O9wQo6wZdN3ISMu4rVrIiTf8yde/31nLW6OEJp+I7N54G7e9rF0VPd skEi5FTkaAS1kU6sI5x92S2LrNBLOzD7DduPa9DSOuXCGjKEJ+bCC+GNp47DUTQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=l/a2Nv JMw6pd1WE71joB44wGcEEtvc6yOZSLHMRKQM0=; b=NZHzfxiIm7oh08F3giOCk3 433VN8ZZwsGoM2aSHULuSCPAxjypl+Rbl5I5XFWi/WW1M2L98B6JeEzKYCvCuxbD xLm2fE70xjpVwzORLVeogU9PqRNpZHaWg/IvzwHRnBPIiMHO7Dh9H2amtPu02YwF 2m3fAv8EdG4l6z13uGX+vgHP2hZJNF/dFJau5ihY2GMwtnMa3Z3SV++1T61uSajf 5DPrBsoLMD5LcLwCSnk67qfJFrwzy3d+t0fDOiTTjuGr8fMcA1i/rRn4m7Rd8CZ9 7i5QTMbsVtDRwVoENWguqmmWH+2z7p7dVR+ni9obPqJITKJvqnV75QV8IUnkmFaA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrtdeggddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomheprh hsthhosehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 21FB8180634; Thu, 20 Jun 2019 06:09:20 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-727-gabab71a-fmstable-20190619v1 Mime-Version: 1.0 Message-Id: <96823fb0-a5fd-4dd7-aed7-28503fb5a6b3@www.fastmail.com> In-Reply-To: References: <96bef250-7821-4a85-85f5-f9df8128e96a@www.fastmail.com> Date: Thu, 20 Jun 2019 12:09:19 +0200 From: "Robert Stepanek" To: "Ben Campbell" , DISPATCH Content-Type: multipart/alternative; boundary=628717ee73bb497baefdf092c1bc7474 Archived-At: Subject: Re: [dispatch] =?utf-8?q?JSContact_Updated_=28was_Re=3A__JSCalendar?= =?utf-8?q?=3A_Updated_to_draft_version_01=29?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 10:09:24 -0000 --628717ee73bb497baefdf092c1bc7474 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 19, 2019, at 8:20 PM, Ben Campbell wrote: > If anyone else is confused by the subject header (as I was), the topic= is =E2=80=9CJSContact=E2=80=9D, not =E2=80=9CJSCalendar=E2=80=9D. That's on me, sorry. I meant "JSContact". --628717ee73bb497baefdf092c1bc7474 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Wed, Ju= n 19, 2019, at 8:20 PM, Ben Campbell wrote:
If anyone else is confused by the subject header (= as I was), the topic is =E2=80=9CJSContact=E2=80=9D, not =E2=80=9CJSCale= ndar=E2=80=9D.

That's on me, s= orry. I meant "JSContact".

--628717ee73bb497baefdf092c1bc7474-- From nobody Thu Jun 20 04:33:04 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308B312008B for ; Thu, 20 Jun 2019 04:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=N1j0hpmU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=p4w40xSE 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 XhfZu6CwZ9BX for ; Thu, 20 Jun 2019 04:33:00 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6887F12004F for ; Thu, 20 Jun 2019 04:33:00 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 578402216E for ; Thu, 20 Jun 2019 07:32:59 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Thu, 20 Jun 2019 07:32:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm3; bh=UQF586RfoJn197Bhjk1Vrbi+Fc4q5ywbpPvBmNq MXqE=; b=N1j0hpmUUQVXAwLjHoXotSyPWO5BipLL16boJUoVKldcxJhQ8Lc72t1 X3bGilt7U3SsheDpYWfnz/LoYH1fk54scJlLBtiX01RgHkZ1/VBZXry4kpK2ZBqE MA11vx5DSHhTRn3FZHxZk41Oud5S/r1MlRYOcmF19poeDdDoGc/nbc2baYuS+iCn gZPZtBU+RDPMe8zOqrV+zcwEqqWnVCr6onYZdq6TQ13rBlXJSvlXk/cdxtrSVWUe +xDgZcofHwrgTZgBqVza1JS+1ISL4kvi8t4BMkhE05KvxXsi1xzVKeqN/jbpeJST cDhNFK58hrOxLq4pxxBLPWlnD2Kxq5g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=UQF586RfoJn197Bhjk1Vrbi+Fc4q5 ywbpPvBmNqMXqE=; b=p4w40xSEFXEAi7QoVIg+Lw3NAIsqVSgJYcI0f8MLvf9cb OK34EMrzpdMQI4c+/w6ZBvzfsSTbkCCmywxJLjO7i/n0k4hMGR5GpeyGh9xw251C pM1pvpVqOwKgbjI/xrh9Dn9golrM+bhOuFWIF5f0Pr062h3pSz0qWppeH/O7+AXZ rfggXzWMRKtr1rWji4bbOB5AlegvCpRPPnHKC/bf1/Ul1zZb9VZN4NHRqumNMXMY XVPtAFzdIob8C958LGkXcNqJ1m2/MRW2gH/mztF5cXBbQHWq6F3iVgiT7XaUZtkT odi5xGnkMz+dscyUXUdmM6lBlRTR2hWhV0ER4DdRQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrtdeggdegvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecurf grrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhm necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9D6D7180634; Thu, 20 Jun 2019 07:32:58 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-727-gabab71a-fmstable-20190619v1 Mime-Version: 1.0 Message-Id: <7044660a-c234-414f-838e-5418452fead6@www.fastmail.com> Date: Thu, 20 Jun 2019 13:32:55 +0200 From: "Robert Stepanek" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=15053e62167449279c0c738c230a1249 Archived-At: Subject: [dispatch] Updated JSContact revision 02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 11:33:02 -0000 --15053e62167449279c0c738c230a1249 Content-Type: text/plain I have just submitted revision draft-stepanek-jscontact-02 of the JSContact RFC draft: https://tools.ietf.org/html/draft-stepanek-jscontact-02 I'm happy to say that Mario Loffredo and me are now co-authors of this draft! Mario provided lots of input since the initial draft, and the current revision is largely shaped by his insights. Thanks, Mario! We are still looking for a workgroup to adopt this draft. If you know any which might be interested, please let us know. Revision 02 address the feedback received on this list and personal emails: - fullName is an array of FullName objects - structuredName wraps the individual name fields - jobTitle and role are multi-valued - Address objects have new properties postOfficeBox and extension - prodId property stores the VCARD PRODID identifier - added the updated UTC-timestamp property - added new kinds: device and application (RFC 6473, RFC 6869) - added categories property - allow RFC3339 timestamps in birthday - added deathDate, birthPlace and deathPlace properties (RFC 6474) - renamed ContactInformation object to ContactMethod - added personalInfo property and PersonalInfo object (RFC 6715) - rephrased uid property definition As always, we are looking forward to your feedback. Regards, Robert --15053e62167449279c0c738c230a1249 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I have just sub= mitted revision draft-stepanek-jscontact-02 of the JSContact RFC draft: = http= s://tools.ietf.org/html/draft-stepanek-jscontact-02
I'm happy to say that Mario Loffredo and me are now co-auth= ors of this draft! Mario provided lots of input since the initial draft,= and the current revision is largely shaped by his insights. Thanks, Mar= io!

We are still looking for a workgroup to= adopt this draft. If you know any which might be interested, please let= us know.

Revision 02 address the feedback = received on this list and personal emails:

= - fullName is an array of FullName objects
- structuredNam= e wraps the individual name fields
- jobTitle and role are= multi-valued
- Address objects have new properties postOf= ficeBox and extension
- prodId property stores the VCARD P= RODID identifier
- added the updated UTC-timestamp propert= y
- added new kinds: device and application (RFC 6473, RFC= 6869)
- added categories property
- allow R= FC3339 timestamps in birthday
- added deathDate, birthPlac= e and deathPlace properties (RFC 6474)
- renamed ContactIn= formation object to ContactMethod
- added personalInfo pro= perty and PersonalInfo object (RFC 6715)
- rephrased uid p= roperty definition

As always, we are lookin= g forward to your feedback.

Regards,
Robert

--15053e62167449279c0c738c230a1249-- From nobody Thu Jun 20 06:53:36 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8844912004A for ; Thu, 20 Jun 2019 06:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org 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 YN9FAyarWLzM for ; Thu, 20 Jun 2019 06:53:25 -0700 (PDT) Received: from mailrelay4-1.pub.mailoutpod1-cph3.one.com (mailrelay4-1.pub.mailoutpod1-cph3.one.com [46.30.210.185]) (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 ADF94120046 for ; Thu, 20 Jun 2019 06:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20140924; h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=FnlNUffwxDjcwTc12VZi5rh7l8oyKYlUB7FJq6Bo2lk=; b=ZYpDKGTpFXajYU2+pM0DaJfJ7jpHH6mZ/jBvthDa0qksm7HBkjbzNGwgBMWeufjzEAuLif68D29z4 lrJT6nso9rX3I3F8XZ4ImqpQWjj929PsJt5dk2TfB9a/IwaFQY3JyTiyBrvOdLNFVN301G7fUGqPEG NHmVuKRhQ5Jwcj54= X-HalOne-Cookie: 3f490e7509b1b829f77aa9b90071def9942da333 X-HalOne-ID: c2f75652-9362-11e9-827b-d0431ea8bb10 Received: from smtp.dmfs.org (unknown [84.129.207.176]) by mailrelay4.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id c2f75652-9362-11e9-827b-d0431ea8bb10; Thu, 20 Jun 2019 13:53:20 +0000 (UTC) Received: from boss.localdomain (unknown [155.133.208.74]) by smtp.dmfs.org (Postfix) with ESMTPSA id 99E78233 for ; Thu, 20 Jun 2019 15:53:19 +0200 (CEST) To: dispatch@ietf.org References: <7044660a-c234-414f-838e-5418452fead6@www.fastmail.com> From: Marten Gajda Message-ID: <43f5e85c-a44e-0eec-544e-e941cd7f5beb@dmfs.org> Date: Thu, 20 Jun 2019 15:53:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <7044660a-c234-414f-838e-5418452fead6@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------509B83AA3E81EADA6C130A7F" Content-Language: en-US Archived-At: Subject: Re: [dispatch] Updated JSContact revision 02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 13:53:35 -0000 This is a multi-part message in MIME format. --------------509B83AA3E81EADA6C130A7F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks! I have a few more comments/ideas. * considering the new "kinds" we should also discuss the name "JSContact" again; JSCard sounds more appropriate. * consider creating one section per property, this way they show up in the index and as section titles which makes it easier to parse the document (I suppose that was planned for a later stage but it would be helpful at this stage already). * nickname is already a very specific type of "alias", there are other kinds of alias names like "religious name" or "stage name", hence an array of "Alias" objects (each with a type and name field) would be more appropriate. * during the Bedford CalConnect we discussed the option to replaces "addresses" with an array of the more generic locations taken from JSCalendar * creating one property for each kind of date associated with a contact doesn't scale well. We already have three different date properties (birthday, deathdate, anniversary), there are others which may be worth taking note of, depending on the "kind" of contact:   * some individuals celebrate two birthdays, like the Queen of England (see https://www.royal.uk/queens-birthday)   * some religions have special personal events like "confirmation", etc.   * devices may have a "next/last maintenance date"   * locations may have a "construction date"  I don't want to suggest to specify them all, just wanted to justify the need for such a structured date type. * deathPlace and birthPlace should become location types instead of dedicated properties * not sure about the PersonalInfo object, all the other properties are pretty much "personal information" as well. In case of a machine (but also a person) you could/would probably call these "capabilities". I think this could be useful for other "kinds" of "contacts" too, like   * whether a "location" is accessible   * whether a "resource" kind like a "projector" is movable   * which kind of fuel a "car" resource needs  I think all these fall into the same category of information. Again I don't suggest to specify all these, just to make this property fit for these use cases too. * it would be helpful to have a few examples (especially for non-individual kind of contacts) to see how this would look like in action. That's all for now. Cheers, Marten Am 20.06.19 um 13:32 schrieb Robert Stepanek: > I have just submitted revision draft-stepanek-jscontact-02 of the > JSContact RFC draft: > https://tools.ietf.org/html/draft-stepanek-jscontact-02 > > I'm happy to say that Mario Loffredo and me are now co-authors of this > draft! Mario provided lots of input since the initial draft, and the > current revision is largely shaped by his insights. Thanks, Mario! > > We are still looking for a workgroup to adopt this draft. If you know > any which might be interested, please let us know. > > Revision 02 address the feedback received on this list and personal > emails: > > - fullName is an array of FullName objects > - structuredName wraps the individual name fields > - jobTitle and role are multi-valued > - Address objects have new properties postOfficeBox and extension > - prodId property stores the VCARD PRODID identifier > - added the updated UTC-timestamp property > - added new kinds: device and application (RFC 6473, RFC 6869) > - added categories property > - allow RFC3339 timestamps in birthday > - added deathDate, birthPlace and deathPlace properties (RFC 6474) > - renamed ContactInformation object to ContactMethod > - added personalInfo property and PersonalInfo object (RFC 6715) > - rephrased uid property definition > > As always, we are looking forward to your feedback. > > Regards, > Robert > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------509B83AA3E81EADA6C130A7F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thanks! I have a few more comments/ideas.

* considering the new "kinds" we should also discuss the name "JSContact" again; JSCard sounds more appropriate.

* consider creating one section per property, this way they show up in the index and as section titles which makes it easier to parse the document (I suppose that was planned for a later stage but it would be helpful at this stage already).

* nickname is already a very specific type of "alias", there are other kinds of alias names like "religious name" or "stage name", hence an array of "Alias" objects (each with a type and name field) would be more appropriate.

* during the Bedford CalConnect we discussed the option to replaces "addresses" with an array of the more generic locations taken from JSCalendar

* creating one property for each kind of date associated with a contact doesn't scale well. We already have three different date properties (birthday, deathdate, anniversary), there are others which may be worth taking note of, depending on the "kind" of contact:
  * some individuals celebrate two birthdays, like the Queen of England (see https://www.royal.uk/queens-birthday)
  * some religions have special personal events like "confirmation", etc.
  * devices may have a "next/last maintenance date"
  * locations may have a "construction date"
 I don't want to suggest to specify them all, just wanted to justify the need for such a structured date type.

* deathPlace and birthPlace should become location types instead of dedicated properties

* not sure about the PersonalInfo object, all the other properties are pretty much "personal information" as well. In case of a machine (but also a person) you could/would probably call these "capabilities". I think this could be useful for other "kinds" of "contacts" too, like
  * whether a "location" is accessible
  * whether a "resource" kind like a "projector" is movable
  * which kind of fuel a "car" resource needs
 I think all these fall into the same category of information. Again I don't suggest to specify all these, just to make this property fit for these use cases too.

* it would be helpful to have a few examples (especially for non-individual kind of contacts) to see how this would look like in action.

That's all for now.

Cheers,

Marten

Am 20.06.19 um 13:32 schrieb Robert Stepanek:
I have just submitted revision draft-stepanek-jscontact-02 of the JSContact RFC draft: https://tools.ietf.org/html/draft-stepanek-jscontact-02

I'm happy to say that Mario Loffredo and me are now co-authors of this draft! Mario provided lots of input since the initial draft, and the current revision is largely shaped by his insights. Thanks, Mario!

We are still looking for a workgroup to adopt this draft. If you know any which might be interested, please let us know.

Revision 02 address the feedback received on this list and personal emails:

- fullName is an array of FullName objects
- structuredName wraps the individual name fields
- jobTitle and role are multi-valued
- Address objects have new properties postOfficeBox and extension
- prodId property stores the VCARD PRODID identifier
- added the updated UTC-timestamp property
- added new kinds: device and application (RFC 6473, RFC 6869)
- added categories property
- allow RFC3339 timestamps in birthday
- added deathDate, birthPlace and deathPlace properties (RFC 6474)
- renamed ContactInformation object to ContactMethod
- added personalInfo property and PersonalInfo object (RFC 6715)
- rephrased uid property definition

As always, we are looking forward to your feedback.

Regards,
Robert


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

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
--------------509B83AA3E81EADA6C130A7F-- From nobody Fri Jun 21 15:09:17 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5566E120019 for ; Fri, 21 Jun 2019 15:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru 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 A1zlpJc4ENvJ for ; Fri, 21 Jun 2019 15:09:12 -0700 (PDT) Received: from forward104p.mail.yandex.net (forward104p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:107]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24D312008A for ; Fri, 21 Jun 2019 15:09:11 -0700 (PDT) Received: from mxback15o.mail.yandex.net (mxback15o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::66]) by forward104p.mail.yandex.net (Yandex) with ESMTP id F3FCE4B00AC8; Sat, 22 Jun 2019 01:09:08 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback15o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 1jnzc6Qwiz-97MucleC; Sat, 22 Jun 2019 01:09:08 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1561154948; bh=8DkXtJevaRrpG5PzX3YJuRMMHdL9SZJ49KeZOoTiUS4=; h=Message-Id:Date:Cc:Subject:To:From; b=Jb3VGrwJf1o/JdJnoxfHbbWrb7Z1bQRGPtiBXfAyuGViQeE9O7FPSW5ftKPTDwec2 4bubRVS9f8JlVd1Ik5NX+91UeWjHL94HchdadA9TvjLpj73JxFwZq/nAU7Qmk+fYx1 qX8SwFAfTWkqQNVTbtMbkE7dBX/M9akU8JA3qeXo= Authentication-Results: mxback15o.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by myt1-06117f29c1ea.qloud-c.yandex.net with HTTP; Sat, 22 Jun 2019 01:09:07 +0300 From: Anton Tveretin To: "rsto@fastmailteam.com" Cc: DISPATCH list MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 22 Jun 2019 03:09:07 +0500 Message-Id: <6852851561154947@myt1-06117f29c1ea.qloud-c.yandex.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: Subject: [dispatch] On JSCalendar X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 22:09:15 -0000 Hello Robert, This is (almost) I was looking for for the NGMTP. Few my thoughts: 1. I do not expect any difference between a telephone number and any other immediate contact (SIP, Skype etc.) We have tel: URI. But RoAs could be present, as separate from AoRs (a new element?) 2. The same for mail. But I do not know any scheme that could contain all of mail (paper, Internet, X.400...) 3. Should names follow their order in the legal name, or their meaning? A Russian legal name consists of the family name, the given name, and the patronymic, in that order; a Spanish legal name consists of the given name, the family name 1, and the family name 2. One implementation I've seen splits a name into part 1, part 2, and part 3. Could you provide several examples? Regards, Anton. From nobody Fri Jun 28 16:03:15 2019 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 680CE120978; Fri, 28 Jun 2019 15:58:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dispatch@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176268241.11015.8225872505022199351.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:58:02 -0700 Archived-At: Subject: [dispatch] dispatch - Requested session has been scheduled for IETF 105 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 22:58:18 -0000 Dear Mary Barnes, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dispatch Session 1 (2:00 requested) Monday, 22 July 2019, Afternoon Session III 1810-1910 Room Name: Laurier size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/dispatch.ics Request Information: --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Mary Barnes Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: secdispatch cfrg extra doh core clue bfcpbis avtcore ecrit mmusic netvc payload rmcat rtcweb sipcore stir xrblock dmarc uta jmap Second Priority: tram tsvwg tsvarea opsarea People who must be present: Barry Leiba Alexey Melnikov Mary Barnes Adam Roach Ben Campbell Resources Requested: Special Requests: Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA, and avoid the same kind of conflicts with other area meetings and any Bofs and potential new ART WGs. --------------------------------------------------------- From nobody Sat Jun 29 07:56:42 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBFA120041 for ; Sat, 29 Jun 2019 07:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=yO0AxXOW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KRwCKAW/ 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 cBIHoZw-t9jx for ; Sat, 29 Jun 2019 07:56:38 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106C912000E for ; Sat, 29 Jun 2019 07:56:38 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CA02221B10; Sat, 29 Jun 2019 10:56:36 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Sat, 29 Jun 2019 10:56:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm3; bh=mFLP VP45ZVFP8OgE/ntlEflyqpxA00xQi5WZa87NXYQ=; b=yO0AxXOWuPNlIhLUBeVg QcXKIPtdhbwuhM/aDtoXlZ95Yd8KSkWhPBIUiKo+5y7oyiKTuXP94L3ZXmeIO1ie BG3yw38mMXsmjLuNgvQj2M06pH5mW8A7YmmuEIxK0rXvlAfPs80wFVPbOcVcvjCy EZQFQ8a/jp00qieKeEyBelImhrhGo89IDjSG80qOUDEmaEZDDQ4Zqn77KZMQzPpG T8SMKaao+DpvLX1oteZwDMDmUfxrbQQZYPAY/hlctz8Kr7irueYH7IsEFn8hG6tq Ymr480iMvs/PDGYhC2y52A9tZJEZNFna5TE8M2isULa+dxK1yk7W+z0ggvrCviBY qw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=mFLPVP 45ZVFP8OgE/ntlEflyqpxA00xQi5WZa87NXYQ=; b=KRwCKAW/fTgDBQ/A0OGQ7R OHG+guFoZZcv3PHqsU6QKeWnJ0MKJDhklEFWvfM+7BRVszwG7t2xA6M3hmX/Nmab FahEVWVE2sZF3+6HAM882UvwOQz0Qr6SfXQJwOrHe88aVLuq062EeYlZdIiQ7SoC m9IJcsoMYpco48tAXjx5dOw/KU8+OcTrDSLlsgfxScExwL72XhTBCdZoAa5R0LO9 kHGQ96j7s6ptgCLVLRzXZr2NzWPVFLaYSLdgCDmeBbhBsdZUYv+/RNNpvRKSNgnW FlmTmeO5criYrwM/ShfxaF7G6UrKbhsPEhGkF9Cv+mip9tIcJVStWqEGwUMcrnAw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvddvgdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedftfhosggv rhhtucfuthgvphgrnhgvkhdfuceorhhsthhosehfrghsthhmrghilhhtvggrmhdrtghomh eqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgvrghm rdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CF454180091; Sat, 29 Jun 2019 10:56:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: <3d13c386-c8d8-426c-9dc0-2c5e5ac35070@www.fastmail.com> In-Reply-To: <6852851561154947@myt1-06117f29c1ea.qloud-c.yandex.net> References: <6852851561154947@myt1-06117f29c1ea.qloud-c.yandex.net> Date: Sat, 29 Jun 2019 16:56:34 +0200 From: "Robert Stepanek" To: "Anton Tveretin" Cc: "DISPATCH list" Content-Type: multipart/alternative; boundary=77697a2068c64b4b8adc9fd5c9a6e0a5 Archived-At: Subject: Re: [dispatch] On JSCalendar X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2019 14:56:40 -0000 --77697a2068c64b4b8adc9fd5c9a6e0a5 Content-Type: text/plain Hi Anton, On Sat, Jun 22, 2019, at 12:09 AM, Anton Tveretin wrote: > Hello Robert, > This is (almost) I was looking for for the NGMTP. Few my thoughts: > 1. I do not expect any difference between a telephone number and any other immediate contact (SIP, Skype etc.) We have tel: URI. But RoAs could be present, as separate from AoRs (a new element?) > 2. The same for mail. But I do not know any scheme that could contain all of mail (paper, Internet, X.400...) I am not familiar with the terms RoAs and AoRs? I understand your points 1 and 2 to discuss if we should unify all contact methods into one property , and let implementations determine the type of the listed methods by the URI scheme? The reason we currently define separate properties for phone, email and others is that it is close to the way how VCARD is organized. It should help to make it simple for developers to switch to our proposed format. It's also close to the layout of the standard adressbooks on mobile devices and a couple other clients. In any case, we need a type property to distinguish the type of contact method, as existing VCARD data also comes in free-form telephone numbers, email addresses, etc. I've updated the next draft version to mention the `tel` and `sip` schemes as typical URI schemes for the phones property, but any URI scheme is allowed. The current RFC draft already includes an example to put Skype links in the `online` property, but I agree that's disputable. > 3. Should names follow their order in the legal name, or their meaning? A Russian legal name consists of the family name, the given name, and the patronymic, in that order; a Spanish legal name consists of the given name, the family name 1, and the family name 2. One implementation I've seen splits a name into part 1, part 2, and part 3. Could you provide several examples? I hope to get more insight into the works of the ISO group ISO/TC 37/SC4 . They aim at representing international names by use of registered profiles. For your example, it would allow to store the names in the card in a pre-defined order, and then use profiles to combine the names in the right order for a particular use case or culture. Regards, Robert --77697a2068c64b4b8adc9fd5c9a6e0a5 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Anton,<= br>

On Sat, Jun 22, 2019, at 12:09 AM, Anton Tv= eretin wrote:
Hello Ro= bert,
This is (almost) I was looking for for the NGMTP. Fe= w my thoughts:
1. I do not expect any difference between a= telephone number and any other immediate contact (SIP, Skype etc.) We h= ave tel: URI. But RoAs could be present, as separate from AoRs (a new el= ement?)
2. The same for mail. But I do not know any scheme= that could contain all of mail (paper, Internet, X.400...)

I am not familiar with the terms RoAs and = AoRs? I understand your points 1 and 2 to discuss if we should unify all= contact methods into one property , and let implementations determine t= he type of the listed methods by the URI scheme?

The reason we currently define separate properties for phone, emai= l and others is that it is close to the way how VCARD is organized. It s= hould help to make it simple for developers to switch to our proposed fo= rmat. It's also close to the layout of the standard adressbooks on mobil= e devices and a couple other clients.

In an= y case, we need a type property to distinguish the type of contact metho= d, as existing VCARD data also comes in free-form telephone numbers, ema= il addresses, etc.

I've updated the next dr= aft version to mention the `tel` and `sip` schemes as typical URI scheme= s for the phones property, but any URI scheme is allowed. The current RF= C draft already includes an example to put Skype links in the `online` p= roperty, but I agree that's disputable.

3. Should names follow their order in t= he legal name, or their meaning? A Russian legal name consists of the fa= mily name, the given name, and the patronymic, in that order; a Spanish = legal name consists of the given name, the family name 1, and the family= name 2. One implementation I've seen splits a name into part 1, part 2,= and part 3. Could you provide several examples?
<= div>
I hope to get more insight into the works of the ISO= group ISO/TC 37/SC4 . They aim at representing international names by u= se of registered profiles. For your example, it would allow to store the= names in the card in a pre-defined order, and then use profiles to comb= ine the names in the right order for a particular use case or culture.

Regards,
Robert
--77697a2068c64b4b8adc9fd5c9a6e0a5-- From nobody Sat Jun 29 08:23:50 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5805E120073 for ; Sat, 29 Jun 2019 08:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=EQPcDcOo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ATcUQkc6 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 kO9TtVcZm1lG for ; Sat, 29 Jun 2019 08:23:48 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E988C120045 for ; Sat, 29 Jun 2019 08:23:47 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4408721B34 for ; Sat, 29 Jun 2019 11:23:47 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Sat, 29 Jun 2019 11:23:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=JheRAHa gT12rWdNWFZ/fz32rfVPEhTYvveyL+Xph9PQ=; b=EQPcDcOocrvIx/Q3nbCg/h8 LF2QvimRY6zy+gf7S9IeBfgonF/6ZsZ4RBjRiPN2zjCLPRVhJII68viRKmIVUZGA x1Ilh0JMH8bTeJoml9/0hp6AKIG2KTJlG6ydLFrmT73Rk7vnoiV6n1p6Pl5yMmuW VASdZPtMhi8YKk5ldBLz4yFyab11xV3EV03op76VNydM+Q+oG3yk2W6YQyVqg62p jC5J4Y0iQZL7lUtgSJIqVBZBZWu4RicCktuxGSThPTzwcE153aZEfx2T+zaWJE4B 9fYXT2eO2zlrlzWO9OYRURuimuY3kdkxo2uidM77DyaYjKTyMe98VnpWvWBKSUQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=JheRAH agT12rWdNWFZ/fz32rfVPEhTYvveyL+Xph9PQ=; b=ATcUQkc6XfjHumsPGdifxD AVJq8OzlsZItUDAGejp9PQxce5lV6/sX3loIPv7NPsDACSEsOicVT7t2Tr9ryJAU ojQJIpiDZDW7iN14VO5uY5c0TpjDxLTsaZiUGpu3t/LStffitwtnaQgUCPXQD4mf eC7Qqkt40FV2WoyDVoWrZ7bKKBmQ/EwZlZdE5R4k59k3YpFbx8WouMliF3vs6MrA N39kZQjZepd0T16U//XFpQWrwAcKdh9WKpAAGoi7gDDeMn99cq5vXl6ahpbFwSJU lN8GVTVNQR3CPfOwEzmOIKtczwTlXgiyE6QVXgNDlk9Vl3hPtC2FQR6GDBowlaCQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvddvgdeklecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomheprh hsthhosehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 88896180091; Sat, 29 Jun 2019 11:23:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: <2816eeca-3823-451a-9300-afeff5d51ef9@www.fastmail.com> In-Reply-To: <43f5e85c-a44e-0eec-544e-e941cd7f5beb@dmfs.org> References: <7044660a-c234-414f-838e-5418452fead6@www.fastmail.com> <43f5e85c-a44e-0eec-544e-e941cd7f5beb@dmfs.org> Date: Sat, 29 Jun 2019 17:23:46 +0200 From: "Robert Stepanek" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=b78bf056ea514cccaacd18f1db22b693 Archived-At: Subject: Re: [dispatch] Updated JSContact revision 02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2019 15:23:49 -0000 --b78bf056ea514cccaacd18f1db22b693 Content-Type: text/plain Hi Marten, thanks for your feedback. On Thu, Jun 20, 2019, at 3:54 PM, Marten Gajda wrote: > Thanks! I have a few more comments/ideas. > > * considering the new "kinds" we should also discuss the name "JSContact" again; JSCard sounds more appropriate. I had this planned as well. The next RFC draft will use JSCard and JSCardGroup. We keep using JSContact for the overall RFC for now. > * consider creating one section per property, this way they show up in the index and as section titles which makes it easier to parse the document (I suppose that was planned for a later stage but it would be helpful at this stage already). Mario and I will keep the current layout for now. I say we'll revisit the document layout when the data format is more stable. > * creating one property for each kind of date associated with a contact doesn't scale well. [...] The next RFC draft will include an anniversaries property. > * nickname is already a very specific type of "alias", there are other kinds of alias names like "religious name" or "stage name", hence an array of "Alias" objects (each with a type and name field) would be more appropriate. > * during the Bedford CalConnect we discussed the option to replaces "addresses" with an array of the more generic locations taken from JSCalendar > * not sure about the PersonalInfo object, all the other properties are pretty much "personal information" as well. In case of a machine (but also a person) you could/would probably call these "capabilities". I think this could be useful for other "kinds" of "contacts" too, like > * whether a "location" is accessible > * whether a "resource" kind like a "projector" is movable > * which kind of fuel a "car" resource needs > I think all these fall into the same category of information. Again I don't suggest to specify all these, just to make this property fit for these use cases too. I'm not convinced of that. Our current idea is to provide specific properties for the common use cases, and add generic properties for the uncommon ones. We assume it's common to organize personal contact addressbook information. That being said, I expect the format will still change considerably, the more we learn about the expected use cases of the format. > * it would be helpful to have a few examples (especially for non-individual kind of contacts) to see how this would look like in action. I'm looking at this RFC mainly with the experience from our contact organizer application at FastMail. It'd be great to see how other people would like to use the non-person contact cards, or how they are doing now with VCARD! Regards, Robert --b78bf056ea514cccaacd18f1db22b693 Content-Type: text/html
Hi Marten,

thanks for your feedback.

On Thu, Jun 20, 2019, at 3:54 PM, Marten Gajda wrote:
Thanks! I have a few more comments/ideas.

* considering the new "kinds" we should also discuss the name "JSContact" again; JSCard sounds more appropriate.

I had this planned as well. The next RFC draft will use JSCard and JSCardGroup. We keep using JSContact for the overall RFC for now.

* consider creating one section per property, this way they show up in the index and as section titles which makes it easier to parse the document (I suppose that was planned for a later stage but it would be helpful at this stage already).

Mario and I will keep the current layout for now. I say we'll revisit the document layout when the data format is more stable.

* creating one property for each kind of date associated with a contact doesn't scale well. [...]

The next RFC draft will include an anniversaries property.

* nickname is already a very specific type of "alias", there are other kinds of alias names like "religious name" or "stage name", hence an array of "Alias" objects (each with a type and name field) would be more appropriate.
* during the Bedford CalConnect we discussed the option to replaces "addresses" with an array of the more generic locations taken from JSCalendar
* not sure about the PersonalInfo object, all the other properties are pretty much "personal information" as well. In case of a machine (but also a person) you could/would probably call these "capabilities". I think this could be useful for other "kinds" of "contacts" too, like
  * whether a "location" is accessible
  * whether a "resource" kind like a "projector" is movable
  * which kind of fuel a "car" resource needs
 I think all these fall into the same category of information. Again I don't suggest to specify all these, just to make this property fit for these use cases too.

I'm not convinced of that. Our current idea is to provide specific properties for the common use cases, and add generic properties for the uncommon ones. We assume it's common to organize personal contact addressbook information. That being said, I expect the format will still change considerably, the more we learn about the expected use cases of the format.

* it would be helpful to have a few examples (especially for non-individual kind of contacts) to see how this would look like in action.

I'm looking at this RFC mainly with the experience from our contact organizer application at FastMail. It'd be great to see how other people would like to use the non-person contact cards, or how they are doing now with VCARD!

Regards,
Robert

--b78bf056ea514cccaacd18f1db22b693-- From nobody Sat Jun 29 08:35:49 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC0F120073 for ; Sat, 29 Jun 2019 08:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Go4aiWFG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=chILlI5v 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 envGnqOp2AuQ for ; Sat, 29 Jun 2019 08:35:46 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B497120058 for ; Sat, 29 Jun 2019 08:35:46 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4CBEE21C24 for ; Sat, 29 Jun 2019 11:35:45 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Sat, 29 Jun 2019 11:35:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm3; bh=W17dZdITylIu4qPBmEG6Wd7Ce0lulo831kcE0sJ mevk=; b=Go4aiWFGIlGriWQuKp/25GrbYmr7m3ijnbRxe69Ok4sjqR+9+On6jyb vwSs3p2VzqTYr/zJhFkpTefQYR2go+SMNd/Dk2fTAgs7/ErmARROjMQXBUrb2fR5 4C6plmQlqXsWy18f0cKnSYFRe7gCM/ldRK/8w125xHfcxXup+3vpM4qImodfd8f1 4G5/A/Hhm2U0XqGRQA8hhX65TsC9fba4qVQNio+Y9YEWjhPSCigAInoEV3U/qQeg UJ+ih/n3D8C/I7F01DFHRdm9sUgDsVaivHeMOD9UWde3m167o8PA/+EUwFCBtGbE TkG+riftm0Sqd0o6Gf1/16pcawVWEOA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=W17dZdITylIu4qPBmEG6Wd7Ce0lul o831kcE0sJmevk=; b=chILlI5vGg1gu+TP5/5DtiQsdT8TjtXCKughypQhpeB0q vvjQRlDhw4nkgNTMxIZu1glxrwWMxAgrv+YpGPI4+fums7ut5tkBJDdK7Epj4KGL ojhdDRCIJ2b266I4zxtoY9Mvm4BsYBMSieSwjxCAhh1XV/ISJRwl3h4Tks6H4HzU LlpBKSsy/N/8Tb+i3O+I35gq+xnHFzmJlsGa0XeyKLHPk47coaT3N65DksjJsmcI A/Jv4bNgvHzqyFc+1KKiYsJwa5b6ntiYWzqEB4IodVrGUI7NwTAqqVRrgwWNrFIj auF0W6zKU7U4YnLY80Kg+3OCTjvMJsRAuaXwozXEw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvddvgdeludcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecurf grrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhm necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B554E180091; Sat, 29 Jun 2019 11:35:44 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: <1a6edc87-724d-4c41-9928-79ca970c4011@www.fastmail.com> Date: Sat, 29 Jun 2019 17:35:44 +0200 From: "Robert Stepanek" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=088df1c3e1bc46cdb1b8c428a921e6fb Archived-At: Subject: [dispatch] JSContact: Updated draft-stepanek-jscontact-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2019 15:35:48 -0000 --088df1c3e1bc46cdb1b8c428a921e6fb Content-Type: text/plain Hi, I have uploaded version 03 of the JSContact RFC draft: https://tools.ietf.org/html/draft-stepanek-jscontact-03 This version includes the following updates: - Renamed Contact and ContactGroup objects to JSCard and JSCardGroup, respectively. - Added the anniversaries property. - Added RFC2368 mailto URLs to allowed values in emails property. - Allowed all URI values in phones property, and mentioned RFC3966 tel: and RFC3261 sip: schemes as typical values. FYI - I will be out of office over the summer months, and will not be able to reply to your feedback. Mario is the co-author of this RFC and on this list. Regards, Robert --088df1c3e1bc46cdb1b8c428a921e6fb Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi,

I have uploaded version 03 of the JSContact RFC draft:= htt= ps://tools.ietf.org/html/draft-stepanek-jscontact-03
<= br>
This version includes the following updates:
- Renamed Contact and ContactGroup objects to JSCard and JSCardGroup, r= espectively.
- Added the anniversaries property.
=
- Added RFC2368 mailto URLs to allowed values in emails property.
- Allowed all URI values in phones property, and mentioned = RFC3966 tel: and RFC3261 sip: schemes as typical values.
<= br>
FYI - I will be out of office over the summer months, and = will not be able to reply to your feedback. Mario is the co-author of th= is RFC and on this list.

Regards,
=
Robert
--088df1c3e1bc46cdb1b8c428a921e6fb--