From nobody Mon Feb 1 01:24:29 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 657A53A0C5B for ; Mon, 1 Feb 2021 01:24:27 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, 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 bufV-ul9XfOa for ; Mon, 1 Feb 2021 01:24:25 -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 9F2BB3A0C57 for ; Mon, 1 Feb 2021 01:24:25 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id 959CDA1C3 for ; Mon, 1 Feb 2021 10:24:22 +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 gDxdV9t8jn8J for ; Mon, 1 Feb 2021 10:24:19 +0100 (CET) Received: from [192.168.0.133] (HSI-KBW-46-223-162-10.hsi.kabel-badenwuerttemberg.de [46.223.162.10]) (Authenticated sender: joris@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id 9C842A1A2 for ; Mon, 1 Feb 2021 10:24:19 +0100 (CET) To: jmap@ietf.org References: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> From: Joris Baum Message-ID: <3101d01e-a9b3-c5c6-fc2c-f57dcd0df533@audriga.com> Date: Mon, 1 Feb 2021 10:24:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> Content-Type: multipart/alternative; boundary="------------BF833508162C3A80135F4A87" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Proposal: split sharing mechanism from JMAP Calendars spec 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 Feb 2021 09:24:27 -0000 This is a multi-part message in MIME format. --------------BF833508162C3A80135F4A87 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Neil, another, related question would be if it would make sense for you to=20 split the calendars capability even further to allow signalling that=20 servers support features like recurrence, participants, relations or=20 alerts? Some clients/servers might not want to implement one of these=20 features. Also, splitting it will make the calendar spec more=20 lightweight. On the downside, we might end up with a more fragmented spec= =2E Regards, Joris On 15.12.20 07:01, Neil Jenkins wrote: > Hi all, > > The JMAP Calendars draft-in-progress currently defines the=20 > CalendarPrincipal and CalendarShareNotification data types under a=20 > separate capability. Looking at it, I have come to the conclusion that = > we should go a step further: drop "Calendar" from the names and split=20 > them out into their own spec. These are really generic sharing=20 > primitives that could then be referenced by the other specs =E2=80=94 e= =2Eg.=20 > calendars, tasks, mail sharing =E2=80=94 to define how you share data o= f types=20 > between entities within a system in a consistent way. > > Please reply with any comments, questions, objections, or agreement=20 > with the proposal and I will write up a draft splitting out these data = > types to propose for acceptance. > > Cheers, > Neil. > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --=20 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=C3=A4ftsf=C3=BChrer: Dr. Frank Dengler, Dr.-Ing. Hans-J=C3=B6rg Hap= pel -------------------------------------------------------------------------= - --------------BF833508162C3A80135F4A87 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Neil,

another, related question would be if it would make sense for you to split the calendars capability even further to allow signalling that servers support features like recurrence, participants, relations or alerts? Some clients/servers might not want to implement one of these features. Also, splitting it will make the calendar spec more lightweight. On the downside, we might end up with a more fragmented spec.

Regards,

Joris


On 15.12.20 07:01, Neil Jenkins wrote:
Hi all,

The JMAP Calendars draft-in-progress currently defines the CalendarPrincipal and CalendarShareNotification data types under a separate capability. Looking at it, I have come to the conclusion that we should go a step further: drop "Calendar" from the names and split them out into their own spec. These are really generic sharing primitives that could then be referenced by the other specs — e.g. calendars, tasks, mail sharing — to define how you share data of types between entities within a system in a consistent way.

Please reply with any comments, questions, objections, or agreement with the proposal and I will write up a draft splitting out these data types to propose for acceptance.

Cheers,
Neil.

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

-- 
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
--------------------------------------------------------------------------
--------------BF833508162C3A80135F4A87-- From nobody Mon Feb 1 01:25: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 C5EB33A0C5B for ; Mon, 1 Feb 2021 01:25:34 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, 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 MX1viB771jFU for ; Mon, 1 Feb 2021 01:25:33 -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 E8F033A0C58 for ; Mon, 1 Feb 2021 01:25:32 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id 4C693A1C3 for ; Mon, 1 Feb 2021 10:25:27 +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 MjbzUwRgeUGX for ; Mon, 1 Feb 2021 10:25:24 +0100 (CET) Received: from [192.168.0.133] (HSI-KBW-46-223-162-10.hsi.kabel-badenwuerttemberg.de [46.223.162.10]) (Authenticated sender: joris@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id 7F404A1A2 for ; Mon, 1 Feb 2021 10:25:24 +0100 (CET) To: jmap@ietf.org References: <161191089978.17240.10563196389228010167@ietfa.amsl.com> <3dc39912-c432-1c4e-df09-b50da0ee738d@audriga.com> From: Joris Baum Message-ID: Date: Mon, 1 Feb 2021 10:25:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <3dc39912-c432-1c4e-df09-b50da0ee738d@audriga.com> Content-Type: multipart/alternative; boundary="------------7354618C562F2BAB59676108" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Fwd: New Version Notification for draft-baum-jmap-tasks-00.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, 01 Feb 2021 09:25:35 -0000 This is a multi-part message in MIME format. --------------7354618C562F2BAB59676108 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On second thought, it probably makes sense to be a bit more specific=20 about obvious "gaps": * I currently left out all properties related to rights * Some methods of JMAP for Calendar deviate quite a lot from the typical JMAP methods. However, JMAP for Tasks will probably not deviate from JMAP for Calendar on most occasions (except for naming). I have not copy-pasted all those paragraphs, yet. Regards, Joris On 29.01.21 14:14, Joris Baum wrote: > Hey all, > > as discussed during last IETF, we pushed forward with a first draft of = > JMAP for Tasks. > > It is heavily based on JMAP for Calendars and uses the new sharing=20 > spec. There are certainly still some gaps and some issues we would=20 > like to discuss deeper. Looking forward to any comments! > > Regards, > > Joris > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-baum-jmap-tasks-00.txt > Date: Fri, 29 Jan 2021 01:01:39 -0800 > From: internet-drafts@ietf.org > To: Hans-Joerg , Joris Baum > > > > > A new version of I-D, draft-baum-jmap-tasks-00.txt > has been successfully submitted by Joris Baum and posted to the > IETF repository. > > Name: draft-baum-jmap-tasks > Revision: 00 > Title: JMAP for Tasks > Document date: 2021-01-29 > Group: Individual Submission > Pages: 16 > URL: https://www.ietf.org/archive/id/draft-baum-jmap-tasks-00.txt > Status: https://datatracker.ietf.org/doc/draft-baum-jmap-tasks/ > Html: https://www.ietf.org/archive/id/draft-baum-jmap-tasks-00.html > Htmlized: https://tools.ietf.org/html/draft-baum-jmap-tasks-00 > > > Abstract: > This document specifies a data model for synchronizing task data with > a server using JMAP. > > > > Please note that it may take a couple of minutes from the time of=20 > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --=20 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=C3=A4ftsf=C3=BChrer: Dr. Frank Dengler, Dr.-Ing. Hans-J=C3=B6rg Hap= pel -------------------------------------------------------------------------= - --------------7354618C562F2BAB59676108 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On second thought, it probably makes sense to be a bit more specific about obvious "gaps":

  • I currently left out all properties related to rights
  • Some methods of JMAP for Calendar deviate quite a lot from the typical JMAP methods. However, JMAP for Tasks will probably not deviate from JMAP for Calendar on most occasions (except for naming). I have not copy-pasted all those paragraphs, yet.

Regards,

Joris

On 29.01.21 14:14, Joris Baum wrote:
Hey all,

as discussed during last IETF, we pushed forward with a first draft of JMAP for Tasks.

It is heavily based on JMAP for Calendars and uses the new sharing spec. There are certainly still some gaps and some issues we would like to discuss deeper. Looking forward to any comments!

Regards,

Joris

-------- Forwarded Message --------
Subject: New Version Notification for draft-baum-jmap-tasks-00.txt
Date: Fri, 29 Jan 2021 01:01:39 -0800
From: internet-drafts@ietf.org
To: Hans-Joerg <hans-joerg@audriga.com>, Joris Baum <joris@audriga.com>



A new version of I-D, draft-baum-jmap-tasks-00.txt
has been successfully submitted by Joris Baum and posted to the
IETF repository.

Name: draft-baum-jmap-tasks
Revision: 00
Title: JMAP for Tasks
Document date: 2021-01-29
Group: Individual Submission
Pages: 16
URL: https://www.ietf.org/archive/id/draft-baum-jmap-tasks-00.txt
Status: https://datatracker.ietf.org/doc/draft-baum-jmap-tasks/
Html: https://www.ietf.org/archive/id/draft-baum-jmap-tasks-00.html
Htmlized: https://tools.ietf.org/html/draft-baum-jmap-tasks-00


Abstract:
This document specifies a data model for synchronizing task data with
a server using JMAP.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



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

-- 
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
--------------------------------------------------------------------------
--------------7354618C562F2BAB59676108-- From nobody Mon Feb 1 18:49: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 9F54E3A16AE for ; Mon, 1 Feb 2021 18:49:26 -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=jibm1ozA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SJNSt9zn 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 zVmO24-cF_nj for ; Mon, 1 Feb 2021 18:49:25 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.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 6482F3A16AD for ; Mon, 1 Feb 2021 18:49:25 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 4EDA6CB9 for ; Mon, 1 Feb 2021 21:49:24 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Mon, 01 Feb 2021 21:49:24 -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=3Ao2GoO ThotZi/OqizTbRNj0cMSDwv0EIndag7Eb02c=; b=jibm1ozATd+230H96XYMlhx NfUmhW4Wag+dTMK9j8WopazfSpv9iZgp5oAj2l3OiD9XMrqeu/K6mRPktNj1s55C s3QMxyBvF39mvDF3UwPTGdMZ6S1Qyhioyz84SlR3ZEbCzHeLgEomEwuI0vxzScGP RBhhWxznPtuzzC0BPAILWmvsAVBWZdqt58gt4o0sXYm5fYmbu1Y4vn/MKXBINK74 +VdX37PW6n9OOHVgNfrKsQxwzRquCmJg5jEkX9dC+uen7AZRQlLJNSmIl1vcF3iZ XfcLcaBF5uYb+14HKktRceZyxkh6njKiYMo4rkQzbxRuW16bs4vcEWherPvBlcQ= = 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=3Ao2Go OThotZi/OqizTbRNj0cMSDwv0EIndag7Eb02c=; b=SJNSt9znoBsACV2Mv0vczU lGpZPIpb/qhaRSKfokRl/mzmmieuHrSkwLjPWOQA5lnOCOuBszdtGp6KWU8qXF33 WznZYrfQpya6T6MC0LCKYuBq05ypzXQXCM0lL5ZrAnPE2IUoJfvIo7MIRQ+G3ag5 +209ZV9zmGI7mEkTS8Z1ct13/fw6GnXYCgHlS5BTMHPvLvJJVY2KXdXOgwtp2cqr 8YODDzEwnCb8oqnsx4tefW6dBiZxyxDYFByoQgl8VsNySJYBJ+uhJDaCvUJ0UprR Kgsq73MH8tJB9lZgs+qBqZLN5EVraaSPvD6qcSdsuVdtTYhndbgnkPtBLvsOr2zQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeelgdeghecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepvedvtedvudelkefhgefhteeftedtlefhheefveffveelkedu tdduffeiveejvefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 576D036005C; Mon, 1 Feb 2021 21:49:23 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-93-gef6c4048e6-fm-20210128.002-gef6c4048 Mime-Version: 1.0 Message-Id: <578c0b6d-4d6c-4470-9744-c6345d0fe029@dogfood.fastmail.com> In-Reply-To: <3101d01e-a9b3-c5c6-fc2c-f57dcd0df533@audriga.com> References: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> <3101d01e-a9b3-c5c6-fc2c-f57dcd0df533@audriga.com> Date: Tue, 02 Feb 2021 13:49:22 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=c4835a3476c74b8eb82ec2ef3ca0ee05 Archived-At: Subject: Re: [Jmap] Proposal: split sharing mechanism from JMAP Calendars spec 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, 02 Feb 2021 02:49:27 -0000 --c4835a3476c74b8eb82ec2ef3ca0ee05 Content-Type: text/plain On Mon, 1 Feb 2021, at 20:24, Joris Baum wrote: > another, related question would be if it would make sense for you to split the calendars capability even further to allow signalling that servers support features like recurrence, participants, relations or alerts? No, I wouldn't split the spec on these. If there's something more specific you have in mind (i.e. an existing server that has particularly limited support) then we can look at making that optional with a capability property to indicate server support, but each additional one makes clients harder to write as you have to support different levels (and combinations!) of capability. Neil. --c4835a3476c74b8eb82ec2ef3ca0ee05 Content-Type: text/html
On Mon, 1 Feb 2021, at 20:24, Joris Baum wrote:

another, related question would be if it would make sense for you to split the calendars capability even further to allow signalling that servers support features like recurrence, participants, relations or alerts?


No, I wouldn't split the spec on these. If there's something more specific you have in mind (i.e. an existing server that has particularly limited support) then we can look at making that optional with a capability property to indicate server support, but each additional one makes clients harder to write as you have to support different levels (and combinations!) of capability.

Neil.
--c4835a3476c74b8eb82ec2ef3ca0ee05-- From nobody Tue Feb 2 05:34: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 9E6143A1ABF for ; Tue, 2 Feb 2021 05:34:39 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, 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 FW2qT15_1hUT for ; Tue, 2 Feb 2021 05:34: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 C96FE3A1ABD for ; Tue, 2 Feb 2021 05:34:37 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id 692CCA1C8 for ; Tue, 2 Feb 2021 14:34:35 +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 S-MJcRhvnh5Q for ; Tue, 2 Feb 2021 14:34:32 +0100 (CET) Received: from [192.168.10.154] (unknown [109.90.161.242]) (Authenticated sender: happel@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id B4202A1A2 for ; Tue, 2 Feb 2021 14:34:32 +0100 (CET) To: jmap@ietf.org References: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> <3101d01e-a9b3-c5c6-fc2c-f57dcd0df533@audriga.com> <578c0b6d-4d6c-4470-9744-c6345d0fe029@dogfood.fastmail.com> From: Hans-Joerg Happel Message-ID: Date: Tue, 2 Feb 2021 14:34:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <578c0b6d-4d6c-4470-9744-c6345d0fe029@dogfood.fastmail.com> Content-Type: multipart/alternative; boundary="------------65D8231EA58BC10E85386DD4" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Proposal: split sharing mechanism from JMAP Calendars spec 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, 02 Feb 2021 13:34:40 -0000 This is a multi-part message in MIME format. --------------65D8231EA58BC10E85386DD4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Neil, the idea regarding more fine grained "capabilities" for the task feature stems from the purpose of using JMAP as an approach for data portability and/or also "modernizing" legacy groupware/task systems API's. While, e.g., attendees/assignees or recurrences are a standard feature for calendars, in our observation the situation is quite different with task management. As one extreme, Google Tasks just supports a handful of task properties. I would limit such capabilities to a handful of feature differences seen in existing task system. I do not see too much interrelation between those features. For fostering an open ecosystem, it would be great if man task systems and task apps could adopt JMAP for Tasks. Without a "capabilities" mechanism however, this would certainly be inhibited. Best, Hans-Joerg On 02.02.21 03:49, Neil Jenkins wrote: > On Mon, 1 Feb 2021, at 20:24, Joris Baum wrote: >> >> another, related question would be if it would make sense for you to >> split the calendars capability even further to allow signalling that >> servers support features like recurrence, participants, relations or >> alerts? >> > > No, I wouldn't split the spec on these. If there's something more > specific you have in mind (i.e. an existing server that has > particularly limited support) then we can look at making that optional > with a capability property to indicate server support, but each > additional one makes clients harder to write as you have to support > different levels (and combinations!) of capability. > > Neil. > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- audriga GmbH Durlacher Allee 47 76131 Karlsruhe, Germany Tel: +49 (0) 721 17029 316 Fax: +49 (0) 721 17029 3179 support@audriga.com https://www.audriga.com Handelsregister: Amtsgericht Mannheim - HRB 713034 Sitz der Gesellschaft: Karlsruhe Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel USt-ID: DE 279724142 --------------65D8231EA58BC10E85386DD4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Neil,

the idea regarding more fine grained "capabilities" for the task feature stems from the purpose of using JMAP as an approach for data portability and/or also "modernizing" legacy groupware/task systems API's.

While, e.g., attendees/assignees or recurrences are a standard feature for calendars, in our observation the situation is quite different with task management. As one extreme, Google Tasks just supports a handful of task properties.

I would limit such capabilities to a handful of feature differences seen in existing task system. I do not see too much interrelation between those features.

For fostering an open ecosystem, it would be great if man task systems and task apps could adopt JMAP for Tasks. Without a "capabilities" mechanism however, this would certainly be inhibited.

Best,
Hans-Joerg

On 02.02.21 03:49, Neil Jenkins wrote:
On Mon, 1 Feb 2021, at 20:24, Joris Baum wrote:

another, related question would be if it would make sense for you to split the calendars capability even further to allow signalling that servers support features like recurrence, participants, relations or alerts?


No, I wouldn't split the spec on these. If there's something more specific you have in mind (i.e. an existing server that has particularly limited support) then we can look at making that optional with a capability property to indicate server support, but each additional one makes clients harder to write as you have to support different levels (and combinations!) of capability.

Neil.

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



-- 
audriga GmbH
Durlacher Allee 47
76131 Karlsruhe, Germany
Tel: +49 (0) 721 17029 316
Fax: +49 (0) 721 17029 3179

support@audriga.com
https://www.audriga.com

Handelsregister: Amtsgericht Mannheim - HRB 713034
Sitz der Gesellschaft: Karlsruhe
Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel
USt-ID: DE 279724142
--------------65D8231EA58BC10E85386DD4-- From nobody Tue Feb 2 17:09:07 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 C2D113A1154 for ; Tue, 2 Feb 2021 17:09:04 -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=N5e9/40F; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Igkf/0Dk 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 4B4cpdnEIbk3 for ; Tue, 2 Feb 2021 17:09:03 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FCB3A115C for ; Tue, 2 Feb 2021 17:09:02 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 901855C031B for ; Tue, 2 Feb 2021 20:09:01 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Tue, 02 Feb 2021 20:09:01 -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=TKpcLNX BMi58cACbsq4Hn7h3Skl/puSgoI1deYlQx3w=; b=N5e9/40FWzWT3f0ba57GBHt bVJJzGY0sgNkN8IA0Yx8owWCzuUz5DhF2sSUrnOSe3Ytsi7wlCG7mypujSYX/0QI n6JlssIYwkibFar7eJiwygyGqWBsbrF3I7g+puzYTY6ajOBqUuE6z1I45UWgPe7M 5WhVRi+UqpuD1/taCvhQNNqdPL6v48m2cUhdqWUjFkZdoUrINZTlqgHkSDKUXo6i 2Mki2+Us2D/IrTj5XX7dHrhoV++qziPj3BzBrkx1IJiT/APDgteNLUyzWsuHYzAr 3HmBqmbr1795mH8z1lYFkSTTfOOBGwbVgUQO6N1wAVdFTtcJ/egp/JoUxf4L2lA= = 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=fm2; bh=TKpcLN XBMi58cACbsq4Hn7h3Skl/puSgoI1deYlQx3w=; b=Igkf/0DkVkin3RyemmZdRy UecwT2TFqduSFcH7ZoKkupSXXRsE8apQmIwScf7+fTwuxp3tMc4q8Yzc6YCfj5kZ XgvKu9IstX4sDDttxuXotuxv830YogQfAapOZzF5GvY8hEPPrWtK/C8QzCaNaHGl W0rewAbCLmiarBBDtxEpXJXpTTc7VTrDSWLUpQIlaKDrznfbqazU5xxMZbEWvTrl LuMOfeTXk/r1f/bQeavbEgknHHB2g5Cwm8/VO/iVZKwDEwBspYUDM3nrfwuRWIaQ KB5UhWi9YUIKzK1A7LD3GStQu8itPGKY/dIyq2/bgjl0vm2rw2tSckYRW2n97f0A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrgedugdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepvedvtedvudelkefhgefhteeftedtlefhheefveffveelkedu tdduffeiveejvefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AE63236005C; Tue, 2 Feb 2021 20:09:00 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-93-gef6c4048e6-fm-20210128.002-gef6c4048 Mime-Version: 1.0 Message-Id: <95c347f5-40c8-4642-a289-87104e1c01a5@dogfood.fastmail.com> In-Reply-To: References: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> <3101d01e-a9b3-c5c6-fc2c-f57dcd0df533@audriga.com> <578c0b6d-4d6c-4470-9744-c6345d0fe029@dogfood.fastmail.com> Date: Wed, 03 Feb 2021 12:08:53 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=2f1b19aec9ed4efdbd1f04eb7169f473 Archived-At: Subject: Re: [Jmap] Proposal: split sharing mechanism from JMAP Calendars spec 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 Feb 2021 01:09:05 -0000 --2f1b19aec9ed4efdbd1f04eb7169f473 Content-Type: text/plain On Wed, 3 Feb 2021, at 00:34, Hans-Joerg Happel wrote: > I would limit such capabilities to a handful of feature differences seen in existing task system. I do not see too much interrelation between those features. > For fostering an open ecosystem, it would be great if man task systems and task apps could adopt JMAP for Tasks. Without a "capabilities" mechanism however, this would certainly be inhibited. Right, so you're thinking of tasks rather than calendars. So we can look at making some things optional in JMAP tasks: I agree that the ability to assign participants may be reasonable to make optional there. But it's important to keep the options as few as possible, as otherwise the implementations become so different that it becomes very hard to build a good client that can handle all of them, so you miss out on the whole point of an open standard: interoperability. Neil. --2f1b19aec9ed4efdbd1f04eb7169f473 Content-Type: text/html
On Wed, 3 Feb 2021, at 00:34, Hans-Joerg Happel wrote:

I would limit such capabilities to a handful of feature differences seen in existing task system. I do not see too much interrelation between those features.

For fostering an open ecosystem, it would be great if man task systems and task apps could adopt JMAP for Tasks. Without a "capabilities" mechanism however, this would certainly be inhibited.


Right, so you're thinking of tasks rather than calendars. So we can look at making some things optional in JMAP tasks: I agree that the ability to assign participants may be reasonable to make optional there. But it's important to keep the options as few as possible, as otherwise the implementations become so different that it becomes very hard to build a good client that can handle all of them, so you miss out on the whole point of an open standard: interoperability.

Neil.
--2f1b19aec9ed4efdbd1f04eb7169f473-- From nobody Wed Feb 3 10:02:27 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 440793A0C85; Wed, 3 Feb 2021 10:02:22 -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.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <161237534221.28731.4646695249400780257@ietfa.amsl.com> Date: Wed, 03 Feb 2021 10:02:22 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-sieve-04.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: Wed, 03 Feb 2021 18:02:22 -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-04.txt Pages : 27 Date : 2021-02-03 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-sieve-04 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-sieve-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-sieve-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 10 04: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 39A133A0F0C for ; Wed, 10 Feb 2021 04:57:30 -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 ILV8GdhRRMWh for ; Wed, 10 Feb 2021 04:57:29 -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 D07733A0F09 for ; Wed, 10 Feb 2021 04:57:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id CA6EBA1A2; Wed, 10 Feb 2021 13:57:25 +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 vi_xjSVTF8fI; Wed, 10 Feb 2021 13:57:23 +0100 (CET) Received: from [192.168.0.94] (HSI-KBW-46-223-162-22.hsi.kabel-badenwuerttemberg.de [46.223.162.22]) (Authenticated sender: joris@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id 4D3A6A135; Wed, 10 Feb 2021 13:57:23 +0100 (CET) To: jmap@ietf.org Cc: Hans-Joerg Happel From: Joris Baum Message-ID: <241335e1-dc0d-6504-c85f-1b0d7a6e0a31@audriga.com> Date: Wed, 10 Feb 2021 13:57:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Jmap] JMAP for Files 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 Feb 2021 12:57:30 -0000 Hi, during the last IETF Bron mentioned an upcoming filesync protocol built on top of JMAP Blob Management Extension called "JMAP for Files". We are currently working on some projects in which we need to migrate file data along with contacts and calendars. Since we want to use JMAP for Contacts/Calendars for the latter, it would be great to have a similar "JMAPpy" API that we could use for files as well. Beyond our particular use case, that might also be useful for other JMAP users and could serve as a potential successor to the use of WebDAV for Online storage. There's work conducted or planned to port Contacts, Calendars, Tasks and Note over JMAP. We saw that Fastmail has custom support for files via https://www.fastmail.com/dev/files . Is there already something we could use, like an initial, rough draft? Maybe even some premature server/client implementations already exist that you could share with us? 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 Feb 11 02:02:05 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 B9F3D3A1460 for ; Thu, 11 Feb 2021 02:02:03 -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=dz9WiYzp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RVyD6Gap 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 tKEjDwxf7D4X for ; Thu, 11 Feb 2021 02:02:01 -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 123553A145F for ; Thu, 11 Feb 2021 02:02:01 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 684DB5C00A1 for ; Thu, 11 Feb 2021 05:02:00 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Thu, 11 Feb 2021 05:02:00 -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=ORikYuR 2Y2AGvOTNH/wC5uxRpcW98/EBjaak40IaMks=; b=dz9WiYzp4xJtNwc9e2ZiPe/ vs6RTsBDMSzom0MMjimLjiM85gD8SjzETbrgTYQXQ/iBoL+bk4xxOih2N2nKWd1O jFyizQv3jAYPzTzA9Xdwrq7z0FQr1xo5uUB4u5Frf2uLrDUjW9hokJdaGQAyGJ+7 ZqPFaRTsSF0onXmVuDvkJXyBP26t9D3710UObSq0pIrdMgLh6UBIJnpe/Xa8WhDr aSeHw8vN3DHMYUavqixJ5BeZkR9aKqkPOUdfvibqv5IuWMeRotN6ufnOZG2P7RPr rv49wFJ4+R0brT/VvMykdhRSG3+cBefJltf8TpyZ05Cq275ji5THaDNOx05lsng= = 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=fm2; bh=ORikYu R2Y2AGvOTNH/wC5uxRpcW98/EBjaak40IaMks=; b=RVyD6Gap7D0PpvgG1gjWwW aB97tBnnW+Cr8ettszO6kP0KFcjNOhs7EB9NWQvH4GMYYO0Xun5+9PpKVx3hMPYN 42o7a0HyE3RSubd5z0xkxmYgP2vkz9ejwfy013uaqN2wKvpihOpbaCxrEeiKKJ/U Og91s0EyF0NCEQ7Z2wjff0NjkLt83EBaXknaPmsXQ93XCWxW4UXVwx1kh14tZTQe hOyU+QIT5/NmvLiUJisqm/EsrAHULhcj2gc+dnRF2avhdU4JP/7SoUo43sOsDhMY D9cWZgYNaMnW2ZylJesL7WWbFPGQAq3UKbw9LA0obsdHbKnrwNfnmbggsSEyJ/mQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrheelgddtkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehmtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepkeeiteejtdeiieegjeehleehffffiedugfdugeetleetleev gffhheegteduheefnecuffhomhgrihhnpehfrghsthhmrghilhdrtghomhenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghs thhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 95057360064; Thu, 11 Feb 2021 05:01:59 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: <7fdb0cd1-c0d2-4ba1-ad37-00131e46ba2d@dogfood.fastmail.com> In-Reply-To: <241335e1-dc0d-6504-c85f-1b0d7a6e0a31@audriga.com> References: <241335e1-dc0d-6504-c85f-1b0d7a6e0a31@audriga.com> Date: Thu, 11 Feb 2021 21:01:58 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/mixed; boundary=cbb12d1c87c5474baa7df1946f798b2d Archived-At: Subject: Re: [Jmap] JMAP for Files 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, 11 Feb 2021 10:02:05 -0000 --cbb12d1c87c5474baa7df1946f798b2d Content-Type: multipart/alternative; boundary=cbd7fa5cb33a4df690bf3cd0be620233 --cbd7fa5cb33a4df690bf3cd0be620233 Content-Type: text/plain Hi Joris, > We saw that Fastmail has custom support for files via > https://www.fastmail.com/dev/files . Is there already something we could > use, like an initial, rough draft? Sure, I've attached our internal spec for what we call the *StorageNode* data type, which represents a file/folder in a user's file storage. It's really pretty simple compared to the other JMAP data types; it just defines the filesystem hierarchy and metadata, and then the standard JMAP blob system takes care of uploads/downloads. You are welcome to use this as a basis for a draft if there's enough interest to standardise this. > Maybe even some premature server/client implementations already exist that you could share with us? We implement the attached spec at Fastmail but it's not something we are able to usefully open source at this time; it's deeply tied to our internal file storage system. Neil. --cbd7fa5cb33a4df690bf3cd0be620233 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Joris,

W= e saw that Fastmail has custom support for files via 
https://www.fastmail.com= /dev/files . Is there already something we could 
use, like an initial, rough draft?

Sure, I've attached our internal spec for what we call the Stor= ageNode data type, which represents a file/folder in a user's file s= torage. It's really pretty simple compared to the other JMAP data types;= it just defines the filesystem hierarchy and metadata, and then the sta= ndard JMAP blob system takes care of uploads/downloads. You are welcome = to use this as a basis for a draft if there's enough interest to standar= dise this.

Maybe even some premature server/client implementations = already exist that you could share with us?
<= br>
We implement the attached spec at Fastmail but it's not so= mething we are able to usefully open source at this time; it's deeply ti= ed to our internal file storage system.

Nei= l.
--cbd7fa5cb33a4df690bf3cd0be620233-- --cbb12d1c87c5474baa7df1946f798b2d Content-Disposition: attachment;filename="StorageNode.mdown" Content-Type: text/markdown; name="StorageNode.mdown" Content-Transfer-Encoding: BASE64 IyBTdG9yYWdlTm9kZQoKQSBTdG9yYWdlTm9kZSBpcyB0aGUgc3RydWN0dXJlIGZvciBzdG9y aW5nIGZpbGUgaW5mb3JtYXRpb24gaW4gSk1BUC4gQSBTdG9yYWdlTm9kZSBjYW4gdGFrZSAy IGZ1bmRhbWVudGFsIGZvcm1zOiBhIG5vZGUgdGhhdCByZWZlcmVuY2VzIGFuIGV4aXN0aW5n IGJsb2IgKGFrYSBhIGZpbGUpIE9SIGEgbm9kZSB0aGF0IGhhcyBubyByZWZlcmVuY2UgdG8g YSBibG9iLCBpcyB1c2VkIGFzIGEgcGFyZW50IG9mIG90aGVyIG5vZGVzIGFuZCB0aHVzIGRl ZmluZXMgcGFydCBvZiB0aGUgc3RydWN0dXJlZCBzdG9yYWdlIChha2EgYSBmb2xkZXIpLgoK QSAqKlN0b3JhZ2VOb2RlKiogb2JqZWN0IGhhcyB0aGUgZm9sbG93aW5nIHByb3BlcnRpZXM6 CgotICoqaWQqKjogYFN0cmluZ2AgKGltbXV0YWJsZTsgc2VydmVyLXNldCkKICBUaGUgaWQg b2YgdGhlIFN0b3JhZ2VOb2RlLiBXaGlsZSBzZXJ2ZXItc2V0LCB0aGUgZm9sbG93aW5nIGZv bGRlcnMgTVVTVCBiZSBwcmVzZW50IGluIGVhY2ggYWNjb3VudCB3aXRoIHRoZSBmb2xsb3dp bmcgaWRzOgoKICAgIC0gYHJvb3RgIC0gVGhlIGlkIG9mIHRoZSB1c2VyJ3MgaG9tZSBkaXJl Y3RvcnkKICAgIC0gYHRyYXNoYCAtIFRoZSBpZCBvZiB0aGUgdXNlcidzIHRyYXNoIGRpcmVj dG9yeQogICAgLSBgdGVtcGAgLSBUaGUgaWQgb2YgdGhlIHVzZXJzJyB0ZW1wIGRpcmVjdG9y eQoKICAgIFRoZXNlIHRocmVlIGNvcmUgZm9sZGVycyBhcmUgYWxsIHNpYmxpbmdzIGluc2lk ZSB0aGUgdXNlcidzIG5hbWVzcGFjZQogICAgZGlyZWN0b3J5LgoKLSAqKnBhcmVudElkKio6 IGBTdHJpbmdgCiAgVGhlIFN0b3JhZ2VOb2RlIGlkIGZvciB0aGUgcGFyZW50IG9mIHRoaXMg bm9kZS4KLSAqKmJsb2JJZCoqOiBgU3RyaW5nfG51bGxgCiAgVGhlIGlkIG9mIHRoZSBiaW5h cnkgZGF0YS4gVGhpcyBpcyBgbnVsbGAgaWYsIGFuZCBvbmx5IGlmLCB0aGUgc3RvcmFnZSBu b2RlIHJlcHJlc2VudHMgYSBmb2xkZXIsIG90aGVyd2lzZSBpdCBNVVNUIGJlIHRoZSBpZCBv ZiB0aGUgYmxvYiByZXByZXNlbnRpbmcgdGhlIGJpbmFyeSBkYXRhIGZvciB0aGUgbm9kZS4K LSAqKm5hbWUqKjogYFN0cmluZ2AKICBVc2VyLXZpc2libGUgbmFtZSBmb3IgdGhlIFN0b3Jh Z2VOb2RlLCBUaGlzIG1heSBiZSBhbnkgVVRGLTggc3RyaW5nIG9mIGF0IGxlYXN0IDEgY2hh cmFjdGVyIGluIGxlbmd0aCwgZXhjZXB0OgoKICAqIFRoZSBuYW1lIE1VU1QgYmUgdW5pcXVl IGZvciBhbGwgU3RvcmFnZU5vZGVzIHdpdGggdGhlIHNhbWUgcGFyZW50SWQuCiAgKiBUaGUg bmFtZSBNVVNUIE5PVCBiZSAiLiIgb3IgIi4uIgogICogVGhlIG5hbWUgTVVTVCBOT1QgY29u dGFpbiBhICIvIgoKICBBIHNlcnZlciBNQVkgbGltaXQgdGhlIG5hbWUgbGVuZ3RoIGFuZCB3 aWxsIHJldHVybiBhbiBgaW52YWxpZFByb3BlcnRpZXNgIGVycm9yIGlmIHRoaXMgbGltaXQg aXMgZXhjZWVkZWQuCi0gKip0eXBlKio6IGBTdHJpbmd8bnVsbGAKICBUaGUgY29udGVudC10 eXBlIG9mIHRoZSBTdG9yYWdlTm9kZS4gVGhpcyBNVVNUIGJlIGBudWxsYCBpZiwgYW5kIG9u bHkgaWYsIHRoZSBub2RlIGRvZXMgbm90IGhhdmUgYSBgYmxvYklkYC4KLSAqKnNpemUqKjog YE51bWJlcmAgKHNlcnZlci1zZXQpCiAgU2l6ZSBpbiBieXRlcyBvZiB0aGUgYXNzb2NpYXRl ZCBibG9iIGRhdGEuIElmIHRoaXMgbm9kZSBkb2VzIG5vdCBoYXZlIGEgYGJsb2JJZGAgdGhl biB0aGlzIE1BWSBiZSB0aGUgY3VtdWxhdGl2ZSBzaXplIGluIGJ5dGVzIG9mIGFsbCBjaGls ZCBub2Rlcy4KLSAqKmNyZWF0ZWQqKjogYFVUQ0RhdGVgCiAgVGhlIGRhdGUgdGhlIG5vZGUg d2FzIGNyZWF0ZWQuCi0gKiptb2RpZmVkKio6IGBVVENEYXRlYAogIFRoZSBkYXRlIHRoZSBu b2RlIHdhcyBsYXN0IHVwZGF0ZWQuCi0gKipteVJpZ2h0cyoqOiBgRmlsZXNSaWdodHNgIChz ZXJ2ZXItc2V0KQogIFRoZSBzZXQgb2YgcmlnaHRzIChBQ0xzKSB0aGUgdXNlciBoYXMgaW4g cmVsYXRpb24gdG8gdGhpcyBmb2xkZXIuIEEgKipGaWxlc1JpZ2h0cyoqIG9iamVjdCBoYXMg dGhlIGZvbGxvd2luZyBwcm9wZXJ0aWVzOgoKICAtICoqbWF5UmVhZCoqOiBgQm9vbGVhbmAK ICAgIFRoZSB1c2VyIG1heSByZWFkIHRoZSBjb250ZW50cyBvZiB0aGlzIG5vZGUuCiAgLSAq Km1heVdyaXRlKio6IGBCb29sZWFuYAogICAgVGhlIHVzZXIgbWF5IG1vZGlmeSB0aGUgcHJv cGVydGllcyBvZiB0aGlzIG5vZGUsIGluY2x1ZGluZyByZW5hbWluZyBjaGlsZHJlbi4KICAt ICoqbWF5QWRtaW4qKjogYEJvb2xlYW5gCiAgICBUaGUgdXNlciBtYXkgY2hhbmdlIHRoZSBz aGFyaW5nIG9mIHRoaXMgbm9kZS4KCi0gKipzaGFyZVdpdGgqKjogYFN0cmluZ1tGaWxlc1Jp Z2h0c118bnVsbGAKICBBIG1hcCBvZiB1c2VySWQgdG8gcmlnaHRzIGZvciB1c2VycyB0aGlz IG5vZGUgaXMgc2hhcmVkIHdpdGguIFRoZSBvd25lciBvZiB0aGUgbm9kZSBNVVNUIE5PVCBi ZSBpbiB0aGlzIHNldC4gVGhpcyBpcyBgbnVsbGAgaWYgdGhlIHVzZXIgcmVxdWVzdGluZyB0 aGUgb2JqZWN0IGRvZXMgbm90IGhhdmUgYG15UmlnaHRzLm1heUFkbWluYCwgb3IgaWYgdGhl IG5vZGUgaXMgbm90IHNoYXJlZCB3aXRoIGFueW9uZS4KCiMjIFN0b3JhZ2VOb2RlL2dldAoK U3RhbmRhcmQgKi9nZXQqIG1ldGhvZC4gU3RvcmFnZU5vZGVzIGNhbiBvbmx5IGJlIGZldGNo ZWQgZXhwbGljaXRseSBieSBpZC4gVGhlcmUgaXMgb25lIGFkZGl0aW9uYWwgYXJndW1lbnQ6 CgotICoqaW5jbHVkZVBhcmVudHNMaW1pdCoqOiBgTnVtYmVyYCAoZGVmYXVsdDogYDBgKQog IFNwZWNpZmllcyBob3cgZmFyIHVwIHRoZSBwYXJlbnQgaGllcmFyY2h5IHRvIHRyYXZlcnNl IGZvciBlYWNoIGZvdW5kIG5vZGUgd2l0aCBhIG5vbi1udWxsIGBwYXJlbnRJZGAsIHJldHVy bmluZyB0aGUgcGFyZW50IFN0b3JhZ2VOb2RlIGFsb25nIHdpdGggdGhlIHJlcXVlc3RlZCBu b2RlLiBBIHZhbHVlIG9mIGAtMWAgaXMgZXF1aXZhbGVudCB0byAnbm8gbGltaXQnLCByZXR1 cm5pbmcgYWxsIHBhcmVudCBub2RlcyBvZiBhbnkgcmVxdWVzdGVkIG5vZGUuCgojIyBTdG9y YWdlTm9kZS9jaGFuZ2VzCgpTdGFuZGFyZCAqL2NoYW5nZXMqIG1ldGhvZC4KCiMjIFN0b3Jh Z2VOb2RlL3F1ZXJ5CgpTdGFuZGFyZCAqL3F1ZXJ5KiBtZXRob2QuCgpUaGUgKipGaWx0ZXJD b25kaXRpb24qKiBvYmplY3QgaGFzIHRoZSBmb2xsb3dpbmcgcHJvcGVydGllczoKCi0gKipw YXJlbnRJZHMqKjogYFN0cmluZ1tdYAogIEEgbGlzdCBvZiBTdG9yYWdlTm9kZSBpZHMuIEEg bm9kZSBtdXN0IGhhdmUgYSBwYXJlbnRJZCBlcXVhbCB0byBPTkUgb2YgdGhlc2UgdG8gbWF0 Y2ggdGhlIGNvbmRpdGlvbi4KLSAqKmFuY2VzdG9ySWRzKio6IGBTdHJpbmdbXWAKICBBIGxp c3Qgb2YgU3RvcmFnZU5vZGUgaWRzLiBBIG5vZGUgbXVzdCBoYXZlIGFuIGFuY2VzdG9yIChw YXJlbnQsIHBhcmVudCBvZiBwYXJlbnQsIGV0Yy4pIGVxdWFsIHRvIE9ORSBvZiB0aGVzZSB0 byBtYXRjaCB0aGUgY29uZGl0aW9uLgotICoqaGFzQmxvYklkKio6IGBCb29sZWFuYAogIElm IGB0cnVlYCwgdGhlIFN0b3JhZ2VOb2RlIG11c3QgaGF2ZSBhIGJsb2JJZCBzZXQgdG8gbWF0 Y2ggKGkuZS4gYmUgYSBmaWxlLCBub3QgYSBmb2xkZXIpLgotICoqY3JlYXRlZEJlZm9yZSoq OiBgRGF0ZWAKICBUaGUgY3JlYXRpb24gZGF0ZSBvZiB0aGUgbm9kZSAoYXMgcmV0dXJuZWQg b24gdGhlIFN0b3JhZ2VOb2RlIG9iamVjdCkgbXVzdCBiZSBiZWZvcmUgdGhpcyBkYXRlIHRv IG1hdGNoIHRoZSBjb25kaXRpb24uCi0gKipjcmVhdGVkQWZ0ZXIqKjogYERhdGVgCiAgVGhl IGNyZWF0aW9uIGRhdGUgb2YgdGhlIG5vZGUgKGFzIHJldHVybmVkIG9uIHRoZSBTdG9yYWdl Tm9kZSBvYmplY3QpIG11c3QgYmUgb24gb3IgYWZ0ZXIgdGhpcyBkYXRlIHRvIG1hdGNoIHRo ZSBjb25kaXRpb24uCi0gKiptb2RpZmllZEJlZm9yZSoqOiBgRGF0ZWAKICBUaGUgbW9kaWZp ZWQgZGF0ZSBvZiB0aGUgbm9kZSAoYXMgcmV0dXJuZWQgb24gdGhlIFN0b3JhZ2VOb2RlIG9i amVjdCkgbXVzdCBiZSBiZWZvcmUgdGhpcyBkYXRlIHRvIG1hdGNoIHRoZSBjb25kaXRpb24u Ci0gKiptb2RpZmllZEFmdGVyKio6IGBEYXRlYAogIFRoZSBtb2RpZmllZCBkYXRlIG9mIHRo ZSBub2RlIChhcyByZXR1cm5lZCBvbiB0aGUgU3RvcmFnZU5vZGUgb2JqZWN0KSBtdXN0IGJl IG9uIG9yIGFmdGVyIHRoaXMgZGF0ZSB0byBtYXRjaCB0aGUgY29uZGl0aW9uLgotICoqbWlu U2l6ZSoqOiBgTnVtYmVyYAogIFRoZSBzaXplIG9mIHRoZSBub2RlIGluIGJ5dGVzIChhcyBy ZXR1cm5lZCBvbiB0aGUgU3RvcmFnZU5vZGUgb2JqZWN0KSBtdXN0IGJlIGVxdWFsIHRvIG9y IGdyZWF0ZXIgdGhhbiB0aGlzIG51bWJlciB0byBtYXRjaCB0aGUgY29uZGl0aW9uLgotICoq bWF4U2l6ZSoqOiBgTnVtYmVyYAogIFRoZSBzaXplIG9mIHRoZSBub2RlIGluIGJ5dGVzIChh cyByZXR1cm5lZCBvbiB0aGUgU3RvcmFnZU5vZGUgb2JqZWN0KSBtdXN0IGJlIGxlc3MgdGhh biB0aGlzIG51bWJlciB0byBtYXRjaCB0aGUgY29uZGl0aW9uLgotICoqbmFtZSoqOiBgU3Ry aW5nYAogIERvZXMgYSBnbG9iIG1hdGNoIG9mIHRoZSBzcGVjaWZpZWQgbmFtZSBhZ2FpbnN0 IHRoZSAqbmFtZSogcHJvcGVydHkgb2YgdGhlIG5vZGUuCi0gKip0eXBlKio6IGBTdHJpbmdg CiAgRG9lcyBhIGdsb2IgbWF0Y2ggb2YgdGhlIHNwZWNpZmllZCB0eXBlIGFnYWluc3QgdGhl ICp0eXBlKiBwcm9wZXJ0eSBvZiB0aGUgbm9kZS4KCkEgU3RvcmFnZU5vZGUgb2JqZWN0IG1h dGNoZXMgdGhlIGZpbHRlciBpZiBhbmQgb25seSBpZiBhbGwgb2YgdGhlIGdpdmVuIGNvbmRp dGlvbnMgZ2l2ZW4gbWF0Y2guIElmIHplcm8gcHJvcGVydGllcyBhcmUgc3BlY2lmaWVkLCBp dCBpcyBhdXRvbWF0aWNhbGx5IGB0cnVlYCBmb3IgYWxsIG9iamVjdHMuCgpUaGUgZXhhY3Qg c2VtYW50aWNzIGZvciBtYXRjaGluZyBgU3RyaW5nYCBmaWVsZHMgaXMgKipkZWxpYmVyYXRl bHkgbm90IGRlZmluZWQqKiB0byBhbGxvdyBmb3IgZmxleGliaWxpdHkgaW4gaW5kZXhpbmcg aW1wbGVtZW50YXRpb24sIHN1YmplY3QgdG8gdGhlIGZvbGxvd2luZzoKCi0gVGV4dCBTSE9V TEQgYmUgbWF0Y2hlZCBpbiBhIGNhc2UtaW5zZW5zaXRpdmUgbWFubmVyLgotIFRleHQgY29u dGFpbmVkIGluIGVpdGhlciAoYnV0IG1hdGNoZWQpIHNpbmdsZSBvciBkb3VibGUgcXVvdGVz IFNIT1VMRCBiZSB0cmVhdGVkIGFzIGEgKipwaHJhc2Ugc2VhcmNoKiosIHRoYXQgaXMgYSBt YXRjaCBpcyByZXF1aXJlZCBmb3IgdGhhdCBleGFjdCBzZXF1ZW5jZSBvZiB3b3JkcywgZXhj bHVkaW5nIHRoZSBzdXJyb3VuZGluZyBxdW90YXRpb24gbWFya3MuIFVzZSBgXCJgLCBgXCdg IGFuZCBgXFxgIHRvIG1hdGNoIGEgbGl0ZXJhbCBgImAsIGAnYCBhbmQgYFxgIHJlc3BlY3Rp dmVseSBpbiBhIHBocmFzZS4KLSBPdXRzaWRlIG9mIGEgcGhyYXNlLCB3aGl0ZS1zcGFjZSBT SE9VTEQgYmUgdHJlYXRlZCBhcyBkaXZpZGluZyBzZXBhcmF0ZSB0b2tlbnMgdGhhdCBtYXkg YmUgc2VhcmNoZWQgZm9yIHNlcGFyYXRlbHkgaW4gdGhlIG5vZGUsIGJ1dCBNVVNUIGFsbCBi ZSBwcmVzZW50IGZvciB0aGUgbm9kZSB0byBtYXRjaCB0aGUgZmlsdGVyLgotIFRva2VucyBN QVkgYmUgbWF0Y2hlZCBvbiBhIHdob2xlLXdvcmQgYmFzaXMgdXNpbmcgc3RlbW1pbmcgKHNv IGZvciBleGFtcGxlIGEgdGV4dCBzZWFyY2ggZm9yIGBidXNgIHdvdWxkIG1hdGNoICJidXNl cyIgYnV0IG5vdCAiYnVzaW5lc3MiKS4KClRoZSBmb2xsb3dpbmcgcHJvcGVydGllcyBhcmUg c3VwcG9ydGVkIGZvciBzb3J0aW5nOgoKLSAqKmlkKio6IFRoZSBpZCBhcyByZXR1cm5lZCBp biB0aGUgU3RvcmFnZU5vZGUgb2JqZWN0LgotICoqaGFzQmxvYklkKio6IElzIHRoZSBTdG9y YWdlTm9kZSBhIGZvbGRlciBvciBhIGZpbGU/Ci0gKipuYW1lKio6IFRoZSBuYW1lIGFzIHJl dHVybmVkIGluIHRoZSBTdG9yYWdlTm9kZSBvYmplY3QuCi0gKip0eXBlKio6IFRoZSB0eXBl IGFzIHJldHVybmVkIGluIHRoZSBTdG9yYWdlTm9kZSBvYmplY3QuCi0gKipzaXplKio6IFRo ZSBzaXplIGFzIHJldHVybmVkIGluIHRoZSBTdG9yYWdlTm9kZSBvYmplY3QuCi0gKipjcmVh dGVkKio6IFRoZSBjcmVhdGVkIGRhdGUgYXMgcmV0dXJuZWQgaW4gdGhlIFN0b3JhZ2VOb2Rl IG9iamVjdC4KLSAqKm1vZGlmaWVkKio6IFRoZSBtb2RpZmllZCBkYXRlIGFzIHJldHVybmVk IGluIHRoZSBTdG9yYWdlTm9kZSBvYmplY3QuCgojIyBTdG9yYWdlTm9kZS9xdWVyeUNoYW5n ZXMKClN0YW5kYXJkICovcXVlcnlDaGFuZ2VzKiBtZXRob2QuCgojIyBTdG9yYWdlTm9kZS9z ZXQKClN0YW5kYXJkICovc2V0KiBtZXRob2QuCgpOb3RlLCAqY3JlYXRlZCogYW5kICptb2Rp ZmllZCogTUFZIGJlIGluY2x1ZGVkIGJ1dCB0aGUgc2VydmVyIFNIT1VMRCBpbXBvc2Ugc29t ZSBzYW5pdHkgY2hlY2tzIChlLmcuIGNhbid0IHNldCBpbiBmdXR1cmUsIHN1YmplY3QgdG8g cmVhc29uYWJsZSBqaXR0ZXIgYWxsb3dhbmNlIG9yIGEgbWluaW11bSBhbGxvd2FibGUgZGF0 ZSkuIFRoaXMgaXMgaW50ZW5kZWQgdG8gc3VwcG9ydCBzeW5jaW5nIGJ5IG9mZmxpbmUgY2xp ZW50cy4gSWYgc2FuaXR5IGNoZWNrcyBhcmUgdHJpZ2dlcmVkIHRoZSBjcmVhdGUvdXBkYXRl IGlzIGFjY2VwdGVkLCBidXQgdGhlIHZhbHVlcyBhcmUgb3ZlcndyaXR0ZW4gYW5kIHRoZSBz ZXJ2ZXIgd2lsbCByZXR1cm4gdGhlIHZhbHVlcyB1c2VkIHRvIHRoZSBjbGllbnQuCgpJZiBv biBjcmVhdGUgYSBub2RlIHdpdGggYSBjb25mbGljdGluZyAqbmFtZSogYWxyZWFkeSBleGlz dHMsIHRoZSBzZXJ2ZXIgd2lsbCBhZGQgYSBzdWZmaXggdG8gdGhlIG5hbWUgdG8gbWFrZSBp dCBubyBsb25nZXIgY2xhc2ggYW5kIGFsbG93IHRoZSBjcmVhdGUgdG8gcHJvY2VlZCwgcmV0 dXJuaW5nIHRoZSBuZXcgbmFtZSBpbiB0aGUgY3JlYXRlZCByZXNwb25zZS4KCklmICp0eXBl KiBpcyBzZXQgdG8gYG51bGxgIGFuZCB0aGUgc3RvcmFnZSBub2RlIGhhcyBhIGJsb2IgaWQs IHRoZSBzZXJ2ZXIgd2lsbCBkZXRlcm1pbmUgdGhlIHR5cGUgYmFzZWQgb24gdGhlIGZpbGVu YW1lIGFuZCByZXR1cm4gdGhpcyB3aXRoIHRoZSBjcmVhdGVkL3VwZGF0ZWQgcmVzcG9uc2Uu CgpTdGFuZGFyZCBzZXQgZXJyb3JzLCBlLmcuIGBvdmVyUXVvdGFgLCBgaW52YWxpZFByb3Bl cnRpZXNgIGV0Yy4gc2hvdWxkIGJlIHJldHVybmVkIHdoZXJlIGFwcHJvcHJpYXRlLgoKQW4g KmlkKiBjb3JyZXNwb25kaW5nIHRvIGEgcHJldmlvdXNseSBkZWxldGVkIGZvbGRlciBNQVkg YmUgcGFzc2VkIGZvciBjcmVhdGVzLiBUaGUgc2VydmVyIHdpbGwgcmVzdG9yZSB0aGUgcHJl dmlvdXMgY29udGVudHMgb2YgdGhpcyBmb2xkZXIgd2hlbiBjcmVhdGluZyB0aGUgZm9sZGVy LCBpZiBmb3VuZC4gSWYgdGhlIG5vZGUgYmVpbmcgY3JlYXRlZCBpcyBub3QgYSBmb2xkZXIs IG9yIHRoZSBpZCBnaXZlbiBpcyBub3QgYSB2YWxpZCBpZCBmb3IgYSBkZWxldGVkIGZvbGRl ciwgcmVqZWN0IHdpdGggYG5vdEZvdW5kYCBlcnJvci4KCiMjIFN0b3JhZ2VOb2RlL2NvcHkK ClN0YW5kYXJkICovY29weSogbWV0aG9kLgo= --cbb12d1c87c5474baa7df1946f798b2d-- From nobody Fri Feb 12 16:35:00 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 2F06C3A1178; Fri, 12 Feb 2021 16:33:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: barryleiba@computer.org, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317640116.31337.15359105834937554752@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:21 -0800 Archived-At: Subject: [Jmap] jmap - Requested session has been scheduled for IETF 110 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: Sat, 13 Feb 2021 00:33:29 -0000 Dear Bron Gondwana, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. jmap Session 1 (2:00 requested) Thursday, 11 March 2021, Session III 1700-1900 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/110/sessions/jmap.ics Request Information: --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 15 Conflicts to Avoid: Chair Conflict: calext extra dispatch Technology Overlap: uta httpbis emailcore dmarc People who must be present: Alexey Melnikov Barry Leiba Bron Gondwana Jim Fenton Neil Jenkins Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Feb 19 08:49:41 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 9DC523A1154; Fri, 19 Feb 2021 08:49:40 -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.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <161375338059.1324.4641187246320270178@ietfa.amsl.com> Date: Fri, 19 Feb 2021 08:49:40 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-jscontact-04.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, 19 Feb 2021 16:49:41 -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 : JSContact: A JSON representation of contact data Authors : Robert Stepanek Mario Loffredo Filename : draft-ietf-jmap-jscontact-04.txt Pages : 17 Date : 2021-02-19 Abstract: This specification defines a data model and JSON representation of contact card information that can be used for data storage and exchange in address book or directory applications. It aims to be an alternative to the vCard data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCard format, it is not a direct mapping from the vCard data model and expands semantics where appropriate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-jscontact-04 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-jscontact-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 19 17:19:10 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 E03EC3A0BD4 for ; Fri, 19 Feb 2021 17:19:08 -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 (2048-bit key) header.d=webb.page 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 2RFk7lDgHZ3O for ; Fri, 19 Feb 2021 17:19:07 -0800 (PST) Received: from box.thenetwork.email (box.thenetwork.email [167.71.99.158]) (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 657BF3A0BD3 for ; Fri, 19 Feb 2021 17:19:07 -0800 (PST) Received: from authenticated-user (box.thenetwork.email [167.71.99.158]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by box.thenetwork.email (Postfix) with ESMTPSA id DA00A3F120 for ; Fri, 19 Feb 2021 19:19:04 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=webb.page; s=mail; t=1613783945; bh=wUdcDRRVwXMmOQ7DB9zkASh5sJvpp7jxERdT7SlAAYA=; h=From:Date:Subject:To:From; b=gL9U9wYqP+lcl7L4oJnbQXmLO/ZWadvN7t+fRj5nADSNwFQyVYOZClLbBKkUiOild TuwhrNO57gu/x980dSt6j+BZLZCj1FelPWjW/K+05kYdbO+9Su65DHaorfCoeknzS1 bL6L5hxA5aLBUrZYrx3ydxW9wfZ/ubDTrVX8usOOo5soWQ/r6ENnZZxYoPWT9ZW9hO ncu2EyfbGxSlYpK1EDQiWkt/V5O4pdlpDNY8tMiYYreO4BviftHcJVattDp+aWeEZu zIcvQlredvMqxuplRKZXaXIjJ5PgbAzpC37wuvoskvn4f72jXID6B1KEQ2WKBDgaS0 JFXuHZT4sqBnA== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Paul Anthony Webb Mime-Version: 1.0 Date: Fri, 19 Feb 2021 17:19:02 -0800 Message-Id: <49DA8CB6-89AC-4E7E-9BD0-700F08DAF5BF@webb.page> To: jmap@ietf.org Archived-At: Subject: [Jmap] Possibility of Handshake support? 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: Sat, 20 Feb 2021 01:19:09 -0000 I=E2=80=99ma fan of JMAP and am also invested in the Handshake protocol. For= the uninitiated, Handshake enables decentralized domain names. Within the l= ast two weeks, someone made a proof of concept and was able to exchange emai= ls over IMAP with these domains. Has anyone in the JMAP space done the same (or is interested in doing so)?= From nobody Sun Feb 21 22:21:10 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 3AFD13A0BB1; Sun, 21 Feb 2021 22:21:09 -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.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <161397486918.14979.12070766272387080195@ietfa.amsl.com> Date: Sun, 21 Feb 2021 22:21:09 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-jscontact-vcard-02.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 Feb 2021 06:21:09 -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 : JSContact: Converting from and to vCard Authors : Mario Loffredo Robert Stepanek Filename : draft-ietf-jmap-jscontact-vcard-02.txt Pages : 39 Date : 2021-02-21 Abstract: This document provides informational guidance for converting the contact card defined by JSContact specification, namely JSCard, from and to vCard. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact-vcard/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-jscontact-vcard-02 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-vcard-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-jscontact-vcard-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/