From nobody Mon Nov 1 05:58:28 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9B63A12B4 for ; Mon, 1 Nov 2021 05:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=fastmail.com header.b=RHDddo+Y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=W47ONC4w 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 Zyne4RYkjO1n for ; Mon, 1 Nov 2021 05:58:22 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1290B3A1292 for ; Mon, 1 Nov 2021 05:58:22 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 78E315C01CF for ; Mon, 1 Nov 2021 08:58:21 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 01 Nov 2021 08:58:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= message-id:date:mime-version:to:from:subject:content-type :content-transfer-encoding; s=fm1; bh=2zFfYgUBozB5/nlstTyOcHUtjU v9iAX7RlbGv0GWXDA=; b=RHDddo+YpCw4kchFn+DjN849HBhkTM+7RdE32bnrJ8 me4FhJNiP3eDaREE3w/XRCvpKULHkhNXH8zsI9fwz36KqUHr7DFtsycM7I7tmClg k00auuexSp3bcDJ7xTfqRiHCdjNm6Ss/yhBnncp+rRNDTy4CtKtkxNxoGdMYB0vE GlqUgdESA842XpHmTg/VgIyf5nP+PR5lJK/8CejWrb6dIqsmjAZRQ/v8sQhXsjnk FghYSkFL0jxulZzMuojKaATRcc4aZBSdkNuHW0iP9+ct4v3FfGHAokNsnShjZ6uA QQ1J4GLCCBTU1xRiE8+3TnGvJPOnTHby8L6SI0euoa8A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=2zFfYg UBozB5/nlstTyOcHUtjUv9iAX7RlbGv0GWXDA=; b=W47ONC4wldXjgGuWz2Koib R5tyi3ghOxfG1Klcg/sMIrJ0+CG/Tly35nKv5y2BxY0lHz3DakUp6gaVfj7yj+0K lCcd1CnsOuFU9lt1FexpeOS0r0PXl9LBmMNhuEybqBt/Hqtf+jZ+OFpk8Hdz0a06 JK5emFnJ5l+hDQw633egsrst9XaCugLqe4OjJhCDmOOork87GDT5Gol0JG+u6MGL V5ncAI00mpxGv8DEopZ0NLqSQTm7iEbvQl5iDucwHlVefjHTWRWNwwIWi6gJReYU V+2tLKCM6r8Q/0dE5qvml/ScrcxkvP070UlAx6dQrFfqUirgLYsY3U/R3lNcqqTg == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdehvddggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfvffhufhotgfgsehtjeertddtfeejnecuhfhrohhmpefmvghnucfo uhhrtghhihhsohhnuceomhhurhgthhesfhgrshhtmhgrihhlrdgtohhmqeenucggtffrrg htthgvrhhnpeekveetgeetjedtjefggfffvddtudelffdvjedvhefffedtueejuedtueej vdekudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmuhhrtghhsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 1 Nov 2021 08:58:20 -0400 (EDT) Message-ID: <792d2e7c-4486-8c3d-ec4a-4b6b718380a1@fastmail.com> Date: Mon, 1 Nov 2021 08:58:14 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US To: IETF JMAP Mailing List From: Ken Murchison Organization: FastMail US LLC Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Jmap] draft-ietf-jmap-blob-05 Review X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 12:58:28 -0000 Overall, this look good. General comment: probably should fully expand "spec" to "specification" throughout Specific nits: - Abstract: "defined endpoint" -> "defined endpoints" - Section 4.1.1: I think the Blob/set{create} response elements should be in list format rather than packed together in a single paragraph. - Section 4.1.3: It is not clear to me whether Blob/set{destroy} is a valid method. - Section 4.1.3: Since the examples are for Blob/set{create}, I think they either belong in Section 4.1.1 or in a new 4.1.4. -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Tue Nov 2 19:49:19 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862123A0A94 for ; Tue, 2 Nov 2021 19:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=KFqLBhL8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=m8mF2e7d 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 DlFlUBz63GnM for ; Tue, 2 Nov 2021 19:49:12 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C4F3A0A90 for ; Tue, 2 Nov 2021 19:49:12 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C9EAB5C0066 for ; Tue, 2 Nov 2021 22:49:11 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Tue, 02 Nov 2021 22:49:11 -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=OWydGwPC61d+YFBesmjdwa7b49cvfTehgJBTI29 UDS8=; b=KFqLBhL8g67quNA2fu8SJHoqjhd4vZo08eMgWtzlvDg57CdcJP6vscJ SO2MWU4mS5TAsm25W9yenGPBY23iBteiPUy3/hCvXebOMV6oAsmco9avq+WL0dqU fIwB2bt2hktFQJsAxe7gcg/FT9gGid8GCZjXjEV61jRqFRDB/CYjIG8tOG3D+9Fu SGpejItbeQ7ehGXShz1RWMyo+IbMK3ywVjngiqMig8PG4ukO7OVns7/PnzkdjAF1 ucCiuBj1ImUdFoFhYxgCgqxRIUb2XumDRvvzc6uPBwDl9boi8duoq97Xjq6NK/Ny hm+xo21P2RAzQvhk055s26KANcfoIOg== 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=OWydGwPC61d+YFBesmjdwa7b49cvf TehgJBTI29UDS8=; b=m8mF2e7dPZlUr39xktTK0ZnUy/EY1CywU4udJyCoNgvMx WnJGhWu6utDCU8KMaIlpmjK4Q4QLx/8jkWU2Xi8sestmHvQOZcdmdUp8CBegiO4W pEklEEIFGTaUzk5RXRmJrVHxt2ibSDxUhL4JyURMV5wIJpnORuodp1+LNC7zrnY6 HUlLsHjGcecQZp2ddJkkrBbTOukLEEPNztukerqj5G8zOjPBmKfN55gC+LKDtQ0F TN6++xFr7/LbuD6/q8yPqA4htX19LxGnX1hLu0gh2JD6CZZyUYhFPvma3l+/IH/j C1qSvcYO4Qkqec2VfLVY5ctpzLWiMQG9XUa9oeoAQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrtddugdeglecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhephfejheekjeekheevue dtjeetiefhffefudeitddtjefhleetveeuheduledtueffnecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 85C52AC0DD1; Tue, 2 Nov 2021 22:49:11 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1399-ga34296eb8f-fm-20211021.002-ga34296eb Mime-Version: 1.0 Message-Id: Date: Wed, 03 Nov 2021 13:48:50 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=4734850292fe4b58a0e5ac96bb0c350c Archived-At: Subject: [Jmap] Plenty of agenda time at IETF112 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2021 02:49:18 -0000 --4734850292fe4b58a0e5ac96bb0c350c Content-Type: text/plain Hi all, I've just put together an initial draft agenda for IETF112 and realise there's a bunch of space available! I booked 2 hours because at the time there was a plan to spend quite a bit of time on JMAP Calendars, with some production experience, but without that in place maybe there's excess time available. So if you have anything else you'd like to talk about, the agenda as uploaded now has 20 spare minutes available, as well as a generous 15 minutes for any other business - so let us know what you'd like the group to talk about! https://datatracker.ietf.org/doc/agenda-112-jmap/ Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --4734850292fe4b58a0e5ac96bb0c350c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi all,
I've just put together an init= ial draft agenda for IETF112 and realise there's a bunch of space availa= ble!  I booked 2 hours because at the time there was a plan to spen= d quite a bit of time on JMAP Calendars, with some production experience= , but without that in place maybe there's excess time available.

So if you have a= nything else you'd like to talk about, the agenda as uploaded now has 20= spare minutes available, as well as a generous 15 minutes for any other= business - so let us know what you'd like the group to talk about!
<= /div>


Cheers,

Bron.

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


--4734850292fe4b58a0e5ac96bb0c350c-- From nobody Wed Nov 3 06:13:32 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B503A1243 for ; Wed, 3 Nov 2021 06:13:30 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKrYhL2mnig8 for ; Wed, 3 Nov 2021 06:13:25 -0700 (PDT) Received: from mail.audriga.com (mail.audriga.com [176.221.42.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F703A1153 for ; Wed, 3 Nov 2021 06:13:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id C91BAA149 for ; Wed, 3 Nov 2021 14:13:21 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.audriga.com Received: from mail.audriga.com ([127.0.0.1]) by localhost (mail.audriga.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXJXGGgDb9k8 for ; Wed, 3 Nov 2021 14:12:57 +0100 (CET) Received: from [192.168.10.127] (b2b-109-90-161-242.unitymedia.biz [109.90.161.242]) (Authenticated sender: joris@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id A361AA178 for ; Wed, 3 Nov 2021 14:12:57 +0100 (CET) Message-ID: <681c1851-a9e9-4cec-81a5-5d80f43f7c3e@audriga.com> Date: Wed, 3 Nov 2021 14:12:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: IETF JMAP Mailing List From: Joris Baum Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Jmap] draft-ietf-jmap-blob-05 Review X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2021 13:13:30 -0000 Looks good to me as well. The examples make sense to me in general, look good and are probably sufficient. One thing I noticed / that confuses me is the "expires" property in the concatenate example (Section 4.1.3 https://www.ietf.org/archive/id/draft-ietf-jmap-blob-05.html#name-destroy ) . As far as I can see there is no mention of it in the upload section 6.1 of RFC 8620 ( https://datatracker.ietf.org/doc/html/rfc8620#section-6.1 ) nor in the JMAP Blob management extension spec. It looks like it is PushSubscription-specific and should not be in the example. Regards, Joris -- Joris Baum Tel: +49 721 170293 16 Fax: +49 721 170293 179 http://www.audriga.com | http://www.twitter.com/audriga -------------------------------------------------------------------------- audriga GmbH | Durlacher Allee 47 | 76131 Karlsruhe Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034 Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel -------------------------------------------------------------------------- From nobody Thu Nov 4 00:26:38 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D503A09FB for ; Thu, 4 Nov 2021 00:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=fastmailteam.com header.b=WA2C5Ayo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XTDrQT92 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 4WOhV31OdKvf for ; Thu, 4 Nov 2021 00:26:31 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875E83A0A00 for ; Thu, 4 Nov 2021 00:26:31 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 979B55C0184 for ; Thu, 4 Nov 2021 03:26:29 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Thu, 04 Nov 2021 03:26:29 -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=XKMWfPkDx1cn2sUwZMUOa5Fjm2Clbq+MhnT6fUG 1C8A=; b=WA2C5AyorVuobcfqE/ozj3gF5XE+wm8vuKErNxxvlAzj4P5Ct6rvWD9 jeZ5n2mkJicvnRpVIElqSqh+IWHuU+GnP6nq1MOo3ZnNpRENUdYQCbL2PIPybYzu R6qzdMbzSAKcu8PavCtCGj0vysZDWLsIytbkuClIVY4ZKRLZpVCG5khR+iykmp2n a06CyGDM6hbRuFMzjqdaWWq4kPVsbihL9nEfcLCx/JNZbpp/cxvTBHNI8EL9/UcA ybQFvuvsIszSk8fu/feN7X1txi6280Wa8NnqA1PobSy20amKYyEHRQsc4116Hmk0 lOm9wQIJozvUWLP/25S4TVODNiQpLPQ== 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=XKMWfPkDx1cn2sUwZMUOa5Fjm2Clb q+MhnT6fUG1C8A=; b=XTDrQT92V64HxHN2VsbGb/fLNfISLPP72xGkwAGdSmNQl 8bsjZIYMXlsBOUNVADBe2+kVlqCgqQW2UDwlFOdRyOEs8Fft5ByWtjzTMjeVcHt2 nu1sX034wQyzw4/hMsI2rMm1eWmkQG9GFZED+c9V/aRIfG4qDQxlzu8XNaiq/Xvh YmsC3mYyfpHzuJ6L4x3KY3prWjUhYElxStpmcbapM5jY9Rc3RMQ5EzflC+F4TV97 aRKjlnd+1V9yVl2M7PYsKwxQ0Y9scxS32lNzdiMx1bEL8B/m51sV5bC9zWiJ/3En ofcC0qBbm4O/Os1gd3WaZiQtBDYjYVyJWqYt7kRUw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrtdefgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthhosehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepgeeikeehkeehhe fhtdehvedvhffghfetudeljeetffdtkeeuleeufeevfedviedunecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 67832AC0DD1; Thu, 4 Nov 2021 03:26:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1420-gdf09e8761c-fm-20211101.001-gdf09e876 Mime-Version: 1.0 Message-Id: <6d42064a-16c9-4484-abd6-a67cf608ab54@www.fastmail.com> Date: Thu, 04 Nov 2021 08:26:09 +0100 From: "Robert Stepanek" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=243cf3de1d1a4ce49123329f6ff9e966 Archived-At: Subject: [Jmap] draft-ietf-jmap-blob-05 Review X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2021 07:26:37 -0000 --243cf3de1d1a4ce49123329f6ff9e966 Content-Type: text/plain Looks good to me, except: Section 4.1.1: the asText/asBase64/asHex forms are stated here without explanation of their semantics. They are defined later in the draft in Section 4.2, and there only as result properties. Section 4.1.2: does not define which SetError type to return in notUpdated? Cheers, Robert --243cf3de1d1a4ce49123329f6ff9e966 Content-Type: text/html
Looks good to me, except:

Section 4.1.1: the asText/asBase64/asHex forms are stated here without explanation of their semantics. They are defined later in the draft in Section 4.2, and there only as result properties.

Section 4.1.2: does not define which SetError type to return in notUpdated?

Cheers,
Robert




--243cf3de1d1a4ce49123329f6ff9e966-- From nobody Fri Nov 5 09:37:58 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988D63A11D5 for ; Fri, 5 Nov 2021 09:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.229 X-Spam-Level: X-Spam-Status: No, score=-5.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-3.33, 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 MWnpOCV_u8UI for ; Fri, 5 Nov 2021 09:37:54 -0700 (PDT) Received: from mail.audriga.com (mail.audriga.com [176.221.42.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65323A11D1 for ; Fri, 5 Nov 2021 09:37:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id 26E3CA149 for ; Fri, 5 Nov 2021 17:37:50 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.audriga.com Received: from mail.audriga.com ([127.0.0.1]) by localhost (mail.audriga.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srqmZgGin9ta for ; Fri, 5 Nov 2021 17:37:25 +0100 (CET) Received: from [192.168.10.154] (b2b-109-90-161-242.unitymedia.biz [109.90.161.242]) (Authenticated sender: happel@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id 96867A0D3 for ; Fri, 5 Nov 2021 17:37:25 +0100 (CET) From: Hans-Joerg Happel To: jmap@ietf.org References: Message-ID: Date: Fri, 5 Nov 2021 17:37:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DFAF6276BE09E3199D3DD3F3" Content-Language: en-US Archived-At: Subject: Re: [Jmap] [Jmap for Sieve] Binary/blob vs. Inline X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 16:37:57 -0000 This is a multi-part message in MIME format. --------------DFAF6276BE09E3199D3DD3F3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 26.10.21 06:43, Neil Jenkins wrote: > On Fri, 22 Oct 2021, at 03:41, Hans-Joerg Happel wrote: >> => We'd argue that this process is both complex to implement plus it's >> not particularly elegant to create a need for storing a temporary file. > > Depends how you look at it; it /is/ elegant to have a single > consistent method for referencing binary data. I think the answer here > if you are trying to add support on a legacy system where this is > difficult is to make the Sieve its own account. Then when you upload a > blob to that account you know it can only be a sieve script, which > should allow you to do something reasonable. Thanks for elaboration - I missed to recognize that it is possible use the "Account-workaround" also for writing. However, enforcing this process makes it still hard to implement in various imaginable cases. Take my initial Database storage example: You might force an implementer to store a temp Sieve script (from blob call) until the second call comes in to continue glue together that data and do the database INSERT. While this is no strict blocker, I think enforcing a blob storage concept so widely is in conflict with the goal of making it easy for as many people as possible to adopt JMAP. Some additional minor points, for the record: * The blobId approach opens up many potential error cases, which server+client implementers need to have in mind (e.g, think about the script validation workflow) * It makes the JMAP Sieve workflow essentially different from the known and closely related ManageSieve workflows > >> It would therefore be good if it is possible to (alternatively?) submit >> the script inline in the "SieveScript/set" command instead of a blobid. > > Using Bron's blob extension you can create a blob in-band and then > backreference it from the SieveScript/set command. But I wouldn't want > to say that was the only way you could do it; that breaks the > consistency of the blob handling. If I understand it correctly, while it is atomic from a HTTP call perspective, the chained processing of commands on server-side is not necessarily atomic from a logical point of view? Which would mean that a client still needs to deal with different cases (partial fail / complete fail ... ) of the chained calls? Best, Hans-Joerg --------------DFAF6276BE09E3199D3DD3F3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 26.10.21 06:43, Neil Jenkins wrote:
On Fri, 22 Oct 2021, at 03:41, Hans-Joerg Happel wrote:
=> We'd argue that this process is both complex to implement plus it's 
not particularly elegant to create a need for storing a temporary file. 

Depends how you look at it; it is elegant to have a single consistent method for referencing binary data. I think the answer here if you are trying to add support on a legacy system where this is difficult is to make the Sieve its own account. Then when you upload a blob to that account you know it can only be a sieve script, which should allow you to do something reasonable.

Thanks for elaboration - I missed to recognize that it is possible use the "Account-workaround" also for writing.

However, enforcing this process makes it still hard to implement in various imaginable cases. Take my initial Database storage example: You might force an implementer to store a temp Sieve script (from blob call) until the second call comes in to continue glue together that data and do the database INSERT.

While this is no strict blocker, I think enforcing a blob storage concept so widely is in conflict with the goal of making it easy for as many people as possible to adopt JMAP.

Some additional minor points, for the record:

* The blobId approach opens up many potential error cases, which server+client implementers need to have in mind (e.g, think about the script validation workflow)
* It makes the JMAP Sieve workflow essentially different from the known and closely related ManageSieve workflows



It would therefore be good if it is possible to (alternatively?) submit 
the script inline in the "SieveScript/set" command instead of a blobid.

Using Bron's blob extension you can create a blob in-band and then backreference it from the SieveScript/set command. But I wouldn't want to say that was the only way you could do it; that breaks the consistency of the blob handling.

If I understand it correctly, while it is atomic from a HTTP call perspective, the chained processing of commands on server-side is not necessarily atomic from a logical point of view? Which would mean that a client still needs to deal with different cases (partial fail / complete fail ... ) of the chained calls?

Best,
Hans-Joerg

--------------DFAF6276BE09E3199D3DD3F3-- From nobody Fri Nov 5 13:00:34 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6060E3A0D2D for ; Fri, 5 Nov 2021 13:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4HZ_7UQgLCK for ; Fri, 5 Nov 2021 13:00:27 -0700 (PDT) Received: from mail.audriga.com (mail.audriga.com [176.221.42.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE56B3A0D29 for ; Fri, 5 Nov 2021 13:00:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id 090D7A2A9; Fri, 5 Nov 2021 21:00:24 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.audriga.com Received: from mail.audriga.com ([127.0.0.1]) by localhost (mail.audriga.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9taGUCq4TC1r; Fri, 5 Nov 2021 20:59:58 +0100 (CET) Received: from [192.168.0.134] (HSI-KBW-46-223-163-87.hsi.kabel-badenwuerttemberg.de [46.223.163.87]) (Authenticated sender: joris@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id 9BCD2A0D3; Fri, 5 Nov 2021 20:59:58 +0100 (CET) Content-Type: multipart/mixed; boundary="------------0cXHKIXYm6POQK1v5oPalAld" Message-ID: <30a6ea04-ff61-66f6-5904-5c1a349033a1@audriga.com> Date: Fri, 5 Nov 2021 20:59:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: IETF JMAP Mailing List From: Joris Baum Cc: Hans-Joerg Happel Archived-At: Subject: [Jmap] JMAP Task Survey X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 20:00:32 -0000 This is a multi-part message in MIME format. --------------0cXHKIXYm6POQK1v5oPalAld Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, the first version of the JMAP Task Survey is now ready. I published it on GitHub at https://gist.github.com/jaudriga/cd323fa75397c76b1dd30861ef590302 and also attached an HTML version of it to this mail. We will provide a summary about it on the next IETF 112. I am looking forward to hearing your opinions on it. Regards, Joris -- Joris Baum Tel: +49 721 170293 16 Fax: +49 721 170293 179 http://www.audriga.com | http://www.twitter.com/audriga -------------------------------------------------------------------------- audriga GmbH | Durlacher Allee 47 | 76131 Karlsruhe Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034 Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel -------------------------------------------------------------------------- --------------0cXHKIXYm6POQK1v5oPalAld Content-Type: text/html; charset=UTF-8; name="jmap_task_survey.html" Content-Disposition: attachment; filename="jmap_task_survey.html" Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWw+CjxodG1sPjxoZWFkPgo8bWV0YSBjaGFyc2V0PSJVVEYtOCI+Cjxs aW5rIHJlbD0ic3R5bGVzaGVldCIgaHJlZj0iaHR0cHM6Ly9jZG5qcy5jbG91ZGZsYXJlLmNv bS9hamF4L2xpYnMvS2FUZVgvMC45LjAtYWxwaGEyL2thdGV4Lm1pbi5jc3MiIGNyb3Nzb3Jp Z2luPSJhbm9ueW1vdXMiPgo8bGluayByZWw9InN0eWxlc2hlZXQiIGhyZWY9Imh0dHBzOi8v Y2RuanMuY2xvdWRmbGFyZS5jb20vYWpheC9saWJzL2hpZ2hsaWdodC5qcy85LjEyLjAvc3R5 bGVzL2RlZmF1bHQubWluLmNzcyI+CjxzY3JpcHQgc3JjPSJodHRwczovL2NkbmpzLmNsb3Vk ZmxhcmUuY29tL2FqYXgvbGlicy9LYVRlWC8wLjkuMC1hbHBoYTIva2F0ZXgubWluLmpzIiBj cm9zc29yaWdpbj0iYW5vbnltb3VzIj48L3NjcmlwdD4KPHNjcmlwdCBzcmM9Imh0dHBzOi8v Y2RuanMuY2xvdWRmbGFyZS5jb20vYWpheC9saWJzL0thVGVYLzAuOS4wLWFscGhhMi9jb250 cmliL2F1dG8tcmVuZGVyLm1pbi5qcyIgY3Jvc3NvcmlnaW49ImFub255bW91cyI+PC9zY3Jp cHQ+CjxzY3JpcHQgc3JjPSJodHRwczovL2NkbmpzLmNsb3VkZmxhcmUuY29tL2FqYXgvbGli cy9oaWdobGlnaHQuanMvOS4xMi4wL2hpZ2hsaWdodC5taW4uanMiPjwvc2NyaXB0Pgo8c2Ny aXB0IHNyYz0iaHR0cHM6Ly91bnBrZy5jb20vbWVybWFpZEA3LjEuMi9kaXN0L21lcm1haWQu bWluLmpzIj48L3NjcmlwdD4KPHN0eWxlPgpAY2hhcnNldCAidXRmLTgiOwoKLyoqCiAqIG1h cmtkb3duLmNzcwogKgogKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTogeW91IGNh biByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeSBpdCB1bmRlcgogKiB0aGUgdGVybXMg b2YgdGhlIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQg YnkgdGhlIEZyZWUKICogU29mdHdhcmUgRm91bmRhdGlvbiwgZWl0aGVyIHZlcnNpb24gMyBv ZiB0aGUgTGljZW5zZSwgb3IgKGF0IHlvdXIgb3B0aW9uKSBhbnkKICogbGF0ZXIgdmVyc2lv bi4KICoKICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQg aXQgd2lsbCBiZSB1c2VmdWwsIGJ1dCBXSVRIT1VUCiAqIEFOWSBXQVJSQU5UWTsgd2l0aG91 dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mIE1FUkNIQU5UQUJJTElUWSBvciBGSVRO RVNTCiAqIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gU2VlIHRoZSBHTlUgTGVzc2VyIEdl bmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUKICogZGV0YWlscy4KICoKICogWW91IHNo b3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIExlc3NlciBHZW5lcmFsIFB1 YmxpYyBMaWNlbnNlCiAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtLiBJZiBub3QsIHNlZSBo dHRwOi8vZ251Lm9yZy9saWNlbnNlcy9sZ3BsLnR4dC4KICoKICogQHByb2plY3QgICAgICBX ZWJsb2cgYW5kIE9wZW4gU291cmNlIFByb2plY3RzIG9mIEZsb3JpYW4gV29sdGVycwogKiBA dmVyc2lvbiAgICAgIEdJVDogJElkJAogKiBAcGFja2FnZSAgICAgIHhodG1sLWNzcwogKiBA YXV0aG9yICAgICAgIEZsb3JpYW4gV29sdGVycyA8Zmxvcmlhbi53b2x0ZXJzLjg1QGdvb2ds ZW1haWwuY29tPgogKiBAY29weXJpZ2h0ICAgIDIwMTIgRmxvcmlhbiBXb2x0ZXJzCiAqIEBj c3Nkb2MgICAgICAgdmVyc2lvbiAxLjAtcHJlCiAqIEBsaWNlbnNlICAgICAgaHR0cDovL2du dS5vcmcvbGljZW5zZXMvbGdwbC50eHQgR05VIExlc3NlciBHZW5lcmFsIFB1YmxpYyBMaWNl bnNlCiAqIEBsaW5rICAgICAgICAgaHR0cDovL2dpdGh1Yi5jb20vRmxvcmlhbldvbHRlcnMv amVreWxsLWJvb3RzdHJhcC10aGVtZQogKiBAbWVkaWEgICAgICAgIGFsbAogKiBAdmFsaWQg ICAgICAgIHRydWUKICovCgppbWcgewoJbWF4LXdpZHRoOiAxMDAlOwp9Cgp0YWJsZSB7Cgli b3JkZXItY29sbGFwc2U6IGNvbGxhcHNlOwoJd2lkdGg6IDEwMCU7Cn0KCnRhYmxlLCB0aCwg dGQgewoJYm9yZGVyOiAxcHggc29saWQgI0VBRUFFQTsKCWJvcmRlci1yYWRpdXM6IDNweDsK CXBhZGRpbmc6IDVweDsKfQoKdHI6bnRoLWNoaWxkKGV2ZW4pIHsKCWJhY2tncm91bmQtY29s b3I6ICNGOEY4Rjg7Cn0KCmJvZHkgewogICAgZm9udC1mYW1pbHk6IEhlbHZldGljYSwgQXJp YWwsIEZyZWVzYW5zLCBjbGVhbiwgc2Fucy1zZXJpZjsKICAgIHBhZGRpbmc6MWVtOwogICAg bWFyZ2luOmF1dG87CiAgICBtYXgtd2lkdGg6NDJlbTsKICAgIGJhY2tncm91bmQ6I2ZlZmVm ZTsKfQoKaDEsIGgyLCBoMywgaDQsIGg1LCBoNiB7CiAgICBmb250LXdlaWdodDogYm9sZDsK fQoKaDEgewogICAgY29sb3I6ICMwMDAwMDA7CiAgICBmb250LXNpemU6IDI4cHg7Cn0KCmgy IHsKICAgIGJvcmRlci1ib3R0b206IDFweCBzb2xpZCAjQ0NDQ0NDOwogICAgY29sb3I6ICMw MDAwMDA7CiAgICBmb250LXNpemU6IDI0cHg7Cn0KCmgzIHsKICAgIGZvbnQtc2l6ZTogMThw eDsKfQoKaDQgewogICAgZm9udC1zaXplOiAxNnB4Owp9CgpoNSB7CiAgICBmb250LXNpemU6 IDE0cHg7Cn0KCmg2IHsKICAgIGNvbG9yOiAjNzc3Nzc3OwogICAgYmFja2dyb3VuZC1jb2xv cjogaW5oZXJpdDsKICAgIGZvbnQtc2l6ZTogMTRweDsKfQoKaHIgewogICAgaGVpZ2h0OiAw LjJlbTsKICAgIGJvcmRlcjogMDsKICAgIGNvbG9yOiAjQ0NDQ0NDOwogICAgYmFja2dyb3Vu ZC1jb2xvcjogI0NDQ0NDQzsKfQoKcCwgYmxvY2txdW90ZSwgdWwsIG9sLCBkbCwgbGksIHRh YmxlLCBwcmUgewogICAgbWFyZ2luOiAxNXB4IDA7Cn0KCmNvZGUsIHByZSB7CiAgICBib3Jk ZXItcmFkaXVzOiAzcHg7CiAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjRjhGOEY4OwogICAgY29s b3I6IGluaGVyaXQ7Cn0KCmNvZGUgewogICAgYm9yZGVyOiAxcHggc29saWQgI0VBRUFFQTsK ICAgIG1hcmdpbjogMCAycHg7CiAgICBwYWRkaW5nOiAwIDVweDsKfQoKcHJlIHsKICAgIGJv cmRlcjogMXB4IHNvbGlkICNDQ0NDQ0M7CiAgICBsaW5lLWhlaWdodDogMS4yNWVtOwogICAg b3ZlcmZsb3c6IGF1dG87CiAgICBwYWRkaW5nOiA2cHggMTBweDsKfQoKcHJlID4gY29kZSB7 CiAgICBib3JkZXI6IDA7CiAgICBtYXJnaW46IDA7CiAgICBwYWRkaW5nOiAwOwp9CgphLCBh OnZpc2l0ZWQgewogICAgY29sb3I6ICM0MTgzQzQ7CiAgICBiYWNrZ3JvdW5kLWNvbG9yOiBp bmhlcml0OwogICAgdGV4dC1kZWNvcmF0aW9uOiBub25lOwp9CgoKZmlndXJlIGZpZ2NhcHRp b24gewogICAgdGV4dC1hbGlnbjogY2VudGVyOwogICAgZm9udC1zaXplOiAxMnB4Owp9Cjwv c3R5bGU+CjwvaGVhZD4KPGJvZHk+CjxkaXYgY2xhc3M9ImRvY3VtZW50Ij4KPGRpdiBjbGFz cz0iaGVhZGVyIj48L2Rpdj48ZGl2IGNsYXNzPSJpbm5lciI+CjxoMiBpZD0idG9jXzEiPlRh c2sgU3lzdGVtIFN1cnZlcnk8L2gyPgoKPGgzIGlkPSJ0b2NfMS4xIj5JbnRyb2R1Y3Rpb248 L2gzPgoKPHA+Sk1BUCAoPGEgaHJlZj0iaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZj L3JmYzg2MjAuaHRtbCI+UkZDODYyMDwvYT4g4oCTIEpTT04gTWV0YQpBcHBsaWNhdGlvbiBQ cm90b2NvbCkgaXMgYSBnZW5lcmljIHByb3RvY29sIGZvciBzeW5jaHJvbml6aW5nIGRhdGEs IHN1Y2ggYXMKbWFpbCwgY2FsZW5kYXJzIG9yIGNvbnRhY3RzLCBiZXR3ZWVuIGEgY2xpZW50 IGFuZCBhIHNlcnZlci4gSXQgaXMgb3B0aW1pemVkIGZvcgptb2JpbGUgYW5kIHdlYiBlbnZp cm9ubWVudHMsIGFuZCBhaW1zIHRvIHByb3ZpZGUgYSBjb25zaXN0ZW50IGludGVyZmFjZSB0 bwpkaWZmZXJlbnQgZGF0YSB0eXBlcyBhbmQgdG8gaW1wcm92ZSBpbnRlcm9wZXJhYmlsaXR5 LiBEYXRhIGZvcm1hdHMgc3BlY2lmaWVkIGluCkpNQVAgc3RhbmRhcmRzIG1pZ2h0IGFsc28g aGVscCB0byBpbXByb3ZlIGRhdGEgcG9ydGFiaWxpdHkgLSBlYXNpbmcgZGF0YQp0cmFuc2Zl ciBiZXR3ZWVuIHN5c3RlbXMgb2YgZGlmZmVyZW50IHZlbmRvcnMuPC9wPgoKPHA+Sk1BUCBm b3IgVGFza3MKKDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJh ZnQtaWV0Zi1qbWFwLXRhc2tzLTAyLmh0bWwiPmlldGYtam1hcC10YXNrczwvYT4pCmV4dGVu ZHMgSk1BUCB3aXRoIHN5bmNocm9uaXphdGlvbiBvZiB0YXNrIGRhdGEuIEl0cyBpbml0aWFs IGRlc2lnbiBpcyBtb3RpdmF0ZWQKYnkgdGFzayBtYW5hZ2VtZW50IGluIGdyb3Vwd2FyZSBh bmQgd2VibWFpbCBzeXN0ZW1zLCB3aGljaCBhcmUgdGhlIGNvcmUgdGFyZ2V0cwpvZiBKTUFQ LiBIb3dldmVyLCB3aGlsZSBtYWlsLCBjb250YWN0IGFuZCBjYWxlbmRhciBmdW5jdGlvbmFs aXR5IGluIHRob3NlCnN5c3RlbXMgaXMgcmVsYXRpdmVseSBzaW1pbGFyLCB0aGVyZSBpcyBt b3JlIGhldGVyb2dlbmVpdHkgd2hlbiBpdCBjb21lcyB0bwp0YXNrcy4gUmVsYXRlZCB0byB0 aGF0LCB0aGVyZSBpcyBhIG1vcmUgaGV0ZXJvZ2VuZW91cyBzZXQgb2Ygc3lzdGVtcyB0aGF0 CmltcGxlbWVudCBzb21lIGtpbmQgb2YgdGFzayBtYW5hZ2VtZW50IGJleW9uZCBncm91cHdh cmUvV2VibWFpbC4gVGhlIGdvYWwgb2YgCnRoaXMgc3VydmV5IGlzIHRvIHByb3ZpZGUgYW4g b3ZlcnZpZXcgYWJvdXQgY3VycmVudCB0YXNrIHN5c3RlbXMgYW5kIGlkZW50aWZ5CnBvdGVu dGlhbCBnYXBzIG9mIHRoZSBjdXJyZW50IEpNQVAgVGFza3MgZGF0YSBtb2RlbCBmb3Igb3Ro ZXIgdXNlIGNhc2VzIGJleW9uZAp0eXBpY2FsIENhbGVuZGFyaW5nIHNvZnR3YXJlLiBUaGlz IHN1cnZleSBmb2N1c2VzIG9uIEdyb3Vwd2FyZSBzeXN0ZW1zLApLYW5iYW4tc3R5bGUgdG9v bHMgYW5kIGJ1ZyB0cmFja2luZyBzeXN0ZW1zLjwvcD4KCjxwPjxlbT5LYW5iYW4tc3R5bGUg dG9vbHM8L2VtPiBjYW4gYmUgdXNlZCB0byBpbXBsZW1lbnQga2FuYmFuIHRvIG1hbmFnZSB3 b3JrLiBUaGV5CnR5cGljYWxseSBoYXZlIGEgYm9hcmQgdGhhdCBjb250YWlucyBidWNrZXRz LCB3aGljaCBpbiB0dXJuIGNvbnRhaW4gY2FyZHMvdGFza3MuCkthbmJhbi1zdHlsZSBzeXN0 ZW1zIGluIHRoaXMgc3VydmV5IGFyZTogTWljcm9zb2Z0IFBsYW5uZXIsIENsaWNrdXAsIEZh Y3RybywKTmV4dGNsb3VkIERlY2ssIFRyZWxsbyBhbmQgWnViZS48L3A+Cgo8cD48ZW0+SXNz dWUgdHJhY2tpbmcgc3lzdGVtczwvZW0+IGFyZSBidWlsdCBmb3IgbWFuYWdpbmcgYW5kIG1h aW50YWluaW5nIGxpc3RzIG9mIGlzc3Vlcy4KVGhlc2Ugc3lzdGVtcyB0eXBpY2FsbHkgaW5j bHVkZSBmZWF0dXJlcyBmb3IgZG9jdW1lbnRpbmcgcmVzb3VyY2UgYWxsb2NhdGlvbiwKdGlt ZSBhY2NvdW50aW5nIGFuZCBwcmlvcml0eSBtYW5hZ2VtZW50LiBXaGlsZSB0aGlzIHN1cnZl eSBvbmx5IGNvdmVycyB0d28gYnVnCnRyYWNraW5nIHN5c3RlbXMsIE1hbnRpcyBhbmQgSmly YSwgdGhlcmUgYXJlIG90aGVyIHR5cGVzIGxpa2UgaGVscCBkZXNrIGFuZApzZXJ2aWNlIGRl c2sgaXNzdWUgdHJhY2tpbmcgc3lzdGVtcy4gQnVnIHRyYWNraW5nIHN5c3RlbXMgdHlwaWNh bGx5IGhhdmUKcHJvamVjdHMgYXMgZm9sZGVycywgd2hpY2ggY29udGFpbiBpc3N1ZXMuPC9w PgoKPHA+VGhlIGZvbGxvd2luZyB0d28gc2VjdGlvbnMgYXJlIGV4cGxhbmF0aW9ucyBvZiA8 Y29kZT5UYXNrTGlzdDwvY29kZT4gYW5kIDxjb2RlPlRhc2s8L2NvZGU+IEpNQVAKb2JqZWN0 cyBhbmQgdGhlaXIgcHJvcGVydGllcywgc29ydGVkIGJ5IHBvcHVsYXJpdHkuIEluIGNhc2Ug dGhlIDxjb2RlPlRhc2s8L2NvZGU+IG9yCjxjb2RlPlRhc2tMaXN0PC9jb2RlPiBvYmplY3Rz IG1pZ2h0IG5vdCBiZSBzdWZmaWNpZW50IHRvIG1vZGVsIGEgcHJvcGVydHksIHRoZXJlIGlz IGEgc21hbGwKbm90ZSBpbiBlYWNoIHNlY3Rpb24uIFZlcnkgdW5jb21tb24gcHJvcGVydGll cyB3aWxsIG5vdCBiZSBkZXNjcmliZWQgaW4gZnVydGhlcgpkZXRhaWwuPC9wPgoKPGgzIGlk PSJ0b2NfMS4yIj5UYXNrTGlzdDwvaDM+Cgo8cD5BbGwgdGFzayBsaXN0cyBoYXZlIGEgbmFt ZS4gU29tZSB0YXNrIGxpc3RzIHN1cHBvcnQgcXVpdGUgYSBmZXcgcHJvcGVydGllcyB0aGF0 CmFyZSB0eXBpY2FsbHkgaW1wbGVtZW50ZWQgaW4gc2luZ2xlIHRhc2tzLiBFeGFtcGxlcyBm b3Igc3VjaCBwcm9wZXJ0aWVzIGFyZToKUHJvZ3Jlc3MsIFByaW9yaXR5LCBEdWUgb3IgQ29t bWVudHMuIEluIHN1Y2ggYSBjYXNlIHRoZXkgbWF5IGJlIGltcGxlbWVudGVkIGFzIGEKcGFy ZW50IDxjb2RlPlRhc2s8L2NvZGU+IHdpdGggc3ViLXRhc2tzIGluc3RlYWQgb2YgaW1wbGVt ZW50aW5nIHRoZW0gYXMgYSA8Y29kZT5UYXNrTGlzdDwvY29kZT4uPC9wPgoKPHA+Q29uc2lk ZXJpbmcgc3lzdGVtcyB3aWxsIGNob29zZSB0byBpbXBsZW1lbnQgc3VjaCBmb2xkZXIgb2Jq ZWN0cyBhcyBwYXJlbnQgdGFza3MsCm1vc3QgcG9wdWxhciBwcm9wZXJ0aWVzIHNob3VsZCBi ZSBjb3ZlcmVkIGJ5IEpNQVAgZm9yIFRhc2tzLiBTbyBmYXIgd2UgaGF2ZQppZGVudGlmaWVk IE1heCBUYXNrcy9Xb3JrIGFuZCBDb21tZW50cyBhcyBwcm9wZXJ0aWVzIG5vdCBjdXJyZW50 bHkgcHJlc2VudCBpbgpKTUFQIGZvciBUYXNrcyBidXQgb2JzZXJ2ZWQgaW4gdGhlIHdpbGQu PC9wPgoKPHA+T2YgdGhvc2Ugbm90IGN1cnJlbnRseSBwcmVzZW50IGluIEpNQVAgZm9yIFRh c2tzLCA8ZW0+cHJvcGVydGllcyBzcGVjaWZpYyB0bwpLYW5iYW4tc3R5bGUgU3lzdGVtczwv ZW0+IGFyZSBjb21tZW50cyBhbmQgcHJvZ3Jlc3MuIEZvbGRlciBvYmplY3RzIG9mIDxlbT5J c3N1ZQp0cmFja2luZyBzeXN0ZW1zPC9lbT4gc3RpbGwgaGF2ZSB0byBiZSBzdXJ2ZXllZC48 L3A+Cgo8dGFibGUgZGlyPSJhdXRvIj4KPHRoZWFkPgo8dHI+Cjx0aD5Qcm9wZXJ0eTwvdGg+ Cjx0aD5KTUFQIGZvciBUYXNrczwvdGg+Cjx0aD5Hb29nbGUgV29ya3BsYWNlPC90aD4KPHRo Pk1pY3Jvc29mdCBUbyBEbzwvdGg+Cjx0aD5NaWNyb3NvZnQgUGxhbm5lcjwvdGg+Cjx0aD5P cGVuWENoYW5nZTwvdGg+Cjx0aD5aaW1icmE8L3RoPgo8dGg+UmVtZW1iZXIgVGhlIE1pbGs8 L3RoPgo8dGg+Q2xpY2t1cDwvdGg+Cjx0aD5GYWN0cm88L3RoPgo8dGg+TmV4dGNsb3VkIERl Y2s8L3RoPgo8dGg+VHJlbGxvIChmcmVlKTwvdGg+Cjx0aD5adWJlPC90aD4KPHRoPlRvdGFs PC90aD4KPC90cj4KPC90aGVhZD4KCjx0Ym9keT4KPHRyPgo8dGQ+VGl0bGU8L3RkPgo8dGQ+ bmFtZTwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4K PHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+ Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+MTE8L3RkPgo8L3RyPgo8dHI+Cjx0ZD5Db2xv cjwvdGQ+Cjx0ZD5jb2xvcjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD48L3RkPgo8 dGQ+PC90ZD4KPHRkPlg8L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3RkPgo8dGQ+PC90ZD4KPHRk Plg8L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3RkPgo8dGQ+NTwvdGQ+CjwvdHI+Cjx0cj4KPHRk PlNvcnQgT3JkZXI8L3RkPgo8dGQ+c29ydE9yZGVyPC90ZD4KPHRkPlg8L3RkPgo8dGQ+PC90 ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4K PHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD48L3RkPgo8dGQ+MzwvdGQ+Cjwv dHI+Cjx0cj4KPHRkPkRlc2NyaXB0aW9uPC90ZD4KPHRkPmRlc2NyaXB0aW9uPC90ZD4KPHRk PjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90 ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3Rk Pgo8dGQ+MzwvdGQ+CjwvdHI+Cjx0cj4KPHRkPlJvbGU8L3RkPgo8dGQ+cm9sZTwvdGQ+Cjx0 ZD48L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD5Y PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3Rk Pgo8dGQ+MjwvdGQ+CjwvdHI+Cjx0cj4KPHRkPkNvbW1lbnRzPC90ZD4KPHRkPk1pc3Npbmc8 L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+ Cjx0ZD48L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD48L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD48L3RkPgo8 dGQ+PC90ZD4KPHRkPjI8L3RkPgo8L3RyPgo8dHI+Cjx0ZD5Qcm9ncmVzczwvdGQ+Cjx0ZD5U YXNrLnByb2dyZXNzL01pc3Npbmc8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3Rk Pgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3RkPgo8 dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjI8L3RkPgo8L3RyPgo8dHI+Cjx0 ZD5NYXggVGFza3MvV29yazwvdGQ+Cjx0ZD5NaXNzaW5nPC90ZD4KPHRkPjwvdGQ+Cjx0ZD48 L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+ Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD4yPC90ZD4K PC90cj4KPHRyPgo8dGQ+UHJpb3JpdHk8L3RkPgo8dGQ+VGFzay5wcmlvcml0eS9NaXNzaW5n PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3Rk Pgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8 dGQ+PC90ZD4KPHRkPjE8L3RkPgo8L3RyPgo8dHI+Cjx0ZD5TdWIgZm9sZGVyczwvdGQ+Cjx0 ZD5NaXNzaW5nPC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD48L3Rk Pgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0 ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjE8L3RkPgo8L3RyPgo8dHI+Cjx0ZD5JcyBGYXZvcml0 ZTwvdGQ+Cjx0ZD5NaXNzaW5nPC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+WDwvdGQ+ Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRk PjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjE8L3RkPgo8L3RyPgo8dHI+Cjx0ZD5F bmFibGUgTm90aWZpY2F0aW9uczwvdGQ+Cjx0ZD5NaXNzaW5nPC90ZD4KPHRkPjwvdGQ+Cjx0 ZD48L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48 L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjE8L3Rk Pgo8L3RyPgo8dHI+Cjx0ZD5NZW1iZXIgR3JvdXA8L3RkPgo8dGQ+TWlzc2luZzwvdGQ+Cjx0 ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48 L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+ Cjx0ZD4xPC90ZD4KPC90cj4KPHRyPgo8dGQ+R3JvdXAgQnk8L3RkPgo8dGQ+TWlzc2luZzwv dGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4K PHRkPlg8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRk PjwvdGQ+Cjx0ZD4xPC90ZD4KPC90cj4KPHRyPgo8dGQ+RHVlPC90ZD4KPHRkPlRhc2suZHVl L01pc3Npbmc8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4K PHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRk PjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+MTwvdGQ+CjwvdHI+Cjx0cj4KPHRkPkF0dGFjaG1lbnRz PC90ZD4KPHRkPlRhc2suYXR0YWNobWVudHMvTWlzc2luZzwvdGQ+Cjx0ZD48L3RkPgo8dGQ+ PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90 ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD4xPC90ZD4K PC90cj4KPHRyPgo8dGQ+S2V5d29yZHM8L3RkPgo8dGQ+VGFzay5LZXl3b3JkL01pc3Npbmc8 L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+ Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0 ZD48L3RkPgo8dGQ+MTwvdGQ+CjwvdHI+Cjx0cj4KPHRkPkNvdmVyPC90ZD4KPHRkPlRhc2su bGlua3MvTWlzc2luZzwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48 L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+ Cjx0ZD5YPC90ZD4KPHRkPjwvdGQ+Cjx0ZD4xPC90ZD4KPC90cj4KPC90Ym9keT4KPC90YWJs ZT4KCjxwPjxzdHJvbmc+VGl0bGU8L3N0cm9uZz4gPHE+U3RyaW5nPC9xPjo8L3A+Cgo8dWwg ZGlyPSJhdXRvIj4KPGxpPlNob3J0IGRlc2NyaXB0aW9uLiBTb21ldGltZXMgY2FsbGVkIDxx Pk5hbWU8L3E+LjwvbGk+CjwvdWw+Cgo8cD48c3Ryb25nPkNvbG9yPC9zdHJvbmc+IDxxPlN0 cmluZzwvcT46PC9wPgoKPHVsIGRpcj0iYXV0byI+CjxsaT5Db2xvciBhc3NvY2lhdGVkIHdp dGggYSBmb2xkZXI8L2xpPgo8L3VsPgoKPHA+PHN0cm9uZz5Tb3J0IE9yZGVyPC9zdHJvbmc+ IDxxPlVuc2lnbmVkSW50PC9xPjo8L3A+Cgo8dWwgZGlyPSJhdXRvIj4KPGxpPlNvbWUgbGlz dHMgY2FuIGJlIHNvcnRlZDwvbGk+CjwvdWw+Cgo8cD48c3Ryb25nPkRlc2NyaXB0aW9uPC9z dHJvbmc+IDxxPlN0cmluZzwvcT46PC9wPgoKPHVsIGRpcj0iYXV0byI+CjxsaT5Mb25nIGRl c2NyaXB0aW9uLiBVc3VhbGx5IG5vIGZvcm1hdHRpbmcuPC9saT4KPC91bD4KCjxwPjxzdHJv bmc+Um9sZTwvc3Ryb25nPiA8cT5TdHJpbmc8L3E+OjwvcD4KCjx1bCBkaXI9ImF1dG8iPgo8 bGk+RGVub3RlcyBzcGVjaWFsIGZvbGRlciB0eXBlIGxpa2UgPHE+SW5ib3g8L3E+LCA8cT5U cmFzaDwvcT4gb3IgPHE+Um9vdDwvcT48L2xpPgo8L3VsPgoKPHA+PHN0cm9uZz5Db21tZW50 czwvc3Ryb25nPjo8L3A+Cgo8dWwgZGlyPSJhdXRvIj4KPGxpPlNvbWUgc3lzdGVtcyBhbGxv dyBjb21tZW50cyBwZXIgZm9sZGVyLjwvbGk+CjxsaT5BIHByb3BlcnR5IGxpa2UgdGhpcyBk b2VzIGN1cnJlbnRseSBub3QgZXhpc3QgaW4gPHN0cm9uZz5KTUFQIGZvciBUYXNrczwvc3Ry b25nPi4gU2VlIENvbW1lbnRzIHN1YnNlY3Rpb24gaW4gVGFza3Mgc2VjdGlvbiBiZWxvdy48 L2xpPgo8L3VsPgoKPHA+PHN0cm9uZz5Qcm9ncmVzczwvc3Ryb25nPjo8L3A+Cgo8dWwgZGly PSJhdXRvIj4KPGxpPkluIHNvbWUgc3lzdGVtcyB0aGUgcHJvZ3Jlc3MgY2FuIGJlIHNldCBv biBhIGZvbGRlci1sZXZlbC48L2xpPgo8bGk+SXQgbWlnaHQgYmUgcG9zc2libGUgdG8gaW1w bGVtZW50IHRhc2sgZm9sZGVyIG9iamVjdHMgd2l0aCB0YXNrLWxldmVsIDxjb2RlPnByb2dy ZXNzPC9jb2RlPiBwcm9wZXJ0eSBhcyA8Y29kZT5UYXNrPC9jb2RlPiBvYmplY3RzIHdpdGgg Y2hpbGRyZW4gaW5zdGVhZCBvZiA8Y29kZT5UYXNrTGlzdDwvY29kZT4gb2JqZWN0cy4gU2Ft ZSBhcyBwcm9ncmVzcyBpbiBUYXNrcyBiZWxvdy4gPC9saT4KPC91bD4KCjxwPjxzdHJvbmc+ TWF4IFRhc2tzL1dvcms8L3N0cm9uZz4gPHE+SW50ZWdlcjwvcT46PC9wPgoKPHVsIGRpcj0i YXV0byI+CjxsaT5Tb21lIDxjb2RlPlRhc2tMaXN0PC9jb2RlPnMgY2FuIGJlIGNvbmZpZ3Vy ZWQgdG8gb25seSBhbGxvdyBhIG1heGltdW0gYW1vdW50IG9mIHRhc2tzIG9yIGEgbWF4aW11 bSBzdW0gb2YgZXN0aW1hdGVkIHdvcmsgb3ZlciBhbGwgaXRzIGNoaWxkIG9iamVjdHMuPC9s aT4KPGxpPkEgbWF4IHRhc2tzL3dvcmsgcHJvcGVydHkgbGlrZSB0aGlzIGN1cnJlbnRseSBk b2VzIG5vdCBleGlzdCBpbiA8c3Ryb25nPkpNQVAgZm9yIFRhc2tzPC9zdHJvbmc+LjwvbGk+ CjwvdWw+Cgo8aDMgaWQ9InRvY18xLjMiPlRhc2s8L2gzPgoKPHA+QWxsIHRhc2tzIGhhdmUg aW4gY29tbW9uOiBhIHRpdGxlIGFuZCBhbiBpbmRpY2F0b3IgZm9yIHByb2dyZXNzLiBMaW5r cyB0bwphdHRhY2htZW50cyBvciB3ZWJzaXRlcywgYSBsb25nZXIgZGVzY3JpcHRpb24gYW5k IGFzc2lnbmVlcyBhcmUgYWxzbyBxdWl0ZQpjb21tb24uPC9wPgoKPHA+UG9wdWxhciBwcm9w ZXJ0aWVzIHRoYXQgYXJlIG5vdCBjb3ZlcmVkIGJ5IEpNQVAgZm9yIFRhc2tzIGFyZSBjdXJy ZW50bHkKQ29tbWVudHMsIEhpc3RvcnksIENoZWNrbGlzdHMsIGVzdGltYXRlZCBhbW91bnQg b2Ygd29yaywgc291cmNlIG9mIHRoZSB0YXNrLAp0YXNrIGltcGFjdC48L3A+Cgo8cD5PZiB0 aG9zZSBub3QgY3VycmVudGx5IHByZXNlbnQgaW4gSk1BUCBmb3IgVGFza3MsIDxlbT5wcm9w ZXJ0aWVzIHNwZWNpZmljIHRvCkthbmJhbi1zdHlsZSBTeXN0ZW1zPC9lbT4gYXJlIGNvbW1l bnRzIGFuZCBoaXN0b3J5LiBFZmZvcnQgZXN0aW1hdGlvbiBpbiBhbiBhYnN0cmFjdAp3YXkg dmlhIGNvbXBsZXhpdHkgcG9pbnRzIGhhcyBvbmx5IGJlZW4gb2JzZXJ2ZWQgYXQgWnViZSBm b3Igbm93LCBidXQgaXQgaXMgYQpjb21tb24gY29uY2VwdCBpbiBTY3J1bS4gPGVtPklzc3Vl IHRyYWNraW5nIHN5c3RlbXM8L2VtPiBoYXZlIGluIGNvbW1vbjogY29tbWVudHMsCmhpc3Rv cnkgYW5kIGltcGFjdC48L3A+Cgo8dGFibGUgZGlyPSJhdXRvIj4KPHRoZWFkPgo8dHI+Cjx0 aD5Qcm9wZXJ0eTwvdGg+Cjx0aD5KTUFQIGZvciBUYXNrczwvdGg+Cjx0aD5Hb29nbGUgV29y a3BsYWNlPC90aD4KPHRoPk1pY3Jvc29mdCBUbyBEbzwvdGg+Cjx0aD5NaWNyb3NvZnQgUGxh bm5lcjwvdGg+Cjx0aD5PcGVuWENoYW5nZTwvdGg+Cjx0aD5aaW1icmE8L3RoPgo8dGg+UmVt ZW1iZXIgVGhlIE1pbGs8L3RoPgo8dGg+Q2xpY2t1cDwvdGg+Cjx0aD5GYWN0cm88L3RoPgo8 dGg+TmV4dGNsb3VkIERlY2s8L3RoPgo8dGg+VHJlbGxvIChmcmVlKTwvdGg+Cjx0aD5adWJl PC90aD4KPHRoPkppcmE8L3RoPgo8dGg+TWFudGlzPC90aD4KPHRoPlRvdGFsPC90aD4KPC90 cj4KPC90aGVhZD4KCjx0Ym9keT4KPHRyPgo8dGQ+VGl0bGU8L3RkPgo8dGQ+dGl0bGU8L3Rk Pgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90 ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwv dGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD4xMzwvdGQ+CjwvdHI+ Cjx0cj4KPHRkPlByb2dyZXNzPC90ZD4KPHRkPnByb2dyZXNzPC90ZD4KPHRkPlg8L3RkPgo8 dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4K PHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+ Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+MTM8L3RkPgo8L3RyPgo8dHI+Cjx0ZD5MaW5r czwvdGQ+Cjx0ZD5saW5rczwvdGQ+Cjx0ZD48L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4K PHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+ Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3Rk Pgo8dGQ+MTI8L3RkPgo8L3RyPgo8dHI+Cjx0ZD5EZXNjcmlwdGlvbjwvdGQ+Cjx0ZD5kZXNj cmlwdGlvbjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3Rk Pgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+ Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjEwPC90 ZD4KPC90cj4KPHRyPgo8dGQ+QXNzaWduZWVzPC90ZD4KPHRkPmF0dGVuZGVlczwvdGQ+Cjx0 ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD48L3RkPgo8dGQ+ WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRk Plg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjEwPC90ZD4KPC90cj4KPHRyPgo8 dGQ+S2V5d29yZHM8L3RkPgo8dGQ+a2V5d29yZHM8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+ Cjx0ZD5YPC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+ Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD48L3RkPgo8dGQ+WDwvdGQ+ Cjx0ZD5YPC90ZD4KPHRkPjk8L3RkPgo8L3RyPgo8dHI+Cjx0ZD5Qcmlvcml0eTwvdGQ+Cjx0 ZD5wcmlvcml0eTwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwv dGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjwv dGQ+Cjx0ZD48L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+OTwv dGQ+CjwvdHI+Cjx0cj4KPHRkPkNvbW1lbnRzPC90ZD4KPHRkPk1pc3Npbmc8L3RkPgo8dGQ+ PC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+WDwv dGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8 L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjk8L3RkPgo8L3RyPgo8dHI+Cjx0ZD5S ZWxhdGlvbnM8L3RkPgo8dGQ+cmVsYXRlZFRvPC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8 dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRk Plg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0 ZD5YPC90ZD4KPHRkPjg8L3RkPgo8L3RyPgo8dHI+Cjx0ZD5EdWU8L3RkPgo8dGQ+ZHVlL3V0 Y0R1ZTwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3RkPgo8 dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4K PHRkPlg8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+OTwvdGQ+Cjwv dHI+Cjx0cj4KPHRkPlN0YXJ0PC90ZD4KPHRkPnN0YXJ0L3V0Y1N0YXJ0PC90ZD4KPHRkPjwv dGQ+Cjx0ZD48L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwv dGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3Rk Pgo8dGQ+WDwvdGQ+Cjx0ZD48L3RkPgo8dGQ+NzwvdGQ+CjwvdHI+Cjx0cj4KPHRkPkhpc3Rv cnk8L3RkPgo8dGQ+TWlzc2luZzwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+ Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8 dGQ+PC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8 dGQ+NzwvdGQ+CjwvdHI+Cjx0cj4KPHRkPkNoZWNrbGlzdDwvdGQ+Cjx0ZD5NaXNzaW5nPC90 ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3Rk Pgo8dGQ+PC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD48L3RkPgo8dGQ+WDwvdGQ+ Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD42PC90ZD4KPC90cj4KPHRyPgo8 dGQ+UmVjdXJyZW5jZXM8L3RkPgo8dGQ+UmVjdXJyZW5jZSBQcm9wZXJ0aWVzPC90ZD4KPHRk Plg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD48L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD48L3RkPgo8dGQ+ WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwv dGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjU8L3RkPgo8L3RyPgo8dHI+Cjx0ZD5BbGVy dHM8L3RkPgo8dGQ+QWxlcnRzIFByb3BlcnRpZXM8L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3Rk Pgo8dGQ+PC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjwvdGQ+ Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0 ZD48L3RkPgo8dGQ+NTwvdGQ+CjwvdHI+Cjx0cj4KPHRkPkVzdGltYXRlPC90ZD4KPHRkPmVz dGltYXRlZER1cmF0aW9uL01pc3Npbmc8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48 L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+WDwv dGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+ Cjx0ZD40PC90ZD4KPC90cj4KPHRyPgo8dGQ+Q2F0ZWdvcmllczwvdGQ+Cjx0ZD5jYXRlZ29y aWVzPC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+ PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3Rk Pgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3RkPgo8dGQ+NDwvdGQ+CjwvdHI+Cjx0 cj4KPHRkPlNvdXJjZTwvdGQ+Cjx0ZD5NaXNzaW5nPC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90 ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3RkPgo8dGQ+PC90ZD4K PHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRk PjwvdGQ+Cjx0ZD4zPC90ZD4KPC90cj4KPHRyPgo8dGQ+UGVyY2VudCBDb21wbGV0ZTwvdGQ+ Cjx0ZD5wZXJjZW50Q29tcGxldGU8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3Rk Pgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4K PHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+ MjwvdGQ+CjwvdHI+Cjx0cj4KPHRkPlR5cGU8L3RkPgo8dGQ+QHR5cGU8L3RkPgo8dGQ+PC90 ZD4KPHRkPlg8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4K PHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+ WDwvdGQ+Cjx0ZD48L3RkPgo8dGQ+MjwvdGQ+CjwvdHI+Cjx0cj4KPHRkPkltcGFjdDwvdGQ+ Cjx0ZD5NaXNzaW5nPC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwv dGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4K PHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjI8L3RkPgo8 L3RyPgo8dHI+Cjx0ZD5Mb2NhdGlvbnM8L3RkPgo8dGQ+bG9jYXRpb25zPC90ZD4KPHRkPjwv dGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPlg8L3Rk Pgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0 ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjI8L3RkPgo8L3RyPgo8dHI+Cjx0ZD5BZGRpdGlvbmFs IGluZm9ybWF0aW9uPC90ZD4KPHRkPk1pc3Npbmc8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+ Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjwvdGQ+Cjx0 ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPlg8 L3RkPgo8dGQ+MjwvdGQ+CjwvdHI+Cjx0cj4KPHRkPkVuZDwvdGQ+Cjx0ZD5wcm9ncmVzcyAr IHByb2dyZXNzVXBkYXRlZDwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0 ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwv dGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3RkPgo8dGQ+PC90ZD4KPHRkPjE8L3Rk Pgo8L3RyPgo8dHI+Cjx0ZD5Db3ZlcjwvdGQ+Cjx0ZD5saW5rczwvdGQ+Cjx0ZD48L3RkPgo8 dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48 L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3Rk Pgo8dGQ+PC90ZD4KPHRkPjE8L3RkPgo8L3RyPgo8dHI+Cjx0ZD5SaXNrPC90ZD4KPHRkPk1p c3Npbmc8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRk PjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90 ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjwvdGQ+Cjx0ZD4xPC90ZD4KPC90cj4KPHRy Pgo8dGQ+UGVuZGluZyBSZWFzb248L3RkPgo8dGQ+TWlzc2luZzwvdGQ+Cjx0ZD48L3RkPgo8 dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48 L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3Rk Pgo8dGQ+PC90ZD4KPHRkPjE8L3RkPgo8L3RyPgo8dHI+Cjx0ZD5Pcmdhbml6YXRpb25zPC90 ZD4KPHRkPk1pc3Npbmc8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+ PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3Rk Pgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjwvdGQ+Cjx0ZD4xPC90ZD4K PC90cj4KPHRyPgo8dGQ+VXJnZW5jeWA8L3RkPgo8dGQ+TWlzc2luZzwvdGQ+Cjx0ZD48L3Rk Pgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0 ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPlg8 L3RkPgo8dGQ+PC90ZD4KPHRkPjE8L3RkPgo8L3RyPgo8dHI+Cjx0ZD5JbnZlc3RpZ2F0aW9u IFJlYXNvbjwvdGQ+Cjx0ZD5NaXNzaW5nPC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+ PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3Rk Pgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+WDwvdGQ+Cjx0ZD48L3RkPgo8 dGQ+MTwvdGQ+CjwvdHI+Cjx0cj4KPHRkPlJvb3QgQ2F1c2U8L3RkPgo8dGQ+TWlzc2luZzwv dGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4K PHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+ PC90ZD4KPHRkPlg8L3RkPgo8dGQ+PC90ZD4KPHRkPjE8L3RkPgo8L3RyPgo8dHI+Cjx0ZD5X b3JrYXJvdW5kPC90ZD4KPHRkPk1pc3Npbmc8L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0 ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwv dGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjwvdGQ+ Cjx0ZD4xPC90ZD4KPC90cj4KPHRyPgo8dGQ+UmVzb2x1dGlvbjwvdGQ+Cjx0ZD5NaXNzaW5n PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3Rk Pgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0 ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPlg8L3RkPgo8dGQ+MTwvdGQ+CjwvdHI+Cjx0cj4KPHRk PlJlcHJvZHVjaWJpbGl0eTwvdGQ+Cjx0ZD5NaXNzaW5nPC90ZD4KPHRkPjwvdGQ+Cjx0ZD48 L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+ Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRk Plg8L3RkPgo8dGQ+MTwvdGQ+CjwvdHI+Cjx0cj4KPHRkPlByb2ZpbGU8L3RkPgo8dGQ+TWlz c2luZzwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+ PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3RkPgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD48L3Rk Pgo8dGQ+PC90ZD4KPHRkPjwvdGQ+Cjx0ZD5YPC90ZD4KPHRkPjE8L3RkPgo8L3RyPgo8L3Ri b2R5Pgo8L3RhYmxlPgoKPHA+PHN0cm9uZz5UaXRsZTwvc3Ryb25nPiA8cT5TdHJpbmc8L3E+ OjwvcD4KCjx1bCBkaXI9ImF1dG8iPgo8bGk+U2hvcnQgZGVzY3JpcHRpb24uIFNvbWV0aW1l cyBjYWxsZWQgPHE+U3VtbWFyeTwvcT4gb3IgPHE+TmFtZTwvcT4uPC9saT4KPC91bD4KCjxw PjxzdHJvbmc+UHJvZ3Jlc3M8L3N0cm9uZz4gPHE+U3RyaW5nPC9xPjo8L3A+Cgo8dWwgZGly PSJhdXRvIj4KPGxpPkFsc28gY2FsbGVkIDxxPlN0YXR1czwvcT4uIEluIHNvbWUgc3lzdGVt cyB0aGlzIGlzIGFzIHNpbXBsZSBhcyA8cT5Eb25lPC9xPiBvcgo8cT5Ob3QgZG9uZTwvcT4u IFRoZXJlIGFyZSB2YXJpb3VzIG90aGVyIG9ic2VydmVkIHN0YXRlcyBsaWtlIDxxPk5vdCBz dGFydGVkPC9xPiwKPHE+SW4gUHJvZ3Jlc3M8L3E+LCA8cT5Eb25lL0NvbXBsZXRlZDwvcT4s IDxxPldhaXRpbmcgKG9uIHNvbWVvbmUgZWxzZSk8L3E+LCA8cT5EZWZlcnJlZDwvcT4sCjxx PkFjdGl2ZTwvcT4sIDxxPkNsb3NlZDwvcT4sIDxxPk5ldzwvcT4sIDxxPkZlZWRiYWNrPC9x PiwgPHE+QWNrbm93bGVkZ2VkPC9xPiwgPHE+Q29uZmlybWVkPC9xPiwgPHE+QXNzaWduZWQ8 L3E+LAo8cT5SZXNvbHZlZDwvcT4uPC9saT4KPGxpPkl0IG1pZ2h0IG1ha2Ugc2Vuc2UgdG8g ZXh0ZW5kIHRoZSA8Y29kZT5UYXNrPC9jb2RlPiBvYmplY3Qgb2YgPHN0cm9uZz5KTUFQIGZv ciBUYXNrczwvc3Ryb25nPiB3aXRoCmFkZGl0aW9uYWwgdmFsdWVzLjwvbGk+CjwvdWw+Cgo8 cD48c3Ryb25nPkxpbmtzPC9zdHJvbmc+IDxxPkxpbms8L3E+OjwvcD4KCjx1bCBkaXI9ImF1 dG8iPgo8bGk+Q2FuIHBvaW50IHRvIGEgQmxvYiBvciB0byBhIHdlYnNpdGUgd2l0aCBwcm9w ZXJ0aWVzIHN1Y2ggYXM6Cgo8dWwgZGlyPSJhdXRvIj4KPGxpPjxjb2RlPmhyZWY8L2NvZGU+ OiA8cT5TdHJpbmc8L3E+IFVSSSAocG90ZW50aWFsbHkgdG8gYSBibG9iKTwvbGk+CjxsaT48 Y29kZT50aXRsZTwvY29kZT46IDxxPlN0cmluZzwvcT4gRGVzY3JpcHRpb24gb2YgcmVzb3Vy Y2U8L2xpPgo8bGk+PGNvZGU+Y3JlYXRlZDwvY29kZT46IDxxPlVUQ0RhdGVUaW1lPC9xPiBX aGVuIHRoZSBibG9iIHdhcyB1cGxvYWRlZDwvbGk+CjwvdWw+PC9saT4KPGxpPkl0IG1pZ2h0 IG1ha2Ugc2Vuc2UgdG8gZXh0ZW5kIDxzdHJvbmc+Sk1BUCBmb3IgVGFza3MmIzM5Ozwvc3Ry b25nPiA8Y29kZT5MaW5rPC9jb2RlPiBkYXRhIHR5cGUgd2l0aCBhCnByb3BlcnR5IHRoYXQg ZGlzcGxheXMgd2hlbiBhIGJsb2Igd2FzIHVwbG9hZGVkLiBPciBhZGQgc3VjaCBhIHByb3Bl cnR5IHRvIHRoZQpKTUFQIEJsb2IgbWFuYWdlbWVudCBleHRlbnNpb24KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1pZXRmLWptYXAtYmxvYi0wNS5o dG1sIj5pZXRmLWptYXAtYmxvYjwvYT48L2xpPgo8L3VsPgoKPHA+PHN0cm9uZz5EZXNjcmlw dGlvbjwvc3Ryb25nPiA8cT5TdHJpbmc8L3E+OjwvcD4KCjx1bCBkaXI9ImF1dG8iPgo8bGk+ TG9uZyBkZXNjcmlwdGlvbi4gU29tZXRpbWVzIHN1cHBvcnRzIHNvbWUgZm9ybWF0dGluZy48 L2xpPgo8L3VsPgoKPHA+PHN0cm9uZz5Bc3NpZ25lZXM8L3N0cm9uZz4gPHE+SWRbUGFydGlj aXBhbnRdPC9xPjo8L3A+Cgo8dWwgZGlyPSJhdXRvIj4KPGxpPkxpc3Qgb2YgYXNzaWduZWVz IHRoYXQgdGhpcyB0YXNrIGlzIGFzc2lnbmVkIHRvLiBNYXkgaW5jbHVkZSBwZW9wbGUgb25s eSB3YXRjaGluZyB0aGUgdGFzay48L2xpPgo8L3VsPgoKPHA+PHN0cm9uZz5LZXl3b3Jkczwv c3Ryb25nPiA8cT5TdHJpbmdbXTwvcT46PC9wPgoKPHVsIGRpcj0iYXV0byI+CjxsaT5VbnN0 cnVjdHVyZWQga2V5d29yZHMgb3IgdGFncy48L2xpPgo8bGk+QWxzbywgc29tZXRpbWVzIHRo ZXkgYXJlIGEgbGlzdCBvZiBvYmplY3RzIHdpdGg6Cgo8dWwgZGlyPSJhdXRvIj4KPGxpPjxj b2RlPnRpdGxlPC9jb2RlPjogPHE+U3RyaW5nPC9xPiA8L2xpPgo8bGk+PGNvZGU+Y29sb3I8 L2NvZGU+OiA8cT5TdHJpbmc8L3E+PC9saT4KPC91bD48L2xpPgo8bGk+PGNvZGU+a2V5d29y ZHM8L2NvZGU+IGluIDxzdHJvbmc+Sk1BUCBmb3IgVGFza3MmIzM5Ozwvc3Ryb25nPiBhcmUg Y3VycmVudGx5IG5vdCBjb25uZWN0ZWQgdG8gYSBjb2xvci4gSXQgbWlnaHQgbWFrZSBzZW5z ZSB0byBjaGFuZ2UgdGhpcy48L2xpPgo8L3VsPgoKPHA+PHN0cm9uZz5Qcmlvcml0eTwvc3Ry b25nPiA8cT5JbnQ8L3E+IHR5cGljYWxseSBiZXR3ZWVuIDAgYW5kIDM6PC9wPgoKPHVsIGRp cj0iYXV0byI+CjxsaT5JdCByZXByZXNlbnRzIHNvbWV0aGluZyBsaWtlIDxxPk5vbmUsIExv dywgTWVkaXVtLCBIaWdoPC9xPiwgPHE+TG93LCBNZWRpdW0sIEhpZ2g8L3E+IG9yIDxxPkxv dywgTWVkaXVtLCBIaWdoLCBVcmdlbnQ8L3E+LiBBbHNvLCB0aGluZ3MgbGlrZSA8cT5Ob25l LCBMb3csIE1lZGl1bSwgSGlnaCwgVXJnZW50LCBJbW1lZGlhdGU8L3E+IHdlcmUgb2JzZXJ2 ZWQuPC9saT4KPC91bD4KCjxwPjxzdHJvbmc+Q29tbWVudHM8L3N0cm9uZz48L3A+Cgo8dWwg ZGlyPSJhdXRvIj4KPGxpPkEgQ29tbWVudCBpcyB0eXBpY2FsbHkgYW4gb2JqZWN0IHdpdGg6 Cgo8dWwgZGlyPSJhdXRvIj4KPGxpPjxjb2RlPmNyZWF0ZWRCeTwvY29kZT46IDxxPlVzZXJJ ZDwvcT48L2xpPgo8bGk+PGNvZGU+ZGF0ZVN1Ym1pdHRlZDwvY29kZT46IDxxPlVUQ0RhdGVU aW1lPC9xPiB3aGVuIHRoZSBjb21tZW50IHdhcyBzdWJtaXR0ZWQ8L2xpPgo8bGk+PGNvZGU+ ZGF0ZUVkaXRlZDwvY29kZT46IDxxPlVUQ0RhdGVUaW1lPC9xPiB3aGVuIHRoZSBjb21tZW50 IHdhcyBsYXN0IGVkaXRlZDwvbGk+CjxsaT48Y29kZT5tZXNzYWdlPC9jb2RlPjogPHE+U3Ry aW5nPC9xPiBjb250ZW50PC9saT4KPGxpPjxjb2RlPmVkaXRIaXN0b3J5PC9jb2RlPjogRGlm ZmVyZW50IHZlcnNpb25zIG9mIHRoZSBjb21tZW50IHNpbmNlIGluaXRpYWwgY3JlYXRpb248 L2xpPgo8bGk+PGNvZGU+ZGVsZXRlZDwvY29kZT46IDxxPkJvb2xlYW48L3E+IGNvbW1lbnQg d2FzIGRlbGV0ZWQ8L2xpPgo8bGk+PGNvZGU+YXR0YWNobWVudHM8L2NvZGU+OiBDb21tZW50 cyBxdWl0ZSBvZnRlbiBhbHNvIGNvbnRhaW4gYXR0YWNobWVudHM8L2xpPgo8L3VsPjwvbGk+ CjxsaT5BIHByb3BlcnR5IGxpa2UgdGhpcyBkb2VzIGN1cnJlbnRseSBub3QgZXhpc3QgaW4g PHN0cm9uZz5KTUFQIGZvciBUYXNrczwvc3Ryb25nPi48L2xpPgo8L3VsPgoKPHA+PHN0cm9u Zz5SZWxhdGVkIFRvPC9zdHJvbmc+IDxxPlN0cmluZ1tSZWxhdGlvbl08L3E+OjwvcD4KCjx1 bCBkaXI9ImF1dG8iPgo8bGk+QSBtYXAgb2YgdGhlIFVJRHMgb2YgdGhlIHJlbGF0ZWQgb2Jq ZWN0cyB0byBpbmZvcm1hdGlvbiBhYm91dCB0aGUgcmVsYXRpb24uIEEgPGNvZGU+UmVsYXRp b248L2NvZGU+IG9iamVjdCBoYXMgZmVhdHVyZXMgbGlrZSB0aGUgZm9sbG93aW5nOgoKPHVs IGRpcj0iYXV0byI+CjxsaT48Y29kZT5yZWxhdGlvbjwvY29kZT46IDxxPlN0cmluZ1tCb29s ZWFuXTwvcT4gaWRlbnRpZmllcyB0aGUgcmVsYXRpb24gc3VjaCBhcyA8cT5ibG9ja3M8L3E+ LCA8cT5wYXJlbnQ8L3E+LCA8cT5jaGlsZDwvcT4sIDxxPmR1cGxpY2F0ZTwvcT4sIDxxPmhh cyBkdXBsaWNhdGU8L3E+IG9yIDxxPnJlbGF0ZWQ8L3E+PC9saT4KPC91bD48L2xpPgo8bGk+ VGhlIDxjb2RlPlJlbGF0aW9uPC9jb2RlPiBkYXRhIHR5cGUgaW4gPHN0cm9uZz5KTUFQIGZv ciBUYXNrczwvc3Ryb25nPiBpcyBtaXNzaW5nIHNvbWUgYWRkaXRpb25hbCBrZXlzIHRvIHJl ZmxlY3QgYWxsIHRoYXQuIFRoZXkgY291bGQgYmU6IGJsb2NrcyAvIGJsb2NrZWQgYnksIGNs b25lcyAvIGNsb25lZCBieSwgZHVwbGljYXRlcyAvIGR1cGxpY2F0ZWQgYnksIGNhdXNlZCBi eSAvIGNhdXNlczwvbGk+CjwvdWw+Cgo8cD48c3Ryb25nPkR1ZTwvc3Ryb25nPiA8cT5Mb2Nh bERhdGVUaW1lL1VUQ0RhdGU8L3E+OjwvcD4KCjx1bCBkaXI9ImF1dG8iPgo8bGk+d2hlbiB0 aGUgdGFzayBpcyBkdWUgKHNvbWV0aW1lcyBvbmx5IGZ1bGwtZGF5IHN1cHBvcnRlZCk8L2xp Pgo8L3VsPgoKPHA+PHN0cm9uZz5TdGFydDwvc3Ryb25nPiA8cT5Mb2NhbERhdGVUaW1lL1VU Q1N0YXJ0PC9xPjo8L3A+Cgo8dWwgZGlyPSJhdXRvIj4KPGxpPndoZW4gdGhlIHRhc2sgaXMg c3VwcG9zZWQgdG8gc3RhcnQgKHNvbWV0aW1lcyBvbmx5IGZ1bGwtZGF5IHN1cHBvcnRlZCk8 L2xpPgo8L3VsPgoKPHA+PHN0cm9uZz5IaXN0b3J5PC9zdHJvbmc+PC9wPgoKPHVsIGRpcj0i YXV0byI+CjxsaT5BIGhpc3Rvcnkgb2YgY2hhbmdlcyB0byB0aGUgb2JqZWN0LjwvbGk+Cjxs aT5BIGhpc3RvcnkgcHJvcGVydHkgZG9lcyBjdXJyZW50bHkgbm90IGV4aXN0IGluIDxzdHJv bmc+Sk1BUCBmb3IgVGFza3M8L3N0cm9uZz4uPC9saT4KPC91bD4KCjxwPjxzdHJvbmc+Q2hl Y2tsaXN0PC9zdHJvbmc+IDxxPkNoZWNrbGlzdDwvcT46PC9wPgoKPHVsIGRpcj0iYXV0byI+ CjxsaT5BbiBvYmplY3Qgd2l0aCBwcm9wZXJ0aWVzIGxpa2U6Cgo8dWwgZGlyPSJhdXRvIj4K PGxpPjxjb2RlPm5hbWU8L2NvZGU+OiA8cT5TdHJpbmc8L3E+PC9saT4KPGxpPjxjb2RlPmNo ZWNrSXRlbXM8L2NvZGU+OiA8cT5DaGVja0l0ZW1bXTwvcT48L2xpPgo8L3VsPjwvbGk+Cjxs aT48cT5DaGVja0l0ZW08L3E+IGFyZSBvYmplY3RzIHNpbWlsYXIgdG8gc2ltcGxpZmllZCB0 YXNrcyB3aXRoIG9ic2VydmVkIHByb3BlcnRpZXM6Cgo8dWwgZGlyPSJhdXRvIj4KPGxpPjxj b2RlPnRpdGxlPC9jb2RlPjogPHE+U3RyaW5nPC9xPiA8L2xpPgo8bGk+PGNvZGU+aXNDb21w bGV0ZTwvY29kZT46IDxxPkJvb2xlYW48L3E+IDwvbGk+CjxsaT48Y29kZT5zb3J0T3JkZXI8 L2NvZGU+OiA8cT5VbnNpZ25lZEludDwvcT48L2xpPgo8bGk+PGNvZGU+ZHVlPC9jb2RlPjog PHE+VVRDRGF0ZVRpbWU8L3E+PC9saT4KPGxpPjxjb2RlPmFzc2lnbmVlPC9jb2RlPjogPHE+ VXNlcklkPC9xPjwvbGk+CjwvdWw+PC9saT4KPGxpPkEgPHE+Y2hlY2tsaXN0PC9xPiBwcm9w ZXJ0eSBkb2VzIGN1cnJlbnRseSBub3QgZXhpc3QgaW4gPHN0cm9uZz5KTUFQIGZvciBUYXNr czwvc3Ryb25nPi48L2xpPgo8L3VsPgoKPHA+PHN0cm9uZz5SZWN1cnJlbmNlPC9zdHJvbmc+ OjwvcD4KCjx1bCBkaXI9ImF1dG8iPgo8bGk+UmVjdXJyZW5jZSBpcyB0aWVkIHRvIHRoZSBE dWUgRGF0ZS4gU29tZXRpbWVzIGl0IGlzIHByZXR0eSBzaW1wbGUgKGxpa2UgZXZlcnkKWCBk YXkvd2Vlay9tb250aC95ZWFyKSBhbmQgc29tZXRpbWVzIGNvbWVzIGNsb3NlIHRvIHRoZSBj b21wbGV4aXR5IG9mIGl0cwpkZWZpbml0aW9uIGluIEpTQ2FsZW5kYXIuPC9saT4KPC91bD4K CjxwPjxzdHJvbmc+QWxlcnRzPC9zdHJvbmc+OjwvcD4KCjx1bCBkaXI9ImF1dG8iPgo8bGk+ U29tZSBzeXN0ZW1zIHN1cHBvcnQgb25seSBhIHNpbmdsZSBhbGVydC9yZW1pbmRlciwgc29t ZSBtdWx0aXBsZS48L2xpPgo8L3VsPgoKPHA+PHN0cm9uZz5Fc3RpbWF0ZTwvc3Ryb25nPiA8 cT5EdXJhdGlvbjwvcT4gb3IgPHE+SW50ZWdlcjwvcT46PC9wPgoKPHVsIGRpcj0iYXV0byI+ CjxsaT5Fc3RpbWF0ZWQgZm9yIGFtb3VudCBvZiB3b3JrIHJlcXVpcmVkIGNhbiBiZSBtZWFz dXJlZCBpbiBkdXJhdGlvbiBvciBtb3JlCmFic3RyYWN0IG1lYXN1cmVzIGxpa2UgY29tcGxl eGl0eSBwb2ludHMuPC9saT4KPGxpPlRoZSA8cT5lc3RpbWF0ZTwvcT4gcHJvcGVydHkgPHE+ ZXN0aW1hdGVkRHVyYXRpb248L3E+IG9mIDxzdHJvbmc+Sk1BUCBmb3IgVGFza3M8L3N0cm9u Zz4gaXMgY3VycmVudGx5Cm9mIDxxPkR1cmF0aW9uPC9xPiB0eXBlLiBJdCBtaWdodCBtYWtl IHNlbnNlIHRvIGFkZCBhIHByb3BlcnR5IHRvIG1lYXN1cmUgZXN0aW1hdGVkCmFtb3VudCBv ZiB3b3JrIGluIGEgbW9yZSBhYnN0cmFjdCB3YXkuPC9saT4KPC91bD4KCjxwPjxzdHJvbmc+ Q2F0ZWdvcmllczwvc3Ryb25nPiA8cT5TdHJpbmdbQm9vbGVhbl08L3E+OjwvcD4KCjx1bCBk aXI9ImF1dG8iPgo8bGk+VHlwaWNhbGx5IHN0cnVjdHVyZWQgb3IgcHJlY29uZmlndXJlZC4g Q291bGQgYWxzbyBiZSBjb25uZWN0ZWQgdG8gYSBjb2xvciBsaWtlIGFib3ZlJiMzOTtzIEtl eXdvcmRzLjwvbGk+CjwvdWw+Cgo8cD48c3Ryb25nPlBlcmNlbnQgY29tcGxldGU8L3N0cm9u Zz4gPHE+VW5zaWduZWQgSW50PC9xPjo8L3A+Cgo8dWwgZGlyPSJhdXRvIj4KPGxpPlR5cGlj YWxseSBhIHZhbHVlIGJldHdlZW4gMCBhbmQgMTAwLjwvbGk+CjwvdWw+Cgo8cD48c3Ryb25n PlR5cGU8L3N0cm9uZz4gPHE+U3RyaW5nPC9xPjo8L3A+Cgo8dWwgZGlyPSJhdXRvIj4KPGxp PlNvbWUgc3lzdGVtcyBoYXZlIGRpZmZlcmVudCB0eXBlcyBvZiB0YXNrcy48L2xpPgo8L3Vs PgoKPHA+PHN0cm9uZz5JbXBhY3Q8L3N0cm9uZz4gPHE+U3RyaW5nPC9xPjo8L3A+Cgo8dWwg ZGlyPSJhdXRvIj4KPGxpPkltcGFjdCBvciBzZXZlcml0eSBvZiB0YXNrIHdpdGggdmFsdWVz IGxpa2U6IGV4dGVuc2l2ZSwgc2lnbmlmaWNhbnQsIG1vZGVyYXRlLCBtaW5vciwgZmVhdHVy ZSwgdHJpdmlhbCwgdGV4dCwgdHdlYWssIG1ham9yLCBjcmFzaCwgYmxvY2s8L2xpPgo8bGk+ QW4gaW1wYWN0IHByb3BlcnR5IGRvZXMgY3VycmVudGx5IG5vdCBleGlzdCBpbiA8c3Ryb25n PkpNQVAgZm9yIFRhc2tzPC9zdHJvbmc+LjwvbGk+CjwvdWw+Cgo8cD48c3Ryb25nPkxvY2F0 aW9uczwvc3Ryb25nPiA8cT5JZFtMb2NhdGlvbl08L3E+OjwvcD4KCjx1bCBkaXI9ImF1dG8i Pgo8bGk+TG9jYXRpb24gd2l0aCB0eXBpY2FsbHkgYSBuYW1lIGFuZCBhbiBhZGRyZXNzLjwv bGk+CjwvdWw+Cgo8cD48c3Ryb25nPlNvdXJjZTwvc3Ryb25nPiA8cT5TdHJpbmc8L3E+Ojwv cD4KCjx1bCBkaXI9ImF1dG8iPgo8bGk+VGhlIHNvdXJjZSBvZiB0aGUgdGFzayBsaWtlIDxx PldlYiBhcHA8L3E+LCA8cT5Nb2JpbGUgY2xpZW50PC9xPiBvciA8cT5FbWFpbDwvcT48L2xp Pgo8bGk+QSBzb3VyY2UgcHJvcGVydHkgZG9lcyBjdXJyZW50bHkgbm90IGV4aXN0IGluIDxz dHJvbmc+Sk1BUCBmb3IgVGFza3M8L3N0cm9uZz4uPC9saT4KPC91bD4KCjxoMyBpZD0idG9j XzEuNCI+Q29uY2x1c2lvbjwvaDM+Cgo8cD5UaGlzIHN1cnZleSBzdHJlc3NlcyBvdXIgaW5p dGlhbCBhc3N1bXB0aW9uIG9mIGhldGVyb2dlbmVpdHkgYWNyb3NzIHRhc2sgc3lzdGVtcy4K T2YgdGhlIHN5c3RlbXMgb2JzZXJ2ZWQsIHRoZXJlIHdhcyBub25lIHRoYXQgc3VwcG9ydGVk IGFsbCBwcm9wZXJ0aWVzIG9mIEpNQVAKZm9yIFRhc2tzLiBUaGF0IG1lYW5zLCBldmVuIHdp dGhpbiB0aGUgZ3JvdXB3YXJlL3dlYm1haWwgc2NvcGUsIHdlIG5lZWQgdG8gZGVhbAp3aXRo IHRoZSBmYWN0IHRoYXQgc29tZSBzZXJ2ZXJzIChhbmQgY2xpZW50cykgd2lsbCBub3Qgc3Vw cG9ydCBhbGwgZnVuY3Rpb25hbGl0eQooZS5nLiB0YXNrIHJlY3VycmVuY2UpLiBPdGhlciBz eXN0ZW0gdHlwZXMgc2VlbSB0byBmaXQgd2VsbCwgc28gaXQgbWFrZXMgc2Vuc2UKdG8gYWRk cmVzcyB0aGVtIGluIEpNQVAuPC9wPgoKPHA+T25lIGNvdWxkIHNlcGFyYXRlIEpNQVAgZm9y IFRhc2tzIGludG8gZXh0ZW5zaW9ucywgc28KZGV2ZWxvcGVycyB3b3VsZCBiZSBhYmxlIHRv IG5hdmlnYXRlIG1vcmUgZWFzaWx5IHRocm91Z2ggdGhlIHNwZWMgd2hlbiBjaG9vc2luZwp3 aGljaCBwYXJ0cyB0byBpbXBsZW1lbnQgZm9yIHRoZWlyIG93biB1c2UgY2FzZXMuIFN1Y2gg ZXh0ZW5zaW9ucyB3b3VsZCBuZWVkIHRvCmNvdmVyIHR3byB0eXBlcyBvZiB0aGluZ3M6IDwv cD4KCjx1bCBkaXI9ImF1dG8iPgo8bGk+U3BlY2lmaWMgc2ltcGxlIGRhdGEgcHJvcGVydGll cyBzdXBwb3J0ZWQgYnkgc29tZSBzeXN0ZW1zIChlLmcuLCBpbiBidWcKdHJhY2tlcnMpPC9s aT4KPGxpPk1vcmUgY29tcGxleCBmZWF0dXJlcyB0aGF0IHNvbWUgc3lzdGVtcyBzdXBwb3J0 IChlLmcuLCBjaGVja2xpc3RzLCBjb21tZW50cyBvcgpyZWN1cnJlbmNlcykgPC9saT4KPC91 bD4KPC9kaXY+CjwvZGl2Pgo8c2NyaXB0PnJlbmRlck1hdGhJbkVsZW1lbnQoZG9jdW1lbnQu Ym9keSk7PC9zY3JpcHQ+CjxzY3JpcHQ+aGxqcy5pbml0SGlnaGxpZ2h0aW5nT25Mb2FkKCk7 PC9zY3JpcHQ+CjxzY3JpcHQ+bWVybWFpZC5pbml0aWFsaXplKHtzdGFydE9uTG9hZDp0cnVl fSk7PC9zY3JpcHQ+CjwvYm9keT4KPC9odG1sPgo= --------------0cXHKIXYm6POQK1v5oPalAld-- From nobody Sun Nov 7 19:16:31 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A723A0AB5 for ; Sun, 7 Nov 2021 19:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.228 X-Spam-Level: X-Spam-Status: No, score=-5.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ictz1rFTB2c for ; Sun, 7 Nov 2021 19:16:25 -0800 (PST) Received: from smtp.linagora.com (smtp.linagora.com [54.36.8.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7453A0AB1 for ; Sun, 7 Nov 2021 19:16:22 -0800 (PST) Received: from [192.168.1.59] (unknown [222.252.23.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id 0C2D84184F for ; Mon, 8 Nov 2021 02:52:41 +0100 (CET) To: jmap@ietf.org References: X-LINAGORA-Copy-Delivery-Done: 1 From: "btellier@linagora.com" Message-ID: Date: Mon, 8 Nov 2021 10:16:15 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------48BE22534A88239EBFA96490" Content-Language: en-US Archived-At: Subject: Re: [Jmap] [Jmap for Sieve] Binary/blob vs. Inline X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 03:16:30 -0000 This is a multi-part message in MIME format. --------------48BE22534A88239EBFA96490 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hello, Nitpicking on this topic. On 05/11/2021 23:37, Hans-Joerg Happel wrote: > On 26.10.21 06:43, Neil Jenkins wrote: >> On Fri, 22 Oct 2021, at 03:41, Hans-Joerg Happel wrote: >>> => We'd argue that this process is both complex to implement plus it's  >>> not particularly elegant to create a need for storing a temporary file.  >> >> Depends how you look at it; it /is/ elegant to have a single >> consistent method for referencing binary data. I think the answer >> here if you are trying to add support on a legacy system where this >> is difficult is to make the Sieve its own account. Then when you >> upload a blob to that account you know it can only be a sieve script, >> which should allow you to do something reasonable. > > Thanks for elaboration - I missed to recognize that it is possible use > the "Account-workaround" also for writing. > > However, enforcing this process makes it still hard to implement in > various imaginable cases. Take my initial Database storage example: > You might force an implementer to store a temp Sieve script (from blob > call) until the second call comes in to continue glue together that > data and do the database INSERT. > > While this is no strict blocker, I think enforcing a blob storage > concept so widely is in conflict with the goal of making it easy for > as many people as possible to adopt JMAP. > > Some additional minor points, for the record: > > * The blobId approach opens up many potential error cases, which > server+client implementers need to have in mind (e.g, think about the > script validation workflow) > * It makes the JMAP Sieve workflow essentially different from the > known and closely related ManageSieve workflows > > "blob based" objects (by this I mean that can only be created with "blob" calls) of the Email spec involves attachments, expected to be large. A few kbs -> MBs. Having an off band mechanisms for those makes perfect sense. However (to me) Sieve scripts are better compared with an HTML body. Sure they are no upper bound but except few outliers, most would be a few KBs (As an administrator, I likely do not want people to upload scripts of more than a few KBs in the first place). HTML bodies can be created in and out of band. The added semantic of having a blob allows things like attaching the sieve script to an email without needing to download + re-upload it (for instance) but it do not look like a common feature to me. So while I am not shocked by the "a Sieve script is a blob" approach, I would consider an inlined String feels more natural. Allowing in and out of bound (so inlined string AND blobId based Sieve script) sure is doable, would settle the debate but brings in a bit more complexity to the backend implementers who now have to code 2 systems instead of one... Would it be "overkill" here? Finally, I think all JMAP capable system should be able to handle blob. This is a requirement for the core spec. Sure for a JMAP proxy on top of a "ManageSieve" server this means that the proxy would have to store temporarily blobs but I would expect JMAP-IMAP proxy to already have similar behavior. This sounds like a non argument to me. >> >>> It would therefore be good if it is possible to (alternatively?) submit  >>> the script inline in the "SieveScript/set" command instead of a blobid. >> >> Using Bron's blob extension you can create a blob in-band and then >> backreference it from the SieveScript/set command. But I wouldn't >> want to say that was the only way you could do it; that breaks the >> consistency of the blob handling. > > If I understand it correctly, while it is atomic from a HTTP call > perspective, the chained processing of commands on server-side is not > necessarily atomic from a logical point of view? Which would mean that > a client still needs to deal with different cases (partial fail / > complete fail ... ) of the chained calls? > Yes I do not think this would spare the "intermediate" storage as a blob you were mentioning above. Best regards, Benoit > > Best, > Hans-Joerg > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --------------48BE22534A88239EBFA96490 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello,

Nitpicking on this topic.

On 05/11/2021 23:37, Hans-Joerg Happel wrote:
On 26.10.21 06:43, Neil Jenkins wrote:
On Fri, 22 Oct 2021, at 03:41, Hans-Joerg Happel wrote:
=> We'd argue that this process is both complex to implement plus it's 
not particularly elegant to create a need for storing a temporary file. 

Depends how you look at it; it is elegant to have a single consistent method for referencing binary data. I think the answer here if you are trying to add support on a legacy system where this is difficult is to make the Sieve its own account. Then when you upload a blob to that account you know it can only be a sieve script, which should allow you to do something reasonable.

Thanks for elaboration - I missed to recognize that it is possible use the "Account-workaround" also for writing.

However, enforcing this process makes it still hard to implement in various imaginable cases. Take my initial Database storage example: You might force an implementer to store a temp Sieve script (from blob call) until the second call comes in to continue glue together that data and do the database INSERT.

While this is no strict blocker, I think enforcing a blob storage concept so widely is in conflict with the goal of making it easy for as many people as possible to adopt JMAP.

Some additional minor points, for the record:

* The blobId approach opens up many potential error cases, which server+client implementers need to have in mind (e.g, think about the script validation workflow)
* It makes the JMAP Sieve workflow essentially different from the known and closely related ManageSieve workflows


"blob based" objects (by this I mean that can only be created with "blob" calls) of the Email spec involves attachments, expected to be large. A few kbs -> MBs. Having an off band mechanisms for those makes perfect sense.

However (to me) Sieve scripts are better compared with an HTML body. Sure they are no upper bound but except few outliers, most would be a few KBs (As an administrator, I likely do not want people to upload scripts of more than a few KBs in the first place). HTML bodies can be created in and out of band.

The added semantic of having a blob allows things like attaching the sieve script to an email without needing to download + re-upload it (for instance) but it do not look like a common feature to me.

So while I am not shocked by the "a Sieve script is a blob" approach, I would consider an inlined String feels more natural.

Allowing in and out of bound (so inlined string AND blobId based Sieve script) sure is doable, would settle the debate but brings in a bit more complexity to the backend implementers who now have to code 2 systems instead of one... Would it be "overkill" here?

Finally, I think all JMAP capable system should be able to handle blob. This is a requirement for the core spec. Sure for a JMAP proxy on top of a "ManageSieve" server this means that the proxy would have to store temporarily blobs but I would expect JMAP-IMAP proxy to already have similar behavior. This sounds like a non argument to me.



It would therefore be good if it is possible to (alternatively?) submit 
the script inline in the "SieveScript/set" command instead of a blobid.

Using Bron's blob extension you can create a blob in-band and then backreference it from the SieveScript/set command. But I wouldn't want to say that was the only way you could do it; that breaks the consistency of the blob handling.

If I understand it correctly, while it is atomic from a HTTP call perspective, the chained processing of commands on server-side is not necessarily atomic from a logical point of view? Which would mean that a client still needs to deal with different cases (partial fail / complete fail ... ) of the chained calls?

Yes I do not think this would spare the "intermediate" storage as a blob you were mentioning above.

Best regards,

Benoit

Best,
Hans-Joerg


_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap
--------------48BE22534A88239EBFA96490-- From nobody Sun Nov 7 20:47:53 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF77C3A08B0 for ; Sun, 7 Nov 2021 20:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=fastmailteam.com header.b=Zla0w0HB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CNJvVASs 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 s2uhxfTtCpju for ; Sun, 7 Nov 2021 20:47:46 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4EE3A08AE for ; Sun, 7 Nov 2021 20:47:46 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 47BCC5C00A9 for ; Sun, 7 Nov 2021 23:47:45 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Sun, 07 Nov 2021 23:47:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=LjPm05P /tU/R4/ngyhxlR+8xtfHDK0t2nXZzxAagIg4=; b=Zla0w0HBuisNSM8VuzHGYVH E6HSMXnghGkmhXqPnf8rYaSkIYgNlhCUtdPdW8ufj67dHfbfEpHeM8YQ4AMKebrG B3Epqz7i9sna34VC7o4Ej8GfVZ8O+kBfUFtvG0LX2dZbFlA8gDXwf73YFeOrT9/1 zZLqA46t8n1xnOGnjzuSwnFJ8I3nXwEaxodmdNIfg+75PkS/yeeRK4tv6xUNIdlt jLTYhBAReW4fEi9NK/WCrSxuPtOgxL5KOT2aWsOQY6eRPjn1E485WKxd1nt0ZfzL 48I4/TLOgMOS+70/eczirfTzuRHb/XPfMFEULdQcbnZozpirqThIfhSWAlXtIsg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=LjPm05 P/tU/R4/ngyhxlR+8xtfHDK0t2nXZzxAagIg4=; b=CNJvVASs25cPoQC+qlMGU/ jftvSJC3vpv9ykho/5dMZIOMB8cMhJsyYr98bbufAtNCN3/AwF+FK7Sj77yaISY2 FF8GgJ41OzI0kevVpPPxkv83oj3IKnb1+qx5vEpYXC8TGD6yPGWAGB/c0JmErS7j l38XQ3s2DpJuBYHM8G9y75jShVQzSyRzmYsijBeSNtIMBM5fHRPOkeGW4LuPA7Ei Q2Z3JZhPxAZITOP/min4DSnJP8II6gsGkHu8+TjF3bsyS/n3Jq58qvm4ZWvYwoEh aiKPC91bbDPEYIy6HYT3T+whmWmNarzcvmMO5tylqkiYoT7SvrbJCN3XjFS1gdvA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddugdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepheeuhfdujedtieevkedvhfffgfelfeelhfefkeehhfekleek hfefueefveffjeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 64738AC0E8C; Sun, 7 Nov 2021 23:47:43 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1420-gdf09e8761c-fm-20211101.001-gdf09e876 Mime-Version: 1.0 Message-Id: <4502396e-b47e-49f1-8273-1fd1b7ed1258@dogfood.fastmail.com> In-Reply-To: References: Date: Mon, 08 Nov 2021 15:47:42 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=3e2a2a6e0b7f4b4b9b4749d83019e0b4 Archived-At: Subject: Re: [Jmap] [Jmap for Sieve] Binary/blob vs. Inline X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 04:47:52 -0000 --3e2a2a6e0b7f4b4b9b4749d83019e0b4 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, 6 Nov 2021, at 03:37, Hans-Joerg Happel wrote: > While this is no strict blocker, I think enforcing a blob storage conc= ept so widely is in conflict with the goal of making it easy for as many= people as possible to adopt JMAP. >=20 Blob support is a part of JMAP core, so if you want to implement JMAP yo= u're probably going to need it. > * The blobId approach opens up many potential error cases, which serve= r+client implementers need to have in mind (e.g, think about the script = validation workflow) Not sure I follow. You validate it just the same, it's just where you ge= t the bytes from. > * It makes the JMAP Sieve workflow essentially different from the know= n and closely related ManageSieve workflows=20 Making it work the same as ManagedSieve is secondary to making it work c= onsistently with other JMAP APIs in my view. I personally don't particularly mind whether the API is blob based or ju= st inline code, but I know this was discussed earlier and I believe ther= e were good reasons to go with blob. > If I understand it correctly, while it is atomic from a HTTP call pers= pective, the chained processing of commands on server-side is not necess= arily atomic from a logical point of view? >=20 That's right. > Which would mean that a client still needs to deal with different case= s (partial fail / complete fail ... ) of the chained calls? Well, it can probably just look at the response of the second call; if t= he blob creation succeeded but the sieve update failed, you can just ign= ore the blob bit; it should get cleaned up at some point automatically. = And if the blob failed, then the sieve update will fail as the result re= f won't resolve, so you can still just look at the second error. =E2=80=94Neil --3e2a2a6e0b7f4b4b9b4749d83019e0b4 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Sat, 6 = Nov 2021, at 03:37, Hans-Joerg Happel wrote:

While this is no strict blocker, I think = enforcing a blob storage concept so widely is in conflict with the goal of making it easy for as many people as possible to adopt JMAP.

=

Blob support is a part of JMAP core, so if you want = to implement JMAP you're probably going to need it.

* The blobId app= roach opens up many potential error cases, which server+client implementers need to have in mind (e.g, think about the script validation workflow)

Not sure I follow. You validate it just the same, it's just where = you get the bytes from.

* It makes the JMAP Sieve workflow essential= ly different from the known and closely related ManageSieve workflows

Making it work the same as ManagedSieve is second= ary to making it work consistently with other JMAP APIs in my view.
<= /div>

I personally don't particularly mind whether th= e API is blob based or just inline code, but I know this was discussed e= arlier and I believe there were good reasons to go with blob.
<= div>

If I und= erstand it correctly, while it is atomic from a HTTP call perspective, the chained processing of commands on server-side is not necessarily atomic from a logical point of view?


That's right.

Which would mean that a client still needs to deal with different cases (partial fail / complete fail ... ) of the chained calls?

Well, it can probably just look at the= response of the second call; if the blob creation succeeded but the sie= ve update failed, you can just ignore the blob bit; it should get cleane= d up at some point automatically. And if the blob failed, then the sieve= update will fail as the result ref won't resolve, so you can still just= look at the second error.

=E2=80=94Neil
--3e2a2a6e0b7f4b4b9b4749d83019e0b4-- From nobody Mon Nov 8 03:04:53 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 388F93A0B91; Mon, 8 Nov 2021 03:04:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163636948717.1974.2518230128440392785@ietfa.amsl.com> Date: Mon, 08 Nov 2021 03:04:47 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-smime-sender-extensions-01.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 11:04:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP extension for S/MIME signing and encryption Author : Alexey Melnikov Filename : draft-ietf-jmap-smime-sender-extensions-01.txt Pages : 6 Date : 2021-11-08 Abstract: This document specifies an extension to JMAP for sending S/MIME signed and S/MIME encrypted messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-smime-sender-extensions/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-jmap-smime-sender-extensions-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-smime-sender-extensions-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 8 03:20:58 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173F33A0C67 for ; Mon, 8 Nov 2021 03:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.429 X-Spam-Level: X-Spam-Status: No, score=-5.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 3e2cBQx1LsjX for ; Mon, 8 Nov 2021 03:20:52 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3F32E3A0C5B for ; Mon, 8 Nov 2021 03:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1636370450; d=isode.com; s=june2016; i=@isode.com; bh=UaDyzIh5FzMa/973WgaKbVbhjKtU9WC+opRFpRBn/KM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=AJX58D7MmGTJWAhaBUe+3/dl8Z0hVb3KNUmSjRQcT9/LIxDpCqe1oV9GDmpfgQc5Noa4uH KG+l+5UGtcpVGudWLwT9a9LddnTn9PTEk4KOkNHKbLsDmHHXH8FMysEkBToBkhq4vndwhz vJ0jA093OrkQVTzAhQkvlK/EGU0nbA8=; Received: from [192.168.1.222] (host5-81-100-95.range5-81.btcentralplus.com [5.81.100.95]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 8 Nov 2021 11:20:50 +0000 To: jmap@ietf.org References: <163636948717.1974.2518230128440392785@ietfa.amsl.com> From: Alexey Melnikov Message-ID: Date: Mon, 8 Nov 2021 11:20:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: <163636948717.1974.2518230128440392785@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-smime-sender-extensions-01.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 11:20:57 -0000 On 08/11/2021 11:04, internet-drafts@ietf.org wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jmap-smime-sender-extensions/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-jmap-smime-sender-extensions-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-smime-sender-extensions-01 In this version I just fixed some XML v3 rendering issues introduced in the previous version. From nobody Mon Nov 8 07:33:25 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659DD3A0FAE for ; Mon, 8 Nov 2021 07:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=IK3dxygl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gjws54ch 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 u2mvhVqR-Kae for ; Mon, 8 Nov 2021 07:33:18 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62BD93A0FAD for ; Mon, 8 Nov 2021 07:33:18 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CB3445C0287 for ; Mon, 8 Nov 2021 10:33:17 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Mon, 08 Nov 2021 10:33:17 -0500 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=BR5lDfkgkLRUoPBUmynBmRzuErAu+xGFbe/LNcf 671s=; b=IK3dxyglirOMBOKo+/m1YBNsa5DvcNYsBk412uGFP3oWi0eTwnFl+ER j98bPl9mmjDsuXSNXUr3jqqe8+MKx0FWP0yLPMf73p8KQpjkvySlX0QNbZDqgK6V kFnbc4j56kUCOY43evfzBER/ubioLxLPtoAorpivdpllIWXkstt5OY8ycAU4W2N/ sBYppfC35OvN8ANN/Xoxz3z4XWTCscXsr07mtE9Ib/k77wClFZGLNieycxIpiQJG s/hRfYz1qNfvRivkRDdcwYIuijxm8snzKEiVukxuZuH46LC6fRh7pkQ5wq+bdnRp eD9D/tI8C4N0bcWTjveLH2TZiuJHUjQ== 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=BR5lDfkgkLRUoPBUmynBmRzuErAu+ xGFbe/LNcf671s=; b=gjws54ch8yGvIBSH4K5lAYJ+LHq7BXt0zD3Sd9tIrYXHQ T/Aag5F6RIegxDezGaaI92QxNlnH0WkyJpVv0vI9k2g+vMBFZ97yoh4pGuporUXd dxUO14G5Jzn+BmlCa9GyBg2Z0ZpV2O+cm0vNU8sakghac2xnvlFjurKdGrPL+91M lj4NFyI0S9bi6dUTux/dui/vfbJ2uLLPDlheQXrSZj17YWQofojXbIl56H+TPZeE d3v3/orP45ek4l0moN6U+lxsYDGwq1TjP0+4rrTK7NIskG3CC/mPBANf9E5HINxj CFVSpjAlRs75sd177JxswtyUKcBf4taSZ6eN8oqRg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddvgdejiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvdetteeiveeihfegie dtgeeigfduveelhefgffelgeelueehhfeitdelgedtffegnecuvehluhhsthgvrhfuihii vgepudenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlth gvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9165CAC0DD1; Mon, 8 Nov 2021 10:33:17 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1420-gdf09e8761c-fm-20211101.001-gdf09e876 Mime-Version: 1.0 Message-Id: Date: Tue, 09 Nov 2021 02:32:56 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=458f0494d5024bd18dbaba3855812266 Archived-At: Subject: [Jmap] call for slides! X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 15:33:24 -0000 --458f0494d5024bd18dbaba3855812266 Content-Type: text/plain Hi JMAPpers, If you have slides for tomorrow (today!)'s meeting, please email them to me in advance or propose them directly in datatracker (you can do that now) - then we will have slides inside datatracker which is nice because it means you'll have the ability to control them. If you do want to present something directly from your computer, you can of course still do that. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --458f0494d5024bd18dbaba3855812266 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi JMAPpers,
If you have slides for tomorro= w (today!)'s meeting, please email them to me in advance or propose them= directly in datatracker (you can do that now) - then we will have slide= s inside datatracker which is nice because it means you'll have the abil= ity to control them.

If you do want to present something = directly from your computer, you can of course still do that.
<= div style=3D"font-family:Arial;">
Cheers,

Bron.

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


--458f0494d5024bd18dbaba3855812266-- From nobody Mon Nov 8 08:18:15 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EC93A11AB; Mon, 8 Nov 2021 08:18:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163638828221.23961.5258805890393819498@ietfa.amsl.com> Date: Mon, 08 Nov 2021 08:18:02 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-sieve-06.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 16:18:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP for Sieve Scripts Author : Kenneth Murchison Filename : draft-ietf-jmap-sieve-06.txt Pages : 29 Date : 2021-11-08 Abstract: This document specifies a data model for managing Sieve scripts on a server using the JSON Meta Application Protocol (JMAP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-sieve/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-jmap-sieve-06.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-sieve-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 9 03:09:43 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C633A0EB6 for ; Tue, 9 Nov 2021 03:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.228 X-Spam-Level: X-Spam-Status: No, score=-5.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5tY41eveZM5 for ; Tue, 9 Nov 2021 03:09:37 -0800 (PST) Received: from mail.audriga.com (mail.audriga.com [176.221.42.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94ABE3A07F4 for ; Tue, 9 Nov 2021 03:09:37 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id D4CF1A137 for ; Tue, 9 Nov 2021 12:09:29 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.audriga.com Received: from mail.audriga.com ([127.0.0.1]) by localhost (mail.audriga.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TWPtId_SHho for ; Tue, 9 Nov 2021 12:09:26 +0100 (CET) Received: from [192.168.10.154] (b2b-109-90-161-242.unitymedia.biz [109.90.161.242]) (Authenticated sender: happel@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id 11B09A149 for ; Tue, 9 Nov 2021 12:09:26 +0100 (CET) To: jmap@ietf.org References: <4502396e-b47e-49f1-8273-1fd1b7ed1258@dogfood.fastmail.com> From: Hans-Joerg Happel Message-ID: Date: Tue, 9 Nov 2021 12:09:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <4502396e-b47e-49f1-8273-1fd1b7ed1258@dogfood.fastmail.com> Content-Type: multipart/alternative; boundary="------------E96E58EBBC3062FF70B33939" Content-Language: en-US Archived-At: Subject: Re: [Jmap] [Jmap for Sieve] Binary/blob vs. Inline X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 11:09:42 -0000 This is a multi-part message in MIME format. --------------E96E58EBBC3062FF70B33939 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Neil, I think we're mainly viewing JMAP from different perspectives: * Yours seems like "a system will be built according to the (full) JMAP specs" * Mine/ours is more like: JMAP can be quite useful to adapt also for existing systems, even if only partially implemented (Every piece of JMAP makes the world a little better ;-) Both perspectives have their merits in my opinion. I am just trying to bring the standard(s) forward by providing some arguments to consider for that second perspective. I do think this is a valid concern, given that there is a large set of existing systems in the area JMAP addresses. Also CardDAV/CalDAV as slighly related standards are mostly implemented on top of existing systems. I agree with you that some of my points don't seem incredibly important, but I think we should also pay attention not to enforce JMAP-specific constraints if not strictly necessary. On 08.11.21 05:47, Neil Jenkins wrote: > On Sat, 6 Nov 2021, at 03:37, Hans-Joerg Happel wrote: >> >> While this is no strict blocker, I think enforcing a blob storage >> concept so widely is in conflict with the goal of making it easy for >> as many people as possible to adopt JMAP. >> > > Blob support is a part of JMAP core, so if you want to implement JMAP > you're probably going to need it. > >> * The blobId approach opens up many potential error cases, which >> server+client implementers need to have in mind (e.g, think about the >> script validation workflow) > > Not sure I follow. You validate it just the same, it's just where you > get the bytes from. I basically had in mind the additional errors cases (as described in your chained call response below), which a client would not need to deal with in an approach more similar to ManageSieve PUTSCRIPT. > >> * It makes the JMAP Sieve workflow essentially different from the >> known and closely related ManageSieve workflows > > Making it work the same as ManagedSieve is secondary to making it work > consistently with other JMAP APIs in my view. ok, fair point. > I personally don't particularly mind whether the API is blob based or > just inline code, but I know this was discussed earlier and I believe > there were good reasons to go with blob. I just found this thread (https://mailarchive.ietf.org/arch/msg/jmap/6u3p0fGs9cdDrBo8y6aU_8Hi2HU/) which does not discuss this too extensive. But I see the point Ken made, that both alternatives are viable, but that it would be better to go with one option only. Thanks and best, Hans-Joerg > >> If I understand it correctly, while it is atomic from a HTTP call >> perspective, the chained processing of commands on server-side is not >> necessarily atomic from a logical point of view? >> > > That's right. > >> Which would mean that a client still needs to deal with different >> cases (partial fail / complete fail ... ) of the chained calls? > > Well, it can probably just look at the response of the second call; if > the blob creation succeeded but the sieve update failed, you can just > ignore the blob bit; it should get cleaned up at some point > automatically. And if the blob failed, then the sieve update will fail > as the result ref won't resolve, so you can still just look at the > second error. > > —Neil > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --------------E96E58EBBC3062FF70B33939 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Neil,

I think we're mainly viewing JMAP from different perspectives:

* Yours seems like "a system will be built according to the (full) JMAP specs"
* Mine/ours is more like: JMAP can be quite useful to adapt also for existing systems, even if only partially implemented (Every piece of JMAP makes the world a little better ;-)

Both perspectives have their merits in my opinion. I am just trying to bring the standard(s) forward by providing some arguments to consider for that second perspective.

I do think this is a valid concern, given that there is a large set of existing systems in the area JMAP addresses. Also CardDAV/CalDAV as slighly related standards are mostly implemented on top of existing systems.

I agree with you that some of my points don't seem incredibly important, but I think we should also pay attention not to enforce JMAP-specific constraints if not strictly necessary.


On 08.11.21 05:47, Neil Jenkins wrote:
On Sat, 6 Nov 2021, at 03:37, Hans-Joerg Happel wrote:

While this is no strict blocker, I think enforcing a blob storage concept so widely is in conflict with the goal of making it easy for as many people as possible to adopt JMAP.


Blob support is a part of JMAP core, so if you want to implement JMAP you're probably going to need it.

* The blobId approach opens up many potential error cases, which server+client implementers need to have in mind (e.g, think about the script validation workflow)

Not sure I follow. You validate it just the same, it's just where you get the bytes from.

I basically had in mind the additional errors cases (as described in your chained call response below), which a client would not need to deal with in an approach more similar to ManageSieve PUTSCRIPT.


* It makes the JMAP Sieve workflow essentially different from the known and closely related ManageSieve workflows

Making it work the same as ManagedSieve is secondary to making it work consistently with other JMAP APIs in my view.

ok, fair point.


I personally don't particularly mind whether the API is blob based or just inline code, but I know this was discussed earlier and I believe there were good reasons to go with blob.

I just found this thread (https://mailarchive.ietf.org/arch/msg/jmap/6u3p0fGs9cdDrBo8y6aU_8Hi2HU/) which does not discuss this too extensive. But I see the point Ken made, that both alternatives are viable, but that it would be better to go with one option only.

Thanks and best,
Hans-Joerg



If I understand it correctly, while it is atomic from a HTTP call perspective, the chained processing of commands on server-side is not necessarily atomic from a logical point of view?


That's right.

Which would mean that a client still needs to deal with different cases (partial fail / complete fail ... ) of the chained calls?

Well, it can probably just look at the response of the second call; if the blob creation succeeded but the sieve update failed, you can just ignore the blob bit; it should get cleaned up at some point automatically. And if the blob failed, then the sieve update will fail as the result ref won't resolve, so you can still just look at the second error.

—Neil

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap
--------------E96E58EBBC3062FF70B33939-- From nobody Tue Nov 9 06:18:31 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D2C3A0D2D for ; Tue, 9 Nov 2021 06:18:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163646750925.13904.11813733710492519395@ietfa.amsl.com> Date: Tue, 09 Nov 2021 06:18:29 -0800 From: IETF Secretariat Archived-At: Subject: [Jmap] Milestones changed for jmap WG X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 14:18:29 -0000 Changed milestone "Adopt a document for S/MIME key management and server side signing/encryption", resolved as "Done", added draft-ietf-jmap-smime-sender-extensions to milestone. Changed milestone "Submit Sieve document to the IESG", set due date to February 2022 from December 2021. Changed milestone "Adopt a document defining JMAP access to addressbooks", set due date to April 2022 from December 2021. Changed milestone "Submit JMAP Calendars document to the IESG", set due date to April 2022 from December 2021. Changed milestone "Submit JSON Contact document to IESG", set due date to April 2022 from December 2021. Changed milestone "Submit JMAP Quotas document to the IESG", set due date to June 2022 from April 2022. URL: https://datatracker.ietf.org/wg/jmap/about/ From nobody Tue Nov 9 09:49:40 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA9F3A0FBD for ; Tue, 9 Nov 2021 09:49:31 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tL9l5VIUBDRr for ; Tue, 9 Nov 2021 09:49:27 -0800 (PST) Received: from mail.audriga.com (mail.audriga.com [176.221.42.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5905C3A0FB8 for ; Tue, 9 Nov 2021 09:49:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id A4AC6A137 for ; Tue, 9 Nov 2021 18:49:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.audriga.com Received: from mail.audriga.com ([127.0.0.1]) by localhost (mail.audriga.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXzdU7O2XTtV for ; Tue, 9 Nov 2021 18:49:17 +0100 (CET) Received: from [192.168.10.154] (b2b-109-90-161-242.unitymedia.biz [109.90.161.242]) (Authenticated sender: happel@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id DFEFBA06C for ; Tue, 9 Nov 2021 18:49:17 +0100 (CET) To: jmap@ietf.org References: <163638828221.23961.5258805890393819498@ietfa.amsl.com> From: Hans-Joerg Happel Message-ID: <10b2bd15-2a04-5af4-aada-2a8923f855a3@audriga.com> Date: Tue, 9 Nov 2021 18:49:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <163638828221.23961.5258805890393819498@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Jmap] VacationResponse vs. JMAP for Sieve / Re: I-D Action: draft-ietf-jmap-sieve-06.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 17:49:39 -0000 Hi, I just rechecked section 3 of the draft ("Compatibility with JMAP Vacation Response") and have some questions. a) The draft says that section 3 applies to "Servers that implement the VacationResponse as a Sieve script that resides amongst other user scripts". My main question: are there examples of systems which do so? Systems I know (e.g., Horde Groupware and several others) will expose vacation notices as a part (single rule) within the standard/active user script. b) The draft further states that those servers "MUST allow the VacationResponse Sieve script to be [de]activated via the "onSuccessActivateScript" In relation to (a), I am slightly confused here. Both ManageSieve (RFC 5804) and the JMAP for Sieve draft allow at most one script to be active. Essentially, that would either allow the "VacationResponse Sieve script" OR a "normal" user script to be active. Would that make any sense, or am I misunderstanding something here? Best, Hans-Joerg On 08.11.21 17: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 JSON Mail Access Protocol WG of the IETF. > > Title : JMAP for Sieve Scripts > Author : Kenneth Murchison > Filename : draft-ietf-jmap-sieve-06.txt > Pages : 29 > Date : 2021-11-08 > > Abstract: > This document specifies a data model for managing Sieve scripts on a > server using the JSON Meta Application Protocol (JMAP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jmap-sieve/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-jmap-sieve-06.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-sieve-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Tue Nov 9 11:15:06 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56243A0FBD for ; Tue, 9 Nov 2021 11:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.394 X-Spam-Level: X-Spam-Status: No, score=-5.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.036, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-3.33, RCVD_IN_MSPIKE_H2=-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=fastmail.com header.b=OXKNwcja; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mVidDld2 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 Xs9GOthIpn90 for ; Tue, 9 Nov 2021 11:14:59 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B973A0E81 for ; Tue, 9 Nov 2021 11:14:59 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 85D5F3200E5D for ; Tue, 9 Nov 2021 14:14:57 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 09 Nov 2021 14:14:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= message-id:date:mime-version:subject:to:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=p WieWCTYMoQR4CGjAWzU9dFcR1Arhvm26Y0XygT3TfY=; b=OXKNwcjakRvRdl5jj Yo65zj9O0Euc8+uJvuvgjS9833da5cCFYnJtIfKDjPD7tEGf+ZktEbRLk3jnb3mq QusWffjZ+R89ahe2Padyfq3MCqU4e0FIEamTFMIicB1S1vUsimsMaZ2EtLMcnNr4 i2CwlLrGv4GVh/bCNd6HLWvo/XLE+6aRej5d3h5o1SwjmgkHKqLkTneqn7VNJHRp vHPq8C9Ny3nqv71bU2Uac3cVnDSLFun6WV5gXkhJdecatPGtgHXF1n+s96vR4Q9g sKPGDL0RLyGLrYvUDE10valH0lwguPKLtI70RFFN4/+H4wgAKCDgY2w+E8ofy0JQ 9Kl/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=pWieWCTYMoQR4CGjAWzU9dFcR1Arhvm26Y0XygT3T fY=; b=mVidDld2duik+5HaWBZ47AfEvS+amUn4KBA9onlv2373KOtqyOuYYxb8B TNv73W55VB0JEaxhflIfCFxke/lq6tb3I6e5boQtPdQ3fLMTjIvuRcarKpeZ6UjB yCNAwxToN0BlHkwCct8a0ERsoZq2qqA+lanKT/3fImdhc9ycoRYiLEKW2QtD700q kT/ENfI+3P/iQEhui+kirfgFYPBfJFL3BqhjVEkwKdWDRpoaokveEFOpSVw7kB7i GELZ7XaC4LKA/XrZRHyeVIC8KgCXFeOmlk7aVccP6awMZViFEAuWU5y+K/owUHz9 E/xNrSdhM/xW1zU2JVQcz6nz1WRgA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudeggdduvdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtje ertddtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgr shhtmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpefgkeejkefgveeffedtgfehud ejteffjeduffeffedttdefvddvvdffheegtdejjeenucffohhmrghinhepihgvthhfrdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh hurhgthhesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 9 Nov 2021 14:14:56 -0500 (EST) Message-ID: <618b27b0-f79c-ef09-7b51-41e7a1749858@fastmail.com> Date: Tue, 9 Nov 2021 14:14:56 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 Content-Language: en-US To: jmap@ietf.org References: <163638828221.23961.5258805890393819498@ietfa.amsl.com> <10b2bd15-2a04-5af4-aada-2a8923f855a3@audriga.com> From: Ken Murchison In-Reply-To: <10b2bd15-2a04-5af4-aada-2a8923f855a3@audriga.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jmap] VacationResponse vs. JMAP for Sieve / Re: I-D Action: draft-ietf-jmap-sieve-06.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 19:15:04 -0000 On 11/9/21 12:49 PM, Hans-Joerg Happel wrote: > Hi, > > I just rechecked section 3 of the draft ("Compatibility with JMAP > Vacation Response") and have some questions. > > > a) The draft says that section 3 applies to "Servers that implement > the VacationResponse as a Sieve script that resides amongst other user > scripts". > > My main question: are there examples of systems which do so? Systems I > know (e.g., Horde Groupware and several others) will expose vacation > notices as a part (single rule) within the standard/active user script. > > > b) The draft further states that those servers "MUST allow the > VacationResponse Sieve script to be [de]activated via the > "onSuccessActivateScript" > > In relation to (a), I am slightly confused here. Both ManageSieve (RFC > 5804) and the JMAP for Sieve draft allow at most one script to be active. > > Essentially, that would either allow the "VacationResponse Sieve > script" OR a "normal" user script to be active. Would that make any > sense, or am I misunderstanding something here? It looks like you've interpreted the current language correctly. If you, or anyone else, would like to see a different interaction with VacationResponse, I am open to changing it, and even more open to suggested text to do so. > On 08.11.21 17: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 JSON Mail Access Protocol WG of the >> IETF. >> >>          Title           : JMAP for Sieve Scripts >>          Author          : Kenneth Murchison >>     Filename        : draft-ietf-jmap-sieve-06.txt >>     Pages           : 29 >>     Date            : 2021-11-08 >> >> Abstract: >>     This document specifies a data model for managing Sieve scripts on a >>     server using the JSON Meta Application Protocol (JMAP). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-jmap-sieve/ >> >> There is also an HTML version available at: >> https://www.ietf.org/archive/id/draft-ietf-jmap-sieve-06.html >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-sieve-06 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Tue Nov 9 14:40:14 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13F93A121B for ; Tue, 9 Nov 2021 14:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, T_SPF_PERMERROR=0.01, UNPARSEABLE_RELAY=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=mildred.fr 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 9PJ6shRe3xrU for ; Tue, 9 Nov 2021 14:40:01 -0800 (PST) Received: from ellomb.netlib.re (elyas.mildred.fr [193.33.56.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33BD3A1230 for ; Tue, 9 Nov 2021 14:40:00 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by ellomb.netlib.re (Postfix) with ESMTPA id C7EC86AC6C14 for ; Tue, 9 Nov 2021 22:39:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mildred.fr; s=dkim; t=1636497594; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=fO97ibMyipQ0fwPfMVjXdV6elcyi/1sM13mXERvHbG8=; b=e2FQdRxs9KYccBsVWIGebbPbYNApJp1mcAiqL8JHlplw3VhzLj9WYc0NJ4d1sB2WqcOE/U +9KA7C5pU5CQo1WHjUL3Pi2FZUTJB2g7Pib/CrptoFFBSGQgAt8Z7MAM81eWncneky7i3t cjtTSPOF713svaFnrN/DPnJQqMwSFrE= Message-ID: <0f29c977-e1f3-2275-7628-5f61e3eb4f33@mildred.fr> Date: Tue, 9 Nov 2021 23:39:53 +0100 MIME-Version: 1.0 To: jmap@ietf.org Content-Language: fr From: Mildred Ki'Lya Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mildred.fr; s=dkim; t=1636497594; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=fO97ibMyipQ0fwPfMVjXdV6elcyi/1sM13mXERvHbG8=; b=P1lHfzpn92MKhp+2yj9thoPTjkgoTYwaiOSklzfLhuouTvEQXchqbYCyEk9DnnyK7dV+r7 xlWmSpK6wsOyWgFz15W3F/wfJ88HgcyvFqNNepsCtQkTwCH96Wgxe2DX+dW4NskWY6Ik0P VS3PvwtdlFImCgxZYXhu0Fx+ZPGeq2o= ARC-Seal: i=1; s=dkim; d=mildred.fr; t=1636497594; a=rsa-sha256; cv=none; b=FGKXLMCU9c8Cw9UiimU2klXlXhwPOt1jufn9wyPxQyW/IKjEfK9rt1eniP3LEtiwJb5OWN +MzBW19GovIaoXRb6aQZo0xrGLSkFEIifcHODDVyOHoNu2Ma1n/ypbm5isdYfoFRLvqo87 l7R4SC3wjJt/QeeW15nhMDjt1UjiOLQ= ARC-Authentication-Results: i=1; ellomb.netlib.re; auth=pass smtp.auth=mildred@mildred.fr smtp.mailfrom=mildred-ml@mildred.fr Authentication-Results: ellomb.netlib.re; auth=pass smtp.auth=mildred@mildred.fr smtp.mailfrom=mildred-ml@mildred.fr X-Spamd-Bar: / Archived-At: Subject: [Jmap] Email/get after an Email/set with create X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 22:40:14 -0000 Hello, It seems I ran in a corner case in JMAP. I'm trying to get an Email object right after its creation. The reason is that I can then access fields generated by the server such as the Message-ID or other headers. My JMAP request looks like:       ['Email/set', {         accountId: jMail.accountId,         destroy: [ email.id ],         create: {           draft: {             mailboxIds: {               [mailboxId]: true             },             messageId: email.messageId,             subject: subject,             bodyStructure: {               type: "text/plain",               partId: "body"             },             bodyValues: {               body: {                 value: body,                 isTruncated: false               }             }           }         }       }, '1'],       ['Email/get', {         accountId: jMail.accountId,         "#ids": { resultOf: "1", name: "Email/set", path: "/created/*/id" }       }, '2'] Here, the Email/get request fails because the path (/created/*/id) is invalid. Indeed, "/created" represents a JSON object indexed by a temporary id ("draft" in my example). I see no way to get the Email object without another round-trip. Can someone enlighten me if I missed something? Thank you From nobody Tue Nov 9 18:37:30 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522FE3A0FDE for ; Tue, 9 Nov 2021 18:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=fastmailteam.com header.b=FoQt3HZs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FzlKSXkG 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 9caXGubtoU_M for ; Tue, 9 Nov 2021 18:37:22 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05E33A0FD9 for ; Tue, 9 Nov 2021 18:37:22 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 715C45C014D for ; Tue, 9 Nov 2021 21:37:21 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Tue, 09 Nov 2021 21:37:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=KcVKd2E DpP1D89JVVgG5p7zYOw6aZ/mZHxJS5i80bMU=; b=FoQt3HZsqL2dC38nBhH0ojt 56nPwaZP8QPdFaEW2oixjYxytmC4avhvvBqqHqxD8IlSvSnn2nstHuXlMgFNDcya 6SvdtmOIl+c+4OVipaXgmF8oIqKgSXC1e54qB54uGbbWY8kjamkZuery/7mrJG8w 4XI+Y439reKMwSrO/t33oCpUqC1RYbLd3YfWQicH3+JZeklD6dvBVFy+uNWc6kwK CxpqsWF3jrB24kTZTMTWzZzpGGwh4lPnObzdUaLhEOsBsadbfrLdNeS8ZRuqismK jyUtj2Ahibkl7CmiNyfHH78ISsGhny1cUsXlhWpV3R8sGZ1y9bZwSI/mVLBdZUQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=KcVKd2 EDpP1D89JVVgG5p7zYOw6aZ/mZHxJS5i80bMU=; b=FzlKSXkGgYnQL8etTiBdPL lrI72lRN9JENV6zuUrpcekGqTdbc4qDtKPbpePG4HBQ2Ez9UD9TCTKAiEJwDbJoB k4zHrYVTcm80K5E5eu9DU0hO6A1V2SjXgbY5KSbGwkxYUVPagtD5jcIhKrobgJIm QgXhZET+F+A2F4WuP+lQxsNwmAyoeaTove92t6fyT4RaXQnbqsGx5zwBA4eHKCFy ZnWmcTWkYvzYSzS0TNclTX2rdi4tLoIBdpXlUIp8xTTmfL2Qu/6YH5WZq2iXTXKi PMAbb6fUW2iueX9LDlv7/JTJWWlb/zvrMKaEL3gWIt8ek52Zr2lMS9XCyooYyP7g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudehgdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepheeuhfdujedtieevkedvhfffgfelfeelhfefkeehhfekleek hfefueefveffjeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0A2E0AC0DD1; Tue, 9 Nov 2021 21:37:21 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1457-g307304a2db-fm-20211109.001-g307304a2 Mime-Version: 1.0 Message-Id: <0bc38380-7d5f-4de6-8cbb-6a4a09c60f7d@dogfood.fastmail.com> In-Reply-To: <0f29c977-e1f3-2275-7628-5f61e3eb4f33@mildred.fr> References: <0f29c977-e1f3-2275-7628-5f61e3eb4f33@mildred.fr> Date: Wed, 10 Nov 2021 13:37:20 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=a49424963a354b599e2ae134e972788f Archived-At: Subject: Re: [Jmap] Email/get after an Email/set with create X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 02:37:28 -0000 --a49424963a354b599e2ae134e972788f Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mildred, > Can someone enlighten me if I missed something? No, you didn't miss anything. This currently requires two round trips. W= e tried to balance expressivity with simplicity and easy of implementati= on, and this is one of the things you can't currently express with the s= tandard JMAP result ref syntax. If there were interest, it's something t= hat could be added as an extension of course. =E2=80=94Neil --a49424963a354b599e2ae134e972788f Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Mildred,
=

Can someone enlighten me if I missed something?
<= div>
No, you didn't miss anything. This currently requires= two round trips. We tried to balance expressivity with simplicity and e= asy of implementation, and this is one of the things you can't currently= express with the standard JMAP result ref syntax. If there were interes= t, it's something that could be added as an extension of course.

=E2=80= =94Neil
--a49424963a354b599e2ae134e972788f-- From nobody Tue Nov 9 20:54:48 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 373A93A11FB for ; Tue, 9 Nov 2021 20:54:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163652008720.30366.8735625437093867106@ietfa.amsl.com> Date: Tue, 09 Nov 2021 20:54:47 -0800 From: IETF Secretariat Archived-At: Subject: [Jmap] Milestones changed for jmap WG X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 04:54:48 -0000 Changed milestone "Submit SMIME Sender Extensions document to the IESG", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/jmap/about/ From nobody Tue Nov 9 23:55:20 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A783A1363 for ; Tue, 9 Nov 2021 23:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=fastmailteam.com header.b=pIPrhoZf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DPBe2tUu 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 J9XSd6qtjLZs for ; Tue, 9 Nov 2021 23:55:14 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366923A135D for ; Tue, 9 Nov 2021 23:55:14 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 73A4432019DA for ; Wed, 10 Nov 2021 02:55:12 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Wed, 10 Nov 2021 02:55:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=BZHk73z K4ff6LGp8GyghH7PlXF4ql7eVTuq6ai+wLFM=; b=pIPrhoZf1pP8hmFYhn3y4hS RhbOKsOdcem9a4T14o3c9/M5ZfXjxUZHR8glYV6U4k/1oc3hkKHRE0JS+dtae0Vq u3KCPYY31JE3DLP8ckWnz3ajqo7SZxHYXS3giE7h0XqcqtdlDy8pYmfj5IciEG+7 8gXYAEkoveynafs1+/uchVpuR6DTQjxnU/jKlaj1nvSJ8+fD4BriwQoU+jIF44XC dPtIdplRWc6YdKUBjQbmvvtNzkk2RetufpOCX/tx81IwRhtCotCWjwPwPiZdY8to 5YiYCm4c9CTQDRonM7EbcLZ6W7n7fX/VdLr+0+YFaIdmrnhB1xJwepOqrS5A9aw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=BZHk73 zK4ff6LGp8GyghH7PlXF4ql7eVTuq6ai+wLFM=; b=DPBe2tUuUWy2mywj2IH7AV TmEfl6N9z7m/3mo0BhPGeDoxtL9w73qoqVyPUA+Xx4Ie5+O5XS/MiVuU616EZCQw Ddjts4fB+QT7mmWS6o4nZVBnFSEviUrawOAzM+Yzf0ih9IvspcM6tkJKmnjfyJLY TO5v7yrjN+tuQ0l7elw5ds9FweCwD9N9jgAsTQKY2l9Wg2WzE7hOtrKRMv1ITn+w tqpktnrzq8A4pQBO9avo2x1Mj5RsT67Fp/fr3oWp8n25OrX0e5TknCv4qy3d5ovs cPItisRz+eH78EOxqxI7/QCoQUYl8O/yHUUB5iHmhaL9uQElnbOVoB0TESMo8CDQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudehgdelkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpefhgfelgeekle dvvedtfeeigfetffejhfeltefgleehheeuvefhgfevjeegueettdenucffohhmrghinhep tgihrhhushhimhgrphdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E5C44AC0DD1; Wed, 10 Nov 2021 02:55:11 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1457-g307304a2db-fm-20211109.001-g307304a2 Mime-Version: 1.0 Message-Id: <6c9d713a-60e5-4344-af7e-9ae78daefdc9@www.fastmail.com> In-Reply-To: <0bc38380-7d5f-4de6-8cbb-6a4a09c60f7d@dogfood.fastmail.com> References: <0f29c977-e1f3-2275-7628-5f61e3eb4f33@mildred.fr> <0bc38380-7d5f-4de6-8cbb-6a4a09c60f7d@dogfood.fastmail.com> Date: Wed, 10 Nov 2021 08:54:51 +0100 From: "Robert Stepanek" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=3d2a4db21b234117896ee54baa0488c4 Archived-At: Subject: Re: [Jmap] Email/get after an Email/set with create X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 07:55:20 -0000 --3d2a4db21b234117896ee54baa0488c4 Content-Type: text/plain On Wed, Nov 10, 2021, at 3:37 AM, Neil Jenkins wrote: > >> Can someone enlighten me if I missed something? > > No, you didn't miss anything. This currently requires two round trips. Just to note: the Cyrus IMAP [1] implementation of JMAP does allow to use creation ids in /get requests as a non-standard feature: ['Email/set', { create : { draft: { ... } }, }, '1'], ['Email/get', { ids: ['#draft'], }, '2'] [1] https://www.cyrusimap.org/ --3d2a4db21b234117896ee54baa0488c4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, No= v 10, 2021, at 3:37 AM, Neil Jenkins wrote:

Can someone enlighten me if I missed something?<= br>

No, you didn't miss anything. = This currently requires two round trips.
Just to note: the Cyrus IMAP [1] implementation of JMAP does= allow to use creation ids in /get requests as a non-standard feature:

['Email/set', {
   create : {
  =    draft: {
    =    ...
     }
  },
}, '1'],
=
['Email/get', {
 &= nbsp;  ids: ['#draft'],
}, '2']
=

--3d2a4db21b234117896ee54baa0488c4-- From nobody Wed Nov 10 00:24:12 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005873A041C for ; Wed, 10 Nov 2021 00:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gultsch-de.20210112.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 XonAlRPTFhNg for ; Wed, 10 Nov 2021 00:24:05 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 4F2BC3A045B for ; Wed, 10 Nov 2021 00:24:04 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id s15so1614600ild.9 for ; Wed, 10 Nov 2021 00:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gultsch-de.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=22MldLqb12G6/SKbe9vmlEgLiNzRJIi5EGI2PaWrut0=; b=KX1+Zep9WQTWQ7ECED7gqIxIgPLYs2D3b6vcmPI3ZhVvNmz730W3V+wNHAOfiml8LV 9PS/WeSo04RMYfydH/ZeYmWP10UETNdzJIkSAenuOms+ynLYC6lFb87J6Z5YmIk3SeiK qA9wT3DXgBwrNQqBCREBRumwB4dximol2yjW8SwQQ97Pt2jEQyBXHrEMUcv5oOspysnA FAa+Lk+4VxC+Sfrffv9XyHHtCnZq9qgsf5fp50x3o6h3FA0EFKz4d+xiqPuGr9SMkjxr RgWqckr9OyzTCu3NjFupj5cFGOHR7xtczysc/p1VMkcDrNGvZK/7j2haz/c8ztqDjSj5 fG9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=22MldLqb12G6/SKbe9vmlEgLiNzRJIi5EGI2PaWrut0=; b=ApnyLg9yNmBInMgxbtPsqc6J6QLBCoIyg9V1+9xJ+rMQAkev0JYZxu3SDZsHAMfDdi /RzJCDbK2VHEdcfnf3ouTuZzhJ2XctPuzO+D8HYftXyqEjx+oX76KurZDKa0EgkuT1Ca CKj7xp8Cgow9MmWhC1cBpjMNUaWwzgVPZIAaIOIk/xLeZ5uj31uGCurDOk17k77GGDJ+ mPJ1/hZykOyafC4XZigYYaJFx7wZa1a8WS/KL2VGbcEF3zZ4+kN6y8J5vUnDAkHP2OOQ tVgYSEqzVGNAezN+JQzmsn7ObXt6bPOKVX4VovXISLTk88MuJ4MEiMGiC+Q9t6NrVIZW hlng== X-Gm-Message-State: AOAM530KwxEH2SCDw5CBQjr47IvXAj2FpvtfC45Z+22+I8XHnKSeYQTl oU1pXv93zQ1CKsfeMsKa6zWOFQtCP1wxYKRivVy3bjya/jF1Wg== X-Google-Smtp-Source: ABdhPJzqOKm0E+qDOMMfi69yR81Pd71WCRSYhFTfZ7jpupa1nPz1Eb3o2sB3q+ktyemv9w0HVXxigNJiBsD+yRk0LKE= X-Received: by 2002:a05:6e02:ef3:: with SMTP id j19mr10256824ilk.212.1636532643412; Wed, 10 Nov 2021 00:24:03 -0800 (PST) MIME-Version: 1.0 References: <0f29c977-e1f3-2275-7628-5f61e3eb4f33@mildred.fr> <0bc38380-7d5f-4de6-8cbb-6a4a09c60f7d@dogfood.fastmail.com> In-Reply-To: <0bc38380-7d5f-4de6-8cbb-6a4a09c60f7d@dogfood.fastmail.com> From: Daniel Gultsch Date: Wed, 10 Nov 2021 09:23:52 +0100 Message-ID: To: Neil Jenkins Cc: IETF JMAP Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Email/get after an Email/set with create X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 08:24:10 -0000 On Wed, Nov 10, 2021 at 3:37 AM Neil Jenkins wrote= : >> Can someone enlighten me if I missed something? > No, you didn't miss anything. This currently requires two round trips. Isn=E2=80=99t the set response supposed to return all server-set properties= of the email object? cheers Daniel From nobody Wed Nov 10 04:05:42 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61F33A0E99 for ; Wed, 10 Nov 2021 04:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=fastmailteam.com header.b=LdK9aQcd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TNNBnsDn 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 X-8PmcXWPKcy for ; Wed, 10 Nov 2021 04:05:35 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E783A0E95 for ; Wed, 10 Nov 2021 04:05:35 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 633E5320148A; Wed, 10 Nov 2021 07:05:32 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Wed, 10 Nov 2021 07:05:32 -0500 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=rbm0 0EFgJG6g4XQmVC5CRZymU3lbQFYEXxYI+rotPJo=; b=LdK9aQcdfpUZ0mXG/tsu N+MXVbkIgp9vMJ86++o1GmyMYjUFbydxLyKzSkRGAKZcxBe1/ptxyE67j/gT5ELg KSyO8/e+wMAgLxyRfY1OX8LSpI7aW8wY+aMWPCHwk7wVblLD/EL5dth61WbH7RQN nOs1HjdHrnZUWuD+bR8kjBe4z8vRWlFlLbiVJapfI5mdCOXR18y1HRMj3GNgpoxs RJzBb+tcQ2chbnSS4SwG7XWqD2rvHjIMKD85XD1SUPyPsNPb3If+c+oEXsCTLyxG dHcjVMGn7DkrVQXfXar1bqltpO7L3/in1qCeXTlA+FhDD5IKZkqcg2pgARfaCloc eA== 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=rbm00E FgJG6g4XQmVC5CRZymU3lbQFYEXxYI+rotPJo=; b=TNNBnsDng79UZNQpZ3RPtw 4cvOAMfHwWNN7C4rkftQKQXrcUnhVVcBTeIzhaNoESRcVXz6d9aMZXf4huxmJzxR XwNsHBG/sF6KgBKjG1L3hkb9PPcP3PHBPYJLzceCSmRdXUL8fmn95mU15geAE4zF o9mER+n7G51rCQp8cHesegdNlDt1JWtBs1jiWUaj5uDY59oPRkbmlEFdW9SpFAKD uCi6WRel52XffLLZe4fNFAobADD2pqz9k6AfAOjow+9f8zJSTYGNvFYAjNq6BWVV 1BADfAJJTa1tLx+Y2kR5qETJEuU19vOISZVPX0Qgrws7URdemqiMQ8J7p9flut+Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudejgdefgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepffeukeejkeefheehfeekfeekieelkeffvddufeetgfeihfej veelieeuveetuefhnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghi lhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D53FEAC0DD1; Wed, 10 Nov 2021 07:05:31 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1457-g307304a2db-fm-20211109.001-g307304a2 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0f29c977-e1f3-2275-7628-5f61e3eb4f33@mildred.fr> <0bc38380-7d5f-4de6-8cbb-6a4a09c60f7d@dogfood.fastmail.com> Date: Wed, 10 Nov 2021 23:05:31 +1100 From: "Neil Jenkins" To: "Daniel Gultsch" Cc: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=7e1c6363ab18437c81c52e16a63f13c4 Archived-At: Subject: Re: [Jmap] Email/get after an Email/set with create X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 12:05:41 -0000 --7e1c6363ab18437c81c52e16a63f13c4 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, 10 Nov 2021, at 19:23, Daniel Gultsch wrote: > Isn=E2=80=99t the set response supposed to return all server-set prope= rties of > the email object? In general, yes. But the Email object is a bit unusual in that it's not = the canonical underlying format (which is a RFC5322 message). Most prope= rties are ways of asking the server to parse the message and return part= of that data in a particular format. Therefore RFC8621 specifies exactl= y what shoul= d be returned for create (which are all the properties not related to pa= rsing the RFC5322 message): For successfully created Email objects, the "created" response contains the "id", "blobId", "threadId", and "size" properties of the object. =E2=80=94Neil --7e1c6363ab18437c81c52e16a63f13c4 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Wed, 10 Nov = 2021, at 19:23, Daniel Gultsch wrote:
Isn=E2=80=99t the set response supposed to re= turn all server-set properties of
the email object?

In general, yes. But the Email objec= t is a bit unusual in that it's not the canonical underlying format (whi= ch is a RFC5322 message). Most properties are ways of asking the server = to parse the message and return part of that data in a particular format= . Therefore RFC8621 specifies exactly what should be returned for crea= te (which are all the properties not related to parsing the RFC5322 mess= age):

   For successfully=
 created Email objects, the "created" response
   contains the "id", "blobId", "threadId", and "size" properties of the
   object.

=E2=80=94Neil
--7e1c6363ab18437c81c52e16a63f13c4-- From nobody Wed Nov 10 13:57:31 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA403A1417 for ; Wed, 10 Nov 2021 13:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, UNPARSEABLE_RELAY=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=mildred.fr 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 HbaOJ6qtMosq for ; Wed, 10 Nov 2021 13:57:23 -0800 (PST) Received: from ellomb.netlib.re (elyas.mildred.fr [193.33.56.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3FDD3A1415 for ; Wed, 10 Nov 2021 13:57:21 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by ellomb.netlib.re (Postfix) with ESMTPA id 4F3646AD4D88 for ; Wed, 10 Nov 2021 21:57:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mildred.fr; s=dkim; t=1636581435; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sdVX9wrFtaUxIud9ySbV8eDXwafXr3LBU3llzOrYGds=; b=h1JG3vMEqfebjzvnCk741M5mNIXWpo4g+OYC6gdxnStOgmhuESPk8PEAMLwO834fwAHqjc qd33oFZmQ80E/xS3Ep8Y2Pp/dxPL0leNzPPa3lh7tz6gSZ/ekxU1U0iOgHmrUtgGDIztS+ mIUCoNI/w6ERP48ecPsPs2v1GKEvQ0Q= Content-Type: multipart/alternative; boundary="------------3g9cmtUpPS0ZRtCyq2Z0mP0I" Message-ID: Date: Wed, 10 Nov 2021 22:57:14 +0100 MIME-Version: 1.0 Content-Language: fr To: jmap@ietf.org References: <0f29c977-e1f3-2275-7628-5f61e3eb4f33@mildred.fr> <0bc38380-7d5f-4de6-8cbb-6a4a09c60f7d@dogfood.fastmail.com> From: mildred-ml@mildred.fr In-Reply-To: <0bc38380-7d5f-4de6-8cbb-6a4a09c60f7d@dogfood.fastmail.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mildred.fr; s=dkim; t=1636581435; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sdVX9wrFtaUxIud9ySbV8eDXwafXr3LBU3llzOrYGds=; b=kKTusIM+iBNxnPUCL+oydc+oNSvVo/anDTN5Fxc+3GFHwSTnJcw4wCT7mybWvQcwqURr4i R4rxwtpPiTMMK+GLIBM+idpz7/q8B/LNqlb2lg8X22tAjlAQvS5MsDN40yU3Waaj3cY0HZ /znf7mh/nOK9arzcopUO4p5hh91wRis= ARC-Seal: i=1; s=dkim; d=mildred.fr; t=1636581435; a=rsa-sha256; cv=none; b=WeF3LJWjjzBAYY9GDaXAisJ3nlcuewxoa2JH4gsRwbEEqitR3i7suwoLgCXHAFGeyhFkOI zAms5hy/08y2FnU1OmFGaB1FtEnRidhe7Icz2I4Ea2K7QLm39eu4ntx+BFuQzCSha8Dhfx XGruNlkf8r8/4xhrcgBl4PWUkpehHFs= ARC-Authentication-Results: i=1; ellomb.netlib.re; auth=pass smtp.auth=mildred@mildred.fr smtp.mailfrom=mildred-ml@mildred.fr Authentication-Results: ellomb.netlib.re; auth=pass smtp.auth=mildred@mildred.fr smtp.mailfrom=mildred-ml@mildred.fr X-Spamd-Bar: / Archived-At: Subject: Re: [Jmap] Email/get after an Email/set with create X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 21:57:28 -0000 This is a multi-part message in MIME format. --------------3g9cmtUpPS0ZRtCyq2Z0mP0I Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 10/11/2021 à 03:37, Neil Jenkins a écrit : > > No, you didn't miss anything. This currently requires two round trips. > We tried to balance expressivity with simplicity and easy of > implementation, and this is one of the things you can't currently > express with the standard JMAP result ref syntax. If there were > interest, it's something that could be added as an extension of course. Thank you for the details, I understand the need to keep the implementation simple but I would have imagined that a returned `createdIds` could have been returned for the sole purpose of chaining commands without needing to complexify the JSON path implementation. In any case, a round-trip is not really a problem (that's not there that I need the maximum performance), I just wanted to be sure that I did not miss something. Mildred --------------3g9cmtUpPS0ZRtCyq2Z0mP0I Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Le 10/11/2021 à 03:37, Neil Jenkins a écrit :

No, you didn't miss anything. This currently requires two round trips. We tried to balance expressivity with simplicity and easy of implementation, and this is one of the things you can't currently express with the standard JMAP result ref syntax. If there were interest, it's something that could be added as an extension of course.

Thank you for the details, I understand the need to keep the implementation simple but I would have imagined that a returned `createdIds` could have been returned for the sole purpose of chaining commands without needing to complexify the JSON path implementation. In any case, a round-trip is not really a problem (that's not there that I need the maximum performance), I just wanted to be sure that I did not miss something.

Mildred

--------------3g9cmtUpPS0ZRtCyq2Z0mP0I-- From nobody Wed Nov 10 14:09:36 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160343A141E for ; Wed, 10 Nov 2021 14:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, UNPARSEABLE_RELAY=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=mildred.fr 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 bfP9y8DZghGp for ; Wed, 10 Nov 2021 14:09:26 -0800 (PST) Received: from ellomb.netlib.re (elyas.mildred.fr [193.33.56.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21913A141F for ; Wed, 10 Nov 2021 14:09:25 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by ellomb.netlib.re (Postfix) with ESMTPA id E0AC86AD4F13 for ; Wed, 10 Nov 2021 22:09:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mildred.fr; s=dkim; t=1636582160; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=Nuo8OUgWN+Dcl6EUIZeFaZcFA3NpLkJFF6moTiBTlcg=; b=NIq774D4lXB6i13l9pg9hRurByBP8ld7uJbGvTDbQhjqmke/7lYs8N4WOuy/wN7qk1cNix ZxC6ZdKs7zKKcev0ZQdN8ZD//eNOBBb9L3d4fPfS7eD/7DbAFuccdAqWml5q25zQruuKpk QwcnwKK0IRfK8wgsdpl/7i3EV6JlAbI= Content-Type: multipart/alternative; boundary="------------pBAoZkw08Vy0win6AC7crdrA" Message-ID: <41cf1339-3a65-d638-5056-927a69a59045@mildred.fr> Date: Wed, 10 Nov 2021 23:09:19 +0100 MIME-Version: 1.0 To: jmap@ietf.org Content-Language: en-US From: Mildred Ki'Lya ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mildred.fr; s=dkim; t=1636582161; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=Nuo8OUgWN+Dcl6EUIZeFaZcFA3NpLkJFF6moTiBTlcg=; b=O66/JuBQgjJ4fjS38EprIC6ERrMt9ikfNLvpVdOMnhbDInNJdtUkLWXC+2tbDC3POc4CXS VsE90+UgHWw018ILAXCVoWCxm5Uvawuuc+FaaUGFjk//aeratkYbI8FCb3kNCRzCj6XmML BoNfr7zfIOibPhtWnoVxwD/M0fd4obE= ARC-Seal: i=1; s=dkim; d=mildred.fr; t=1636582161; a=rsa-sha256; cv=none; b=HS/vL0htheNLavt3ChOMK31E15XkJJzU50pNQX5y1AU4xojFuDT9gT7FD3nWbQq4ZCN1oU vRsN2al8XogLcpemfjMqA/UVHFC2T+WnrCBaUqPdB6XNX7khJAu4VX+J6Xw1qms8LrkVUj IKe+jPjN2IbxnwEbp0oaEU3PHLB7E88= ARC-Authentication-Results: i=1; ellomb.netlib.re; auth=pass smtp.auth=mildred@mildred.fr smtp.mailfrom=mildred-ml@mildred.fr Authentication-Results: ellomb.netlib.re; auth=pass smtp.auth=mildred@mildred.fr smtp.mailfrom=mildred-ml@mildred.fr X-Spamd-Bar: / Archived-At: Subject: [Jmap] Another question about updating a draft Email X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 22:09:31 -0000 This is a multi-part message in MIME format. --------------pBAoZkw08Vy0win6AC7crdrA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, For the lack of a better mailing list, I believe I took this place as a support forum :) I need to take an existing draft Email, modify it (through the compose interface I'm building) and then save it back with the changes. I would like the changed Email to be as close as the original as possible (same headers, ...). For this reason I'm taking the result of an Email/get operation, patch it with the changed values, and feed it to Email/set (create). If I could I'd try to update the Email object but i understand that's not possible as Email are immutable. Doing so, I uncovered a bug in the previous version of Cyrus most probably related to the additional extra fields I'm including in Email/set. Properties such as id, threadId, blobId, size, trustedSender, hasAttachment, preview, and similar properties in textBody and htmlBody are rejected by the server (rightfully as this is not part of the Email file itself). Again, am I missing something on how to do this easily without having to prune those illegal properties before calling Email/set. Is there a way to update an Email object. I'm also asking this because some received Emails contains bogus information (such as bogus dates) that might be interesting to correct while keeping all the other headers (including the Received headers). Thank you Mildred --------------pBAoZkw08Vy0win6AC7crdrA Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hello,

For the lack of a better mailing list, I believe I took this place as a support forum :) I need to take an existing draft Email, modify it (through the compose interface I'm building) and then save it back with the changes. I would like the changed Email to be as close as the original as possible (same headers, ...). For this reason I'm taking the result of an Email/get operation, patch it with the changed values, and feed it to Email/set (create). If I could I'd try to update the Email object but i understand that's not possible as Email are immutable.

Doing so, I uncovered a bug in the previous version of Cyrus <https://github.com/cyrusimap/cyrus-imapd/issues/3766> most probably related to the additional extra fields I'm including in Email/set. Properties such as id, threadId, blobId, size, trustedSender, hasAttachment, preview, and similar properties in textBody and htmlBody are rejected by the server (rightfully as this is not part of the Email file itself).

Again, am I missing something on how to do this easily without having to prune those illegal properties before calling Email/set. Is there a way to update an Email object. I'm also asking this because some received Emails contains bogus information (such as bogus dates) that might be interesting to correct while keeping all the other headers (including the Received headers).

Thank you

Mildred

--------------pBAoZkw08Vy0win6AC7crdrA-- From nobody Thu Nov 11 20:44:36 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD4B3A0CD3; Thu, 11 Nov 2021 20:44:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163669227033.29649.148187148141492069@ietfa.amsl.com> Date: Thu, 11 Nov 2021 20:44:30 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-blob-06.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2021 04:44:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP Blob management extension Author : Bron Gondwana Filename : draft-ietf-jmap-blob-06.txt Pages : 20 Date : 2021-11-11 Abstract: The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data via HTTP POST and GET on defined endpoint. This binary data is called a "Blob". This extension adds additional ways to create and access Blobs, by making inline method calls within a standard JMAP request. This extension also adds a reverse lookup mechanism to discover where blobs are referenced within other data types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-blob/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-jmap-blob-06.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-blob-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 15 04:23:45 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FF03A0A6C for ; Mon, 15 Nov 2021 04:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=fastmailteam.com header.b=OdjO+Gfb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AnEDA4zE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_qfg5lPMyvI for ; Mon, 15 Nov 2021 04:23:38 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B123A0A66 for ; Mon, 15 Nov 2021 04:23:38 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 562A53201C29 for ; Mon, 15 Nov 2021 07:23:36 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Mon, 15 Nov 2021 07:23:36 -0500 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=TyYlxwy52c3REEWd7uoIzGqWsyo0Tzv326s0/q1 DV0Q=; b=OdjO+GfbYXD8vz5WcpqrH15DWonmtbVk8PqQawnygPIPBYEHOUrHVx8 YjFILMcdOIWky5ocgNilLjBX0xb/5UFyrRBo8bOuo+yzQG1iQdY0SDYEKT0hVqvk 4mrrD+GA+StHX2bxrlpcYuVXZP2ya7RDNPj811OCoggIlfCo1DJcMjKz8kmSkVwg s+4/AY9OLSoOYd7oyvUHSAASc9iAVSTkCpqiu+SyjRhHbqufJ5gSUZ/tLSh0Q7Ch LX/6CAbeT7cKKDGwX8BH4nPrkvUnkLYfj7+s2SbIKl8ioZLuqjC4G61gt8ny5eRl PT2Ie1/iugcJTdgbgDz3yJ3xy9HTXGA== 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=TyYlxwy52c3REEWd7uoIzGqWsyo0T zv326s0/q1DV0Q=; b=AnEDA4zESlqt8c0uU68hPxrMoijINQRX+tE6qGxvmQZY2 E+a4EQzK5+v33QR/7K3kQk2N1cLBIjwycC+D5P6XOKHL3yJ9S75Rbh6aQD+AKNFx xpXTv49tzR0NGh7AQ3mKYTR4a5TmuH+7cKaKGNI3BIzBsnAJhdMPCNB9UYNLxlFp MxEJY63jieoL8Nfo6LyzS17cNdHSQ3tnNwinB1mtMiYCY5A44+wj72dZqZIkYnDz hCWphtfsZpPPbtcl908RDNPnqebmzgVebVu9KqnavA4yTwag9okqniLiEzORPz+K iVOyYuy6OTfP2rpSWignjZJjbmYA/Nc+iwzbWeJyg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrfedtgdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre erjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnheptdelfeegudettefhhe egtdelvefhudduhfeijeeghedtveeitddtuefggedvjeehnecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 92E6BAC0DD1; Mon, 15 Nov 2021 07:23:35 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1457-g307304a2db-fm-20211109.001-g307304a2 Mime-Version: 1.0 Message-Id: <3a66c632-3ff6-4cc1-b9e2-97c1f79e808e@dogfood.fastmail.com> Date: Mon, 15 Nov 2021 23:23:05 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=2cdff5126ea046a7aa54334f7372aa5c Archived-At: Subject: [Jmap] IETF112 session minutes uploaded X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2021 12:23:44 -0000 --2cdff5126ea046a7aa54334f7372aa5c Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, The minutes from our session at IETF112 have been uploaded to the datatr= acker. You can find them here: https://datatracker.ietf.org/doc/minutes-112-jmap/ There are also quite a few actions out of this one! ACTION: *Bron* will upload a new blob draft, then ask Jim to issue a WGL= C. ACTION: *Neil* to remind Alexey of Email/changes issue with changing smi= me status. ACTION: *Bron* to think of other names for smimeStatusAtDelivery. ACTION: *Alexey* will publish a new draft for smime, then ask IESG to pu= blish. ACTION: *Bron* to suggest a "decryptBody: true" parameter to Email/get f= or smime-advanced. ACTION: *Neil* to update jmap-calendars draft based on the feedback from= previous meetings. ACTION: *Joris* and *Hans-J=C3=B6rg* to continue refining surveys and co= ntacing developers/vendors for jmap-tasks. ACTION: *Robert* to work on a document for general way of doing history = for JMAP objects. ACTION: *Robert* will contact Unicode and let them know what we're doing= with jscontact names. ACTION: *Bron* will call for adoption in the EXTRA working group for ima= p-partial. ACTION: *Bron* and *Ken* to re-visit inline options for sieve scripts in= jmap-sieve. ACTION: *Bron* and *Alexey* to reply on the EXTRA mailing list about ann= otating sieve rules with a name. Please note any actions which are for you. Thanks, Bron and Jim, your JMAP chairs -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --2cdff5126ea046a7aa54334f7372aa5c Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi all,

The minutes from our session at IET= F112 have been uploaded to the datatracker.  You can find them here= :

=

There are also quite a few actions out of this one!

ACTION: Bron will upload a new blob draft, then ask Jim to issue= a WGLC.
ACTION: Neil = to remind Alexey of Email/changes issue with changing smime status.
<= /div>
ACTION: Bron to think of o= ther names for smimeStatusAtDelivery.
ACTION: Alexey will publish a new draft for smime, then = ask IESG to publish.
ACTION: = Bron to suggest a "decryptBody: true" parameter to Email/get for = smime-advanced.
ACTION: Ne= il to update jmap-calendars draft based on the feedback from previou= s meetings.
ACTION: Joris<= /b> and Hans-J=C3=B6rg to continue refining surveys and contacing= developers/vendors for jmap-tasks.
ACTION: Robert to work on a document for general way of do= ing history for JMAP objects.
ACTION: Robert will contact Unicode and let them know what we're= doing with jscontact names.
= ACTION: Bron will call for adoption in the EXTRA working group fo= r imap-partial.
ACTION: Br= on and Ken to re-visit inline options for sieve scripts in jm= ap-sieve.
ACTION: Bron= and Alexey to reply on the EXTRA mailing list about annotating s= ieve rules with a name.

<= /div>
Please note any actions which are= for you.

Thanks,

Bron and Jim, your JMAP = chairs

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

--2cdff5126ea046a7aa54334f7372aa5c-- From nobody Mon Nov 15 18:35:16 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40343A043C for ; Mon, 15 Nov 2021 18:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=aE8A+PBe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZZ1z88HI 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 mKlb0APj__Vq for ; Mon, 15 Nov 2021 18:35:09 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994213A041B for ; Mon, 15 Nov 2021 18:35:09 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A80695C029D for ; Mon, 15 Nov 2021 21:35:08 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Mon, 15 Nov 2021 21:35:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=PAeDzb6 1HMbXGaUhh1DELsvUfoaWiDEYaeJ+0qOJHaU=; b=aE8A+PBe/XkrSis63jWJVbN D1sdg/l56/ZvrVt27arjKJFAz6RuKFFSHcBdeUqcwC1SK5cwPvBBLUhEJmXnF/Dl WQTcm3N0i/zDP8eLpv9ySNDpUUzVrBu6SQ/0Tt+kapwww1VlII20TrF6ZEz0QutM fAShxxkdN5uWmBhIN1sXYnSuZ09491SHyNcihkJkDmWkr5ottUPe2weKvCMtBjvL jrMvHJKw9lH3S/+/zDHm+Vp+rwqgMUeeMeBgYJzqbsJyx78AzwKVTw2AM8J9u4hn xaQxvabzTbBMTM7GHnD4IDOsiYhbylXnalblfBbbYg/OdFD8RYRkDXKgvZ5IeHQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=PAeDzb 61HMbXGaUhh1DELsvUfoaWiDEYaeJ+0qOJHaU=; b=ZZ1z88HIz/nZnf8AFRCAa7 mmpgXJD9k7PDF3/wA8aTlp7Y7fijpXXJJb0s5wH6w/3qwg6kwiTrVKG1sRVHAvUf uVTRa9bFzRcJZx2132m9ww83YWU2A70S5PIKw7gBaWQNfNW8/f+DtM6tQruNlpJd KAoquFYrWCArVf3JmFJd4vA7JfFV2C0WiJfSNgtGvYQ8h3mT++Pu+jo4Keu07YHe 2WRkCChBKPF6txeexw9BYXOIsTC8fO0P5B46GIpLsZJHSJ8+Y84nS1VWoLkgbIaC VfDvHuLJxWjKu16IWdR2DSPgEVfvubxoLkxAymc9tjQYi2O0DxUFoQkIiXjgn80g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrfedugdeghecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepheeuhfdujedtieevkedvhfffgfelfeelhfefkeehhfekleek hfefueefveffjeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5D306AC0DD1; Mon, 15 Nov 2021 21:35:08 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1457-g307304a2db-fm-20211109.001-g307304a2 Mime-Version: 1.0 Message-Id: In-Reply-To: <41cf1339-3a65-d638-5056-927a69a59045@mildred.fr> References: <41cf1339-3a65-d638-5056-927a69a59045@mildred.fr> Date: Tue, 16 Nov 2021 13:35:07 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=f9c639aa3bd24809ba8cb69125d16dfe Archived-At: Subject: Re: [Jmap] Another question about updating a draft Email X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2021 02:35:15 -0000 --f9c639aa3bd24809ba8cb69125d16dfe Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable If you fetch the `headers` property you'll get a list of all headers in = the email (unparsed). You should be able to use that in the `Email/set` = to get the create a message with the sam set of headers (or you could mo= dify some first). Similarly the `bodyStructure` property to clone the ex= isting body structure. Then it's just a matter of including the metadata= properties to put it in the mailbox(es) you want/set any keywords. =E2=80=94Neil --f9c639aa3bd24809ba8cb69125d16dfe Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
If you fetch th= e headers property you'll get a list of all hea= ders in the email (unparsed). You should be able to use that in the Email/set to get the create a message with the sam = set of headers (or you could modify some first). Similarly the bodyStructure property to clone the existing body struct= ure. Then it's just a matter of including the metadata properties to put= it in the mailbox(es) you want/set any keywords.

=E2=80=94Neil
--f9c639aa3bd24809ba8cb69125d16dfe-- From nobody Wed Nov 17 02:15:18 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCCD3A0BC5; Wed, 17 Nov 2021 02:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=fastmailteam.com header.b=J3M31rSj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=m3oF9NDi 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 f-0MLGkF9Vwy; Wed, 17 Nov 2021 02:15:08 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4935D3A0BB4; Wed, 17 Nov 2021 02:15:08 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 113463201D60; Wed, 17 Nov 2021 05:15:05 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Wed, 17 Nov 2021 05:15:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:cc :subject:content-type; s=fm1; bh=byr0RpNYgl2/QwcFZ83bZgZQtrqKqCI r3uvzVd/YO2k=; b=J3M31rSjTiQrFdcIByLyN9Lce5rsKf5IIy1RPjk4FeI6Szb ouSMeRkpSa4snuNWqh9owy9FDBjViza8WOfu13p9PWnwF7LsyisSGCmwKUu+9sgc 70XbeOmnlrTLMwwcwWQ69VuBAn2547VbWy13himwuWax0ce1PiJsAc2VdR14DrGF lhMudUMQdyTPTv+dbxVmq7deJVHDCzYHSOZOuh/BdQta2UA+NS5RSoRxCe4Cpxic 03o5orX0qqtQqok27GjWyv2Donw85XGFgqg20pWzbQ0HSRw01zdZuhqtBEF7Kr5d H9hlh9QwqWUs4Hr0WimtBJ/GigA1hc41ynT1WUQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=byr0RpNYgl2/QwcFZ83bZgZQtrqKq CIr3uvzVd/YO2k=; b=m3oF9NDilqGcJRocGT0SGXhO/348ZzVa1mMhxAA09jBhe iGgvs/Y73N8oL7l1GKz/ZeFOPIJGKS94iAbmslNYcKnNx01QOPZ03bpr3Bn1VedZ 3fy1DkSThg4ntgiz6kKTjT3Anx0YVVWEBLZBSPTdydJVjmRlyS+eS28K3S9Ga1LK i2vimoY3C5dlrs36uiO9Ue92Fu6joZE53JpMUxj7CiiRWOzvgQx5DKoC6sspXdLn mrcXayxTigNeokV27oKv/p46lLkivlPqRGRWV5KXshQYk1eZ1CIjgyvUwMKkUk0X oDxeZey4zvF/dDWhPowdk4VZ507EYXvZFbl+2gu+Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrfeeggddtkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre erjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnheptdelfeegudettefhhe egtdelvefhudduhfeijeeghedtveeitddtuefggedvjeehnecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 78B27AC0DD1; Wed, 17 Nov 2021 05:15:03 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1457-g307304a2db-fm-20211109.001-g307304a2 Mime-Version: 1.0 Message-Id: <283e06dd-9bbe-41af-b9bf-9326ed91c131@dogfood.fastmail.com> Date: Wed, 17 Nov 2021 21:13:48 +1100 From: "Bron Gondwana" To: calsify@ietf.org, jmap@ietf.org Cc: art-ads@ietf.org Content-Type: multipart/alternative; boundary=328d2b25234445c49e408cfaf3f733fc Archived-At: Subject: [Jmap] PROPOSAL: recharter CALEXT and bring contact work and maintenance in charter X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2021 10:15:14 -0000 --328d2b25234445c49e408cfaf3f733fc Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi - both JMAP and CALEXT working groups, I'm emailing both groups, because this proposal includes taking the curr= ent jscontact work and moving it from JMAP to CALEXT where it will be ma= intained on an ongoing basis - along with the icalendar, vcard and jscal= endar specs as well as the caldav and carddav protocols. This new chart= er anticipates a long lived maintenance working group for all the contac= ts, calendars, and related data formats. The reasons for taking on the = VCARD and CardDAV work are pretty obvious: * Both have *DAV protocols. * Both have similar syntax model (VOBJECT) * Could move maintenance of JSContact over from JMAP where it doesn=E2=80= =99t really fit either. * Frequently implemented together. * Both handled by CalConnect as well, maintain the relationship. * Better than starting another group for contacts! We already have enou= gh groups. We also propose to close the 'calsify' mailing list and move all the sub= scribers to a list called 'calext@ietf.org' so that the mailing list nam= e matches the working group name, because this is an ongoing source of c= onfusion to new people. We have deliberately left the "out of scope" a little loose so that thin= gs like tasks or even file synchronization (which is needed for managed = attachments in calendars among other things) might come into scope - so = long as it's related to the documents that this group currently maintain= s and isn't better suited to another existing group, then it's a candida= te to be worked on in CALEXT. That's hopefully a good balance between t= oo much charter lawyering for things we should be working on, while not = opening the door to do arbitrary stuff here. The CALEXT chairs and our two ADs (Francesca and Murray) would love any = feedback you have on this charter text over the next couple of weeks bef= ore we formally propose this charter to the IESG. *Please send feedback= by December 1st (earlier is better so we can iterate)* Thanks, Bron. https://notes.ietf.org/calext-proposed-charter-2021 - pasted below Charter Text: The CALEXT working group is chartered to maintain and extend the specifi= cations for formats and protocols related to calendaring and contacts wi= thin the IETF, starting from the basis of: * CalDAV (RFC 4791) * iCalendar (RFC 5545) * iTIP (RFC 5546) * VCARD (RFC 6350) * CardDAV (RFC 6352) * JSCalendar (RFC 8984) * JSContact (draft-ietf-jmap-jscontact) and the many existing extensions and companion documents to these. This working group is envisaged to be long-running, and deal with a stea= dy slow flow of changes. Experience has shown that these specifications = are still seeing significant need for updates, as new use-cases are iden= tified and user requirements change. This working group will do the following: * maintain existing standards and proposed standards, processing errata= and refreshing them as required * evaluate and develop extensions to the existing standards to provide = for new use-cases where there is demand * publish informative documents describing existing implementations of = non-standard extensions, where vendors have already shipped an implement= ation and with which our protocols will need to interoperate The working group will work under the following parameters: * The extensions developed are expected to be backwards-compatible with= the existing standards. Incompatibilities must be identified, minimized= , and justified. * Any extensions to icalendar or jscalendar must include a representati= on in both formats, and define a robust mapping between them. * Any extensions to vcard or jscontact must include a representation in= both formats, and define a robust mapping between them. * All calendar extensions must examine their impact on the iTIP protoco= l (RFC 5546), and define any necessary extensions to iTIP to accommodate= such impact. The working group will maintain relationships with other working groups: * HTTPBIS and HTTPAPI: when extending the CalDAV or CardDAV protocols t= o ensure that changes are consistent with good http practices. * JMAP: when making updates to JSCalendar and JSContact to ensure that = the changes are compatible with the JMAP methods for managing data in th= ese formats. * EXTRA, DMARC and EMAILCORE: for changes related to iTIP delivery via = email. * Other working groups as appropriate, when their work interacts with o= urs. The following are out of scope for the working group: * Any attempt to develop non-Gregorian calendar systems/calculations. * Work which is in scope for any other ART area working group, and bett= er suited to that group. * Work which is unrelated to anything that this group is currently main= taining. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --328d2b25234445c49e408cfaf3f733fc Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi - both JMAP and CALEXT working groups,

I= 'm emailing both groups, because this proposal includes taking the curre= nt jscontact work and moving it from JMAP to CALEXT where it will be mai= ntained on an ongoing basis - along with the icalendar, vcard and jscale= ndar specs as well as the caldav and carddav protocols.  This new c= harter anticipates a long lived maintenance working group for all the co= ntacts, calendars, and related data formats.  The reasons for takin= g on the VCARD and CardDAV work are pretty obvious:
  • Both have *DAV protocols.
  • Both have simil= ar syntax model (VOBJECT)
  • Could move maintenance = of JSContact over from JMAP where it doesn=E2=80=99t really fit either.<= br>
  • Frequently implemented together.
  • Both handled by CalConnect as well, maintain the relationship.
  • Better than starting another group for contacts! W= e already have enough groups.
We also propose to close the 'calsify' mailing list and move all th= e subscribers to a list called 'calex= t@ietf.org' so that the mailing list name matches the working group = name, because this is an ongoing source of confusion to new people.
<= /div>

We have deliberately left the "out of scope" a little loose s= o that things like tasks or even file synchronization (which is needed f= or managed attachments in calendars among other things) might come into = scope - so long as it's related to the documents that this group current= ly maintains and isn't better suited to another existing group, then it'= s a candidate to be worked on in CALEXT.  That's hopefully a good b= alance between too much charter lawyering for things we should be workin= g on, while not opening the door to do arbitrary stuff here.

The CALEXT chairs and our two ADs (Francesca and Murray) would love = any feedback you have on this charter text over the next couple of weeks= before we formally propose this charter to the IESG.  Please se= nd feedback by December 1st (earlier is better so we can iterate)

Thanks,

Bron.

Charter Text:

The CALEXT working group is chartered to maintain and extend the specificat= ions for=20 formats and protocols related to calendaring and contacts within the=20 IETF, starting from the basis of:

  • CalDAV (RFC 4791)
  • iCalendar (RFC 5545)
  • iTIP (RFC 5546)
  • VCARD (RFC 6350)<= br>
  • CardDAV (RFC 6352)
  • JSCalendar = (RFC 8984)
  • JSContact (draft-ietf-jmap-jscontact)<= br>

and the many existing extensions and comp= anion documents to these.

This working group is envisaged to be long-running, and deal with a steady=20 slow flow of changes. Experience has shown that these specifications=20 are still seeing significant need for updates, as new use-cases are=20 identified and user requirements change.

This working group will do th= e following:

  • maintain existing= standards and proposed standards, processing errata and refreshing them= as required
  • evaluate and develop extensions to t= he existing standards to provide for new use-cases where there is demand=
  • publish informative=20 documents describing existing implementations of non-standard=20 extensions, where vendors have already shipped an implementation and=20 with which our protocols will need to interoperate

The working group will work under the following parameters:
  • The extensions=20 developed are expected to be backwards-compatible with the existing=20 standards. Incompatibilities must be identified, minimized, and=20 justified.
  • Any extensions to=20 icalendar or jscalendar must include a representation in both formats,=20 and define a robust mapping between them.
  • Any ext= ensions to vcard or jscontact must include a representation in both form= ats, and define a robust mapping between them.
  • Al= l calendar=20 extensions must examine their impact on the iTIP protocol (RFC 5546),=20 and define any necessary extensions to iTIP to accommodate such impact.<= br>

The working group will maintain r= elationships with other working groups:

  • HTTPBIS and HTTPAPI:=20 when extending the CalDAV or CardDAV protocols to ensure that changes=20 are consistent with good http practices.
  • JMAP: wh= en making=20 updates to JSCalendar and JSContact to ensure that the changes are=20 compatible with the JMAP methods for managing data in these formats.
    =
  • EXTRA, DMARC and EMAILCORE: for changes related to i= TIP delivery via email.
  • Other working groups as a= ppropriate, when their work interacts with ours.

The f= ollowing are out of scope for the working group:

  • Any attempt to develop non-Gregorian calendar systems= /calculations.
  • Work which is in scope for any oth= er ART area working group, and better suited to that group.
  • Work which is unrelated to anything that this group is curren= tly maintaining.

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


= --328d2b25234445c49e408cfaf3f733fc-- From nobody Wed Nov 17 02:29:19 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F99B3A0BD5; Wed, 17 Nov 2021 02:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 jrAmofsByP4x; Wed, 17 Nov 2021 02:29:08 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 166B43A0C50; Wed, 17 Nov 2021 02:28:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1637144935; d=isode.com; s=june2016; i=@isode.com; bh=O4UzBjqDl3FFcSa07Rb1YU2kbIHY0kdtkIiubpDLGBk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=MSMjPIcmLItuGSNe74uMkBY2HrRLNBLEsPSTbc0IPiuA3UKJDtQYdnSmPWqZ13p8w7xzNn TqQp9VtkevmZfa746PDu0MxwVQJjC3OOwYcD2xDYbUXWafl0JgYCwdR1KwsADaJjqVzNad QhWaxtECjPfiV1eUOyTPOkrDCFkGCYI=; Received: from smtpclient.apple ((unknown) [94.3.228.58]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 17 Nov 2021 10:28:54 +0000 X-SMTP-Protocol-Errors: NORDNS From: Alexey Melnikov In-Reply-To: <283e06dd-9bbe-41af-b9bf-9326ed91c131@dogfood.fastmail.com> Date: Wed, 17 Nov 2021 10:28:52 +0000 Cc: calsify@ietf.org, jmap@ietf.org, art-ads@ietf.org Message-Id: <93F6D4CA-ED71-4A86-8156-14C2339E5134@isode.com> References: <283e06dd-9bbe-41af-b9bf-9326ed91c131@dogfood.fastmail.com> To: Bron Gondwana X-Mailer: iPhone Mail (18H17) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-D48CF21D-39F4-467D-977A-3C39BD28A1B1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jmap] [calsify] PROPOSAL: recharter CALEXT and bring contact work and maintenance in charter X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2021 10:29:13 -0000 --Apple-Mail-D48CF21D-39F4-467D-977A-3C39BD28A1B1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Bron, > On 17 Nov 2021, at 10:15, Bron Gondwana wrote: >=20 > We also propose to close the 'calsify' mailing list and move all the subsc= ribers to a list called 'calext@ietf.org' so that the mailing list name matc= hes the working group name, because this is an ongoing > source of confusion to new people. May I suggest that instead of the above you keep calsify@ietf.org as an alia= s for calext@ietf.org, as it existed for quite a long time. The rest of the m= ailing list change proposal makes sense. Best Regards, Alexey= --Apple-Mail-D48CF21D-39F4-467D-977A-3C39BD28A1B1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Bron,

On 17 Nov 2021, at 10:15, Bron Gondwana <brong@fastmailteam.com> wrote:

We also propose to close the 'calsify' mailing list and move all the subscribers to a list called 'calext@ietf.org' so that the mailing list name matches the working group name, because this is an ongoing
source of confusion to new people.

May I suggest that instead of the above you keep calsify@ietf.org as an alias for calext@ietf.org, as it existed for quite a long time. The rest of the mailing list change proposal makes sense.

Best Regards,
Alexey
--Apple-Mail-D48CF21D-39F4-467D-977A-3C39BD28A1B1-- From nobody Wed Nov 17 02:34:01 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD183A0BDF; Wed, 17 Nov 2021 02:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 V8Z6ikpyyQdH; Wed, 17 Nov 2021 02:33:51 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 114AE3A0BDC; Wed, 17 Nov 2021 02:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1637145229; d=isode.com; s=june2016; i=@isode.com; bh=5qXEar/nmI5RC95zHjstleKn5s/7TyK/yVBo5BBh8WM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=a51gHaXWVnbAtyJGOY5UQaeUhS8/8NRJUu+r+K6pv+A1olEOAqeuUsre/9R/dSKt/UjpWl I01cg35nHvlSEQdB1pwRLxSSe3877olrZPVg2aKKfag6m2i94IJ+XZXonWlkLuGLhqogJC qf8SYTT3IqJqdTctXPchSbMkPFp3zD8=; Received: from smtpclient.apple ((unknown) [94.3.228.58]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 17 Nov 2021 10:33:48 +0000 X-SMTP-Protocol-Errors: NORDNS From: Alexey Melnikov In-Reply-To: <283e06dd-9bbe-41af-b9bf-9326ed91c131@dogfood.fastmail.com> Date: Wed, 17 Nov 2021 10:33:48 +0000 Cc: calsify@ietf.org, jmap@ietf.org, art-ads@ietf.org Message-Id: <1EDEAA9F-D41D-48AE-A145-78A21072B9A5@isode.com> References: <283e06dd-9bbe-41af-b9bf-9326ed91c131@dogfood.fastmail.com> To: Bron Gondwana X-Mailer: iPhone Mail (18H17) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] [calsify] PROPOSAL: recharter CALEXT and bring contact work and maintenance in charter X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2021 10:33:56 -0000 Hi all, The charter looks fine to me. It is a bit broad in scope, but if IESG is fin= e with it, than that is fine with me :-). Best Regards, Alexey= From nobody Wed Nov 17 07:11:33 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3E03A0D6D; Wed, 17 Nov 2021 07:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 JLJexMlfTrVQ; Wed, 17 Nov 2021 07:11:18 -0800 (PST) Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam07on2057.outbound.protection.outlook.com [40.107.212.57]) (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 A14CE3A0D6C; Wed, 17 Nov 2021 07:11:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aCb4gFyJl7oWfA1aB3WRfV2M0r/emOqIZPWWuFXhQdxy2pKcbcYtnCOSzUfhI3QvLMkoDhtppVD5LkwwR8MlgYzMaAElmG2Kg3S91v4eo92IGJVMTaWGUbGw83HmkMojem6gJvb0sfQsK/ROdLDkglFtvGM4/jWRIeyQPvvc9Yh7LL+skXirlLTmK1C9c2TZtOntm+WSKKBIkogRBl7h7AK6BWFhZAxXT+1oGDK7UnHy/hQsGmoBeoi3oTlCULNtiWG04y9LPystC+PdcLVSxtPP6bYxmRk2DnXVa7Rfk2Ffgv35ImaEJqBMpcE1t56WfD62GvER6toRR7O7Maj3fQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZD8vT451fH7Rqp9tzdK0sN5SonealrlT3ZKVwX5Ulqg=; b=FK936CFOBTC+N+KACF62+WZK2oQvKdNfkgTlQqK0iaWt63eHcfi+m2cB//I2mcK9uud0JfURCZ43ZsbfBf28KNt8u/t3FCIyVD7zLfeJr4zczsO+H0HT9lRILDFhEqtugI2Pz3ZZPRPvUeIpMuKNrwd/FE0nsxSsSdMKUG11Sb0WlBr7cRkck00DgFFeZ9BE8pqqXOUSBz8Z0Sv61KuiABjpupZhaWYqL2KctIJRKUq1VbW/bDsuTksd1kuPmDX7eKjB8cm4M+nZsCvuxMXquGRlTcdKDOlMyP2BdePq96YtKqlg41XZ3uxcQnmp/yy5cyVWaBv8RMzF/AXVmdEQwQ== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZD8vT451fH7Rqp9tzdK0sN5SonealrlT3ZKVwX5Ulqg=; b=tXcANukH/u7ndRvvPGVQNaCraUXQxBupkIl9gl0B9nnO3KI13BjS76OnWbWwL93ItPi/E4I58Lyswp0DKab9c5/hT8PBX6ONqVTLSiE+TtQx1LTl8iAH76fULzVxHFC9Mp1Lczy0DnZXydRgkhQ/+gU84KwiPPLDrkETWw6tGIs= Received: from DM6PR15MB3689.namprd15.prod.outlook.com (2603:10b6:5:1fb::27) by DM5PR15MB1786.namprd15.prod.outlook.com (2603:10b6:4:51::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.26; Wed, 17 Nov 2021 15:11:16 +0000 Received: from DM6PR15MB3689.namprd15.prod.outlook.com ([fe80::bde9:d912:2fb6:3539]) by DM6PR15MB3689.namprd15.prod.outlook.com ([fe80::bde9:d912:2fb6:3539%5]) with mapi id 15.20.4690.027; Wed, 17 Nov 2021 15:11:16 +0000 From: Daniel Migault To: Alexey Melnikov , Bron Gondwana CC: "jmap@ietf.org" , "art-ads@ietf.org" , "calsify@ietf.org" Thread-Topic: [calsify] PROPOSAL: recharter CALEXT and bring contact work and maintenance in charter Thread-Index: AQHX25wORQDCyxpGpUmTElIatREp66wHhf0AgABK5gA= Date: Wed, 17 Nov 2021 15:11:16 +0000 Message-ID: References: <283e06dd-9bbe-41af-b9bf-9326ed91c131@dogfood.fastmail.com> <1EDEAA9F-D41D-48AE-A145-78A21072B9A5@isode.com> In-Reply-To: <1EDEAA9F-D41D-48AE-A145-78A21072B9A5@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ea853495-b052-45bd-72eb-08d9a9dc808a x-ms-traffictypediagnostic: DM5PR15MB1786: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gMkHWNQhgGPL3FD5SrYV9c2YEQjhZ7ci6XqOkXxXc6nog4qpwHprPkK3jhCRmlxJ/AQrvLfQcjfUGj+ZDkVWb55gkdD8uuOnpLPHU6DXz1bnJlm58Jsoo9rlzUxfVvJc//C2Or76nlhtobOyWBDfAAAoGZsFjdkXCs4i/Vy9NQGmf3M1Ff+LAx3xNcMnofJK9oJeDkL8tIEC5vq88x+pRik28cqz+PWGMZN5hrqh3596w+FqJDb+Vw7tavW5uD9SLUbpNUjhDcdR3w+wKadiyC6ikmN8VVXBTVjarFdhrgz1MISxR8GYQMsQJXQLHssPRYOH5X131S5FdfwmGtlmR+XNI6UxhvPIU4sQLoSSeXM+BYT18xPGlXN/pGeGIRgGoLvk9NgDeNzHA2eQrT8LdL/Wn6T/97T46BpsXomn9RdOMKG41qHYp9RrV5LGk+U2LJTKUk7BwVa+zrz/tpPRZYOuOPtK1uDu95TeVHl0aVrevrGlDH7sfNQ0MOre3tSMpU0T/K/pQyuZ7Np+w/X/OheGvMSfemAwXcfLI5Xz8NsFRv/fIITh4VmCxdzHO/UN6ZVtnzl97ut8BPF+L1A8DCxCYmmBFcasNkHxdyZQutCuQwZMZQwP0ZqLyHfe6lqqWp44o8JrRgNcEpeA0Q3C9txPtCJB96PA9JRO+QzB/bHlT9hQuQ/DI1wB4FBKmxeeJ5B9PIfr0bM+K4UUvuIErfhm2WHXYsCzIfdt+ykmccqtEIpzab+qcsm/VlT2kwqTd2WWJ23nUtdhIgwRqtWHYKG8fayHYqzzkRoCbG6crhycsZst9R4wNvJu+Qg7K12o x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR15MB3689.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(122000001)(86362001)(38100700002)(71200400001)(508600001)(316002)(52536014)(186003)(9686003)(38070700005)(966005)(5660300002)(110136005)(54906003)(55016002)(82960400001)(8676002)(76116006)(6506007)(53546011)(64756008)(66476007)(66556008)(4326008)(83380400001)(8936002)(66446008)(33656002)(7696005)(44832011)(2906002)(26005)(66946007)(200143007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?K3RhY01XeWw4QUZGMnQ4RkV4WVZyV0dnSGVpVEZ6T1pSSmFjdVZjYVZjdFpW?= =?utf-8?B?L0xjbEpHdW1XeUhyemV0UkI5R2RuNXZBYXNTMTZ5Vm9FSlczMFZMRkpObVNS?= =?utf-8?B?RzFTWnhKZFB3d2N6OWtOUmRwbnZobEQzWSt6aTJobmc4anI2eng3alk1MzI4?= =?utf-8?B?UVVRUmdDOWRrams3Mm55b0xuZVFJMXB2ZnZ5MzkyR2V6MXp6Nk5saUc0L08y?= =?utf-8?B?L1VvZHFCdlhNZEg5ellyN1lYL3lMMjFieFJaT0Z6eEliTEVoSEthQXowdEtt?= =?utf-8?B?VjE0WnJEN0JxdTYvV0RreEpzSlFFMll0TG5YMGczc0NTdEcxek1NMEtyeElh?= =?utf-8?B?Qzh1YnMyRGJuUklDVjk5c1hQZ2N4Uk1MelROT1FUWUZhOFM2ek9sZDQ5Qlhm?= =?utf-8?B?UWR5eElpRmV6UjdNYnZEc1BpRjFxVnBrV3FjNVF3Y3h3NThDR1g2enh5Z29s?= =?utf-8?B?V0pJZThOVElUN3dWdnpNdk53MW9ZUUozR0E2bFpxYXNpQWExYWV3ZHp1TVBY?= =?utf-8?B?eWxaZTM3aXVNejJmNmUvVXYwSVluMExJQnBYNHRvbkV4M2s0djJFdy82cG9t?= =?utf-8?B?OE53MTBQZ1RLeXZKTm9OSVliZ2ZjV0tnRk9FaXY5OTBDbEVSMjd3dFViY3lS?= =?utf-8?B?RGpzNnROL2FVeWtPRUtTT21FUXU3MW9XaloxYjVlS2VpSmIyc2lXTU9aYnM4?= =?utf-8?B?NVhwcGN2bE1jZHBUVUlrUXZkRGlSZE1PWkVyemdFcDlLMitlMnFyb1dvUW1R?= =?utf-8?B?cUJEVVA0UVFVa1lldU5wbXBRZnBIdjRQanFiakRjUG1MN3IwY0tuMXpOODNs?= =?utf-8?B?ckpqWm9pamJaWnlwVzljQ3lHZzFhZytBWHBBNHFqK25Fc0M3S2YzOVh1ZG9E?= =?utf-8?B?eGdLWnhxM3JScWVGaTVLdXgzM1RNbzFqMVZGTWlId0J4bEtiRnVqeG4xREMy?= =?utf-8?B?L0svOFBQR1lreDZ4YndvQVl2T1hrSHdlWmR0L2h3OThuNDYvenZoOEREVysv?= =?utf-8?B?WGZISXBpSzVMa2RiazhzVEVXZ0tmVDdmbjNlYUdGcldGUmE0NkZGb2ZxWE5Y?= =?utf-8?B?Unh3QVk1Z21xdzFwSTdJOVRrbXF3YlUvU3Fyd04vN3RhYkNmVTZRbStQdGJM?= =?utf-8?B?eEV6TEJwMnN0RGVCdjJrM210ZDdxd2g2VDlGaGR2djA1T0V1eXNzS1dXMlJG?= =?utf-8?B?VWU4Kzg1NktNOFNLZXFTVmJ0dFNkTnhRUTVEWCsvaUhJOTVoWTVUZ29PMlov?= =?utf-8?B?cmRLTzJodjBkMllMRXNCcjlzaDdhNzUzcXZEcjJOVnRNOGsyU1k0c0dkL3I2?= =?utf-8?B?RXF2NXJnRWV3OFVibEUxYzBZNTJmckp5M3pYNjFjVjBOUFZwc3cxV3o3VFA2?= =?utf-8?B?TDZDaStUNEhzdXBGS3B0Qi9JcklnRndYcGl5akhjQTdGdlBSc0kwTXZqNDBx?= =?utf-8?B?bXdhdGx3d3N4ZTV1cmFDZ3Y0ZjVCMHVkaDlPTGFOZWtwN0VMTm55RTNKeTl3?= =?utf-8?B?bzA1Y0NWSysyMTRtazFKYjFtNDV4WVdZTzkrWlhpcnJKcElWc3BQK0dPeEE5?= =?utf-8?B?cXVFeUtoeG04SVpXN3pXTGxhRW1Xd3o1SUZlelkxczJPQWFPSkp3ZGlkWFdL?= =?utf-8?B?T21TTkxMZ0RnTjdCY3dhOS9KV1pUY2Y0NEJYUXpFeGFaNkNZVzlFck1Dbk8v?= =?utf-8?B?R0ZNb1g4Y2JtejhraWIzTGtxWWZaTDFuNTFHdXBoVlgrYzBUbTRhS2ErM21P?= =?utf-8?B?ZzYwMGozYnk5Z1pSMEt6WEtzM243M2JSYXJvU2VXSVBJd2x2Q3oxdEVqbnBM?= =?utf-8?B?bkZObmlqTExsYkkyNlFjcmVqU2RmQ3NFTkVKNk85UVJ3by9QNWhyVFVUT2J2?= =?utf-8?B?cmtyNEFqVTlkZERkY1FXTkk5WXpCb3NRV3VoakdIL0NqRkc0M3QwbXRCeFc0?= =?utf-8?B?NWd0VjNQQnJEbmhNRnNJaEhoTm9qOUt4TzVlcnlEZVBGSXRoMmhSSGdSakRv?= =?utf-8?B?MFJKUnF3OEZhQmdGOE0rQlk0d3VkbGU4RjZKWW16bFRkTkNoWk1BWFhvS1ZU?= =?utf-8?B?aExQYm9sUUF5bVFsRXBjb0FzQ0Y4aURSTUJEb0JXQmx1VWV4akhmUUFMc2Zs?= =?utf-8?B?R0YrS040U0g2SGQzSE9iR2ZmU1cyeFI3eXV3aDZuVjh4MmE2NG9CcmdYK2JX?= =?utf-8?B?QmtEM29vOTh6VWkrVWVPV1NhTHBWSzB1VU12WGFaajh5MXVxMlMyd0dkTUQ1?= =?utf-8?B?WDJtV1lBdUJaa2FVUHFJWklKL2R3PT0=?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR15MB3689.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ea853495-b052-45bd-72eb-08d9a9dc808a X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2021 15:11:16.2613 (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: 3n3RNnVhUcQ3N02i6MyvnMdLPCkdLAhzVFK1fUdRIVgwgPg+z2oEUn6XKCcct3sXqneXZX6WccE6jjYDm1HY11gleAe50NHvw2wo4kYFg0o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1786 Archived-At: Subject: Re: [Jmap] [calsify] PROPOSAL: recharter CALEXT and bring contact work and maintenance in charter X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2021 15:11:24 -0000 SSB0aGluayB0aGUgYnJvYWQgc2NvcGUgYWN0dWFsbHkgZml0cyB0aGUgY3VycmVudCBzdGF0ZSBv ZiB0aGUgV0cgYXMgaXQgaXMgbm93LiBNb3JlIHNwZWNpZmljYWxseSwgdGhlIHdvcmtpbmcgZ3Jv dXAgaXMgdmVyeSBjb25zZW5zdWFsIGluIHBpY2tpbmcgaXRzIHRvcGljcyBhbmQgd2UgbmVlZCBz dWNoIGZsZXhpYmlsaXR5IHRvIHN5bmNoIHdpdGggQ2FsY29ubmVjdC4gSSBiZWxpZXZlIHRoYXQg cmFpc2luZyBjaGFydGVyIGRpc2N1c3Npb25zIGZvciBhbnkgdG9waWMgd2lsbCByZXN1bHQgaW4g YSBsZXNzIGFjdGl2ZSBXRy4gDQpPZiBjb3Vyc2UgdGhlIHNjb3BlIG1pZ2h0IGJlIHJldmlzaXRl ZCBpbiB0aGUgZnV0dXJlIHdoZW4gY2FsZXh0IHdpbGwgaGF2ZSB0b28gbWFueSBwYXJhbGxlbGVk IGRpc2N1c3Npb25zLiBJIGd1ZXNzIHdlIHN0aWxsIG5lZWQgYSBmZXcgbW9udGhzIHRvIGdldCB0 aGVyZSDwn5iJLiBCdXQgeWVzIHRoYXQgaXMgc29tZXRoaW5nIHdlIGhhdmUgaW4gbWluZCwgdGhh dCB3ZSBtYXkgbmVlZCB0byByZXZpc2l0IHRoZSBjaGFydGVyIGF0IHNvbWUgcG9pbnRzLg0KDQpZ b3VycywgDQpEYW5pZWwNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNh bHNpZnkgPGNhbHNpZnktYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEFsZXhleSBNZWxu aWtvdg0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNywgMjAyMSA1OjM0IEFNDQpUbzogQnJv biBHb25kd2FuYSA8YnJvbmdAZmFzdG1haWx0ZWFtLmNvbT4NCkNjOiBqbWFwQGlldGYub3JnOyBh cnQtYWRzQGlldGYub3JnOyBjYWxzaWZ5QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NhbHNpZnld IFBST1BPU0FMOiByZWNoYXJ0ZXIgQ0FMRVhUIGFuZCBicmluZyBjb250YWN0IHdvcmsgYW5kIG1h aW50ZW5hbmNlIGluIGNoYXJ0ZXINCg0KSGkgYWxsLA0KDQpUaGUgY2hhcnRlciBsb29rcyBmaW5l IHRvIG1lLiBJdCBpcyBhIGJpdCBicm9hZCBpbiBzY29wZSwgYnV0IGlmIElFU0cgaXMgZmluZSB3 aXRoIGl0LCB0aGFuIHRoYXQgaXMgZmluZSB3aXRoIG1lIDotKS4NCg0KQmVzdCBSZWdhcmRzLA0K QWxleGV5DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Y2Fsc2lmeSBtYWlsaW5nIGxpc3QNCmNhbHNpZnlAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2Fsc2lmeQ0K From nobody Thu Nov 18 11:21:33 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42C23A09E5; Thu, 18 Nov 2021 11:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 b6tl9qE63-o7; Thu, 18 Nov 2021 11:21:24 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 63A9B3A09E1; Thu, 18 Nov 2021 11:21:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1637263277; d=isode.com; s=june2016; i=@isode.com; bh=+FBajyf7C+mNWjUfKEkQ0V+A1kRVJUPdFI/Ms9yVXzM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=S8P6nKL5nJ8GzAebeSk8JJ0Q+C5mIwGfvbaZPoIgyzHdWpmGVbKUIpiYqF0XLAi7O625vi gSpQyT7RuLtLRt38IrotjgKYM0yv/B2gkXhll2n35ypdbHpgYF7dce5YQzQX6i4sGrVs1P KorpTDenl8LX2sp5TPgGlGMYCiMOkaU=; Received: from [192.168.0.5] ((unknown) [94.3.228.58]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 18 Nov 2021 19:21:17 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <1eec30c5-eca1-6b16-91f1-22a36648b01f@isode.com> Date: Thu, 18 Nov 2021 19:21:16 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 From: Alexey Melnikov To: Roman Danyliw , The IESG Cc: jmap@ietf.org, draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, brong@fastmailteam.com References: <163460214370.19974.15716909300314956596@ietfa.amsl.com> <002266b6-50e4-846b-e325-86721eea8769@isode.com> In-Reply-To: <002266b6-50e4-846b-e325-86721eea8769@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Roman Danyliw's No Objection on draft-ietf-jmap-smime-09: (with COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2021 19:21:28 -0000 Hi Roman, On 21/10/2021 15:16, Alexey Melnikov wrote: > Hi Roman, > > On 19/10/2021 01:09, Roman Danyliw via Datatracker wrote: >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> ** Section 4.1.=C2=A0=C2=A0 Recommend sticking to verification practices = by=20 >> citation when >> defining the semantics of =E2=80=9CsmimeStatus=E2=80=9D >> >> OLD >> signed/verified:=C2=A0 S/MIME signed message and the sender's signature >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 was successfully verified, the sende= r matches the From header >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 field, and the sender's certificate = (and the certificate=20 >> chain) is >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 trusted for signing. >> >> =C2=A0=C2=A0=C2=A0 signed/failed:=C2=A0 S/MIME signed message, but the si= gnature failed to >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 verify. >> >> NEW >> signed/verified:=C2=A0 S/MIME signed message and the sender's signature w= as >> successfully verified per the verification process in [RFC8551] and=20 >> [RFC8550]. >> >> signed/failed:=C2=A0 S/MIME signed message, but the signature failed=20 >> to=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 verify >> per the processes in [RFC8551] and [RFC8550]. > [RFC8551] and [RFC8550] are already listed earlier on when smimeStatus=20 > is described in more general terms, so implementing your suggestion=20 > becomes less urgent. Let me think a bit more about the best way of=20 > updating the draft to reflect this comment. This should be clarified in -11. Best Regards, Alexey From nobody Thu Nov 18 11:27:27 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E773A09F6; Thu, 18 Nov 2021 11:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 KMECe8yVoswP; Thu, 18 Nov 2021 11:27:00 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id DE3493A09F5; Thu, 18 Nov 2021 11:26:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1637263616; d=isode.com; s=june2016; i=@isode.com; bh=b5C+4HYqWCaMaYSS7Lzn6ZHJAHXa2zO3RPvJaZLcxqA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=nX4LVIZW6mf6D416GaavQ72JBuZcr0Lwsw5fyVfvG3UtcOZC5sMM3EMuqYdSnFS8Ea3w6f Xf8eXeg73mv/s2d91GaYi73ha9nur2B8KcFyY3AAgZIwgYp1KoJ9G+8hk8VNs2sImgIS2F jzqWDwbRoOSAvD3NTRUqDkFpNZNHUXA=; Received: from [192.168.0.5] ((unknown) [94.3.228.58]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 18 Nov 2021 19:26:56 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <7f654570-98c6-1866-bcaf-e997f764c543@isode.com> Date: Thu, 18 Nov 2021 19:26:55 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 From: Alexey Melnikov To: Robert Wilton , The IESG Cc: jmap@ietf.org, draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, brong@fastmailteam.com References: <163472256651.12981.413656253938594590@ietfa.amsl.com> In-Reply-To: <163472256651.12981.413656253938594590@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jmap] Robert Wilton's No Objection on draft-ietf-jmap-smime-09: (with COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2021 19:27:05 -0000 Hi Robert, On 20/10/2021 10:36, Robert Wilton via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > I have to confess that I don't know IMAP, and hence my question may have an > obvious answer, but it is unclear to me whether a server supporting the > smimeverify capability implies that it SHOULD also support checking the S/MIME > signature at delivery time? If this is the case, should this be clarified, > perhaps in section 3? The intent was to require support of all attributes specified in the draft. > I.e., section 3 states: > Servers supporting > _this_ specification MUST add a property called > "urn:ietf:params:jmap:smimeverify" to the capabilities object. > > E.g., section 4.1 states: > > signed: S/MIME signed message, but the signature was not yet > verified. Some servers might not attempt to verify a signature > until a particular message is requested by the client. JMAP > servers compliant with this document SHOULD return "signed/ > verified" or "signed/failed" instead of this signature status. > > These two statements seem to imply that a server returning the smimeverify > capability SHOULD also support checking the S/MIME signature at delivery > because they SHOULD either return signed/verified or signed/failed for a > request for smimeStatusAtDelivery, which at least implies that they have > previously checked the signature when it was delivered. Is that was is > intended? I clarified in -11 that "smimeStatusAtDelivery" doesn't actually need to be calculated at delivery. Best Regards, Alexey From nobody Thu Nov 18 11:28:16 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC12C3A09F4; Thu, 18 Nov 2021 11:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 RLaDuo5u20Qi; Thu, 18 Nov 2021 11:28:10 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7F63A09F5; Thu, 18 Nov 2021 11:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1637263688; d=isode.com; s=june2016; i=@isode.com; bh=64xXPeHWv/pWl3BElM0hjJk7hLk4EUVtLJElPwPO+e8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=U3KiPOqmRGcfDRLTCs7MKr2vBgTIRPbWtz47p/BBOvQwyTkibnffUA4VC0lE2xy+9dZ8sQ EFrFYtj0fS8W0pDO4U+Gg3nuQdNXDxUvwo0olQEI0hcSxoaJuR1Lg4RJquZJqVm4NS6aJb 6D/qLi8way1dcfaZAXM7DQwwBag/0Qo=; Received: from [192.168.0.5] ((unknown) [94.3.228.58]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 18 Nov 2021 19:28:08 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <8f16775d-824f-6214-e2c9-25632c2236a5@isode.com> Date: Thu, 18 Nov 2021 19:28:07 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 From: Alexey Melnikov To: Erik Kline , The IESG Cc: jmap@ietf.org, draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, brong@fastmailteam.com References: <163453890907.1076.7397961358484844853@ietfa.amsl.com> <9fd6316b-add5-0100-f975-2f0af605d20c@isode.com> In-Reply-To: <9fd6316b-add5-0100-f975-2f0af605d20c@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Erik Kline's No Objection on draft-ietf-jmap-smime-09: (with COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2021 19:28:15 -0000 Hi Erik, On 18/10/2021 15:20, Alexey Melnikov wrote: > Hi Erik, > > Thank you for your comments. > > On 18/10/2021 07:35, Erik Kline via Datatracker wrote: >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Just some random questions that came to mind... >> >> [S4.2, question] >> >> * Is there any benefit to/reason to consider some boolean like >> =C2=A0=C2=A0 "hasVerifiedAtDeliverySmime"? > Yes, it might be useful to know whether a message (or a group of=20 > messages) was valid (S/MIME signed/verified) at delivery time. I've added this to about to be published -11. Best Regards, Alexey From nobody Thu Nov 18 11:29:40 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4B03A09F4; Thu, 18 Nov 2021 11:29:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163726377805.25481.9069755452446236188@ietfa.amsl.com> Date: Thu, 18 Nov 2021 11:29:38 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-smime-11.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2021 19:29:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : S/MIME signature verification extension to JMAP Author : Alexey Melnikov Filename : draft-ietf-jmap-smime-11.txt Pages : 10 Date : 2021-11-18 Abstract: This document specifies an extension to JMAP for Mail (RFC 8621) for returning S/MIME signature verification status. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-jmap-smime-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-smime-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 22 05:24:36 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3F13A0975; Mon, 22 Nov 2021 05:24:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163758747079.13426.14914894202032816857@ietfa.amsl.com> Date: Mon, 22 Nov 2021 05:24:30 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-blob-07.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 13:24:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP Blob management extension Author : Bron Gondwana Filename : draft-ietf-jmap-blob-07.txt Pages : 26 Date : 2021-11-22 Abstract: The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data via HTTP POST and GET on defined endpoint. This binary data is called a "Blob". This extension adds additional ways to create and access Blobs, by making inline method calls within a standard JMAP request. This extension also adds a reverse lookup mechanism to discover where blobs are referenced within other data types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-blob/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-jmap-blob-07.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-blob-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 22 05:27:30 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E478F3A09A5 for ; Mon, 22 Nov 2021 05:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=p572nU4s; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CbMfFklO 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 7gUvrXZd25h3 for ; Mon, 22 Nov 2021 05:27:23 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DF93A099E for ; Mon, 22 Nov 2021 05:27:23 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DAF285C020E; Mon, 22 Nov 2021 08:27:22 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Mon, 22 Nov 2021 08:27:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:cc :subject:content-type; s=fm1; bh=EH6905OnpKUYlYZglscyllH6DZpUqLB YOZLLd1q523g=; b=p572nU4sATF2cPolW4xQTmjJZCOjGjBiFh64Pgau/PvRCXz xn0Dc7JAH2YV+DSP7AoPu+8/P/VNYCW6rFTceYh+e4mDBdMLxsgwcWfay/4CRBXv 4LjuMyL2DzS80rGgLgwJTixtCD7fFwmgRH+JxAuP7j6dfen3sSFV6SZTc0hQ2Bwt gTQ9fCo7I8In7EWCYkqAkf1Rlh70BVGP2/DrZHgN3h8uQ49CO7YJ/8VXHVGl9Qer 565xhXoYbbt6nHoLv/UEwRz4iN8NuZJWj9+3Rf/S/zjxOG7s5pQMhfAUWJqyHDME M8RXXYknfcIOMsN000Irb+OEvyXyAjMRoEyCZcQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=EH6905OnpKUYlYZglscyllH6DZpUq LBYOZLLd1q523g=; b=CbMfFklOzDxXNDUrclMJvlQpTEcd4VHIMT2a5m5pbJY1J ORdxkypdLs65JeDDIv2TjkkIklYN98wWefd4nflLskwaX5t+5yHTBnFdmJENuGsx IYQ85DwolWZx325h69u7sn/9MsLS/71D4cb6Z/0Tbe1Pyj3t5jMdKw+7RjbSG81z SyQOUSoD6VnZS9tRNvzmVKNLHWmKlK/y/3Oj2WdAahAO9qUOFUVUe2BcSi8OIpii P7xeq7K5jLd+afL9QkTLjy0XEZ/k8CzfXuRUz1/60ODRW9JNPIABAUZdIxwvTAHz lcA3K47JsxsLokUvAvsC0CJomisgwUdib8l8bm0Jw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrgeeggdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhnucfi ohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenuc ggtffrrghtthgvrhhnpefhjeehkeejkeehveeutdejteeihffffeduiedttdejhfelteev ueehudeltdeuffenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhl thgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5ED8BAC03DB; Mon, 22 Nov 2021 08:27:22 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1457-g307304a2db-fm-20211109.001-g307304a2 Mime-Version: 1.0 x-forwarded-message-id: <163758747090.13426.6845616644704126155@ietfa.amsl.com> Message-Id: Date: Tue, 23 Nov 2021 00:27:02 +1100 From: "Bron Gondwana" To: jmap@ietf.org Cc: "Jim Fenton" Content-Type: multipart/alternative; boundary=e460c7a64c9448e2b129b65ec065b437 Archived-At: Subject: [Jmap] Fwd: New Version Notification for draft-ietf-jmap-blob-07.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 13:27:29 -0000 --e460c7a64c9448e2b129b65ec065b437 Content-Type: text/plain Hi Jim, I believe this is now ready for working group last call. I've added another example showing how isTruncated and isEncodingProblem work, as well as tidying up the headings around examples. I expect that two weeks would be a good time for the WGLC on this, I don't anticipate major reviews, as not much has changed since the last set of reviews, and that feedback has been merged in. Thanks, Bron. ----- Original message ----- From: internet-drafts@ietf.org To: Bron Gondwana Subject: New Version Notification for draft-ietf-jmap-blob-07.txt Date: Tuesday, November 23, 2021 00:24 A new version of I-D, draft-ietf-jmap-blob-07.txt has been successfully submitted by Bron Gondwana and posted to the IETF repository. Name: draft-ietf-jmap-blob Revision: 07 Title: JMAP Blob management extension Document date: 2021-11-22 Group: jmap Pages: 26 URL: https://www.ietf.org/archive/id/draft-ietf-jmap-blob-07.txt Status: https://datatracker.ietf.org/doc/draft-ietf-jmap-blob/ Html: https://www.ietf.org/archive/id/draft-ietf-jmap-blob-07.html Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-jmap-blob Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-blob-07 Abstract: The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data via HTTP POST and GET on defined endpoint. This binary data is called a "Blob". This extension adds additional ways to create and access Blobs, by making inline method calls within a standard JMAP request. This extension also adds a reverse lookup mechanism to discover where blobs are referenced within other data types. The IETF Secretariat -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --e460c7a64c9448e2b129b65ec065b437 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Jim, I believe this is now ready for working group last= call.  I've added another example showing how isTruncated and isEn= codingProblem work, as well as tidying up the headings around examples.<= br>

I expect that two weeks would be a good time for the WGLC= on this, I don't anticipate major reviews, as not much has changed sinc= e the last set of reviews, and that feedback has been merged in.

Thanks,

Bron.
=

----- Original me= ssage -----
To: Bron Gondwana &l= t;brong@fastmailteam.com&g= t;
Subject: New Version Notification for draft-ietf-jmap-b= lob-07.txt
Date: Tuesday, November 23, 2021 00:24


A new vers= ion of I-D, draft-ietf-jmap-blob-07.txt
has been successfully submitted by Bron Gondwana and posted t= o the
IETF repository.

Name: draft-ietf-jmap-blob
Revision: 07
Title: = JMAP Blob management extension
Document date: 2021-11-22
G= roup: jmap
Pages: 26

= Abstract:
   The JM= AP base protocol (RFC8620) provides the ability to upload and
<= div style=3D"font-family:Arial;">   download arbitrary binary = data via HTTP POST and GET on defined
   endpoint.  This binary data is called a "Blob= ".

   This extension adds additional ways to cr= eate and access Blobs, by
&nb= sp;  making inline method calls within a standard JMAP request.
=

   This extension also adds a reverse lookup mecha= nism to discover where
 =   blobs are referenced within other data types.

&nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;         

=
The IETF Secretariat




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


--e460c7a64c9448e2b129b65ec065b437-- From nobody Mon Nov 22 13:36:01 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03943A089B for ; Mon, 22 Nov 2021 13:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=bluepopcorn.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 T8614bp-XM-r for ; Mon, 22 Nov 2021 13:35:51 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 BF0A83A08A1 for ; Mon, 22 Nov 2021 13:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=hrLVLnXqBci2Y5+j9vpeYipunsacEVjppwzyQE4L2eU=; b=O0lvUn6fLdu1+g6kTGPY4Fnu3m pCQk3PdTgAy7kgGn+8SPhNyT103FJnqh+hTYyQqKWW3WzkwDcNV3uGbqh/2AbD/ZqbUAlr9ZHNMvP 4TRYBsY+fJD+jahd0HXxTFPAE4bLalAeR3LzafBzwsvrAA3vWGngVdaoALbuqM3Qa9GE=; Received: from [2601:647:4400:1261:551c:af4b:b05f:dbd6] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mpGyb-0000RZ-Cp for jmap@ietf.org; Mon, 22 Nov 2021 13:35:49 -0800 From: Jim Fenton To: jmap@ietf.org Date: Mon, 22 Nov 2021 13:35:48 -0800 X-Mailer: MailMate (1.14r5820) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; markup=markdown Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Jmap] WGLC: draft-ietf-jmap-blob-07 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 21:36:00 -0000 Per the discussion in our WG meeting on November 9: This starts a 2 week Working Group Last Call on draft-ietf-jmap-blob-07. = Please provide your feedback on this document by December 7, 2021. -Jim