From ranjitkav12@gmail.com Wed Oct 2 10:48:34 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 2B5F612080D for ; Wed, 2 Oct 2019 10:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 xESmlgoAOptg for ; Wed, 2 Oct 2019 10:48:33 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 C36501201AA for ; Wed, 2 Oct 2019 10:48:32 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id r5so20615233wrm.12 for ; Wed, 02 Oct 2019 10:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=QxmF9+TzbMt7RPtjvBDR6M3XAW4l6rUFwzXN+9OLiaI=; b=CY6JoCV9vPzTZYcmG0nSt8avz66qv3oqv0lZh7BQY7KJf+fcmnCaI/OWw0J4FrTLfJ j7P9MnA335E8RlJJ6YvCJ/s+iavZ3CotuGDbALkTSla6y2WYxNRwtQh3BjMXotFrUgaQ CNnSAAPy7zMNye7DMqA4rlovq3DZWZtb1mkAYqUrkSug1wlXgk5tUtJbsx5G2e8+ZjG0 97V5hakAFD4dpy8cP8qsE7kumyJDA89XgjDVJiYBgfcr7LZhQe/q8iV3Yg5KxmfSbzmE 65629dRplgeP0v+7oXFlDC/GezzgttgRyFB7hs9OUbAvU+nhBFfJum/YLdDjo/J69I67 oqwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=QxmF9+TzbMt7RPtjvBDR6M3XAW4l6rUFwzXN+9OLiaI=; b=LKBdLKWh7yQsrx42me3kS3/JOe3Sl+jloeV15o3T6/8lZa3u/I0x5JK1HiLpRTSAVl VPLxFovF1jnxSf56boNB04cmM14sOZl7HLyuPhNq2DKiZcHtFV2dbTccFKn1Nnm9PQpg 3qycjX+ITGzdwQ1PG9PdebltosGAbxsgOe3qHUUw23Al1qk+yvq3u4vHjS6cXAl5osOq PweIJnFS1y42WgDldFgRWDLF4O39d5f1xbEhOr0/V/ZLfUMdj0QxW+jWVSIVYZzDRF+/ Kc0pMcWIMytsIEM3fSQv/FvVps+GqeVpebGb68OUMpTACCdqfPGl1Uf1P9u16jN/k9fk rSQQ== X-Gm-Message-State: APjAAAUK0maCU0kkYUTISAFGQFqiB3gnP4hMiPgn7q55rOvAtIPWgWr3 V9wo16/iVMHkPkmerXKcx97k/yWAoV2nZJbE4QqT4w== X-Google-Smtp-Source: APXvYqwhHhHb6zGi0ZxyYfOzQip7S2nvE+7A38Oy/izhPh8ZX7jXA4PUfxLXFysiRyV1P3MniDriSIrVpiYdXdHEGvM= X-Received: by 2002:adf:9b81:: with SMTP id d1mr2887102wrc.157.1570038511111; Wed, 02 Oct 2019 10:48:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ranjit Avasarala Date: Wed, 2 Oct 2019 12:48:19 -0500 Message-ID: To: dispatch@ietf.org Content-Type: multipart/alternative; boundary="000000000000bd118a0593f113c7" Archived-At: Subject: [dispatch] Fwd: sip ue-addr contact hdr parameter 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, 02 Oct 2019 17:51:32 -0000 --000000000000bd118a0593f113c7 Content-Type: text/plain; charset="UTF-8" Hello all I am looking for an I-D or RFC that describes the syntax and behaviour of proxies receiving ue-addr parameter in SIP INVITE and when they do and do not forward it further Thank you Ranjit --000000000000bd118a0593f113c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all
=
I am looking for an I-D or RFC that describes the syntax=C2= =A0and behaviour of proxies receiving ue-addr parameter in SIP INVITE and w= hen they do and do not forward it further

Thank yo= u
Ranjit
--000000000000bd118a0593f113c7-- From nobody Wed Oct 2 11:38: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 2D0A212081E for ; Wed, 2 Oct 2019 11:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=ericsson.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 6RzDmUpbFHtw for ; Wed, 2 Oct 2019 11:38:01 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150044.outbound.protection.outlook.com [40.107.15.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86313120851 for ; Wed, 2 Oct 2019 11:38:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eWfL/x+nJoLeChfFUaw6aHdFbvTnTI1wQXoZ6nWxzV3dn18xFRAlyk0YXFEgxxWJak4sT7WMuVPB9tDjj11ByWAezqTjN/cicDl3z/hr5ncD0hOUD6IHXKcmAPIYQIpoL6eFKBTf+zdY1o5V4wUczal8jqozNYn9VEYKaxJzbZgC0/J4mBQpnpPwdB7uX7wgUaTD1aOxTmXLeEs32hoVBvn5ihUJv2Kzv1tecGIVqF4bTF4WAqnsyAnjBpZWxXBl89q6/tNlmfPpxVd/zmt3GkCexZw2mz4BrD/SzcxTAkXvwpKFwWe3ce7EojO0JGpU1oBCszvjanM2L8Ob1EaPRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F2EoVUVMKXAwGYncCiuE6egmd6p//1fAxa4kc2jhYJk=; b=KeJWJevWmz5wZ5ED5ojxhXJ+2nKLtKjYR6Y9g4EA58UNupo6B0BPlsMXh8tiq72Zlh9rKpIyMxIje9EvIRAIyVw0Nijj1OHScIgplgq/inu7uWTCOqP9XWRAlVC4kunIaXOyOMBUoG860mJb16YBQPxJV2ZbAtyOPITEgFX+1yx6P2XEMmn6dyFv330wrUTySJn88uoduZvCzhTRQybtJN1dFkdJ0stvPbPtJCiHs2hKIpbJq8+R3YiM9ZzKXcn2CASHARnoXhSqwzd3qAb0HAYcUQXATm0GhOfXD4Q32fJ435Bu8M8BNEgC2XXKyCAuoJkt4BsOCMFZykqoq+W5XA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F2EoVUVMKXAwGYncCiuE6egmd6p//1fAxa4kc2jhYJk=; b=ZFgA6e0PPFfQLzTCbS0upHSYK84kZ+Smb3DmmY58rxH6Ijvx6d214v8Nd4Ok67R4Y3BvZ8ZjMKzwET7HqtvHAmiZRY79IUal4u011sR6IaP6ZO+C1FhG+fRYZNaSP53zHcW87UnbbzJfhn5epxakr+r1MqdElkUwPDewlO0JE7Y= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3306.eurprd07.prod.outlook.com (10.170.242.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.10; Wed, 2 Oct 2019 18:37:58 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::14d0:5c4f:26b7:b6e9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::14d0:5c4f:26b7:b6e9%3]) with mapi id 15.20.2327.017; Wed, 2 Oct 2019 18:37:58 +0000 From: Christer Holmberg To: Ranjit Avasarala , "dispatch@ietf.org" Thread-Topic: [dispatch] Fwd: sip ue-addr contact hdr parameter Thread-Index: AQHVeUoQHymi/RecDkC1KA2O5RG5MqdHrkow Date: Wed, 2 Oct 2019 18:37:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [79.134.118.162] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 59ddf89a-e149-4c6a-7414-08d74767a5ba x-ms-traffictypediagnostic: HE1PR07MB3306: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(366004)(346002)(396003)(376002)(53754006)(199004)(189003)(9686003)(256004)(71200400001)(2906002)(478600001)(3846002)(110136005)(2501003)(9326002)(8676002)(44832011)(8936002)(5660300002)(316002)(81166006)(4744005)(81156014)(71190400001)(6116002)(7696005)(790700001)(476003)(446003)(26005)(554214002)(186003)(64756008)(102836004)(66556008)(86362001)(66066001)(11346002)(33656002)(6306002)(6436002)(54896002)(14454004)(74316002)(66446008)(76176011)(25786009)(99286004)(76116006)(66946007)(486006)(52536014)(7736002)(66476007)(6506007)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3306; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UPh6cK4FzT9/hcdvH+ZxpcXJ6tAyJtX2ByuzUCcCwcvodIs543hz/Elc96Wv3ZHJlrE5yPBkaToM2eNyEcE3zpzU/nAdHlyjFPyFxaj1Z0R7LMJGQzoopKRL0p4BvR1IYfeTsSFOp99uHfK2akZcEoAFzVbBXj30X+hdAjS4ggQ/TSKArCgjRqRNPYHquVVGlc0BoIN3MzbWIUUMNQ9IyD6dAuwNlQvvADljTVsz7y9IHBGPTkxpYxfD7MixNC79pw4fweyLnm8MFcPcfUTkwt30gcdrcZ9+r1jRY5j8kAlhveK50IZ6tX7bxSWbBGVrHJb+LWmA2MWNCaCQIO0cOcHlbdOuaefnxesktmjEu64KZx72WSpR/LG8feI9mqSg5k67wSXgToAYa/LgbdUbwGTB48xRinbdTJIALFD10bw= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3161E516064384192072173E939C0HE1PR07MB3161eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 59ddf89a-e149-4c6a-7414-08d74767a5ba X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2019 18:37:58.1999 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ESXEYB4YnGCm0VrpYoE7JJcCE9HQUNOVTS02vKYxh0nj8nNGOGAhKSEX8geM/Q1E0a/re1IW4kvociW0LuG/sn5aRbxjbkWEf6rEhSXVujs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3306 Archived-At: Subject: Re: [dispatch] Fwd: sip ue-addr contact hdr parameter 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, 02 Oct 2019 18:38:05 -0000 --_000_HE1PR07MB3161E516064384192072173E939C0HE1PR07MB3161eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoaXMgcXVlc3Rpb24gcHJvYmFibHkgYmVsb25ncyB0byBTSVBDT1JFLg0KDQrigKZh bmQsIHdoYXQgaXMgdWUtYWRkciBwYXJhbWV0ZXI/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN CkzDpGhldHTDpGrDpDogZGlzcGF0Y2ggPGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc+IFB1b2xl c3RhIFJhbmppdCBBdmFzYXJhbGENCkzDpGhldGV0dHk6IGtlc2tpdmlpa2tvIDIuIGxva2FrdXV0 YSAyMDE5IDIwLjQ4DQpWYXN0YWFub3R0YWphOiBkaXNwYXRjaEBpZXRmLm9yZw0KQWloZTogW2Rp c3BhdGNoXSBGd2Q6IHNpcCB1ZS1hZGRyIGNvbnRhY3QgaGRyIHBhcmFtZXRlcg0KDQpIZWxsbyBh bGwNCg0KSSBhbSBsb29raW5nIGZvciBhbiBJLUQgb3IgUkZDIHRoYXQgZGVzY3JpYmVzIHRoZSBz eW50YXggYW5kIGJlaGF2aW91ciBvZiBwcm94aWVzIHJlY2VpdmluZyB1ZS1hZGRyIHBhcmFtZXRl ciBpbiBTSVAgSU5WSVRFIGFuZCB3aGVuIHRoZXkgZG8gYW5kIGRvIG5vdCBmb3J3YXJkIGl0IGZ1 cnRoZXINCg0KVGhhbmsgeW91DQpSYW5qaXQNCg== --_000_HE1PR07MB3161E516064384192072173E939C0HE1PR07MB3161eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlNoa3Bvc3RpdHl5bGkx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGlzIHF1ZXN0aW9uIHBy b2JhYmx5IGJlbG9uZ3MgdG8gU0lQQ09SRS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+4oCmYW5kLCB3aGF0IGlzIHVlLWFkZHIg cGFyYW1ldGVyPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRkkiPkzDpGhldHTDpGrDpDo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkZJIj4gZGlzcGF0Y2ggJmx0O2Rpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5Q dW9sZXN0YSA8L2I+UmFuaml0IEF2YXNhcmFsYTxicj4NCjxiPkzDpGhldGV0dHk6PC9iPiBrZXNr aXZpaWtrbyAyLiBsb2tha3V1dGEgMjAxOSAyMC40ODxicj4NCjxiPlZhc3RhYW5vdHRhamE6PC9i PiBkaXNwYXRjaEBpZXRmLm9yZzxicj4NCjxiPkFpaGU6PC9iPiBbZGlzcGF0Y2hdIEZ3ZDogc2lw IHVlLWFkZHIgY29udGFjdCBoZHIgcGFyYW1ldGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBhbGw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbG9va2luZyBmb3IgYW4gSS1EIG9yIFJGQyB0 aGF0IGRlc2NyaWJlcyB0aGUgc3ludGF4Jm5ic3A7YW5kIGJlaGF2aW91ciBvZiBwcm94aWVzIHJl Y2VpdmluZyB1ZS1hZGRyIHBhcmFtZXRlciBpbiBTSVAgSU5WSVRFIGFuZCB3aGVuIHRoZXkgZG8g YW5kIGRvIG5vdCBmb3J3YXJkIGl0IGZ1cnRoZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SYW5qaXQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_HE1PR07MB3161E516064384192072173E939C0HE1PR07MB3161eurp_-- From nobody Wed Oct 2 11:56: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 D6AE21200B7 for ; Wed, 2 Oct 2019 11:56:21 -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 2pFAAfz3Z__n for ; Wed, 2 Oct 2019 11:56:19 -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 D72A6120052 for ; Wed, 2 Oct 2019 11:56:18 -0700 (PDT) Received: from Kokiri.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 x92IuFiE012994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 2 Oct 2019 14:56:16 -0400 To: ranjitkav12@gmail.com References: Cc: dispatch@ietf.org From: Paul Kyzivat Message-ID: <4a0c083e-b5c7-4a68-7675-4591b679d68c@alum.mit.edu> Date: Wed, 2 Oct 2019 14:56:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.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] Fwd: sip ue-addr contact hdr parameter 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, 02 Oct 2019 18:56:22 -0000 On 10/2/19 2:37 PM, Christer Holmberg wrote: > Hi, > > This question probably belongs to SIPCORE. A more appropriate place would be sip-implementors@lists.cs.columbia.edu. > …and, what is ue-addr parameter? AFAIK it isn't a term that appears in ietf sip documents. Given the use of "ue" I guess perhaps this may be a question about 3gpp. Thanks, Paul > Regards, > > Christer > > *Lähettäjä:*dispatch *Puolesta *Ranjit Avasarala > *Lähetetty:* keskiviikko 2. lokakuuta 2019 20.48 > *Vastaanottaja:* dispatch@ietf.org > *Aihe:* [dispatch] Fwd: sip ue-addr contact hdr parameter > > Hello all > > I am looking for an I-D or RFC that describes the syntax and behaviour > of proxies receiving ue-addr parameter in SIP INVITE and when they do > and do not forward it further > > Thank you > > Ranjit > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Wed Oct 2 16:47:44 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 2B0F2120108 for ; Wed, 2 Oct 2019 16:47:42 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTABvyyrQxSt for ; Wed, 2 Oct 2019 16:47:39 -0700 (PDT) Received: from smtp108.iad3b.emailsrvr.com (smtp108.iad3b.emailsrvr.com [146.20.161.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F301200F4 for ; Wed, 2 Oct 2019 16:47:39 -0700 (PDT) X-Auth-ID: fluffy@iii.ca Received: by smtp22.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 41E7D600F3; Wed, 2 Oct 2019 19:47:36 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (d75-155-57-73.abhsia.telus.net [75.155.57.73]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Wed, 02 Oct 2019 19:47:38 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_6984B694-1D1C-4538-AEEF-39F3D553DBA8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Cullen Jennings In-Reply-To: Date: Wed, 2 Oct 2019 17:47:36 -0600 Cc: "Kaustubh Inamdar (kinamdar)" , "dispatch@ietf.org" Message-Id: References: To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dispatch] New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt - SIP OPTIONS? 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, 02 Oct 2019 23:47:42 -0000 --Apple-Mail=_6984B694-1D1C-4538-AEEF-39F3D553DBA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 23, 2019, at 8:15 AM, Christer Holmberg = wrote: >=20 > Hi Kaustubh, >=20 > Thank You for the reply! Please see inline. >=20 >>>> Constructs in SIP such as NOTIFY and OPTIONS may be used to achieve = the end goal - which is to have the SIP service provider offload its set = of capabilities. >>>> However, with I see a couple of challenges with using OPTIONS=E2=80=A6= >>>>=20 >>>> 1. It is entirely plausible for the SIP service provider to offload=20= >>>> different capability set documents to different enterprises or = different sites within an enterprise. Accordingly, it would be a = challenge to fine tune the OPTIONS response on a per enterprise/site = basis. >>>=20 >>> I assume the service provider will have to know from which = enterprise network the OPTIONS request comes from - similar to the HTTPS = GET in the draft. >>=20 >> Kaustubh: The point of contention isn=E2=80=99t how the service = provider determines =E2=80=9Cwhere=E2=80=9D the OPTIONS request came in = from. This can be done by examining SIP header fields or the source IP = address of the >request. The point I was trying to make was two-fold: >> 1. Service providers would have to upgrade their SIP stacks to = handle this new response type in the body of the OPTIONS response.=20 >>=20 >> 2. I don=E2=80=99t know if it would be very simple to handle = customised capability set responses based on enterprise identity at the = SIP layer - even if it is, it is=20 >> needlessly a lot of work for something that can be accomplished much = more easily using an alternate mechanism. =20 >=20 > I don't understand how it would be "must more easily". In both cases = the server is adding the capabilities in the response of a request (SIP = OPTIONS or HTTP GET), and in both cases the server needs to implement = the support for that.=20 In many cases, the SP could just put a more or less static web page on = existing server with a bit of DNS config. That sounds easier to me than = waiting to deploy a new version of software on SBCs. I also don=E2=80=99t = really know how to solve the chicken and egg problem of how to get the = config for the SIP OPTIONS to get the config for the SIP.=20 >=20 >> While I completely get that SIP OPTIONS was designed for the purpose = of probing a remote entity for its capabilities, the path of least = disruption seems to be to use HTTPS. >=20 > One of the draft co-authors also co-authored the RIPP draft, which is = kind of going in that direction (at least for a specific use-case). But, = at least in the draft you are marketing this as a SIP feature :) >=20 >=20 This is draft is a small trivial change to try and make it easier to set = up a sip trunk, RIPP is, uh, something else. But whatever it is, it is = not a small change.=20 --Apple-Mail=_6984B694-1D1C-4538-AEEF-39F3D553DBA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Sep 23, 2019, at 8:15 AM, Christer Holmberg <christer.holmberg=3D40ericsson.com@dmarc.ietf.org> = wrote:

Hi Kaustubh,

Thank You for the reply! Please = see inline.

Constructs in SIP such as NOTIFY and OPTIONS may be used to = achieve the end goal - which is to have the SIP service provider offload = its set of capabilities.
However, with I see a couple of = challenges with using OPTIONS=E2=80=A6

1. = It is entirely plausible for the SIP service provider to offload 
different = capability set documents to different enterprises or different sites = within an enterprise. Accordingly, it would be a challenge to fine tune = the OPTIONS response on a per enterprise/site basis.

I assume the service provider = will have to know from which enterprise network the OPTIONS request = comes from - similar to the HTTPS GET in the draft.

Kaustubh: The point of contention = isn=E2=80=99t how the service provider determines =E2=80=9Cwhere=E2=80=9D = the OPTIONS request came in from. This can be done by examining SIP = header fields or the source IP address of the >request. The point I = was trying to make was two-fold:
1.  Service = providers would have to upgrade their SIP stacks to handle this new = response type in the body of the OPTIONS response. 

2.  I don=E2=80=99t know if it would be very simple to = handle customised capability set responses based on enterprise identity = at the SIP layer - even if it is, it is 
needlessly a = lot of work for something that can be accomplished much more easily = using an alternate mechanism.  

I don't understand how it would = be "must more easily". In both cases the server is adding the = capabilities in the response of a request (SIP OPTIONS or HTTP GET), and = in both cases the server needs to implement the support for that. 

In many cases, = the SP could just put a more or less static web page on existing server = with a bit of DNS config. That sounds easier to me than waiting to = deploy a new version of software on SBCs. I also don=E2=80=99t really = know how to solve the chicken and egg problem of how to get the config = for the SIP OPTIONS to get the config for the SIP. 


While I completely get that SIP = OPTIONS was designed for the purpose of probing a remote entity for its = capabilities, the path of least disruption seems to be to use HTTPS.

One of the draft co-authors also co-authored the RIPP draft, = which is kind of going in that direction (at least for a specific = use-case). But, at least in the draft you are marketing this as a SIP = feature :)



This is draft is a small trivial change to try and = make it easier to set up a sip trunk, RIPP is, uh, something else. But = whatever it is, it is not a small change. 




= --Apple-Mail=_6984B694-1D1C-4538-AEEF-39F3D553DBA8-- From nobody Thu Oct 3 09:11:59 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 E17BE12011F for ; Thu, 3 Oct 2019 09:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=g001.emailsrvr.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 JhFtM9GOHolC for ; Thu, 3 Oct 2019 09:11:55 -0700 (PDT) Received: from smtp67.ord1d.emailsrvr.com (smtp67.ord1d.emailsrvr.com [184.106.54.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D845120104 for ; Thu, 3 Oct 2019 09:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1570119114; bh=qWlCkv9NLn7ZfX4PlcdKF7cESyauUtZ38YJ/4ggdiyc=; h=From:Date:Subject:To:From; b=CYNOFVeaDKNyE7rAFxzYOCT9vGDHlgyYviCd4Kw7eG8rH2+8Rfq/OV7GXwiT66aEA 0KK2K/H5nU/dIJGsiF05DKsiC3tZ/hYhckNiTRQ2RwyKKcsAaZpD6BAgiAulBXOWsu Zcnl8nTCM5YmdL1xVXGLYzuo8ZE1lr9219k2jJhI= X-Auth-ID: fluffy@iii.ca Received: by smtp9.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 74841C011F; Thu, 3 Oct 2019 12:11:54 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (d75-155-57-73.abhsia.telus.net [75.155.57.73]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Thu, 03 Oct 2019 12:11:54 -0400 From: Cullen Jennings Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EA78E5AF-6D69-40E9-B82F-268496CD25B1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 3 Oct 2019 10:11:53 -0600 In-Reply-To: To: Mary Barnes , DISPATCH References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dispatch] Reminder: BOF proposals due in 2 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: Thu, 03 Oct 2019 16:11:58 -0000 --Apple-Mail=_EA78E5AF-6D69-40E9-B82F-268496CD25B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi,=20 I would like to request time for two things=20 RIPP =20 and auto-peer There is also some chance of asking for time for a draft that is not = published yet./=20 At IETF 105, the time for the meeting got canceled before the draft = deadline so there was not enough time to have any reasonable discussions = in the WG. feel that significantly set back progress on RIPP. I hope the = chairs reserve a reasonable amount of time and wait until they have seen = what drafts arrive by the draft deadline to cancel it. Thanks.=20 > On Sep 20, 2019, at 8:35 AM, Mary B wrote: >=20 > As a reminder, the DISPATCH WG deadlines come up quickly after the BoF = deadline. And, of course, if you think you have a topic of broad = interest that might warrant a full BoF, you should be talking to ADs. >=20 > Here are the DISPATCH WG deadlines: > Oct 7, 2019. Cutoff date to notify the chairs/DISPATCH WG of plans to = submit a proposal/topic. > Oct 14, 2019. Cutoff for proposals (i.e., problem statement and = proposed deliverables) for topics posted to the DISPATCH WG mailing = list. > Oct 21, 2019. Announcement of topics that have been dispatched for = IETF-105. > Nov 4, 2019. Draft submission deadline. > That information is always available on the Wiki and there's a bit of = detail on the overall DISPATCH process that's summarized there: = https://trac.ietf.org/trac/dispatch/wiki = >=20 > We appreciate folks that have already started discussions on topics - = that makes it much easier for us to retain our usual two hour time slot = on Monday morning..=20 >=20 > Regards, > Mary=20 > DISPATCH WG co-chair > ---------- Forwarded message --------- > From: IETF Chair > > Date: Fri, Sep 20, 2019 at 8:41 AM > Subject: Reminder: BOF proposals due in 2 weeks > To: IETF-Announce > > Cc: IETF > >=20 >=20 > I wanted to remind everyone that proposals for "Birds of a Feather=E2=80= =9D (BOF) sessions at IETF 106 are due Friday, October 4 by 23:59 UTC. = Instructions for submitting your proposal are available at: = https://www.ietf.org/how/bofs/bof-procedures/ = .. 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= >=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://www.ietf..org/about/groups/iesg/members/ = ) about your idea if = you=E2=80=99re thinking about proposing a BOF. >=20 > IETF 106 will take place November 16-22 in Singapore. More information = is available at: https://www.ietf.org/how/meetings/106/ = >=20 > Thanks, > Alissa Cooper > IETF Chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_EA78E5AF-6D69-40E9-B82F-268496CD25B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi, 

I = would like to request time for two things 

RIPP
 
and

auto-peer

There = is also some chance of asking for time for a draft that is not published = yet./ 

At IETF 105, the time = for the meeting got canceled before the draft deadline so there was not = enough time to have any reasonable discussions in the WG. feel that = significantly set back progress on RIPP. I hope the chairs reserve a = reasonable amount of time and wait until they have seen what drafts = arrive by the draft deadline to cancel it. Thanks. 


On Sep 20, 2019, at 8:35 AM, Mary B <mary.h.barnes@gmail.com> wrote:

As a reminder, the DISPATCH WG deadlines come up quickly = after the BoF deadline.  And, of course, if you think you have a = topic of broad interest that might warrant a full BoF, you should be = talking to ADs.

Here = are the DISPATCH WG deadlines:
  • Oct = 7, 2019. Cutoff date to notify the chairs/DISPATCH WG of plans to submit = a proposal/topic.
  • Oct 14, 2019. Cutoff for proposals = (i.e., problem statement and proposed deliverables) for topics posted to = the DISPATCH WG mailing list.
  • Oct 21, 2019. Announcement = of topics that have been dispatched for IETF-105.
  • Nov = 4, 2019. Draft submission deadline.
That = information is always available on the Wiki and there's a bit of detail = on the overall DISPATCH process that's summarized there:  https://trac.ietf.org/trac/dispatch/wiki

We appreciate folks that = have already started discussions on topics - that makes it much easier = for us to retain our usual  two hour time slot on Monday = morning.. 

Regards,
Mary 
DISPATCH WG co-chair
---------- = Forwarded message ---------
From: IETF Chair <chair@ietf.org>
Date: Fri, Sep = 20, 2019 at 8:41 AM
Subject: Reminder: BOF proposals due = in 2 weeks
To: IETF-Announce <ietf-announce@ietf.org>
Cc: IETF <ietf@ietf.org>


I = wanted to remind everyone that proposals for "Birds of a Feather=E2=80=9D = (BOF) sessions at IETF 106 are due Friday, October 4 by 23:59 = UTC. Instructions for submitting your proposal are available = at: https://www.ietf.org/how/bofs/bof-procedures/.. 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://www.ietf..org/about/groups/iesg/members/) about = your idea if you=E2=80=99re thinking about proposing a BOF.

IETF 106 will take place November 16-22 in = Singapore. More information is available at: https://www.ietf.org/how/meetings/106/

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

= --Apple-Mail=_EA78E5AF-6D69-40E9-B82F-268496CD25B1-- From nobody Thu Oct 10 18:11: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 3EF0512003E for ; Thu, 10 Oct 2019 18:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmTJ4aZWWNoJ for ; Thu, 10 Oct 2019 18:11:46 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207: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 0CE17120041 for ; Thu, 10 Oct 2019 18:11:45 -0700 (PDT) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-01v.sys.comcast.net with ESMTP id Ij8bijuV3et2yIjT7iSN8q; Fri, 11 Oct 2019 01:11:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1570756305; bh=PyVp96pYi/nXCaLppGPVRjNlSk+5PkdaqwPNiVXX6kE=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=GJkENTdTrOwapKAcA+WrQRzmTL93mI0YXP9QKLu5ssp+wLLLkuy45Irlo16G5TUIa 32YGy0CL7hybaVKRxS1ChUuWLQMOYCdSlIbuYw/NYcdT5lzvgkOH1hPhITgPOgXylG rIHfTMWKDF+mcyEZqiY/8qbM08GCThePg9wbkV7kTH9gsnAaN1GfrAn23EGcIPvE9t lSMklsohyqpdi4A2avc4BJFtRWyq3WgW2nPnJLOXYEvh35BziJqH0ok5xndYZIsaH9 gTC148798Q9F5gjJxdgmclLodSCjJYr5eRv5DhtRm18GIRVB8JRpv+bzgNpJ6UoET+ LLaKhk6tliXhw== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4600:1e00:222:fbff:fe91:d396]) by resomta-ch2-03v.sys.comcast.net with ESMTPA id IjT5iCyjhyhXHIjT6irfAg; Fri, 11 Oct 2019 01:11:44 +0000 X-Xfinity-VMeta: sc=-100;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id x9B1BgkM001480; Thu, 10 Oct 2019 21:11:42 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id x9B1BgJE001477; Thu, 10 Oct 2019 21:11:42 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Ranjit Avasarala Cc: dispatch@ietf.org In-Reply-To: (ranjitkav12@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 10 Oct 2019 21:11:41 -0400 Message-ID: <87lftsozle.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [dispatch] Fwd: sip ue-addr contact hdr parameter 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, 11 Oct 2019 01:11:47 -0000 Ranjit Avasarala writes: > I am looking for an I-D or RFC that describes the syntax and behaviour of > proxies receiving ue-addr parameter in SIP INVITE and when they do and do > not forward it further In regard to parameters in the URI in the *request* line, the RFCs give a device complete flexibility in regard to how they modify that URI before forwarding the request. In regard to the *Contact* headers, proxies aren't supposed to modify those at all. However "B2BUAs" can have arbitrary behavior. Dale From nobody Tue Oct 15 16:55:09 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 A28DF120825; Tue, 15 Oct 2019 16:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 de8PJA8Cz8RM; Tue, 15 Oct 2019 16:55:06 -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 7421C120019; Tue, 15 Oct 2019 16:55:06 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x9FNsw4s074238 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 15 Oct 2019 18:55:03 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1571183705; bh=qccM11TtOO5V+sfxM5S+aQ+EN+gBlDDZ07SuZdy1fpw=; h=To:Cc:Reply-To:From:Subject:Date; b=XjJ1UTDw8CJlX0xnQJ20k71NEl1wxsTILHlJX4zTkNyThJO08JKQcUtPwblCNzJoI 41Tu02lOfTyFy6hHUvgAVkDioBijQrS9+//KBNL5Xi6KWiNLm+cYHi0N7TfKwi8oB7 a8lVD3HNQ9JwiqxM29NZxy4QvaP8JQwTe+UAlWHM= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Applications and Real-Time Area Discussion Cc: "dispatch@ietf.org" , HTTP Working Group , "art-ads@ietf.org" Reply-To: Applications and Real-Time Area Discussion From: Adam Roach Message-ID: Date: Tue, 15 Oct 2019 18:54:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [dispatch] Last Call for Comments: draft-nottingham-rfc7320bis (BCP 190 update) 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, 15 Oct 2019 23:55:08 -0000 ART community (cc DISPATCH and HTTPBIS, but please respond only to ART): Based on conversations on the DISPATCH and ART mailing lists this past summer [1], and on in-person discussions that took place in Montreal, Mark Nottingham has produced a revision of BCP 190 that takes into account community input on several points. The changes are all intended to be relaxations of previously-enforced restrictions on how URI namespaces could be used. The revised document is at: https://datatracker.ietf.org/doc/draft-nottingham-rfc7320bis/ And diffs from the current, in-force version of BCP 190 can be seen here: https://www.ietf.org/rfcdiff?url1=rfc7320&url2=draft-nottingham-rfc7320bis-02 This message is intended to serve as a final, two-week last call for input from the ART community before the document is put forth for formal IETF consensus. The final consensus document will be published as a replacement of RFC 7320 (formally, it will obsolete it), and will become the new BCP 190. Please provide input on the document on the ART mailing list (art@ietf.org) by Wednesday, October 30th. To prevent the conversation from becoming fragmented, please do not respond to the HTTPBIS or DISPATCH mailing lists on this topic. Thanks! /a ____ [1] https://mailarchive.ietf.org/arch/search/?q=bcp%20190&f_list=art%2Cdispatch From nobody Tue Oct 22 21:08: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 5573312022C for ; Tue, 22 Oct 2019 21:08:39 -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, 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=bt3olme/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rNhD3lzH 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 t2aR8vPyNlYe for ; Tue, 22 Oct 2019 21:08:37 -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 2540212000F for ; Tue, 22 Oct 2019 21:08:37 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 80E7221B1B for ; Wed, 23 Oct 2019 00:08:35 -0400 (EDT) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Wed, 23 Oct 2019 00:08:35 -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=fm1; bh=O9bTL3wTfCxo9hV12OIwlZlbeORkpJtOtyuMTr8 /BTg=; b=bt3olme/xXUicnqd+WVUvk6vuXDLPMnKRIhSaCcYcjLREDcwMaz/+73 OsQJbqlxzplzgqtpAj/vDMdOfpUgpYe7MVriMEn6wRjVbNqf7dG/r5GnfhRjOVoJ 7bALf2xTZBhdPp9OmW6edpfXUwsXVQhJ7A6WPukWwXd8sqIvYmwAYtZ7yrcFpxeG V9O25Ra6ako7Jo+UzMN5eqtLeK6h239p7bMCMR4hX2tGLv0Ub59UI35hFsjJzrxb ORj9CxhslvhH8uPTC0wiWPlT8hNXeEVXUHszzScrCHuX7shXRorua0lH9P+e8FcA DRmp4fb6gsVOI41KEQIqv0jivtDztHA== 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=fm1; bh=O9bTL3wTfCxo9hV12OIwlZlbeORkp JtOtyuMTr8/BTg=; b=rNhD3lzHUfAJN07US5gfJbr61D8l6v6pICnNVGMypqDgs QmqSUQqVApIthsuKhg6kU/wyFslq+N17DFrDaQn2CXs5I4pRXG2c9wF85R8a26rl 0x0oMtL8YTsS7rJXeI9gWgNGvedWmyUgZyGzuU0cowGY+eqgO8a6Z9og+bQIcssH rmjuPL8OKxbN4Dhxz7aBWoGQfjaTDjrDAVMZEaqkGw+VKoXFF0QlC1xu1QbNutlY oaeMURzJwdVubfgYrUJniwQXzw/JyC2GJ2xjFK12lyuEgUdMmJApWfpd24XXbojw aj+UP7aXCd5ZJ+tjXxum2PE1EM4l+jtL351gTsfFA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrkeekgdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpih gvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhm rghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 429F431C7F1; Wed, 23 Oct 2019 00:08:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-470-gedfae93-fmstable-20191021v4 Mime-Version: 1.0 Message-Id: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> Date: Wed, 23 Oct 2019 15:08:34 +1100 From: "Bron Gondwana" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=87bfec6cade24d329dd2dbb9ac419ef2 Archived-At: Subject: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV 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, 23 Oct 2019 04:08:39 -0000 --87bfec6cade24d329dd2dbb9ac419ef2 Content-Type: text/plain There's a couple of interesting things that have been going on in different places that I'm working on trying to get aligned and to find a home for at the IETF: Web push for IMAP servers here: https://github.com/coi-dev/coi-specs/blob/master/webpush-spec.md Web push for CalDAV and CardDAV servers here: https://datatracker.ietf.org/doc/draft-gajda-dav-push/ (there's a more recent version in the CalConnect private repositories - we haven't been pushing it just yet because the CALEXT group is already pretty busy, and we're not sure if it belongs there or in another group). And of course JMAP already has a web push built in with the push subscription object: https://tools.ietf.org/html/rfc8620#section-7 Anyway, I'm not sure if this is ripe for discussion at Singapore, or indeed if we've missed the deadlines for a BOF, but I figured if I post here I might see if there's any others working on similar things and if we could pull everyone together to join forces and make sure all the different push mechanisms work similarly. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --87bfec6cade24d329dd2dbb9ac419ef2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
There's a couple of interesting things that have been goin= g on in different places that I'm working on trying to get aligned and t= o find a home for at the IETF:

Web push for IMAP servers = here:


Web push for CalDAV and CardDAV se= rvers here:


(there's a more recent version in the CalConnect= private repositories - we haven't been pushing it just yet because the = CALEXT group is already pretty busy, and we're not sure if it belongs th= ere or in another group).
And of course JMAP already has = a web push built in with the push subscription object:

https://tools.ie= tf.org/html/rfc8620#section-7

Anyway, I'm not sure if= this is ripe for discussion at Singapore, or indeed if we've missed the= deadlines for a BOF, but I figured if I post here I might see if there'= s any others working on similar things and if we could pull everyone tog= ether to join forces and make sure all the different push mechanisms wor= k similarly.

Cheers,

Bron.

--
  Bron Gondwana= , CEO, Fastmail Pty Ltd
  brong@f= astmailteam.com


--87bfec6cade24d329dd2dbb9ac419ef2-- From nobody Tue Oct 22 22:27:47 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 2F78B120058 for ; Tue, 22 Oct 2019 22:27:45 -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 j0hzK0FXBYdV for ; Tue, 22 Oct 2019 22:27:43 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 76F74120024 for ; Tue, 22 Oct 2019 22:27:43 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id 21so901955pfj.9 for ; Tue, 22 Oct 2019 22:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=3ccESqdG9HrZEFzd0bPIWMDgU51rVnN5mWs2RMDcBaU=; b=ErB3KLJgjdyLUc3XmDTcHnU5Bt45uSyO12aqosXl5Q6ky1spcQwnvzvQTr/uDeVUms mrwQoq8wsDNi7DFCHQ6Pg+zxORHRhMFAFOiyh9cjoTL91BbjDqyAP1OMcg5GJ7LUrJ2u B9wj1wG3SdgbKPCbVVegNYf98WJoDud9Xe7iocWUfUeIodSiUOWCofWR2m+64NOCOMeP awV4OcCbo0Akz4hL/ka2Wz2OHlCwZkwCzuVCAw3fgTATM6b8JlDl7ZnwQrJ3285RDZ3T y4mIBoPX8pQNnMb+vZ1Xfoh7hJ6QU4tyY4pZCQFpig/RfbnBLivWtDqzbJ8Bg4+o7Qth +OxA== 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 :message-id:references:to; bh=3ccESqdG9HrZEFzd0bPIWMDgU51rVnN5mWs2RMDcBaU=; b=uOWGXZIyk5ynGfb9P2+TMOGHOF3rDFWF/RRVIMx5737C3LmQB8FyZKmQL4TeMkAk9O 8fU9gCEWMthWop4F6227RMy35xflKQ8X9EjnM1nBsPiU6z8IKDqtBt6WSBA66NERNwHz TzlaI3QffF7hZ0rYL2McbWXOptKUyn8RDx+iZEhkENkQ6Jfle3Gs4q1gma2GVxb+RjQi IvJInlkzW4LlBeLUggDSyKtw9z8k9ipfSRX278RQIdCnuhdblgOOhPLv9fvlGCQ+WMiN MAap0wfS0GVZV0p0FTNkO+/fYyCa2gE93uOZVzF/mb+5YQDF88v9ZYtKZUogP+l7YR6e PHXw== X-Gm-Message-State: APjAAAXnd1HSTHGFiYr7Ky5JDmozMFqUyvvXK7zjBRVG0hJGWGSd8JE7 G8rnkGZ+F1W34fOIAc5JTocxglKP X-Google-Smtp-Source: APXvYqxKYENWJ8JNEiyI9vcOomgMnv9QvOBS+45zuZPX5GUGcTnIqncuPBxdE4YpW3IrtyHJ7SJ4nQ== X-Received: by 2002:a17:90a:b78c:: with SMTP id m12mr9338751pjr.12.1571808462818; Tue, 22 Oct 2019 22:27:42 -0700 (PDT) Received: from [192.168.42.3] (135-180-2-130.static.sonic.net. [135.180.2.130]) by smtp.gmail.com with ESMTPSA id 14sm20823313pfn.21.2019.10.22.22.27.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 22 Oct 2019 22:27:42 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1941F27E-36CD-469F-BC6C-5A683BB89F09" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Toomim In-Reply-To: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> Date: Tue, 22 Oct 2019 22:27:41 -0700 Cc: dispatch@ietf.org Message-Id: References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> To: Bron Gondwana X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV 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, 23 Oct 2019 05:27:45 -0000 --Apple-Mail=_1941F27E-36CD-469F-BC6C-5A683BB89F09 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Bron! The work on the Braid HTTP extension also provides a "web = push". We are also trying to find a general approach. The current design allows clients to specify a "Subscribe" header in the = GET request, which tells the server to keep the connection open and = stream all updates to the resource, as they happen. We will be = publishing a new draft within the next week or two. > On Oct 22, 2019, at 9:08 PM, Bron Gondwana = wrote: >=20 > There's a couple of interesting things that have been going on in = different places that I'm working on trying to get aligned and to find a = home for at the IETF: >=20 > Web push for IMAP servers here: >=20 > https://github.com/coi-dev/coi-specs/blob/master/webpush-spec.md = >=20 > Web push for CalDAV and CardDAV servers here: >=20 > https://datatracker.ietf.org/doc/draft-gajda-dav-push/ = >=20 > (there's a more recent version in the CalConnect private repositories = - we haven't been pushing it just yet because the CALEXT group is = already pretty busy, and we're not sure if it belongs there or in = another group). >=20 > And of course JMAP already has a web push built in with the push = subscription object: >=20 > https://tools.ietf.org/html/rfc8620#section-7 = >=20 > Anyway, I'm not sure if this is ripe for discussion at Singapore, or = indeed if we've missed the deadlines for a BOF, but I figured if I post = here I might see if there's any others working on similar things and if = we could pull everyone together to join forces and make sure all the = different push mechanisms work similarly. >=20 > Cheers, >=20 > Bron. >=20 > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = --Apple-Mail=_1941F27E-36CD-469F-BC6C-5A683BB89F09 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Bron! The work on the Braid HTTP extension = also provides a "web push". We are also trying to find a general = approach.

The = current design allows clients to specify a "Subscribe" header in the GET = request, which tells the server to keep the connection open and stream = all updates to the resource, as they happen. We will be publishing a new = draft within the next week or two.

On Oct 22, 2019, at 9:08 PM, = Bron Gondwana <brong@fastmailteam.com> wrote:

There's a couple of interesting things = that have been going on in different places that I'm working on trying = to get aligned and to find a home for at the IETF:

Web push = for IMAP servers here:


Web push = for CalDAV and CardDAV servers here:

https://datatracker.ietf.org/doc/draft-gajda-dav-push/

(there's = a more recent version in the CalConnect private repositories - we = haven't been pushing it just yet because the CALEXT group is already = pretty busy, and we're not sure if it belongs there or in another = group).

And of = course JMAP already has a web push built in with the push subscription = object:

https://tools.ietf.org/html/rfc8620#section-7

Anyway, = I'm not sure if this is ripe for discussion at Singapore, or indeed if = we've missed the deadlines for a BOF, but I figured if I post here I = might see if there's any others working on similar things and if we = could pull everyone together to join forces and make sure all the = different push mechanisms work similarly.

Cheers,

Bron.

--
 = Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


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

= --Apple-Mail=_1941F27E-36CD-469F-BC6C-5A683BB89F09-- From nobody Tue Oct 22 23:50: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 6745D12004C for ; Tue, 22 Oct 2019 23:50:55 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUvaFY0J9l9Y for ; Tue, 22 Oct 2019 23:50:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 4F1B8120024 for ; Tue, 22 Oct 2019 23:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1571813443; bh=08LRA1J7bchUMLHUnLhITdM7V9Fj53ok7p/CQZTMq2o=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=jyhSTP18Kvix3B381xJt3vR6GT35Z7zdHxaFFR1B2LcWufmhRv3MZ3SD7j/5S8ngE p4zyw8xcmBo1mGJytgra174A7H8u8X2YFzhINl4Pm027v9vk10ZmdgNe4CuwimfL2Y demkpR9+bj80pMN3rzMEwqVJmaWPSGR6tyb+VSMw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.144.113]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MGQnF-1iF8gA2Djp-00Gqln; Wed, 23 Oct 2019 08:50:43 +0200 To: Michael Toomim , Bron Gondwana Cc: dispatch@ietf.org References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> From: Julian Reschke Message-ID: <839ea4e5-db2d-8220-6058-93869a29c185@gmx.de> Date: Wed, 23 Oct 2019 08:50:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:wgtcdk/ZJWR7UqLzIzzKMRBq1rhXVL4tROdudBaALTQNn3DYt7l oHUQBhRFunOixgbORZKQ0f8QLg8QgYHYvJ3VhOAXbZj+1tkgIhuZM44Y95/ainWzod0er9V ocPSLathCt/tN2Tvt7O9qr2h7ngNNqtnuOfZKaJ0WJldIDiBCam9BVi14zfGYTfarEbNHs9 VkEg6KSCrzmyziQmx1BbQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:Lx7NyizI4MU=:c5Vsi3H5iw5tl2mdql8WUg Dn5jBkU+IWAuVAOy7FZN+Fu+dulaNW0FY9PmWz+aI0LHfhqWoWGWaov8U5Z7nD1uRA1O7cYkY FkGmaWP49FDJIrr5HFVfaYohd0lu7MtlGCvfm2BjzDZclyMGfoQW/bq4BSqM5tQvl2wYTn8EP ena637GEMYLzCCj2RG1vfwD3yc/wuOtSqqpj4oYi7UGMH4SBzT4K8XcQkouxYzn23dAfqMOS7 vbXMZkE7bLnsoOf7EqdWcuasENnVMaGVgEXYvfDd72U2IonafeKrZ51ZNfshs45GoJwfZcX20 yuiGtJ74ueDb1mPPC2CfBorhMW+4yi6L8wjSrDYBmatcAgNbOaT+mRiAUGEr0FkKkM6EtD2YP w2N5TiUtMmmAtj2QHu8F7/V1Orz2QUGXaAq9L7cX1quHb+kELikmgTd6XZIRkhv6yGLYDo3K8 ptPWItd2Yycy352Q3YaFjV0094TSPpIunoVNeQOCW7OU8pf2LIcDvZl0EMEPVzgN/HFXz6gXo yQVLPkozShxQTUV4amKgxJCfARebBpESfaP6Zk9VUgPQ9V7T2261/iNgqmmUOmnyiPRu5iG5t zBrUE6rum8cce7thr02rEY4ffwt5ehvUtpFtaak9lmd9EFpLWiYOf4IL+CSZBHntSmC/dkubK 3EIJ+rwADV22VPpo7Fc9u52PVPlRh+iiGy7+rTsIdaL6bUuiRdTUO2ocGwwen6xrYRxOOZ78e irQLyfSYfGMynWXPwJfiyGBTqw8hzjKlKWQrFTQkr+wC50aDaRtMn4Jg1NnJRfYyRYBQidSao hX+JCPiJmIOwU1ledxo0f4NLAWGNESHG1es0zIS3EjATVTLJT0ciQsXYlKzoy62MKuDiSY409 p+p+6M08gK2iwVMDek15hJt3W1uTZA2GgD+SrJqAmCocZpk77Ha8WBb949Dj22lPLcv7QrSny mHnjCxLXSek1YGaTCx205eZNz85aE7PTmBhQ4aCHQN5hHdRXPMgsxCZZUHqo/9eWHFH2fP37l uol3c8GISt7uKmHIErUOd4ZWG+AL3XKRpkglfvJqj9ZkbtjyaKqZDNV6V9cBf7K5568uxLsgi Zs+iBWRbNrpVa5ATJz9MDcYSOijGQmSdIr5KxQLX1HaQ0AbbLMqnMpZnqTwK8tqX+3Vsc4tIv +enPEKx3nVSW9uIyqPjd+dqBwoaEhfiPmLqxrGUAD3YrAuM7KXRz0irZklCzDzpnXd3JObDg4 oHFqsglJY8Ru7faMAwpoovvHAblgVxyPyWSudEtl9P4MSy+E1fpqUErZFb1U= Archived-At: Subject: Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV 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, 23 Oct 2019 06:50:56 -0000 On 23.10.2019 07:27, Michael Toomim wrote: > Hi Bron! The work on the Braid HTTP extension also provides a "web > push". We are also trying to find a general approach. > > The current design allows clients to specify a "Subscribe" header in the > GET request, which tells the server to keep the connection open and > stream all updates to the resource, as they happen. We will be > publishing a new draft within the next week or two. > ... Why would you need a new header field for that? Best regards, Julian From nobody Wed Oct 23 14:22:25 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 E6CC81200EF for ; Wed, 23 Oct 2019 14:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 KBrMTtJ_uH27 for ; Wed, 23 Oct 2019 14:22:21 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 55CEE1200A4 for ; Wed, 23 Oct 2019 14:22:21 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id b128so13729681pfa.1 for ; Wed, 23 Oct 2019 14:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9OG4QRNlPvvosjPfFmyDd8uYPQ5ZeO/0PeaGtOxl2po=; b=OASBqhzdCeiPxcu/HmKatG3XeKSPVtWm2P/Q/Fr/lkMYRndwLc3sWeTmNHYXUSrNuB kC5gPP0pDVhi9O5GWz3NGhEtrGDXqbQvvruAy++QDqUK0tZRaz0jUqdk7IDBNT4oEUi7 ctSZJwR14BlPPqO1JA0dZTXG37sA5h2yed6zfDfdJYZout5wv8ZG2q4MOdeqPJtfxIsU oDjuwWfsRi48zBYpeQ5yb8m1oDokb3o8RJ4ukUE/zNiOBBQB2QgXkF2z1EjKifR2uYl+ U9HDBGJCxXzdLqXWF85t5GUXz3n2N/wKqktlbZr/BXWwRu4zeXer8A8NZA+82ArdsavA G67w== 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=9OG4QRNlPvvosjPfFmyDd8uYPQ5ZeO/0PeaGtOxl2po=; b=K+ro8wgKWrmdrHaWkZI4tV6pxxr9jF6T/2nASWJGmOnoxD9SLMj/tznTmp6zC8XVxl CtikCncTfgABSCH9a5bV6gu1FRZdWayKWUxU/3f0x5P/kcddjEVRgQZt6O/ixsUT+BPw bpixyENgCzwuSqf9IkY+YG66Owo/L7TI7FNsf9p0743MgLHMCLtI7VaL1GXG5PdOejtq nc1SkinUDOAFFEEovyEE5pxZtksvGDiBPKrjqXVgLjrEUaAh0IJ826z6n78YHoWG0nSE cvg2bgsmuD3V+yMrLlB9eG4b+zxJxQVyahTgW2z4n115wvtuHBRX5nv2OJEkCXu96+Hw EB2A== X-Gm-Message-State: APjAAAXX1IaXiHF8xDGAPtLyE8VwWj61JxXCs32n8fc5AZT+kGKrky5Z TCLR61NPuFZiC+sqhAI72OE= X-Google-Smtp-Source: APXvYqxV2NAmV/Pl6u1Maw8CTy3PpFuZtF/n06HcH38PokdGN7MpaRlA1o2JapvQzw4IM/V8nq8gmQ== X-Received: by 2002:a63:68c8:: with SMTP id d191mr12016505pgc.197.1571865740750; Wed, 23 Oct 2019 14:22:20 -0700 (PDT) Received: from [192.168.42.3] (135-180-2-130.static.sonic.net. [135.180.2.130]) by smtp.gmail.com with ESMTPSA id r30sm25093116pfl.42.2019.10.23.14.22.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 23 Oct 2019 14:22:20 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Toomim In-Reply-To: <839ea4e5-db2d-8220-6058-93869a29c185@gmx.de> Date: Wed, 23 Oct 2019 14:22:19 -0700 Cc: Bron Gondwana , dispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <82F33D05-D8BC-4F69-A198-677773F3427C@gmail.com> References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> <839ea4e5-db2d-8220-6058-93869a29c185@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV 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, 23 Oct 2019 21:22:23 -0000 Julian: > Mike: >> The current design allows clients to specify a "Subscribe" header in = the >> GET request, which tells the server to keep the connection open and >> stream all updates to the resource, as they happen. >=20 > Why would you need a new header field for that? The header is just one way to do it. What we *need* is some way for the = client to signal to the server that it wants to subscribe to changes. = Right now, a header on GET seems to be the most elegant way to signal = that.= From nobody Wed Oct 23 20:32:33 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 BE74312010D for ; Wed, 23 Oct 2019 20:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHkxssIX-Fiz for ; Wed, 23 Oct 2019 20:32:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 B268B1200F6 for ; Wed, 23 Oct 2019 20:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1571887937; bh=SbrdViMHp+HzQHAzHysO5sZeHm13qqWbXd3giHOGMJ0=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=aM/4iW35NzG07axdGrcoJTkbXFL71cLqxDm9hWI4X19ogUIBax8BFwQROdaXl6b2/ obZmw7M2viBcU+/RNSvIISmA9lsDdPL2zCTOkztzzvKWtkIN1C+4qWYqSmr/jdpCV8 HPSekW4bjSn20hQFlsYvQtAj/4XqOUN140a2UPFw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.146.174]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MoO24-1hdQkL3CJ6-00oopV; Thu, 24 Oct 2019 05:32:17 +0200 To: Michael Toomim Cc: Bron Gondwana , dispatch@ietf.org References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> <839ea4e5-db2d-8220-6058-93869a29c185@gmx.de> <82F33D05-D8BC-4F69-A198-677773F3427C@gmail.com> From: Julian Reschke Message-ID: <11cabf2e-1550-53e5-60dd-7d1bdf65805a@gmx.de> Date: Thu, 24 Oct 2019 05:32:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <82F33D05-D8BC-4F69-A198-677773F3427C@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:tTa/UpEb7dcB+vFtzQ1BGDSDb6DiaicL0eepinD3/eBIJzJXS6p LplKFr9v/GdaSzt/+gSfZLJdqlgpgnuGcPkuvZGT3ZBUMYRGfzIFPwAT9h44TEKIXjckPln 3IF6Lcen/AFBWRt4euQ/svZmatC0aaFQtS2hvlc/0xw948D9vInkoYT3kEkIwyshpe33AIx EK9joThjSJH3/rrPV77XQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:F5p5/gdUFLE=:JEDLDQcUbhw9a7g4YF5Y0W U4oOCznJWCmVbgWRVnaRfc9HSG4+bQ3qd+UajZ1pRJFYsDrpIFNStOMRRcfXkUJG6nDEmg7cU YgZjqqEPs870qIW+Z7Z7KMPQufCuVQhf790MA8Mopc3gZLZ6YjP2xOw0caRyhvEEOoPApLCLv NJsp53HP5WNUX5gATmdapYLqESpH+5DOqI5v55zgRqBBLhuhE258lq2B65wlqJnXM4l2D4G/m P/Jj8jw25mwEAIrCuqvvFATDsL6Qa85/t84L+sfV0D6DJz7hodmJdhrUm6ht2zDH/Egy59gNg kgYqJJPB+UYN4VGjxMTHQ8zNHhzHIDjrEYXfdjji9h/jr8PnJ5oAqXgcOGb56DzhDkNZe3rUA BtG3AMu/ThZiR5sJRJAloC4kxmA74fpD4ecEXxPa+DM/hDpnHzcLKvHB38UuDIma0WJFK8s8V HseCvwI6dpo/BQK9UymOG6DUOpyP7x+O736XikvSIvbvsBufuuMiljswjsb3mP7UZV+2scvZ0 /n1n6pQlzyXZYddknugKCE8z7lEYW9m9PPl6kFYAWJc4ITOPNsVMywEtm4o/AYMGomj73lh4Y BfVyV8xOdyrtZZeanhm+jdjEllfVOdXm11q+/YLpInj5FH2MhqQjha/eomHL1qzKmxIwxUQAz O2x18Bhu8MvrZCHrDsLdWlCkKsF4cFvdaTLIWALao6/IXkvv9geXtwtDloDjVv3TjF0tTgCkX JYB9gWy+5uMH1MSGGw3ZZW9U2vHF5n9GxXAaPMMJKb5Ld/ZiAkeLa9F0a/LXaVQ+WaUe1D5El naqPRkLTcIpC6JbzuFJqrImDYWiquStXxcVIkoso6yXogxKyxIsipaitRp8HIJAWRIvkY/ut7 e0+xDY+BV/RTJQPDJPrATKGdiKQiwbHLVY8Fv21N/wLKLyK59M/4ggmDI+jA3Ypc859mc6/4A 0+KXYwL3qgf5ZKsvJS/ckhodSbu9fABIoL4QuQ/E/159Z3fBs5hrMmXZwaPl745cIvmfNFFjJ OzURvxIM0x1RUE9A2NXiIcvxHYn1srPkJg0Y9lmh2Xh6ohuS+czcvmxtJRlhtAkgKxFpdeVb7 ozdpwVIjck5//yoWq/sMHaXh4Hcg/kItQQNnbbKl8MuXkxGo3a1C6ILxdfgbjbcFhm+B13R5v Pjjyc4QURJ3n06/NxEsg3YPRbdh4GW3YV+w4v4oY5zMvxoVU81SplJXqw3I47FAH11jXPlrML gF+jeMv6acDRz4EEwCTI0Cc4zOnKztRad6GG0QQ5iKqmOKiH5zky8o1CAZ2c= Archived-At: Subject: Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV 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, 24 Oct 2019 03:32:32 -0000 On 23.10.2019 23:22, Michael Toomim wrote: > Julian: >> Mike: >>> The current design allows clients to specify a "Subscribe" header in t= he >>> GET request, which tells the server to keep the connection open and >>> stream all updates to the resource, as they happen. >> >> Why would you need a new header field for that? > > The header is just one way to do it. What we *need* is some way for the= client to signal to the server that it wants to subscribe to changes. Ri= ght now, a header on GET seems to be the most elegant way to signal that. My gut feeling is that you should define a media type that handles this kind of continueing-to-update content, and then just use Accept: to tell the server... Best regards, Julian From nobody Wed Oct 23 21:24:22 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 5419D1200CD for ; Wed, 23 Oct 2019 21:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 tYQM1EAdMwWu for ; Wed, 23 Oct 2019 21:24:19 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 00C9A12006E for ; Wed, 23 Oct 2019 21:24:18 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id q21so3123773plr.13 for ; Wed, 23 Oct 2019 21:24:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YWyZDEkA7+sQIhBhMxvUwLo+bO/kNmqNGD8RB3ilWxE=; b=CgNvi3uefruILJWWdHEZgCT+ywcRIs6I2S6LwUWKxVUL5zAUkeUc/tcAICHLT/xOzf y85IucQM6IR4ievAG16BMIRqHcSVIG82uZzTKxEv0anFv/jeBELaLQQ4GI0axlIG1SLl NShUes8t75kjT0uYTpERkgw6Nf45dr7oBLe4mFD7foQdQRrhNKDlUnecZNRqmElH65CD QBKKPyDqdenF5B2A1UhdMPEvucS6LyNOrqci2+LO8g4DcYiZiXiD9sHeRpE5Bd3uHsYU HP5tg27iVr7xgO3s3vFv7a75QWbr0oWoHORMDgwZk/ggamDz2+JKeEhKUVfkZSlTclak JEEw== 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=YWyZDEkA7+sQIhBhMxvUwLo+bO/kNmqNGD8RB3ilWxE=; b=konSCQ4dGKEY4QN50Ky7WW9alzlWZCgnImompPWfwPUniP4UUWf34kaZr5uPdc9ymK T/AjWDYV9JuhRATEmcVSpiFSNMxiBt7VizEglGR9f6rt18N0mn4IpAN2jIzl3sMpM+q+ cDV6bApmxL7w32aC0+nYocOGzCLUqwxgP69M17T0dEVkTzxxTssMn7rEv7YZWjh0182w 1yM2l7qo3zkYOAFBfQghf6e7ayPE/k4YKQH7BaD48/MwxOPybrepjX/qqngLzLA+csFo bZCaAd2nrSbDs/pC4QoYW2KHVdg19Y92xPK7SC4KYBbFVaehvST1HrZOc05Ypw4pBz2N 68pQ== X-Gm-Message-State: APjAAAX0CI1AMNyaP4avkvOy7q6mwcd5ChePIG4l7Vu8TwLPx+f1/1ig aJuThTcfgKPmJJEPUYL1C7c= X-Google-Smtp-Source: APXvYqzlLfhRdfGiGcW8l201wD6oEEkk/W7zR+eA8MckkapQRrYhR2ZRgiMKS5BUMjIXhXaWlaSikg== X-Received: by 2002:a17:902:561:: with SMTP id 88mr7588125plf.40.1571891058428; Wed, 23 Oct 2019 21:24:18 -0700 (PDT) Received: from [192.168.42.3] (135-180-2-130.static.sonic.net. [135.180.2.130]) by smtp.gmail.com with ESMTPSA id u11sm34644170pgo.65.2019.10.23.21.24.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 23 Oct 2019 21:24:17 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Toomim In-Reply-To: <11cabf2e-1550-53e5-60dd-7d1bdf65805a@gmx.de> Date: Wed, 23 Oct 2019 21:24:16 -0700 Cc: Bron Gondwana , dispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> <839ea4e5-db2d-8220-6058-93869a29c185@gmx.de> <82F33D05-D8BC-4F69-A198-677773F3427C@gmail.com> <11cabf2e-1550-53e5-60dd-7d1bdf65805a@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV 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, 24 Oct 2019 04:24:20 -0000 Julian: >=20 > My gut feeling is that you should define a media type that handles = this > kind of continueing-to-update content, and then just use Accept: to = tell > the server... Thank you, Julian! Our spec works for any media type. You can apply it = to existing HTML, JSON, or images. It allows CDNs to get live updates = via patches, of the existing content they distribute. CDNs will be able = to support dynamic content, not just static content.= From nobody Wed Oct 23 23:38:09 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 6065512080E for ; Wed, 23 Oct 2019 23:38:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dF8GY2E9Hfcz for ; Wed, 23 Oct 2019 23:38:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 2D57F12000F for ; Wed, 23 Oct 2019 23:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1571899079; bh=9qlRf1ZJYU3r+7AB8fHKq0kGINsvebYA2snnJ58CK4c=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=BQflp2GLe6ftV949f6KXpDf2zwb4xxa7TXOTeJgaZufKEb85YPkhFbK3t6ETeaBDj em/YZmwcxWWRyL+EnbnqPmWVoadOgqtuJlBPy/t7GSBCrTo946ximPr18h54BMLgVd 5KRKRXL5vVDEUN+F06aZ6pPff5RRqCqrCVVq4Xn4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.146.174]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MPXhK-1ibE4Q2MT4-00MgMC; Thu, 24 Oct 2019 08:32:48 +0200 To: Michael Toomim Cc: Bron Gondwana , dispatch@ietf.org References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> <839ea4e5-db2d-8220-6058-93869a29c185@gmx.de> <82F33D05-D8BC-4F69-A198-677773F3427C@gmail.com> <11cabf2e-1550-53e5-60dd-7d1bdf65805a@gmx.de> From: Julian Reschke Message-ID: <450f4113-7cdb-f65e-761d-9023e3d625bd@gmx.de> Date: Thu, 24 Oct 2019 08:32:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:v2wonFRS4+ZfBFf02G1A8bNGNFmP1LizdiLWhEnscUmq/O37JpN La+2JNH4D9JjxVA/mDhPooGRIeRbTdiQCmRf9DzZsujWEm45jl7BXR4KelO2coDVESBxtuw nPet8eiYgoSOVaBeNoqVTX559gcMRpKVpjIJEuAPnEeHNtNikp1kuoMD6uEq+UmprMsHVtN tSA84dH/mddkYHzatXoRA== X-UI-Out-Filterresults: notjunk:1;V03:K0:BHmoHBD5ON4=:fnUtgTC6GH5H6Nswx+JYpL Z3TQGu0V4Tv8TAAuxs9xjvP6osmxayPlM6y3lGVmsT5pRAaq/qgNr3JQ09c30RcQFvSXpuRiv voUIS+OZYm7zJI8wdxSjCJ9EoSeC95l51vDkXr6kHa5ATkn5Xr81hNcUbSCPPhXWyqCm891Ud p4BGE/K5oWKnCpE23OvF9oAqh3zDMxvEZNVi0lGeAxmSRHGuYB/Zz99wgG3r5XtLi96pvNs0l McWB4lKtgudqroXS8Tm4VZUVucEu3gs63I6FZts7N8yuMECyEMbajabeiCWFd+S+6OYO8OFbS 6GarB6bDQi7e2Y69PjgB/EJZmNxagTBl5U5V1w7YfKRiN6jlF95nylZB7EOySOcg2HKaqA7xD D18RfOH9trS9gvtSxBw83tAX4vcUSRaECgMf2LtDPXb/ke65xjUzRG0Ie6+EJELw4KbQq28G4 MpNXp6Mfs5qY3PpIMbz3xT3GxcQwf/aSF5SpeLLUe9FHPoQEJ2/2crDhpc8+wZRYH59MFh//q +YmjsOIH7Ri07+wkMJ8dVU4qbQjCvp0diVLpQviX3kL/SccFp86Qholts51OC5ZVcRpVEHQW8 t1Q0sQYu7+fyVmfkSR+5MLuicc66pOpmIBfnDAvrYcm2ioIR1Y0KzUzN+/BkcgYpr4AknZcN5 JJ1Ea1a0AzhdBEvV/Y9UFB65u22fbZXROfAn8VQVBXTaY9zHmPMa96bpYHGCVpjuEvJ+Gh8ev 8nCcitR/dOap+IfqiZoOE4KBuoq3JC1skW5nQH37dTK/4LMPflSR0oWadYuVM8+yvNTzZuQpi WIwvpW+BqhQ7dGD6rW44TLI9Ka4O6xvCuqQEuWSf7YYWdviarTHuo0fVQwHeDejeTIJksI0ud 2nhW9f1tct2nN0aQ6fYd+M/PgZqhl75RuGaIROMm4PRTpzLdn06nSweXJQHmzNtovkzLHfSTF ZgPZleYynIydh80so+vwONZ0aoO0Cpc5hyEJRNR0MubkXCXGHW61x5HYuAlQeV0Tklvsv+uX4 pzUiJ3VyrHqCtccasIk5zKKOhRlRSk2Y36jJ1HBO7MLyKbHopNbjRTaM09J9bL3tdjsNo+jrg sEd7ZgVoxuoORR1aRinm3yf2k7vYXu2VEkMsNh0tICZGvDj6mU39kSZAcJ/4iqj2jtk9HCe0i uIVQPcwx1Yl522TdR0M9hi2NzSTdu6tQcd0M0mFTqSwGRc0QDD3v4VxWLaKNBUrvbLbJr97xb nIZfV8OP9MYeJyb1j9bAiHg02j5sN7eTlw0FSKFhpPJ2NLV3bznCLeocf0XY= Archived-At: Subject: Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV 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, 24 Oct 2019 06:38:08 -0000 On 24.10.2019 06:24, Michael Toomim wrote: > Julian: >> >> My gut feeling is that you should define a media type that handles this >> kind of continueing-to-update content, and then just use Accept: to tel= l >> the server... > > Thank you, Julian! Our spec works for any media type. You can apply it= to existing HTML, JSON, or images. It allows CDNs to get live updates vi= a patches, of the existing content they distribute. CDNs will be able to = support dynamic content, not just static content. Where's the spec? Best regards, Julian From nobody Thu Oct 24 01:38:33 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 76D341208B6 for ; Thu, 24 Oct 2019 01:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 SAlMH4lLxeNV for ; Thu, 24 Oct 2019 01:38:29 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0: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 9FF66120814 for ; Thu, 24 Oct 2019 01:38:29 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id b128so14707514pfa.1 for ; Thu, 24 Oct 2019 01:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GsixY8OFgB1UxAe/GJplMaxGB5bEhtD5swH48aN9ktU=; b=fI2LASfmMzY/oSmrm+Fv7fYgJknATHWICq12JWqb4Ulb7dx7MsxHHlcyyrpp89SwS/ 3C0rI5jZwZ65qXpybC8u7j5UCCAq5WuHRUz6jDtP56D46NaxNYTOzaH2HGGRbSh5ARat eaepNO9UlOcMKXh65CY3P9/pTkgMidQ8cdeNxjkMQVvG+zgH0pKUSS0uSYKj3Ewd605y YT2HlxLE4bAlU4ghvHOtmn7u8KTBw+L1VnkwKGgHRTAfRYrYk5/vc/ijSkZBmE9+gz2g XznJtQNKkGiC5Frz8ZBhwfmRZ+6FGM5RW+iKa+vdNyEgZfv4jN577rCcPxdNAmeK4B+P xw2A== 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=GsixY8OFgB1UxAe/GJplMaxGB5bEhtD5swH48aN9ktU=; b=ZaQ1db2cd5FD+7bfEfWyiqsPuPboVZrAPwVuQgiQ8xir7fxFUb9cLOM+l89tllXv2X OnntrExJCVN7kmq3W+a7BLQ11tO0OyYURqfWlf9G5/mySjJaJNbkooLGfwPPbTl7wf3j 4uBob192mc8yOYWyiq+lleN+Sd2fiPPFW3ifDPlJ8mQ3WJqT1CwXdUbPANLvaOFOWBGJ /DmHO2LvMfdiArzXTs/kcmE4lqpREn7zXrqcxwQseFnb8Koz1aqB4ba1r/V7YnLKtcja zrMpC+4oJt8ra1C2TvrrpX3moTOliCn9v0JQb2c4zKFNArRZ/jY49JPrv6ZGHx4Uv21t VHew== X-Gm-Message-State: APjAAAX4npB8UV+wvVigPRf9Om3tlHhmNmfFI1nJj6VkyQWBVupBNO3j RB83aDAVespkqYIm2YPZi2c= X-Google-Smtp-Source: APXvYqz1NuekAAl8vuDygs8dsBUxDqoVelGQd1B/JBSMRRGQICv6QUqFw2jXoZxurbKz7ukE4wyu8g== X-Received: by 2002:a17:90a:328b:: with SMTP id l11mr1786801pjb.44.1571906308702; Thu, 24 Oct 2019 01:38:28 -0700 (PDT) Received: from [192.168.42.3] (135-180-2-130.static.sonic.net. [135.180.2.130]) by smtp.gmail.com with ESMTPSA id c10sm27628307pfo.49.2019.10.24.01.38.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Oct 2019 01:38:27 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Toomim In-Reply-To: <450f4113-7cdb-f65e-761d-9023e3d625bd@gmx.de> Date: Thu, 24 Oct 2019 01:38:27 -0700 Cc: Bron Gondwana , dispatch@ietf.org, Seph Gentle , Rafie Walker Content-Transfer-Encoding: quoted-printable Message-Id: References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> <839ea4e5-db2d-8220-6058-93869a29c185@gmx.de> <82F33D05-D8BC-4F69-A198-677773F3427C@gmail.com> <11cabf2e-1550-53e5-60dd-7d1bdf65805a@gmx.de> <450f4113-7cdb-f65e-761d-9023e3d625bd@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV 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, 24 Oct 2019 08:38:32 -0000 > Julian: >> Michael: >>> Julian: >>>> My gut feeling is that you should define a media type that handles = this >>>> kind of continueing-to-update content, and then just use Accept: to = tell >>>> the server... >>=20 >> Thank you, Julian! Our spec works for any media type. You can apply = it to existing HTML, JSON, or images. It allows CDNs to get live = updates via patches, of the existing content they distribute. CDNs will = be able to support dynamic content, not just static content. >=20 > Where's the spec? We're still editing it for publication, but our working area is here: https://github.com/braid-work/braid-spec= From nobody Thu Oct 24 01:48: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 AB7C31200B8 for ; Thu, 24 Oct 2019 01:47:59 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvu6Tj9L3wk0 for ; Thu, 24 Oct 2019 01:47:57 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 C7BD612006B for ; Thu, 24 Oct 2019 01:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1571906869; bh=iX7IXYmIVBRwt3IsQvzQAoWI3DbgZ2GG+OUhX51wIgs=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=V3GMZU3X4OAzKU9D++Oa9K/uI9AJjHqPTDCTnQaG+18Lvz7Sp4+ny0zr9dOEfXyJe KI/cbrB+AHf1BoppUNIbDDu+PSbN7yh56TmiOPc8GGadrhg/Rl9H2l9fCmpqx2tm+E OJfXmBK24J6+CmcRDLAGF7qSawIl5pptVQNkVsA4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.146.174]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MaJ3t-1iSh3R3uNR-00WFJl; Thu, 24 Oct 2019 10:47:49 +0200 To: Michael Toomim Cc: Bron Gondwana , dispatch@ietf.org, Seph Gentle , Rafie Walker References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> <839ea4e5-db2d-8220-6058-93869a29c185@gmx.de> <82F33D05-D8BC-4F69-A198-677773F3427C@gmail.com> <11cabf2e-1550-53e5-60dd-7d1bdf65805a@gmx.de> <450f4113-7cdb-f65e-761d-9023e3d625bd@gmx.de> From: Julian Reschke Message-ID: Date: Thu, 24 Oct 2019 10:47:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:lD+0hIdJbkoofFckqUnRPG2yn+DjLKiGCHiaIiokUHIQGvqS6+a XgsT7fWaTCgD+YwsAodgbHsDMrJHh3nBvBvMRNMKOCVJrmaUVz3qRWOt1rzrYsaZBksvvP0 DFy1ueZgdFmPmI+bPaaq2i3WZ9EgCgyM6cYyXTEsXwnioHE41l2SopYbu24nxw5agtEU903 Wqu4avgTcfYmV68Mu/cYg== X-UI-Out-Filterresults: notjunk:1;V03:K0:dFgHFlpP/40=:KKZZc4LfIgp+eQA27rfPob 3F4aF4XhmhWlIXmtISfZr8hiHtDtYh77XF/T+Dm7rOKSZLC4w4UAphcL1Vtv693TpR1F2dkwD JvYRgaX9ns/x6gowHvV7R1j+uqFxCkMkSXJpA3hTmSpLvFVK7SmZiEfLNM10sNlH2Wms46Zgs R/BLRQO6La67MOiBIHj8Hfx8idD063I6PsKmPQSavIe3lknfcS0s+pC7GJGl+djU+T0I2bC/3 F/dGGm0a15x584vQXKgDDUWM8ln8mQqVOmdst8Q+qWlaM5TRHO7LP+48Q6j28RV9GeIhHhBIh 2k425WDnzNPuD+OrfyiEtNmyfIYT+jaCQkwEbgC9EW/ZLO+vmv92ogSx6r49lHqA8y2R15z2y uEZS+8D7P/IVRTBp8zucPiIu15Iz8xhfhBmkXy+38mYMdupBMCGU/WmfR52dBu2G30MWTWZ51 r7I7l+ikEYJClQCsKB/nMLG7UvrCs+RpuFuNGbf9XAjxcn3O1tP0qvWUp/bkYk7DCvWbuKO5E VjES2O02l3yII4DCTShbhwDieQ4BnQJB1t841d3wWdHblsppR1jlqg+7tDP/8AdPA2K7vv2w2 JaJf0s4cpD3XUYasKoh1rxdIGtUM/ampuD8lDIRBHPv//2ZjQCZhMILOfaqdYpYP47Wx+HpqN 51JxnOcRF42xmJk4BpcL7D12snDDFO3/hxwMUbiFq0JZNELZVoU94sERSkfixxLFWqKX1fNtt i4qaExL1j0w4001ZXFuEBFQpP1hzeg58z2PBf7oXJWQfA7n/3JcVT3/Za5vYNxlXTsZ526Mrl Gp1L0ZObqWIn8h3QXquYbS2Xm3HGr9f3Z27fHADmqQ3+uHY3gOce+J4qjBrC+KLsteA5hgWqe MMg7/5JukI0WbIFIJ6n33kzwCUXEAsJ/HfrfHywMmIPvHiHnKov/oicQzKZO5TyesAl8C6UWd bcF4vTxL+kMeqjM/Cuawu26zJRwsY4Y+seRh/wEMpr2OcoaqkuobOSwUp6LwghywVkOuMdfGK ylKUJdyUl/+bqSalLxm53QWwNvzg90XZ51AMKVzK31brwOa4wEw2UIfREOUzN+XqDWbCxmOSi EwUAuSHS63o9F10IInpYosze3C0Ty4JhIJ0YSsIKvU4VvqVkSYigWedTJ6tI3t6x2eHGHQitz Lq4RlDfvEczyce9qPPe/YH3IweSUqVU0W70ge/aSrCQKMPhFgl0/FK04kQqfXSnwD9pogRCFi MoJlEXyrDredekO1ET+0tnkBoq9d+y/40hgRR3GZ4xx3icFDAy78//zWj8lY= Archived-At: Subject: Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV 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, 24 Oct 2019 08:48:00 -0000 On 24.10.2019 10:38, Michael Toomim wrote: >> Julian: >>> Michael: >>>> Julian: >>>>> My gut feeling is that you should define a media type that handles t= his >>>>> kind of continueing-to-update content, and then just use Accept: to = tell >>>>> the server... >>> >>> Thank you, Julian! Our spec works for any media type. You can apply = it to existing HTML, JSON, or images. It allows CDNs to get live updates = via patches, of the existing content they distribute. CDNs will be able t= o support dynamic content, not just static content. >> >> Where's the spec? > > We're still editing it for publication, but our working area is here: > > https://github.com/braid-work/braid-spec Hmm. I think you'll need to work on the proper labeling of things. Even if the client opts into this format, the Content-Type will still have to describe the overall payload. You're basically inventing a new payload format that can wrap multiple payloads. But then we already have multipart/*; it really seems to me you should be using that instead. Best regards, Julian From nobody Thu Oct 24 02:34:13 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 6F3D61207FE for ; Thu, 24 Oct 2019 02:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 7NHS8Ay2x703 for ; Thu, 24 Oct 2019 02:34:10 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 009AD120024 for ; Thu, 24 Oct 2019 02:34:09 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id y5so14775445pfo.4 for ; Thu, 24 Oct 2019 02:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=45kwT7fMY3KMfnR1rBkeiqqCaSwiZN8gh4oLvxaJkaE=; b=QjGFAcGNkZ0436BNQhrqbk7lAS0Hhoxfe0P08rNkSVrbrxIe4QAHUCPP6SPJNQoq+H yLYAjgvGkAqn5W0AnXd/al25LpMiWz4Dr1sF/Oew7LjFPt2diI5uAVYHH4mMe5GLfDB7 NrvDLvdQhcAxm5EjoyREjxqZhHAntTCcBTofwDqRVmJBJW5NSQ8Vr24ew+31Yl1D1K4H wVquxaHi0UBlQDsINRBtGFiUNVJNkQfiPv6ilRM3DL+SgyOfE5xyzSvPvXvmIWhMBmFg EHv17ElydPiTRIB7gQ88/Rqmm4cBHbvVsphprx8TihbGQgh03VaJsdN3gfiuvyQBTvLi urBQ== 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=45kwT7fMY3KMfnR1rBkeiqqCaSwiZN8gh4oLvxaJkaE=; b=aW49xps/GxYbMLkbES5i8F5emeAFaicQcpR5e93F3+gH3wl9oeL3bF/dM4WhV3gTOq KdzKeaVxM38rsr3FAlDjM29Ip2ZkoHA+sw0DLLvXzevO9R308/zSCW1jd88t/ZTBNwA+ x8m9JDsptfcN1/9eq9nd2yo7oVcRyNkF8A0dDGcGb6SkbHjK32VvfuH7IHB+PhiumtEE EPFZ1rbNLuUMod+QUUZcR9tiOr15mDqB+B81UkwhcsBTrnwFG44sySU9wAjhOmK+oYrd rNQ4HpNH7BcRzWzHqwnzfnJH8VDcoT6fpU2qyOusXEdWwy2pQMmOYhaTa/w+kDBlEZ50 yQWw== X-Gm-Message-State: APjAAAVaXn/T5PcsYfzNhtrnzb8N6XNg3toAZgxlP10NuIriZ1EINicK 7qYgSJQsTpRl7tYI8HVAkJQ= X-Google-Smtp-Source: APXvYqyt2rL9xRwENK5E0sbQNG6mU/WA1HEHlFRREFXb82K4uHVEYkCx8AsmsTCiQIwvdiONA/DT+A== X-Received: by 2002:a62:1b50:: with SMTP id b77mr3334287pfb.187.1571909649441; Thu, 24 Oct 2019 02:34:09 -0700 (PDT) Received: from [192.168.42.3] (135-180-2-130.static.sonic.net. [135.180.2.130]) by smtp.gmail.com with ESMTPSA id x26sm1892420pfr.110.2019.10.24.02.34.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Oct 2019 02:34:08 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Toomim In-Reply-To: Date: Thu, 24 Oct 2019 02:34:07 -0700 Cc: Bron Gondwana , dispatch@ietf.org, Seph Gentle , Rafie Walker , Bryn Bellomy , greg little Content-Transfer-Encoding: quoted-printable Message-Id: <34B388A2-50A7-4344-98B6-0D8B08E1277F@gmail.com> References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> <839ea4e5-db2d-8220-6058-93869a29c185@gmx.de> <82F33D05-D8BC-4F69-A198-677773F3427C@gmail.com> <11cabf2e-1550-53e5-60dd-7d1bdf65805a@gmx.de> <450f4113-7cdb-f65e-761d-9023e3d625bd@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV 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, 24 Oct 2019 09:34:11 -0000 Thank you very much for your early comments! Julian: >=20 > Hmm. I think you'll need to work on the proper labeling of things. = Even > if the client opts into this format, the Content-Type will still have = to > describe the overall payload. Hm, I think I see where you're coming from. Here's the example in my = mind: Request: GET /animated-braid.gif Subscribe Response: OK 200 Subscribe Cache-Control: no-cache Patch-Type: braid-patch(bytes, sync9(array)) ---- Part 1 Content-Type: image/gif Patch-Type: braid-patch(bytes, sync9(array)) Content-Length: 1239 [100:200] =3D ---- Part 2 Content-Type: image/gif Patch-Type: braid-patch(bytes, sync9(array)) Content-Length: 62638 [348:887] =3D I think you're saying that the Content-Type of each part should need to = describe the BODY of each part. Why is that necessary? I would imagine = that it would only impact a cache, but we rule out caches with no-cache = unless they understand the patch format. It seems to me that the Content-Type *could* conceivably describe the = semantic content of the resource, even though its updates are described = with a particular Patch-Type. Similar to how Range Requests don't = change the Content-Type, even though they are only sending a small patch = of the object in the BODY. > You're basically inventing a new payload format that can wrap multiple > payloads. But then we already have multipart/*; it really seems to me > you should be using that instead. I'm open to using multipart/*. Are there any advantages to it? It = requires the sender to come up with a unique separator string, which = means they need to scan all messages before choosing the separator to = wrap them with. It seems simpler to just use Content-Length: N to = communicate how to break apart multiple messages, and as a bonus, you = can stream the data and process just one message at a time. Thank you very much for your early comments!= From nobody Thu Oct 24 02:46: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 4DB261207FE for ; Thu, 24 Oct 2019 02:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, 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=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-WZ_-MFzeDs for ; Thu, 24 Oct 2019 02:45:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 5CF6D120024 for ; Thu, 24 Oct 2019 02:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1571910347; bh=KTc63ShOB2+iRRaTLdpdQ8HDPFXE/G4mdLhFmxshsIM=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=bWCUO+tsvjhGnRdTYFM1AAoaIlDEdkCgem8B1lve/UeW+dnF4S7nkz943PGS/Vd1q QREcbCqs2VE+weYoCRDsa78lk1GMl74F6S8U4VSk8KVO3bBG2zpSRKux7INGfKvfr9 WtCdCvwv0tDs1TiP+WlLqkBE9gL+UpNuLmbF+b9w= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MA7GS-1iHUsz2iAU-00Bg8Q; Thu, 24 Oct 2019 11:45:47 +0200 To: Michael Toomim Cc: Bron Gondwana , dispatch@ietf.org, Seph Gentle , Rafie Walker , Bryn Bellomy , greg little References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> <839ea4e5-db2d-8220-6058-93869a29c185@gmx.de> <82F33D05-D8BC-4F69-A198-677773F3427C@gmail.com> <11cabf2e-1550-53e5-60dd-7d1bdf65805a@gmx.de> <450f4113-7cdb-f65e-761d-9023e3d625bd@gmx.de> <34B388A2-50A7-4344-98B6-0D8B08E1277F@gmail.com> From: Julian Reschke Message-ID: Date: Thu, 24 Oct 2019 11:45:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <34B388A2-50A7-4344-98B6-0D8B08E1277F@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:fcP9pG8Xq4HAjyojmxXMRbCbAgStOUVjdSnkBjdvsjqVMg3vCgS cEw2XBXwDNyaGEJGL4WbtL6/qStnRWk/PAs5aHIRLfloghwmHn3fOfhDpYpjDsHUu+XqsMn DXsidXDTKgwcoi3oZV6//ap9mf5Uw2i/0wI29Pr2D0heLrcwryTCHxsi7hyjllzaZFmBoeq d8aGMOG6k/F4ktyQQsp3A== X-UI-Out-Filterresults: notjunk:1;V03:K0:buDduV+r8HU=:VAxYL2gu7CvZL8c/ySf2Sy IAhqNajN5Qdide7oo1D70Q9GOeMKZipf2TCJsN84RdMG2GSAXDt6tegTkXIfrYTnuaSzu2gHa 01HnE4jXNYE0Pcfn9L04awMWhYlCR4CtYbn9Hu0olacHlyrB5ltpLflqXBcvLWpkbxUUi/9GJ NsLGjzS5KIVz65wmnpQR50Nia5qMirABj6WeBO/FgI91t58cqbbsORmqUPSg7rqUDqooptbWI 3XWfoLcoWQweNIhsR/S0iEYpkd+OwhdyWUdr8bhUAM9VU/4bHmWwchjalB9OQDbnKHTRD8QZh 9cS30k6MvpHolKm6DXXGn5DIGndWnOuru8/1aw4an39jFP76sRawN1EBtlWHVgDoP28ZoTfuE xED7iWrIruwKKFyqk0iiifmCsP8ttlfN3W+MyBPBCI+Cb9zEcyt1NrUCr+i1QFrXPzYLshiFo I2SHip/+0+F5UIf0O5Q0KWVA2ULnvyg8RWLy7PExPK2WCplqeSqDECXCx8B2MxnR5uCtCsA6e WP5TrPTiJqGz8nY21KTJok1BWKeFvKvFk6XqcdsijSXc+xpvdGG0UiH9MDVC0TF2SgbEzqOnf BtlZMljNmAEIC9ZHsDsLM9LR3ww8JLGzh4wvr7OPCORfkDxWU+kBqeDUE54kEd2OaB6ootnu8 kEqOnVOL1wyti9B9hkX3jCno/hi4o/kh5ZA6RGlLTb0eizUE9j6VFC3PhS+RCbTMRDPAGcana rKc0AbfvoOhiDu8/a7PYzQdufGNdrHsZPT+dUruG8R9agMhinPvUPeEWYrni2rCSHv6EPeJdv lf06bz7y5b6YWCj+bXw7ziF5xN4o89iEeGWP/Lg/snivR5lZId1hZLQDTclTcHsDnOwuj0Ywm jFejRyj/d/rOqZxvq9IuSugO4jizUOdaby2IuaLjosxt3cI5728O93yZqm5rGrGNNTRYX1E/B 4cAIhjfSesma7bMYdtYp5UIUvNpzUsydzupWxMiwb0Z+H46F/LrD5KF/x5Bzy5mq9bqRYVyb/ dt0MNQpsEDJIRwziOT36ynzFj/JNN6x/aKuz9SkQ2wbpwcuU/h4o+3Fm0PwCjO5I1MZBAF/El Bv4aEVWQDBqnJtsrH9c1SSS2FGET/Q+jDX5j2I2b1wLRaANY5RKkgtwNzqikeVBqk6D7sFL4A Vsbwu+igFkJI6/06aWMmyJ4ssX2VX6MmKDOxXrFKDo5ACWiOUBQdsVrYLu6IumT1iGvfrmo2U pFoi5K0CEIOePAvOnj01j1Dc8iAT1pSpQAqEQJg4/+Xlkupv/aPUItzCW2cU= Archived-At: Subject: Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV 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, 24 Oct 2019 09:45:58 -0000 On 24.10.2019 11:34, Michael Toomim wrote: > Thank you very much for your early comments! > > Julian: >> >> Hmm. I think you'll need to work on the proper labeling of things. Even >> if the client opts into this format, the Content-Type will still have t= o >> describe the overall payload. > > Hm, I think I see where you're coming from. Here's the example in my mi= nd: > > Request: > GET /animated-braid.gif > Subscribe > > Response: > OK 200 > Subscribe > Cache-Control: no-cache > Patch-Type: braid-patch(bytes, sync9(array)) > ---- Part 1 > Content-Type: image/gif > Patch-Type: braid-patch(bytes, sync9(array)) > Content-Length: 1239 > > [100:200] =3D > ---- Part 2 > Content-Type: image/gif > Patch-Type: braid-patch(bytes, sync9(array)) > Content-Length: 62638 > > [348:887] =3D > > I think you're saying that the Content-Type of each part should need to = describe the BODY of each part. Why is that necessary? I would imagine t= hat it would only impact a cache, but we rule out caches with no-cache unl= ess they understand the patch format. Not necessarily every part... > It seems to me that the Content-Type *could* conceivably describe the se= mantic content of the resource, even though its updates are described with= a particular Patch-Type. Similar to how Range Requests don't change the = Content-Type, even though they are only sending a small patch of the objec= t in the BODY. > >> You're basically inventing a new payload format that can wrap multiple >> payloads. But then we already have multipart/*; it really seems to me >> you should be using that instead. > > I'm open to using multipart/*. Are there any advantages to it? It requ= ires the sender to come up with a unique separator string, which means the= y need to scan all messages before choosing the separator to wrap them wit= h. It seems simpler to just use Content-Length: N to communicate how to b= reak apart multiple messages, and as a bonus, you can stream the data and = process just one message at a time. > > Thank you very much for your early comments! And the end of the day, this is still HTTP. The response needs a media type that describes the payload. You are defining a new payload format that can handle multiple resources, so you need a container-like format. multipart can do that, but I agree the mail format legacy with the boundary string is sub optimal. But then, sending Content-Length inside the payload is a bit weird as well; it defeats streaming the part; you may want to consider a binary container format instead (based on HTTP chunked, for instance). Best regards, Julian From nobody Thu Oct 24 02:55:44 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 C4FD612007A for ; Thu, 24 Oct 2019 02:55:42 -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 G4Lr9-MwXbn1 for ; Thu, 24 Oct 2019 02:55:41 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 5DE50120024 for ; Thu, 24 Oct 2019 02:55:41 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id q7so14810373pfh.8 for ; Thu, 24 Oct 2019 02:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=IWud95icTFamCB4g1K4TET6Pg+6YkkO+A0enn+Oakig=; b=pyHfy8W2+XRaNrGP4t2F1y79uvlRCZ55YPFdKSQH3/rQr8t7O2NEwWAnVh9WFNB5uR xfccQB3nOtO68JOy2pUX8b2y1xtVTJTbfhh6k4NPe42A5ogrIsUleuMClQrN5X86oU9D LIUs0zRqmi35RDJAeRS6phf1rxKJIa4CuyRroh8TEUrUZuejHMSZZdY1Vv6ap0ok6gvp 5AAYloQ2CGqVXqwaC4AMMxreVI+fIOWc3nh39u8NF37ISpZNAlpLgxu91FLW+yJHhApR dlue+1pFB1uBQtGCIK4lPSAupMec72uS9+MKn77b3anXZUufQQ7lria5x2OBk+ChVQuF N2fQ== 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 :message-id:references:to; bh=IWud95icTFamCB4g1K4TET6Pg+6YkkO+A0enn+Oakig=; b=SXYV4zPPIXvMRp8pzwRGGpaLdbsSDnho0izK2aryJX76zTjV8Ldkxq1KWZtUW1P+0a SgUEzRtawHG+XU7jjh3VSpEo3G8x/o2xY/WC3bboF9r3Xmrdwd7vzX7P01vWRkb1I9H4 QsXDeEB/sJuGKbllZ42UvD1mEbOzdR+5mzoaqWyGnkuBD6XNKASMDkmOt9h6EWy8Rxhh Cf2PlcvmotdLSHXX650IyFtdeE4gyZwDeeYepvThcg4ktBQCCGI2Okizg9mtDQr2etDv MLPCtNndP5pDBc0HLhJOWmJbKTbh9wDVV5qkq9nOXQhbr3dW0QQbeiHrg/8aWxg2kfj9 NJPg== X-Gm-Message-State: APjAAAUKYGbFrLgQ8DdYP2j3yW4ODQZFk/gwaj/rHzVsjhdwdkDcHI3I 6Zvff6yc06eECKZ0Cjr7Xx0= X-Google-Smtp-Source: APXvYqw9b+skhO62nnQmuKEo+reE9kxanV5Cm/RsjNwZ3Do2sDUlszTOmHl59IAMfqoJTrXX298uPQ== X-Received: by 2002:a17:90a:fe04:: with SMTP id ck4mr5960408pjb.90.1571910940308; Thu, 24 Oct 2019 02:55:40 -0700 (PDT) Received: from [192.168.42.3] (135-180-2-130.static.sonic.net. [135.180.2.130]) by smtp.gmail.com with ESMTPSA id d10sm25208890pfh.8.2019.10.24.02.55.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Oct 2019 02:55:39 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5FDF5B8A-375B-4D3C-B34D-0219494C477F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Toomim In-Reply-To: Date: Thu, 24 Oct 2019 02:55:38 -0700 Cc: Bron Gondwana , dispatch@ietf.org, Seph Gentle , Rafie Walker , Bryn Bellomy , greg little , Braid Message-Id: <086C29B2-00BC-403B-8080-1AAE3A99D382@gmail.com> References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> <839ea4e5-db2d-8220-6058-93869a29c185@gmx.de> <82F33D05-D8BC-4F69-A198-677773F3427C@gmail.com> <11cabf2e-1550-53e5-60dd-7d1bdf65805a@gmx.de> <450f4113-7cdb-f65e-761d-9023e3d625bd@gmx.de> <34B388A2-50A7-4344-98B6-0D8B08E1277F@gmail.com> To: Julian Reschke X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV 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, 24 Oct 2019 09:55:43 -0000 --Apple-Mail=_5FDF5B8A-375B-4D3C-B34D-0219494C477F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Julian: > And the end of the day, this is still HTTP. The response needs a media > type that describes the payload. You are defining a new payload format > that can handle multiple resources, so you need a container-like = format. > multipart can do that, but I agree the mail format legacy with the > boundary string is sub optimal. Ah, yes-- that *is* what we are doing. Thank you for articulating it = nicely! > But then, sending Content-Length inside the payload is a bit weird as > well; it defeats streaming the part; you may want to consider a binary > container format instead (based on HTTP chunked, for instance). Ah, yes. Well, you can still stream updates here by breaking up a = single change into multiple patches. Then each patch can occupy a = different message. You can make them as small as you'd like; you'll = only face the overload of an extra frame header in http/2. I'm cc'ing the braid list, in case they are interested. [Thread link] = = --Apple-Mail=_5FDF5B8A-375B-4D3C-B34D-0219494C477F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Julian:
And the end = of the day, this is still HTTP. The response needs a media
type that describes the payload. You are defining a new = payload format
that can handle multiple resources, so you = need a container-like format.
multipart can do that, but I = agree the mail format legacy with the
boundary string is = sub optimal.

Ah, yes-- that *is* what we are doing. =  Thank you for articulating it nicely!

But then, sending = Content-Length inside the payload is a bit weird as
well; = it defeats streaming the part; you may want to consider a binary
container format instead (based on HTTP chunked, for = instance).

Ah, = yes.  Well, you can still stream updates here by breaking up a = single change into multiple patches.  Then each patch can occupy a = different message.  You can make them as small as you'd like; = you'll only face the overload of an extra frame header in = http/2.

I'm = cc'ing the braid list, in case they are interested. [Thread link]
= --Apple-Mail=_5FDF5B8A-375B-4D3C-B34D-0219494C477F-- From nobody Thu Oct 24 05:32: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 C72441200FA for ; Thu, 24 Oct 2019 05:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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=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 zSCebgaSnhl7 for ; Thu, 24 Oct 2019 05:32:37 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 53AEE1200E0 for ; Thu, 24 Oct 2019 05:32:37 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id a11so9790903wra.6 for ; Thu, 24 Oct 2019 05:32:37 -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=/qmyP0m78YUlwLZ0a3E0/xbBJg+L23mmeOUto+l7Ius=; b=Hj3JaPpL2V6bFUK/DlREI12DinKVqKxQQ2DyfLiABVKVyapg8ZXq3c8HE/pl7VkIGW FaSgGy5b8qkGc/oY4dJTDENUzqIubfEN5JnVfIT+7NNITc8PHLqWe7riuL/O9Dw1aKBB BB5UalQmIwJu5zKTdfQH7IXNeqVW3nmiorfG2xLwAB0yN02n/KAYb0rCvXMLn2QJ7TFy NDsh3xK5bCR6m9deZ/4VY+jRj6R/AEOhmg6YZ2lOfu2c1a5toD6VjaZJ5Q9YmosP27Yg xQVXo6eUKcGdhXhvSvRireV3GlENR+COsNtSi9LrKCEhok06n1tr0ltV6lGJrU1nF77U upTQ== 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=/qmyP0m78YUlwLZ0a3E0/xbBJg+L23mmeOUto+l7Ius=; b=Ep3IzqdVCqvGWGQoQunLlbgAUkhCnn8BNgdK1GmdRDKNBlC9r51K/J4oVpi4x2REIE Z+WnjRDBU308YA8AGbV3rhCPNf7Z16mryNDoQ1uqfFX4lFgCIqnILjC9GmkviwLfhuX9 D1JSOKuDd4B2v2idHJN0r/k3zdxbC3wE/QzjaryQZxTi/AfaXQeicfK84/836rawsa8i DkcJppS3SWgJBgSZpAlvk0n9H/5wEFZO7msTgY0tTNt4Zx1yQAcjDg8WTCg40UjP8sUS PYPgnb4UW+UQlBZ38oah4zeoD1buvHin6eWIy6nIm5en4RuPLFPBu7nY4ToUTP4p4E/A TonA== X-Gm-Message-State: APjAAAX7lq78bChbc0bTwqzbWoBY4oj8b6SYxrY/H7J3PFOhGdCOFDec 4A5HMvCf5WqUK2b+Qh+H9VR7b2mw5b0vwfCiCLY= X-Google-Smtp-Source: APXvYqzjUJG6Z3J2cEwcZ8kB7WBZshtcM1l8KIuS9y4jN6HTMbg4Xy+9Jqw4cuCBUr6VNdk/az98zDrnNlAZLHmzCfE= X-Received: by 2002:a5d:54c7:: with SMTP id x7mr3415599wrv.99.1571920355786; Thu, 24 Oct 2019 05:32:35 -0700 (PDT) MIME-Version: 1.0 References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> <839ea4e5-db2d-8220-6058-93869a29c185@gmx.de> <82F33D05-D8BC-4F69-A198-677773F3427C@gmail.com> <11cabf2e-1550-53e5-60dd-7d1bdf65805a@gmx.de> <450f4113-7cdb-f65e-761d-9023e3d625bd@gmx.de> <34B388A2-50A7-4344-98B6-0D8B08E1277F@gmail.com> <086C29B2-00BC-403B-8080-1AAE3A99D382@gmail.com> In-Reply-To: <086C29B2-00BC-403B-8080-1AAE3A99D382@gmail.com> From: Ranjit Avasarala Date: Thu, 24 Oct 2019 07:32:24 -0500 Message-ID: To: Michael Toomim Cc: Julian Reschke , dispatch@ietf.org, greg little , Braid , Rafie Walker , Seph Gentle , Bryn Bellomy Content-Type: multipart/alternative; boundary="0000000000006c06a50595a73a8c" Archived-At: Subject: Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV 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, 24 Oct 2019 12:32:39 -0000 --0000000000006c06a50595a73a8c Content-Type: text/plain; charset="UTF-8" why can't we use WebSockets which is based on HTTP and helps keep session active? On Thu, Oct 24, 2019 at 4:55 AM Michael Toomim wrote: > Julian: > > And the end of the day, this is still HTTP. The response needs a media > type that describes the payload. You are defining a new payload format > that can handle multiple resources, so you need a container-like format. > multipart can do that, but I agree the mail format legacy with the > boundary string is sub optimal. > > > Ah, yes-- that *is* what we are doing. Thank you for articulating it > nicely! > > But then, sending Content-Length inside the payload is a bit weird as > well; it defeats streaming the part; you may want to consider a binary > container format instead (based on HTTP chunked, for instance). > > > Ah, yes. Well, you can still stream updates here by breaking up a single > change into multiple patches. Then each patch can occupy a different > message. You can make them as small as you'd like; you'll only face the > overload of an extra frame header in http/2. > > I'm cc'ing the braid list, in case they are interested. [Thread link] > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0000000000006c06a50595a73a8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
why can't we use WebSockets which is based on HTTP and= helps keep session active?=C2=A0

On Thu, Oct 24, 2019 at 4:55 AM Michael To= omim <toomim@gmail.com> wrote= :
Julian:
And= the end of the day, this is still HTTP. The response needs a media
type= that describes the payload. You are defining a new payload format
that = can handle multiple resources, so you need a container-like format.
mult= ipart can do that, but I agree the mail format legacy with the
boundary = string is sub optimal.

Ah, yes-- that *= is* what we are doing.=C2=A0 Thank you for articulating it nicely!
But then, sending Content-Length inside the payl= oad is a bit weird as
well; it defeats streaming the part; you may want = to consider a binary
container format instead (based on HTTP chunked, fo= r instance).

Ah, yes.=C2=A0 Well, you can still st= ream updates here by breaking up a single change into multiple patches.=C2= =A0 Then each patch can occupy a different message.=C2=A0 You can make them= as small as you'd like; you'll only face the overload of an extra = frame header in http/2.

I'm cc'ing the bra= id list, in case they are interested.=C2=A0[T= hread link]
_______________________________________________<= br> dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--0000000000006c06a50595a73a8c-- From nobody Thu Oct 24 12:40:09 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 16E77120071 for ; Thu, 24 Oct 2019 12:40:08 -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 u22gR2Q5uJ2q for ; Thu, 24 Oct 2019 12:40:04 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 BD047120020 for ; Thu, 24 Oct 2019 12:40:04 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id x28so2301848pfi.12 for ; Thu, 24 Oct 2019 12:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=M3JtA+E816R1ct92aXoxxMc0D+VnvO+HKNFuMFgzsYc=; b=Fv4Xi6iFn6pB9KxtahuhwyO5A49oqlQXPUyR/2cPFtNp5BoLBhuz6Vwwf+CoD8HtyU VMk+aJev1V47NL9KjXN8LEgPMaFQdM9a7SFcsLN4RhDpMTXmVy0zKqAtZNm53P9VyWzV FPh7dYetzDAtysEDYP4+m1kVFQizf+NFYHTh+rd5RmD0Ttw9hY2UewSLLL6Aa95ebQzL nMmLwlUanAB0WgrTFIsJDugQHbuRfh5HRsFvSm0F2+L9m2m70aQVhOxi/4PSHdUy5oaV 1jc0/8Tplqo5gdkoOYuf1ysBhqGHNzat8yyQXZVj4gjOYqb3xzzOvd4sjStb1o7AOHni vDNA== 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 :message-id:references:to; bh=M3JtA+E816R1ct92aXoxxMc0D+VnvO+HKNFuMFgzsYc=; b=J3AaJiGiXiAP9mGKXPNfiKN5wI0LicgT758fnywJZ8cDRZ7x1zHVciCDuxs6COv5o/ cTmuExAx+W9sr8lNgipCqCJjSOYvRN/L/u/sjVK8VJnyeSyK1P0QtJ2VpIQ0Lq8iDIbg GiW6KGBXEm7oBcJZCL1edBinuYeZPcTgFA9jQxBwqmXy3gfRBebXzKLNs6/1Y3ApcmFw KduPv2AXb7yjzBXhfCQMILTQwOAfwrFOIDmu9P9eJF4a4+we9LsrS6Lkw6RzTNw8U0H6 qxjA9M2nzYThY317AlGars/Qb6GRmhZr3oOa7+fE9Y7B01lcFLwoNssZEm0YSYq1BJpS Gh4Q== X-Gm-Message-State: APjAAAX5jqqlDef/37K4IOpcf/g/9F7Ztz7/FQN0tkph+VyCzJYQlEFp mKr7reGMf3FNPeHpRFYBYPw= X-Google-Smtp-Source: APXvYqxS5ZyDt5OY0H4Ubm3pWwkqxlhzf/AMiYrRpa92OG193DwPNgF/li6chnevAzXuWqX+CYVFaw== X-Received: by 2002:a62:1951:: with SMTP id 78mr4021576pfz.257.1571946004140; Thu, 24 Oct 2019 12:40:04 -0700 (PDT) Received: from [192.168.42.3] (135-180-2-130.static.sonic.net. [135.180.2.130]) by smtp.gmail.com with ESMTPSA id a24sm10496304pgd.93.2019.10.24.12.40.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Oct 2019 12:40:03 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2F1C2286-1437-49B8-AD29-FD3C535A2531" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Toomim In-Reply-To: Date: Thu, 24 Oct 2019 12:40:03 -0700 Cc: Julian Reschke , dispatch@ietf.org, greg little , Braid , Rafie Walker , Seph Gentle , Bryn Bellomy Message-Id: References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> <839ea4e5-db2d-8220-6058-93869a29c185@gmx.de> <82F33D05-D8BC-4F69-A198-677773F3427C@gmail.com> <11cabf2e-1550-53e5-60dd-7d1bdf65805a@gmx.de> <450f4113-7cdb-f65e-761d-9023e3d625bd@gmx.de> <34B388A2-50A7-4344-98B6-0D8B08E1277F@gmail.com> <086C29B2-00BC-403B-8080-1AAE3A99D382@gmail.com> To: Ranjit Avasarala X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV 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, 24 Oct 2019 19:40:08 -0000 --Apple-Mail=_2F1C2286-1437-49B8-AD29-FD3C535A2531 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ranjit: > why can't we use WebSockets which is based on HTTP and helps keep = session active?=20 Thank you for the question. We certainly could use a WebSocket, and in = fact, the previous version of the spec = did use a WebSocket = as transport! The question is why you'd prefer to use a WebSocket as the = underlying transport, rather than a multipart-body GET request. Since we = still want all the great things from HTTP=E2=80=94 caching, URLs, = idempotency, content-types, etc. =E2=80=94we'd either have to implement = all the existing HTTP methods on top of a WebSocket, or add these new = subscription features on top of HTTP. In the end, it seems to be simpler = and more elegant to do the latter. Also, the introduction mentions WebSockets=E2=80=94did it address your = question adequately? Or is there something we should add to this: 1. Introduction When a client GETs a resource over HTTP, the server provides the latest version, but does *not* provide updates when the resource changes. This means that programmers have to implement workarounds whenever they need to synchronize with data that changes. The web originally required users to click reload when a page changed. In the year 2000, XMLHTTPRequest made it possible to update just part of a page, running a GET request behind the scenes. But the GET request still could not push updates. To work around this, web programmers would poll the resource, which was inefficient. Long-polling was invented to overcome the inefficiencies, which was standardized as SSE. But SSE provides semantics of an *event-stream*, and although a programmer can encode a protocol within the event stream for updating a resource, there is still no standard way to update a resource. In practice, programmers today often give up on using a standard semantic for "data that changes", and instead write their own idiosyncratic update protocol over a WebSocket, or adopt a web framework that does this for them. However, we can add support for "state that changes" into HTTP with a few small extensions. Doing so transforms HTTP from a *state transfer* protocol into a *state synchronization* protocol, and extends the REST architecture into RESS: REpresentational State Synchronization. = https://raw.githubusercontent.com/braid-work/braid-spec/master/draft-xx-ht= tpbis-braid-00.txt = But let me say that some things actually are more elegant to implement = with a WebSocket. Specifically, we are finding the request/response = model of HTTP to be getting in the way. After this spec is complete, I = expect us to propose a generalization of request/response that can run = peer-to-peer over a QUIC channel, in which either peer can initiate or = respond to GET and PUT requests, and both peers will ACK changes in = state symmetrically. We sketched this in Section 4.2 of the the previous = spec . It = makes the protocol both simpler and more capable. Thank you, Ranjit!= --Apple-Mail=_2F1C2286-1437-49B8-AD29-FD3C535A2531 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Ranjit:
why can't we use WebSockets which is based on = HTTP and helps keep session active? 

Thank you for the question. We certainly could use a WebSocket, and in fact, the = previous version of the spec did use a WebSocket as transport! = The question is why you'd prefer to use a WebSocket as the underlying = transport, rather than a multipart-body GET request. Since we still want = all the great things from HTTP=E2=80=94 caching, URLs, idempotency, = content-types, etc. =E2=80=94we'd either have to implement all the existing HTTP methods on top of a WebSocket, or add = these new subscription features on top of HTTP. In the end, it seems to = be simpler and more elegant to do the latter.

Also, the introduction mentions WebSockets=E2=80=94d= id it address your question adequately? Or is there something we should = add to this:

1.  Introduction

  When a client GETs a resource over HTTP, the server provides the
  latest version, but does *not* provide updates when the resource
  changes.  This means that programmers have to implement workarounds
  whenever they need to synchronize with data that changes.

  The web originally required users to click reload when a page changed.
  In the year 2000, XMLHTTPRequest made it possible to update just part
  of a page, running a GET request behind the scenes.  But the GET
  request still could not push updates.  To work around this, web
  programmers would poll the resource, which was inefficient.
  Long-polling was invented to overcome the inefficiencies, which was
  standardized as SSE.  But SSE provides semantics of an *event-stream*,
  and although a programmer can encode a protocol within the event
  stream for updating a resource, there is still no standard way to
  update a resource.  In practice, programmers today often give up on
  using a standard semantic for "data that changes", and instead write
  their own idiosyncratic update protocol over a WebSocket, or adopt a
  web framework that does this for them.

  However, we can add support for "state that changes" into HTTP with a
  few small extensions.  Doing so transforms HTTP from a *state
  transfer* protocol into a *state synchronization* protocol, and
  extends the REST architecture into RESS: REpresentational State
  Synchronization.
https://raw.githubusercontent.com/braid-work/braid-spec/master/= draft-xx-httpbis-braid-00.txt

But let me say that some things actually are more elegant to implement = with a WebSocket. Specifically, we are finding the request/response = model of HTTP to be getting in the way. After this spec is complete, I = expect us to propose a generalization of request/response that can run = peer-to-peer over a QUIC channel, in which either peer can initiate or = respond to GET and PUT requests, and both peers will ACK changes in = state symmetrically. We sketched this in Section 4.2 of the the previous spec. It makes the = protocol both simpler and more capable.

Thank you, Ranjit!
= --Apple-Mail=_2F1C2286-1437-49B8-AD29-FD3C535A2531-- From nobody Thu Oct 24 19:44:53 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB7D1200E7 for ; Thu, 24 Oct 2019 19:44:51 -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, 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=KjYjRgZN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XrcdE3fO 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 dtDLV30LnVrL for ; Thu, 24 Oct 2019 19:44:49 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C3112008D for ; Thu, 24 Oct 2019 19:44:49 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id DCCE842E; Thu, 24 Oct 2019 22:44:46 -0400 (EDT) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Thu, 24 Oct 2019 22:44: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:cc:subject:content-type; s=fm1; bh=+TTj Mwvc37xXyr/Hf12SLko/Qc1B8t5du0YsB57kCVg=; b=KjYjRgZN+OmX9DKsAXxn LZrBhHcjEAfSB+uE3J0E+iWD0Ov5Wu523ZKb/0XnYChvgfqPaQD9y/D+DQygNai+ fUnUnTXf2J2X5qg1spuyOWYom82/hqzkKPdfNvzhYtArIQwmQtsxwYwCuuCNOBGY /FTZO2vIekhVwG4GgD/igGUjG1U9RrZtLg8B+QHQKFrPPEu5Zg1YKV7hXc2ucirg h2UViHQDl0sH0BbY5shRrcFwMJcAmfhM1WYfYVv1VIox5HyMsGwwynjxpnq8X6rc iAEvAXpjlgb/gN0SsMj/IArFCD8EnsEiLpjbCDTVuBhXjGauAGbq1b3iVRx+JWha RA== 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=fm1; bh=+TTjMw vc37xXyr/Hf12SLko/Qc1B8t5du0YsB57kCVg=; b=XrcdE3fOtPOVEcuWN+zLI4 k2cB2FBcV2tJjvKsn5wmE8t7rhrAp+SuJAs9Zr+IsY3yDGK934N7RK6nOLbyCPgs 9ZyTD0dUhRgY2qQQFOn00K4PXab9zBL1Q1E0DuSG1UHL0xl5W4RlEQcsQpCxNNZs 30XxlajH2ikT5k3ByLHAPyXRsmoNF4jcEd3+UDpc6zAPcUGEc1w6XkWxSuPo+qur DiHEoMEcf27eHvZTPxEuyZ6LJlIsuGKAp1KnI6cqjOxFb8hAIhcTBnvJGCAwUkIr WeufFHGoZOAda4k34X3QX15wC7kJTtO6m+4vOmGRAMS5ZfBiV7s8urCAiKZtaYOg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrledvgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucffohhmrghinhepfihikhhiphgvughirgdrohhrghdpghhithhhuhgsrdgtohhmpdhi vghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmh grihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 18E8E388EDA; Thu, 24 Oct 2019 22:44:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-470-gedfae93-fmstable-20191021v4 Mime-Version: 1.0 Message-Id: <00358631-a34d-45db-bf87-44709972387b@beta.fastmail.com> In-Reply-To: References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> Date: Fri, 25 Oct 2019 13:44:25 +1100 From: "Bron Gondwana" To: "Michael Toomim" Cc: dispatch@ietf.org Content-Type: multipart/alternative; boundary=1f514ff9a47f44a2a646c7cec04fe3d3 Archived-At: Subject: [dispatch] =?utf-8?b?PT9VVEYtOD9RP1JlOl9fUG90ZW50aWFsX2luY29t?= =?utf-8?b?aW5nX3dvcms6X3dlYl9wdXNoX2Zvcl9JTUFQLCBfQ2FsPz0gREFWIGFuZCBD?= =?utf-8?q?ardDAV?= 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, 25 Oct 2019 02:44:52 -0000 --1f514ff9a47f44a2a646c7cec04fe3d3 Content-Type: text/plain It looks like the conversation went a long way down this path, which by my reading is "ask the server to maintain a long running connection and keep pushing updates down it" which is a slightly different use-case from the push proposals I was making, which are: * Client establishes a relationship with a third party push server (potentially via some platform specific, highly efficient protocol - e.g. APNs or GCM ) * Client requests server inform the third party push server when there are changes. * Third party push server passes details down to client, which can then request updates from the server without having to hold a connection open or poll. This is a general pattern which 1st party clients frequently use (including ours at Fastmail) but which doesn't have a general solution, so my impression of the work required there is defining a standard for how to request the server make that push to a third party, and what gets included in that push. This other work of having the server hold a connection open is also interesting and potentially useful, it's just not exactly what I was suggesting! Cheers, Bron. On Wed, Oct 23, 2019, at 16:27, Michael Toomim wrote: > Hi Bron! The work on the Braid HTTP extension also provides a "web push". We are also trying to find a general approach. > > The current design allows clients to specify a "Subscribe" header in the GET request, which tells the server to keep the connection open and stream all updates to the resource, as they happen. We will be publishing a new draft within the next week or two. > >> On Oct 22, 2019, at 9:08 PM, Bron Gondwana wrote: >> >> There's a couple of interesting things that have been going on in different places that I'm working on trying to get aligned and to find a home for at the IETF: >> >> Web push for IMAP servers here: >> >> https://github.com/coi-dev/coi-specs/blob/master/webpush-spec.md >> >> Web push for CalDAV and CardDAV servers here: >> >> https://datatracker.ietf.org/doc/draft-gajda-dav-push/ >> >> (there's a more recent version in the CalConnect private repositories - we haven't been pushing it just yet because the CALEXT group is already pretty busy, and we're not sure if it belongs there or in another group). >> >> And of course JMAP already has a web push built in with the push subscription object: >> >> https://tools.ietf.org/html/rfc8620#section-7 >> >> Anyway, I'm not sure if this is ripe for discussion at Singapore, or indeed if we've missed the deadlines for a BOF, but I figured if I post here I might see if there's any others working on similar things and if we could pull everyone together to join forces and make sure all the different push mechanisms work similarly. >> >> Cheers, >> >> Bron. >> >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd >> brong@fastmailteam.com >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --1f514ff9a47f44a2a646c7cec04fe3d3 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
It looks like the conversation went a long way down this p= ath, which by my reading is "ask the server to maintain a long running c= onnection and keep pushing updates down it" which is a slightly differen= t use-case from the push proposals I was making, which are:

  • Client establishes a relationship with a third party push server (= potentially via some platform specific, highly efficient protocol - e.g.= APNs or GCM)
  • Client request= s server inform the third party push server when there are changes.
    <= /li>
  • Third party push server passes deta= ils down to client, which can then request updates from the server witho= ut having to hold a connection open or poll.

This is = a general pattern which 1st party clients frequently use (including ours= at Fastmail) but which doesn't have a general solution, so my impressio= n of the work required there is defining a standard for how to request t= he server make that push to a third party, and what gets included in tha= t push.

This other work of having the server hold a connect= ion open is also interesting and potentially useful, it's just not exact= ly what I was suggesting!
Cheers,

Bron.


On Wed, Oct = 23, 2019, at 16:27, Michael Toomim wrote:
Hi Bron! The work on the Braid HTTP ex= tension also provides a "web push". We are also trying to find a general= approach.

The = current design allows clients to specify a "Subscribe" header in the GET= request, which tells the server to keep the connection open and stream = all updates to the resource, as they happen. We will be publishing a new= draft within the next week or two.

On Oct 22, 2019, at 9:08 PM, Bron Gondwana <brong@fastmailteam.com> w= rote:

There's a couple= of interesting things that have been going on in different places that = I'm working on trying to get aligned and to find a home for at the IETF:=

Web push for IMAP server= s here:

<= /div>
https://github.com/coi-dev/coi-specs/blob/master/webpush-spec.md

Web push for CalDAV and Ca= rdDAV servers here:

https://datatracker.ietf.org/doc/draft-gajda-dav-push/
=

(there's a more recent version in t= he CalConnect private repositories - we haven't been pushing it just yet= because the CALEXT group is already pretty busy, and we're not sure if = it belongs there or in another group).

And of course JMAP already has a web push built in with th= e push subscription object:

https://tools.ietf.org/html/rfc8620#section-7

Anyway, I'm not sure if this is ripe for dis= cussion at Singapore, or indeed if we've missed the deadlines for a BOF,= but I figured if I post here I might see if there's any others working = on similar things and if we could pull everyone together to join forces = and make sure all the different push mechanisms work similarly.

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


_______________= ________________________________
dispatch mailing list<= /span>

--
  Bron Gondwana, CEO, Fastmail Pty Ltd=
  brong@fastmailteam.com


--1f514ff9a47f44a2a646c7cec04fe3d3-- From nobody Fri Oct 25 13:14: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 8186212003E for ; Fri, 25 Oct 2019 13:14:33 -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 2GDU68fevIwp for ; Fri, 25 Oct 2019 13:14:31 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 8365712004F for ; Fri, 25 Oct 2019 13:14:31 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id l3so2234190pgr.8 for ; Fri, 25 Oct 2019 13:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Fr1GfyDoKzQYIKep43RLR4o8AJWncbR/hf7xlnhUD+4=; b=KNq4YoeeloDzxGOePDiA5v8oSEsnP+wCNpV0Jtwg77x18V6DS5U+H17TcVWcZT4zCt QKaPrYBInegrxHOiqDA1vVWGW/lgXwj8BrI0cVXNin8isk7bR7e6EtYPl1MuQf4VX9g5 TMN1nUDei8f1SJ6/wwVf82hCPuOkox9cGApoEhxkNhgd+HJW5X4JZEdbtiDn9CEPXBkJ UOdIjm7z62DVJ5nwBIP3rLuGQUKjXc7Bj9RNHH6g7IwRMSZd2aavR8qu7C0zIiX+taz8 1GLOJJu6M/hfDbsGQylTg2QZSxrndJirPFNZ98uuWY9PqPU4z3n0MB4ixTfYPMq1APJY s12g== 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 :message-id:references:to; bh=Fr1GfyDoKzQYIKep43RLR4o8AJWncbR/hf7xlnhUD+4=; b=FDZez01xvJwDX5s3FI6nZ2nBVvFxdM3KjXVpapSVpAM0NG3PVXG4yonuYBC83Ow5WK tkFG0JFwcx4uyU9RDXHTiLvpAF/JpINnf9u2zycuo9ySL1cK3SCy9L5asXmROeu2zrNT XQgQAud+DCHr3DdazETS7QGWF0VfpSOOfr+Y+laxIrx+zRU3VPjjiTXBHD2zeYd7131b PKe2a7Q9f8vfoGlzRBwxe8Kv++LGW3ovhTNKaUI03PrR/PrL3pauaoQWGWz6nOzLTnWa bbvX8dG4xWj+dXNnGj0jqb+RfTTb2gcd7nTkX+Uv01DAl3dTqlCjsZFbXwMk69mzPM9Q /GrQ== X-Gm-Message-State: APjAAAUQt+FvLV5Sz8VdoWbb5z38Q7ufusmwUhWOdEfMox60QUCbqEcw JIu1Q43s+PJnNptPlnCNDdU= X-Google-Smtp-Source: APXvYqzA7CpTbQAHB8eGbqfKzI9+qAdwoqCrZrT+9CcMVZsgVeuOQSUHVRQv4PdTKPRaYoZOqtNI1g== X-Received: by 2002:a17:90a:9406:: with SMTP id r6mr6767525pjo.0.1572034470854; Fri, 25 Oct 2019 13:14:30 -0700 (PDT) Received: from [172.16.103.49] (c-71-202-89-74.hsd1.ca.comcast.net. [71.202.89.74]) by smtp.gmail.com with ESMTPSA id 2sm2971153pfo.91.2019.10.25.13.14.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 25 Oct 2019 13:14:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8B5329E3-D79E-42B6-9F1A-CD650A960E06" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Toomim In-Reply-To: <00358631-a34d-45db-bf87-44709972387b@beta.fastmail.com> Date: Fri, 25 Oct 2019 13:14:21 -0700 Cc: dispatch@ietf.org, Braid Message-Id: <1C9B1121-B20E-479E-B596-C04A416B5EE1@gmail.com> References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> <00358631-a34d-45db-bf87-44709972387b@beta.fastmail.com> To: Bron Gondwana X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV 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, 25 Oct 2019 20:14:33 -0000 --Apple-Mail=_8B5329E3-D79E-42B6-9F1A-CD650A960E06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Bron Gondwana: > It looks like the conversation went a long way down this path, which = by my reading is "ask the server to maintain a long running connection = and keep pushing updates down it" which is a slightly different use-case = from the push proposals I was making, which are: >=20 > Client establishes a relationship with a third party push server = (potentially via some platform specific, highly efficient protocol - = e.g. APNs = or GCM = ) > Client requests server inform the third party push server when there = are changes. > Third party push server passes details down to client, which can then = request updates from the server without having to hold a connection open = or poll. >=20 > This is a general pattern which 1st party clients frequently use = (including ours at Fastmail) but which doesn't have a general solution, = so my impression of the work required there is defining a standard for = how to request the server make that push to a third party, and what gets = included in that push. >=20 > This other work of having the server hold a connection open is also = interesting and potentially useful, it's just not exactly what I was = suggesting! Hi Bron, thank you for articulating this distinction, it gave me a bunch = to chew on! However, after some thought, I don't think we are actually that far off. = Consider that JMAP supports both of these methods: you can subscribe to = a stream of updates via a long-running GET request (section 7.3 = ) or via a third-party = server (section 7.2 ). = Braid should eventually support both as well. The choice between whether you want to use a long-running TCP connection = vs. a third-party server mostly comes down to whether you're a cell = phone=E2=80=94 it saves radio power if you don't have to maintain a TCP = connection to each data source you care about. But if you're a server, = or you're a cell phone that is already online, it's better to connect = directly. Now, we could certainly go about defining separate web push standards = for these two cases. But I think there's a good case to be made for = putting them together in a single standard, with a single API for = programmers to use. I think we can gain a lot by putting this standard into basic HTTP, = rather than building layers on top. By adding Synchronization to HTTP, = we get the functionality of Web Push, but it can be implemented = automatically, for all resources, without any extra effort from the = programmer. The whole web has changed in the last 20 years=E2=80=94 from = static pages to dynamic data =E2=80=94and it's time we upgrade the = protocol at a deep level. Getting a notification of a message on your = phone shouldn't be any different from getting the actual message in the = app.= --Apple-Mail=_8B5329E3-D79E-42B6-9F1A-CD650A960E06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Bron Gondwana:
It looks like the conversation went a long way down this = path, which by my reading is "ask the server to maintain a long running = connection and keep pushing updates down it" which is a slightly = different use-case from the push proposals I was making, which = are:

  • Client = establishes a relationship with a third party push server (potentially = via some platform specific, highly efficient protocol - e.g. APNs or GCM)
  • Client requests server inform the third party push server = when there are changes.
  • Third party push server passes details down to = client, which can then request updates from the server without having to = hold a connection open or poll.

This is a general pattern which 1st = party clients frequently use (including ours at Fastmail) but which = doesn't have a general solution, so my impression of the work required = there is defining a standard for how to request the server make that = push to a third party, and what gets included in that push.

This = other work of having the server hold a connection open is also = interesting and potentially useful, it's just not exactly what I was = suggesting!

Hi Bron, thank you for articulating this distinction, it gave = me a bunch to chew on!

However, after some thought, I don't think we are actually = that far off. Consider that JMAP supports both of = these methods: you can subscribe to a stream of updates via a = long-running GET request (section 7.3) or via a third-party server (section 7.2). Braid should eventually support both as = well.

The = choice between whether you want to use a long-running TCP connection vs. = a third-party server mostly comes down to whether you're a cell phone=E2=80= =94 it saves radio power if you don't have to maintain a TCP connection = to each data source you care about. But if you're a server, or you're a = cell phone that is already online, it's better to connect = directly.

Now, = we could certainly go about defining separate web = push standards for these two cases. But I think there's a good case to = be made for putting them together in a single standard, with a single = API for programmers to use.

I think we can gain a lot by putting this standard into basic HTTP, rather than building layers on top. = By adding Synchronization to HTTP, we get the functionality of Web Push, = but it can be implemented automatically, for all resources, without any = extra effort from the programmer. The whole web has changed in the last = 20 years=E2=80=94 from static pages to dynamic data =E2=80=94and it's = time we upgrade the protocol at a deep level. Getting a notification of = a message on your phone shouldn't be any different from getting the = actual message in the app.
= --Apple-Mail=_8B5329E3-D79E-42B6-9F1A-CD650A960E06-- From nobody Fri Oct 25 14:16:45 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 4DD021209B4; Fri, 25 Oct 2019 14:12:12 -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.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203793231.2724.18396945426826741636.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:12 -0700 Archived-At: Subject: [dispatch] dispatch - Requested session has been scheduled for IETF 106 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, 25 Oct 2019 21:12:23 -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, 18 November 2019, Morning Session I 1000-1200 Room Name: Sophia size: 200 --------------------------------------------- Special Note: Joint with ARTAREA iCalendar: https://datatracker.ietf.org/meeting/106/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: Chair Conflict: secdispatch acme cfrg extra doh core avtcore ecrit mmusic payload rmcat sipcore stir xrblock dmarc uta jmap Technology Overlap: 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 Fri Oct 25 16:00: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 5DFC81200B3 for ; Fri, 25 Oct 2019 16:00:56 -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, 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=zGU3Af0t; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iLKMIPfu 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 7wfGjUTwPcwE for ; Fri, 25 Oct 2019 16:00:54 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D1012009C for ; Fri, 25 Oct 2019 16:00:54 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5D5EA220C3; Fri, 25 Oct 2019 19:00:52 -0400 (EDT) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Fri, 25 Oct 2019 19:00:52 -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=fm1; bh=mdzY JeuVTPFlVK9c+wxf9cEirEg4h+/4bkaOV9e1KhI=; b=zGU3Af0tIqTip+qChEnt YLoBmINlN4y3lOk695wFps5srg/Uzs9KtJvXnRrZM/B+iv+qawmss73o/a362maZ w1ph1/Bxi2ai/sSv2SST0DlLFnaTMziK08Yvzh9NMhoYLdans9AiFcBC5BtJBJ+V /tP6BMG8VIe3Gg3hDyjWVQxcNeiWfCNLpCxDjHLxlyAWFyfT6j9ShI2Rtb1kellW tJTHeWu2WOc2C1bwRdlxH2oW41P7LJ48AKU4mI8Ran65S/19WRMfcg+hRrbuuDlu AnvollqsbYaduiIV7erVX2S55fiH9504s7p8gFSLCH7Y6ZsW2LcwFVqcTzeJMgmT gQ== 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=fm1; bh=mdzYJe uVTPFlVK9c+wxf9cEirEg4h+/4bkaOV9e1KhI=; b=iLKMIPfuYMu2U8C1io7ihD vr48LTRrA8XvuqZqpEOyDSgoEmEgszJnIkY8LlMPFqX6nGoWBubkIrtAin9XW/iL oTSA6iNJd00WXHnevZ7qpU1AuFLvDj6DRD17hJc1LGZYGjGkcrvYLkc8/iNPXCLK cna/j/aSxFfIkoHVFAzovxIdlc5oGVTyq523YZedy5ssqr6Qrh1UyasxlZMnXA2c dMTwF0/s8/TtKEFFQV8jIQ6ofp0+hVreyMSBh+J0AO1jL+XPCZB66pk9qeBbVMB6 HCSn7if1EnIteHlqFr8dGE4iFSMbMyGsotJ8dUtUUF3DKnIPizHINnnR31rt+Vrg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrleeggddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucffohhmrghinhephhhtthhprhgrthhhvghrthhhrghnsghuihhlughinhhglhgrhigv rhhsohhnthhophdrsgihnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrg hsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C67E33AAF2E; Fri, 25 Oct 2019 19:00:51 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-470-gedfae93-fmstable-20191021v4 Mime-Version: 1.0 Message-Id: <191d3882-3bc4-48de-a4b2-dac05c7b1288@www.fastmail.com> In-Reply-To: <1C9B1121-B20E-479E-B596-C04A416B5EE1@gmail.com> References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> <00358631-a34d-45db-bf87-44709972387b@beta.fastmail.com> <1C9B1121-B20E-479E-B596-C04A416B5EE1@gmail.com> Date: Sat, 26 Oct 2019 10:00:31 +1100 From: "Bron Gondwana" To: "Michael Toomim" Cc: dispatch@ietf.org, Braid Content-Type: multipart/alternative; boundary=06243df71c3e45299ce9936f423cd238 Archived-At: Subject: [dispatch] =?utf-8?b?PT9VVEYtOD9RP1JlOl9fUG90ZW50aWFsX2luY29t?= =?utf-8?b?aW5nX3dvcms6X3dlYl9wdXNoX2Zvcl9JTUFQLCBfQ2FsPz0gREFWIGFuZCBD?= =?utf-8?q?ardDAV?= 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, 25 Oct 2019 23:00:56 -0000 --06243df71c3e45299ce9936f423cd238 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, Oct 26, 2019, at 07:14, Michael Toomim wrote: > I think we can gain a lot by putting this standard *into* basic HTTP, = rather than building layers on top. By adding Synchronization to HTTP, w= e get the functionality of Web Push, but it can be implemented automatic= ally, for all resources, without any extra effort from the programmer. T= he whole web has changed in the last 20 years=E2=80=94 from static pages= to dynamic data =E2=80=94and it's time we upgrade the protocol at a dee= p level. Getting a notification of a message on your phone shouldn't be = any different from getting the actual message in the app. At this point the big difference is whether you want a push of the entir= e resource, or (as JMAP does) an edge trigger to say "there's something = new of this object type on the server - issue a query about which bits y= ou're interested in to see if there's anything new you want to fetch". At which point the granularity of detail becomes interesting - because y= ou only want to be informed of changes if there's a high probability tha= t they are things you are interested in, and even more so - if there's a= high probability that you'll be able to see them! You don't want a push= every time a resource on a server with a million users changes if you c= an only see your own resources! We do that on our own server with pushing you every change to you own re= sources plus doing ACL filtering to see if any other user can see the re= sources and giving them an ACL push too, even if they aren't subscribed = to the resources and won't notice a change.... so there could be more sm= arts in the push filter but it seems to balance out OK in a real life, j= ust the occasional extra wake. And we separate data types like email and= calendar into separate change pools. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --06243df71c3e45299ce9936f423cd238 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Sat, Oct 26, 2019, at 07:14, Michael Toomim wrote:
<= /div>
I think we can gain a lot by putting this standard i= nto basic HTTP, rather than building layers on top. By adding S= ynchronization to HTTP, we get the functionality of Web Push, but it can= be implemented automatically, for all resources, without any extra effo= rt from the programmer. The whole web has changed in the last 20 years=E2= =80=94 from static pages to dynamic data =E2=80=94and it's time we upgra= de the protocol at a deep level. Getting a notification of a message on = your phone shouldn't be any different from getting the actual message in= the app.

At this point the big difference i= s whether you want a push of the entire resource, or (as JMAP does) an e= dge trigger to say "there's something new of this object type on the ser= ver - issue a query about which bits you're interested in to see if ther= e's anything new you want to fetch".

At which point the g= ranularity of detail becomes interesting - because you only want to be i= nformed of changes if there's a high probability that they are things yo= u are interested in, and even more so - if there's a high probability th= at you'll be able to see them!  You don't want a push every time a = resource on a server with a million users changes if you can only see yo= ur own resources!

<= div style=3D"font-family:Arial;">We do that on our own server with pushi= ng you every change to you own resources plus doing ACL filtering to see= if any other user can see the resources and giving them an ACL push too= , even if they aren't subscribed to the resources and won't notice a cha= nge.... so there could be more smarts in the push filter but it seems to= balance out OK in a real life, just the occasional extra wake.  An= d we separate data types like email and calendar into separate change po= ols.

Bron.
--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com

--06243df71c3e45299ce9936f423cd238-- From nobody Fri Oct 25 16:18: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 39199120020 for ; Fri, 25 Oct 2019 16:18:17 -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 ahQRtwbBgFLo for ; Fri, 25 Oct 2019 16:18:15 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 011F712009E for ; Fri, 25 Oct 2019 16:18:14 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id f19so2519200pgn.13 for ; Fri, 25 Oct 2019 16:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=IoyYsfEcpjxM0rK/0CGRskyozgF9sV3SBKfldApptj0=; b=l1AhOxSt83nXHwtyd4YntNaSFowkqNHVI//3+gjZHOcGGF99Gnnq3JrqVziWlga6Cy Cvc44p6Z56AuzivZLrtRsQrsOP3jZlN5V+LK6Tk7rQA/qL2v1RRQoGL8pwhTNoer5Erc PujEVWMeQ8NozsRtAZ+wMiFKxojtA1OC0nlkv5+nWuz9/0TSkCJixqyZ1fkGGvJREbt0 yzm3RFYiMUKohgpAhfX/RutEFCzrVdwI5Oext6MF9ZlvN4Igpo2fVNr12aBXw8+svJgS Ty4LAIZkZrRJ+hxlUKjXE+iDx9iQUbruYr/eYJt17pIC6+iJ/ZHipsvf9zEmIZygT4E0 7vmQ== 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 :message-id:references:to; bh=IoyYsfEcpjxM0rK/0CGRskyozgF9sV3SBKfldApptj0=; b=POY7EAoQvzFzXikBOvwhlbtlTM/LynwHsA1qgmyjXdLc9HYoZhxFSd7AWYU06jOIzh Tv+oXpdF8jaPXhR/StuEJQ+Z8YcHRJ+b6c7kYX3acaQGocH/6auJy/x8xo26/JukFFKv TfC8G062kH8TVbHZ6ONr6XMQmgRDuu9ICGIgINhOk+CdAM332kgnvX9pglDTzvAYlGVy qPjQBCqE6+fpQJor6r2NGGoaOEBN3LU6y2j22cUB9QkNNXvpAAkRhNf9noTpjRkitwg3 kVpT2OJ0/4lbbHvPJkf6JmNd9CoDo2dyiH8hlOszeKJapFJ3SDsm5M3SOp7njY6YSCBs tnoQ== X-Gm-Message-State: APjAAAVkQUPe4NtpfmS73huNHrzXOWMxldVaLPtSN3SNti0eapkNcOEU DMPHnvGwaKJke2lpVe8moQE= X-Google-Smtp-Source: APXvYqynwMkS8IUR/7vuWao9kWiJuNE/NXYEJgYn/lYh+cqCpywt7xhzgemws61PfZ6eVgr+4dIgyg== X-Received: by 2002:a17:90a:bb0a:: with SMTP id u10mr7465108pjr.14.1572045494157; Fri, 25 Oct 2019 16:18:14 -0700 (PDT) Received: from [172.16.103.49] (c-71-202-89-74.hsd1.ca.comcast.net. [71.202.89.74]) by smtp.gmail.com with ESMTPSA id q20sm3477607pfl.79.2019.10.25.16.18.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 25 Oct 2019 16:18:13 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_30D343AF-7C13-4458-AD18-72C1B8DBF7D0" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Toomim In-Reply-To: <191d3882-3bc4-48de-a4b2-dac05c7b1288@www.fastmail.com> Date: Fri, 25 Oct 2019 16:18:12 -0700 Cc: dispatch@ietf.org, Braid Message-Id: References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> <00358631-a34d-45db-bf87-44709972387b@beta.fastmail.com> <1C9B1121-B20E-479E-B596-C04A416B5EE1@gmail.com> <191d3882-3bc4-48de-a4b2-dac05c7b1288@www.fastmail.com> To: Bron Gondwana X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV 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, 25 Oct 2019 23:18:17 -0000 --Apple-Mail=_30D343AF-7C13-4458-AD18-72C1B8DBF7D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Bron Gondwana: > At this point the big difference is whether you want a push of the = entire resource, or (as JMAP does) an edge trigger to say "there's = something new of this object type on the server - issue a query about = which bits you're interested in to see if there's anything new you want = to fetch". >=20 > At which point the granularity of detail becomes interesting - because = you only want to be informed of changes if there's a high probability = that they are things you are interested in, and even more so - if = there's a high probability that you'll be able to see them! You don't = want a push every time a resource on a server with a million users = changes if you can only see your own resources! >=20 > We do that on our own server with pushing you every change to you own = resources plus doing ACL filtering to see if any other user can see the = resources and giving them an ACL push too, even if they aren't = subscribed to the resources and won't notice a change.... so there could = be more smarts in the push filter but it seems to balance out OK in a = real life, just the occasional extra wake. And we separate data types = like email and calendar into separate change pools. Ah, yes the JMAP approach is to inform the client of EVERY change to = EVERY object, even if that object isn't being displayed right now. The = client just ignores the unnecessary changes. That works well enough for email, where all changes are bounded to the = user's mailbox, and things just don't change that often. However, it = doesn't scale to the general case, where a server might be serving = millions of resources, and any client could conceivably want to watch = any of them, but probably only a few at a time. It is much more efficient here for a client to explicitly subscribe to = the resources it wants to watch. In Braid, you subscribe to a resource = by adding the Subscribe header to a GET. Then the server promises to = send you updates, even if you go offline, until you explicitly give it a = FORGET. This means that the granularity of subscription is a URI, and clients = are responsible for expressing which URIs they want to subscribe to. = This works quite well in practice. You usually start out with just a few = URIs, which means your client will do a few GETs, and then if you need = finer granularity, you can always break up your objects into multiple = URIs. The Linked JSON spec = makes that easy.= --Apple-Mail=_30D343AF-7C13-4458-AD18-72C1B8DBF7D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Bron Gondwana:
At this point the big difference is whether you want a push = of the entire resource, or (as JMAP does) an edge trigger to say = "there's something new of this object type on the server - issue a query = about which bits you're interested in to see if there's anything new you = want to fetch".

At which point the granularity of detail becomes interesting = - because you only want to be informed of changes if there's a high = probability that they are things you are interested in, and even more so = - if there's a high probability that you'll be able to see them!  = You don't want a push every time a resource on a server with a million = users changes if you can only see your own resources!

We do = that on our own server with pushing you every change to you own = resources plus doing ACL filtering to see if any other user can see the = resources and giving them an ACL push too, even if they aren't = subscribed to the resources and won't notice a change.... so there could = be more smarts in the push filter but it seems to balance out OK in a = real life, just the occasional extra wake.  And we separate data = types like email and calendar into separate change = pools.

Ah, yes the JMAP approach is to inform = the client of EVERY change to EVERY object, even if that object isn't = being displayed right now. The client just ignores the unnecessary = changes.

That = works well enough for email, where all changes are bounded to the user's = mailbox, and things just don't change that often. However, it doesn't = scale to the general case, where a server might be serving millions of = resources, and any client could conceivably want to watch any of them, = but probably only a few at a time.

It is much more efficient here for a = client to explicitly subscribe to the resources it wants to watch. In = Braid, you subscribe to a resource by adding the Subscribe header to a = GET. Then the server promises to send you updates, even if you go = offline, until you explicitly give it a FORGET.

This means that the granularity of = subscription is a URI, and clients are responsible for expressing which = URIs they want to subscribe to. This works quite well in practice. You = usually start out with just a few URIs, which means your client will do = a few GETs, and then if you need finer granularity, you can always break = up your objects into multiple URIs. The Linked JSON = spec makes that easy.
= --Apple-Mail=_30D343AF-7C13-4458-AD18-72C1B8DBF7D0-- From nobody Mon Oct 28 21:06: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 E513D12008D; Mon, 28 Oct 2019 21:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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=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 pusl-e_MaoMP; Mon, 28 Oct 2019 21:06:12 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 4F66412008C; Mon, 28 Oct 2019 21:06:12 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id p4so12053325wrm.8; Mon, 28 Oct 2019 21:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=S1+xVB98x5BC0QuIYkzAj7CE2XOLxn+K5ugZghjaS24=; b=Grz2b3aKqJkjFw0AXtivEg9hFV1+HlcMkLble6zVhktL5rvsnQiEyn3NIzBZ833Ftc dHgGbseiLJi9e2ayeyX95vySOCOikr1gwgJYv+RhxUJfw2wcN+D/lv/SyhsHsxeWhLu2 GaiZzG5tUONmBc/jXT1KjVelhQfVhlvdNNIuPYRsrvt6h/gnQFPXb30KrVhOrI0rXSgm QFaZvcNLcVFi0G8qoE7Glb5Neb5bObeTFtSctdMkPplrUPqYWxWZNY+tHEJ0VsiyvS8h NgXAHGSlMAPDlClvGBH/l9uo2k5wX436NCcx/YdPLAKUq2EosFIoDS+JIGxT6qlzsGG7 Oo2g== 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=S1+xVB98x5BC0QuIYkzAj7CE2XOLxn+K5ugZghjaS24=; b=sjlcCIuZaTnyIQrUL3ZgYjLfxn60scvXCbuNjBx9QDekjWfvyj4oEMgvNwwbTkNzNH g7hCbV4g5qn+MvJsDK94+TX5z+hys1WqaAohqzPva13UGVKl6jdQdn4s9aqHlfEygGnQ JwcDieZk4ZqpXY8TYkX0dmTlODU2OdVfEcO5+vCftIPYvMv2B6iDtqlybuITLZMSe95N p8CGe3SbeZSoShxUL2eL6IbfmCCAloifOb5v10x4KNUvCOHsD+haHBY454ZPq42sGeSf n1rabKDQeW884nLhTUolwksIo2nGp7JWKpmGQ06cMuA3wLJr+orvVeqG5trWrYdDVE5u jzeQ== X-Gm-Message-State: APjAAAU44f2cNQDgsCcoiGb/AxHMse0Lhpa6QsfCmmpk07aHtrMXZUmu zJ9P8xUUDF454DgpTqhAT1z7YjfZY96SsfEzTkrzgQ== X-Google-Smtp-Source: APXvYqyddVieEFpd8k8pBCj/JY0Zvziveaco4mAgA5iLQlL021qJ6I3cTCg8OVFTMjY7qwwv6VpKmK2JCwq3T//+iLY= X-Received: by 2002:a5d:54c7:: with SMTP id x7mr16789417wrv.99.1572321970582; Mon, 28 Oct 2019 21:06:10 -0700 (PDT) MIME-Version: 1.0 From: Ranjit Avasarala Date: Mon, 28 Oct 2019 23:05:59 -0500 Message-ID: To: sipcore@ietf.org, dispatch@ietf.org, Sip-implementors@lists.cs.columbia.edu Content-Type: multipart/alternative; boundary="0000000000008779c5059604bc02" Archived-At: Subject: [dispatch] Proposal for a mew SIP 4xx Error code 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, 29 Oct 2019 04:06:14 -0000 --0000000000008779c5059604bc02 Content-Type: text/plain; charset="UTF-8" Hello all Many times I experienced scenarios where SIP requests (e.g. INVITE, PUBLISH or PRACK or any other) have either invalid parameters in the header or a particular header is missing in the request or the header value is incomplete. Some e.gs are - SIP Route header in INVITE contains additional "lr" parameter. Ideally, "lr" parameter needs to be associated with a particular route - i.e. sip URI - the Accept header is missing in SIP PUBLISH - the Allow header misses UPDATE method - ..... many more Currently, in all the above cases the SIP Proxy server that receives the request, responds with a 400 Bad Request. Though 400 Bad Request is acceptable given that there is some issue in the SIP request, a more detailed error would be more useful - as sometimes interpreting 400 Bad Request is harder E.g. a 4xx Invalid header/parameter may be more appropriate with reason E.g. if there is additional "lr" parameter in SIP INVITE, then the proxy can return a 4xx Invalid Header/parameter with Reason: SIP code=4xx; Text="Invalid lr parameter in Route header" Let me know your thoughts on if this proposal can be taken forward as an Internet draft. Thank you Ranjit --0000000000008779c5059604bc02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all

Many times I experienced scen= arios where SIP requests (e.g. INVITE, PUBLISH or PRACK or any other) have = either invalid parameters in the header or a particular header is missing i= n the request or the header value is incomplete.=C2=A0 Some e.gs are
  • SIP Route header in INVITE contains= additional "lr" parameter. Ideally, "lr" parameter nee= ds to be associated with a particular route - i.e. sip URI
  • the Acce= pt header is missing in SIP PUBLISH
  • the Allow header misses UPDATE = method=C2=A0
  • .....=C2=A0 many more
Currently, in all = the above cases the SIP Proxy server that receives the request, responds wi= th a 400 Bad Request.
Though 400 Bad Request is acceptable given = that there is some issue in the SIP request, a more detailed error would be= more useful - as sometimes interpreting 400 Bad Request is harder
E.g.
a=C2=A0 4xx Invalid header/parameter may be more appropria= te with reason
E.g. if there is additional "lr" paramet= er in SIP INVITE, then the proxy can return a 4xx Invalid Header/parameter = with Reason:=C2=A0 SIP code=3D4xx; Text=3D"Invalid lr parameter in Rou= te header"

Let me know your thoughts on if th= is proposal can be taken forward as an Internet draft.

=
Thank you
Ranjit


--0000000000008779c5059604bc02-- From nobody Mon Oct 28 23:35: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 D521D120048; Mon, 28 Oct 2019 23:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 v28Lo9aixS6S; Mon, 28 Oct 2019 23:35:24 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00061.outbound.protection.outlook.com [40.107.0.61]) (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 0ED1B120020; Mon, 28 Oct 2019 23:35:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kEw2FNFH04EhvXqpcDCgzWVT7xdHk0fcctTJ+7FFTQw0ZCaomYpPqhgAPmd1byVGbS2f7CLOSatPa5pU/CFKrnDCPm7ijlE5Nw38trhhPbt9oHYR0Tqkzimh/wn1CzWkyxQsLiqe2vn9Mw8UVLXFBHhqeA5M2fmDLpL+qSZFaEbdGOmFrJMuXd/fq7GcpRqbHcfPZC9d3WyCDWbWr0+//bXRiyyDhzIfIVSk0TJw3n1CAAu+ap0GLPr9dFYZ8ZkyG/sbmSo1lIvE1mPYZX6PZ33t6JweARxiZGsX2t8vqpuHRUfj834W9QLtfhbv76YgCeqnPcJwhULO4kduPOtSxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+ud4ux5q812bXqwgmuzvR5NGG47kx/yxWEZhZT+tbJQ=; b=BIBZrAvNg0xKR4j6y5vQmhTT9Y0tcS1QSMP99ZQEBJ4oiTovDZZRhh8XeCb1unDcVVrJVHD/9ciirWMKAl6/d4xwOkTCuZUqGhOO/JEhwq6GpLqzNZKNsW93D9JqndugQ7zgYhvhOpDO9RezMlfB1ZMWb7+MMD/mx+0MVvCos7RhsAl2LfEbw8ocV5WHLS2TqYKM2fvkBtAQlPlK33BF/vqcqcQ8c5nGuQKSW1ylcxxMwhOogFs19eTcy9XnhGHcI6Eo+ENV5MN8VMZhR8r7g6RJhlgAQCE5zF8jAI9aj6Q+OSL4CKqUxXwNv80v1IDby+/GCyfveCTPVvmMEEh3Hw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+ud4ux5q812bXqwgmuzvR5NGG47kx/yxWEZhZT+tbJQ=; b=kNassNsieyHGK3YsNjDw1+BrIPsMUouMTUDh82PA8bCthQql26+WO/+1w9+2CfrU0+r83szeA5c4bb5GhCI2a+VWjibquSVWRd20ZWo/x5tWxzednzKxSz4rl9TicLf3V8mMvRv5p0OPyTFw5Q/cbzflsOt2hP0bgeRcsfryzIY= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3273.eurprd07.prod.outlook.com (10.170.248.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.15; Tue, 29 Oct 2019 06:35:21 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5499:1231:e707:4cb7]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5499:1231:e707:4cb7%7]) with mapi id 15.20.2408.016; Tue, 29 Oct 2019 06:35:21 +0000 From: Christer Holmberg To: Ranjit Avasarala , "sipcore@ietf.org" , "dispatch@ietf.org" , "Sip-implementors@lists.cs.columbia.edu" Thread-Topic: [dispatch] Proposal for a mew SIP 4xx Error code Thread-Index: AQHVjg48nX8QtQl4x0aJ8SlhWJh8TqdxKWtR Date: Tue, 29 Oct 2019 06:35:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [86.50.147.151] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: edbbcbb4-9b06-47ed-1c25-08d75c3a2c58 x-ms-traffictypediagnostic: HE1PR07MB3273: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0205EDCD76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(366004)(396003)(39860400002)(199004)(189003)(53754006)(2171002)(102836004)(2906002)(186003)(74316002)(606006)(8676002)(236005)(99286004)(9686003)(6306002)(6116002)(54896002)(19627405001)(66066001)(52536014)(316002)(3846002)(229853002)(110136005)(71190400001)(26005)(8936002)(6436002)(14454004)(71200400001)(5660300002)(7696005)(478600001)(33656002)(105004)(76116006)(14444005)(66946007)(86362001)(64756008)(66446008)(76176011)(66556008)(66476007)(55016002)(6246003)(25786009)(256004)(446003)(2501003)(11346002)(81156014)(476003)(81166006)(53546011)(6506007)(486006)(7736002)(561944003)(2201001)(44832011)(66574012); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3273; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9MSemgZwNHnwrEAIu7Emm/3X/EDFV2edbr24WVxqeO5UeWE+oPlyMewbOkwfOCuYcVqQ7Ig1kkhiKj/lFSqmIDGqMCS314JS6uyzqnHXUVjyqzbZKUu5kAAIWo0jsqRfnQy5snBCSckCnFjtDL54QJyplsgBb5CSplrNJTtOyWMRCLgyiyWkfz3xhQyYfELmnyyLKqdOtMFZU01GY5umLRmDuraYJXfqL1M3tqgLZPInWy7vq5Oplyp/1+2dXEMrDXpaT1/OKNXMouKAqYDAmmeVlbbGzqAF9ITEDGeaBOBUD7YjWG8JeN6sEfNNEMI7ecUUimcFAMJKFgC4JthpZajbfekMfnjSVNgoSJ8PfdrE/1FnFDhoFOx/OxJFhHxYKsaVhzpQxP3zixkKtHfoHkgptZS/O+2OfgS0dRsCR4ez7v4oUShj0GetIyBa9xwg x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR07MB316193008872CD421120942993610HE1PR07MB3161eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: edbbcbb4-9b06-47ed-1c25-08d75c3a2c58 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2019 06:35:21.6995 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pbelhOzEZaun1m/4oupZvrfo5BsGBx6g8s5mMb3GcXwz7KkKmJUh8a4n+KcNzL1hIIjVa2tO9odIJLXNamwB53wy53JkLtmtLXvjThGRiAE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3273 Archived-At: Subject: Re: [dispatch] Proposal for a mew SIP 4xx Error code 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, 29 Oct 2019 06:35:27 -0000 --_000_HE1PR07MB316193008872CD421120942993610HE1PR07MB3161eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I assume this discussion can be moved to SIPCORE, because I don't think DIS= PATCH needs to discuss the need for a new SIP response code, and where the = work defining such would be done. Regards, Christer ________________________________ From: dispatch on behalf of Ranjit Avasarala Sent: Tuesday, October 29, 2019 6:05 AM To: sipcore@ietf.org ; dispatch@ietf.org ; Sip-implementors@lists.cs.columbia.edu Subject: [dispatch] Proposal for a mew SIP 4xx Error code Hello all Many times I experienced scenarios where SIP requests (e.g. INVITE, PUBLISH= or PRACK or any other) have either invalid parameters in the header or a p= articular header is missing in the request or the header value is incomplet= e. Some e.gs are * SIP Route header in INVITE contains additional "lr" parameter. Ideall= y, "lr" parameter needs to be associated with a particular route - i.e. sip= URI * the Accept header is missing in SIP PUBLISH * the Allow header misses UPDATE method * ..... many more Currently, in all the above cases the SIP Proxy server that receives the re= quest, responds with a 400 Bad Request. Though 400 Bad Request is acceptable given that there is some issue in the = SIP request, a more detailed error would be more useful - as sometimes inte= rpreting 400 Bad Request is harder E.g. a 4xx Invalid header/parameter may be more appropriate with reason E.g. if there is additional "lr" parameter in SIP INVITE, then the proxy ca= n return a 4xx Invalid Header/parameter with Reason: SIP code=3D4xx; Text= =3D"Invalid lr parameter in Route header" Let me know your thoughts on if this proposal can be taken forward as an In= ternet draft. Thank you Ranjit --_000_HE1PR07MB316193008872CD421120942993610HE1PR07MB3161eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

I assume this discussion can be moved to SIPCORE, because I don't think DIS= PATCH needs to discuss the need for a new SIP response code, and where the = work defining such would be done.

Regards,

Christer



From: dispatch <dispatch= -bounces@ietf.org> on behalf of Ranjit Avasarala <ranjitkav12@gmail.c= om>
Sent: Tuesday, October 29, 2019 6:05 AM
To: sipcore@ietf.org <sipcore@ietf.org>; dispatch@ietf.org <= ;dispatch@ietf.org>; Sip-implementors@lists.cs.columbia.edu <Sip-impl= ementors@lists.cs.columbia.edu>
Subject: [dispatch] Proposal for a mew SIP 4xx Error code
 
Hello all

Many times I experienced scenarios where SIP requests (e.g. INVITE, PU= BLISH or PRACK or any other) have either invalid parameters in the header o= r a particular header is missing in the request or the header value is inco= mplete.  Some e.gs are
  • SIP Route header in INVITE contains additional "lr" parameter= . Ideally, "lr" parameter needs to be associated with a particula= r route - i.e. sip URI
  • the Accept header is missing in SIP PUBLISH<= /li>
  • the Allow header misses UPDATE method 
  • .....  man= y more
Currently, in all the above cases the SIP Proxy server that receives t= he request, responds with a 400 Bad Request.
Though 400 Bad Request is acceptable given that there is some issue in= the SIP request, a more detailed error would be more useful - as sometimes= interpreting 400 Bad Request is harder
E.g.
a  4xx Invalid header/parameter may be more appropriate with reas= on
E.g. if there is additional "lr" parameter in SIP INVITE, th= en the proxy can return a 4xx Invalid Header/parameter with Reason:  S= IP code=3D4xx; Text=3D"Invalid lr parameter in Route header"

Let me know your thoughts on if this proposal can be taken forward as = an Internet draft.

Thank you
Ranjit


--_000_HE1PR07MB316193008872CD421120942993610HE1PR07MB3161eurp_-- From nobody Tue Oct 29 03:59: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 08BDC120099 for ; Tue, 29 Oct 2019 03:59:56 -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, 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=A3yhs/Id; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Dks9DBQJ 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 cRAFE7RVGuAl for ; Tue, 29 Oct 2019 03:59:54 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE83120041 for ; Tue, 29 Oct 2019 03:59:54 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A72F222015 for ; Tue, 29 Oct 2019 06:59:53 -0400 (EDT) Received: from imap99 ([10.202.2.99]) by compute1.internal (MEProxy); Tue, 29 Oct 2019 06:59:53 -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=fm1; bh=nmF7e1EXkNFleOHiq2DOfSFlM//oat+FNhdAMrj g+EU=; b=A3yhs/IdZcOfygMMXke3R35kI3adtd2HsWIH98t5B2N6VKUptSGdGhQ B7RE/aubCR1yAtwJCQYby4DdAGIX+xOVUzEpjIPjUQLFsxLK7+yqtrTK5kfYhRT1 ywMIZ/EWK5iJ/wgj//KfYwesQ1tF/TkOP6vPLkdkrn1neurzz3w808H51yO8cdDc spyR60zl14dRpzIPB+9WhNVrpYO9OtblYnRuEFi+/aJksxD/Q832U083456WSkCL jbj1Fct6vHv5bYe5Uy1srdUYv4GLP34zGm6n2niprC12E5kJY7EF9eiTRUiG9aqf Z8qQLSwc3HxE2cnAAle8C56ZAbn5vpA== 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=fm1; bh=nmF7e1EXkNFleOHiq2DOfSFlM//oa t+FNhdAMrjg+EU=; b=Dks9DBQJ7cdC9PvCbSMEew+WIypP3qZD5NVyW9miUc9Rh JJjfFqs0tVCq3woMwy05ggKw9J9ryVZXkIR3zEjcLvnT7lq31hSSmsuJuYILmzJr 1NnRFA8cGCFldIz1HNXX6Q6y1WAjS95EECbf28qo1tX4+6ZG5WvsVv4+4wKPqlkt 6eDbzlhy+n+xtEU0t2ab/Xu5tlYdDj/XrhoRk779e9kQY01Rcpunmz6wHfY2OmMD 4yk9WM2KzNXodDu8GVruLNxf6/l34MbdIS61HceHaocWNK/hPwTkKHXWcJD0OFkm PPqEG+RfwcM1vKpCbShQ3dwWC+zWtW3hzJftvLxUw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtuddgvdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthhosehf rghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenuc frrghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrghilhhtvggrmhdrtgho mhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 416FD300096; Tue, 29 Oct 2019 06:59:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-512-g193a140-fmstable-20191028v1 Mime-Version: 1.0 Message-Id: <771b0fa1-dced-4bd5-82db-2569999ac8ab@www.fastmail.com> Date: Tue, 29 Oct 2019 11:59:33 +0100 From: "Robert Stepanek" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=63cacf6eb739434e85e37e1e6d7dd290 Archived-At: Subject: [dispatch] JSContact - Updated to revision 05 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, 29 Oct 2019 10:59:56 -0000 --63cacf6eb739434e85e37e1e6d7dd290 Content-Type: text/plain Hi, We just updated the JSContact RFC draft to revision 5: https://tools.ietf.org/html/draft-stepanek-jscontact-05 This version: - adds the relatedTo property to JSCard - embeds JSCard objects in JSGroup entries rather than just their uid Some feedback is not yet addressed in this version. This includes alternatives to the current localizations approach, a more generic model for addresses and names, and support for merging JSCards. We are currently assessing options to address these. Mario will present JSContact at IETF106, which will be a great opportunity to discuss. Cheers, Robert --63cacf6eb739434e85e37e1e6d7dd290 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi,

We just updated the JSContact RFC draft to revision 5:= htt= ps://tools.ietf.org/html/draft-stepanek-jscontact-05
<= br>
This version:
- adds the relatedTo property = to JSCard
- embeds JSCard objects in JSGroup entries rathe= r than just their uid

Some  feedback i= s not yet addressed in this version. This includes alternatives to the c= urrent localizations approach, a more generic model for addresses and na= mes, and support for merging JSCards.

We ar= e currently assessing options to address these. Mario will present JSCon= tact at IETF106, which will be a great opportunity to discuss.
=

Cheers,
Robert
--63cacf6eb739434e85e37e1e6d7dd290-- From nobody Thu Oct 31 12:18:35 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 938E4120800; Thu, 31 Oct 2019 12:18:33 -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.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dispatch@ietf.org Message-ID: <157254951352.30368.2283290904010953066@ietfa.amsl.com> Date: Thu, 31 Oct 2019 12:18:33 -0700 Archived-At: Subject: [dispatch] I-D Action: draft-ietf-dispatch-javascript-mjs-05.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: Thu, 31 Oct 2019 19:18:34 -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-05.txt Pages : 21 Date : 2019-10-31 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-dispatch-javascript-mjs-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dispatch-javascript-mjs-05 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 Thu Oct 31 12:28:56 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDFA120018 for ; Thu, 31 Oct 2019 12:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 o4lSjey_px3R for ; Thu, 31 Oct 2019 12:28:53 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 17268120013 for ; Thu, 31 Oct 2019 12:28:53 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id f201so796216ilh.6 for ; Thu, 31 Oct 2019 12:28:53 -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=80qGbinKb5Muj5usD9n3Bxf2O1Sgk2uzcIqSqvFUxGQ=; b=UafHMjaWH7YiXEvFXVRvqIqQomgBYOPT0RToaPlY0WZvIuWlKep3M+1kVNLgwOJEM4 hRQI0h6iIdryzLb4/okU5CTWNw29W8sGz7q7OsCUBKWtWKAxwIDW72E5kVD6a2NvsHL7 i1u4lRgdCx18Eo/gxNwWGITMFKPQ1oUDvW6uxLOaEVTXyvlT6hA609wBYwA+Nh4gT30X HzDyiLPz6g+br+ECBIhPotoLd9p//E1Rh4MOMowNFAKNRuUAQJI0o/OTajURbNGn5SD6 nA25+ZwwOgyFBqW7p5A3e6oUTQ96yD85hv4BE8jC/yDTuVZ2BHZqxjcgVGdhSiGlWu2w Cs3w== 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=80qGbinKb5Muj5usD9n3Bxf2O1Sgk2uzcIqSqvFUxGQ=; b=aY8r9uzdABp2Hr26tpCGotem9c6JGHVdAspqVkgKD3s0ssyc3LZ6z+PAmLN0U/POQY TikzqhhBtla+R9jpM4Rz0X8GRQ9n5MuYibbjbPyL3dRHVlZDwVxodBcsBN5GT1hvtfVN CnsanOo2BPTEqhePmsAddl50DuDK5MLvFjPaczaSHZmqr8iYrBfkJ1TEPr3A093MYRKe R4NWEZGkkFy6tJGVQ11sr4F8H5Ioy3PD1LcxOTGyFtxTlIx9oKf6HEw/G//GP/5peL+5 Y89qEUynE2JSL3D11VO3RrJwGOT463C+yOXYUM09bLEEUfVTr66YVKPzW1v4rRQzv2H6 RL/Q== X-Gm-Message-State: APjAAAWsSdy95TU70mQhsogcjbdqsopnpgMFwqx4XAN0jtjTsephF4Ma tY5BR//7cUmfNSziempVF0vBnEwj5oO5ew== X-Google-Smtp-Source: APXvYqwbm0t602lGOM+ai7rwdG6OAHDsI8bCowzlFOmPJdjGytDHSSLBhT6OVeMYDQK3MolGw2Arcg== X-Received: by 2002:a92:d64a:: with SMTP id x10mr7778145ilp.305.1572550131170; Thu, 31 Oct 2019 12:28:51 -0700 (PDT) Received: from mmiller-44677.local ([2601:280:4f00:14a:891c:a4b8:a64:ccb4]) by smtp.gmail.com with ESMTPSA id v28sm702659ill.74.2019.10.31.12.28.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Oct 2019 12:28:49 -0700 (PDT) Sender: Matthew Miller To: dispatch@ietf.org References: <157254951352.30368.2283290904010953066@ietfa.amsl.com> 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: Date: Thu, 31 Oct 2019 13:28:48 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <157254951352.30368.2283290904010953066@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] I-D Action: draft-ietf-dispatch-javascript-mjs-05.txt 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, 31 Oct 2019 19:28:55 -0000 This revision addresses most of the comments made by the current document shepherd, Ben Campbell. The only comment not addressed is to Obsolete RFC 4329. Rather than waiting to complete that change (which would be editorially substantial), we published this revision with other substantive changes first. A revision that obsoletes 4329 we hope to publish shortly after submissions reopen. - m&m Matthew A. Miller On 19/10/31 13:18, internet-drafts@ietf.org wrote: > > 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-05.txt > Pages : 21 > Date : 2019-10-31 > > 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-05 > https://datatracker.ietf.org/doc/html/draft-ietf-dispatch-javascript-mjs-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dispatch-javascript-mjs-05 > > > 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/ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >