From nobody Mon Oct 5 14:04:39 2020 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 E14CB3A0F61; Mon, 5 Oct 2020 14:04:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-jmap-mdn@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, Bron Gondwana , brong@fastmailteam.com X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160193187289.4946.17482930539468511819@ietfa.amsl.com> Date: Mon, 05 Oct 2020 14:04:32 -0700 Archived-At: Subject: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-mdn-15: (with DISCUSS and COMMENT) 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, 05 Oct 2020 21:04:33 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-jmap-mdn-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-jmap-mdn/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This should be quite easy to resolve; I'm just not sure yet which direction the resolution will be. I think we should be a little more clear about whether the client can override the finalRecipient calculation (or just provide a suggestion to do so, or not give any input at all, etc.): the description of the finalRecipient property of an MDN object says that "if set, it overrides the value that would be calculated by the server from the Identity", which to me suggests that the client could set something to override the server (if the server sua sponte did something different that would typically be an "exception", not an "override"), but later on in Section 2.1 we say that "[w]hen sending the MDN, the server is in charge of generating the "originalRecipient", "finalRecipient" and "originalMessageId" fields according to the [RFC8098] specification. I do not see discussion in RFC 8098 of client intput into the server's populating of this field, so I'm unsure whether/where the client has input. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for noting the `jq` validation in the sheperd writeup! Section 1 A client can have to deal with MDNs in different ways: (editorial) "have to deal with" seems like it can be read as implying obligation to do so (even though the majuscule "MUST" is not used); it seems like this is just attempting to enumerate the cases in which an MDN might be encountered or need to be interacted with. 2. When sending an email message, an MDN can be requested. This must be done with the help of a header, and is already specified by [RFC8098] and can already be handled by [RFC8621] this way. (nit?) "header" or "header field"? (We get this a lot for HTTP and I've forgotten if SMTP uses the same rule...) 3. When receiving an MDN, the MDN could be related to an existing sent message. This is already covered by [RFC8621] in the EmailSubmission object. [...] (The "DeliveryStatus" member, in particular, right?) Section 1.3 The value of this "urn:ietf:params:jmap:mdn" property is an empty object in the account's "accountCapabilities" property. I presume it's also an empty object in the server's "capabilities" property as well (and we should probably say so). Section 2 It's a little interesting to me that RFC 8261 did not define or mention specific access to the User-Agent string but we need to have a specific reportingUA here. I do recognize that it's (an optional) part of the RFC 8098 ABNF, and that RFC 8098 mentions the relevant security considerations already. Perhaps a subtle nudge in this section that the "null" option may have better privacy properties would be appropriate. (We may also revisit whether/what to include in the examples for reportingUA.) o finalRecipient: "String|null" Recipient for which the MDN is being issued. if set, it overrides the value that would be calculated by the server from the Identity. Could we get a couple more words to support the definite article? (I am not sure which Identity is "the" Identity just from this context; it is only later on that we discover that there is an identityId in the MDN/send arguments.) o extensionFields: "String[String]|null" Object where keys are extension-field names and values are extension-field values. I used process of elimination to conclude that these are RFC 8098 extension-field ABNF names/values; I don't know if there's a good way to hint the reader of that fact. o actionMode: "String" This MUST be one of the following strings: "manual-action" / "automatic-action" o sendingMode: "String" This MUST be one of the following strings: "mdn-sent-manually" / "mdn-sent-automatically" I recognize that this is entirely the responsibility of RFC 8098 and not this document, but is it valid to combine "automatic-action" with "mdn-sent-manually"? I am not 100% I understand the semantics. Section 2.1 The latter because of the implicit call to Email/set and the use of Identities, described below. [...] nit: does this sentence have a verb? The following already registered SetError would mean: nit: these are the SetError types, right? Section 3.x It might be helpful to use a different creation ID for the different classes of example (though not required by the protocol). Section 3.1 "extension": { "X-EXTENSION-EXAMPLE": "example.com" } nit(?): somehow I thought X- extensions were generally thought to not be needed/useful anymore. Section 5 In order to enforce trust regarding the relation between the user sending an email message and the identity of this user, the server SHOULD validate in conformance to the provided Identity that the user is permitted to use the finalRecipient value and return a forbiddenFrom error if not. "enforce" and "SHOULD" are not words I usually see in combination. From nobody Mon Oct 5 20:57:15 2020 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 D2D7B3A0F4B; Mon, 5 Oct 2020 20:57:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-jmap-mdn@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, Bron Gondwana , brong@fastmailteam.com X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <160195663247.26202.9916738287258170843@ietfa.amsl.com> Date: Mon, 05 Oct 2020 20:57:12 -0700 Archived-At: Subject: [Jmap] Roman Danyliw's No Objection on draft-ietf-jmap-mdn-15: (with COMMENT) 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, 06 Oct 2020 03:57:13 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-jmap-mdn-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-jmap-mdn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few minor comments: ** Section 2. Per “This property MUST NOT be null for "MDN/send", but may be null in the response from the "MDN/parse" method”, should a normative MAY be used here instead (or would that conflict with RFC8098) ** Section 2. The guidance to reference RFC8098 for further details is helpful. In addition to the guidance on case sensitivity, I would have also would have benefit from a bit of prose on how to convert the fields names between this document and RFC8098. From nobody Wed Oct 7 11:15:28 2020 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 DEA583A11A9; Wed, 7 Oct 2020 11:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=cooperw.in header.b=AGVDcewz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qCUw8Grg 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 O98kIAz0I2OZ; Wed, 7 Oct 2020 11:15:22 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335813A11A8; Wed, 7 Oct 2020 11:15:19 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id F1CB9C53; Wed, 7 Oct 2020 14:15:17 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 07 Oct 2020 14:15:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=K OcIzjcfrqC0hHQAAdZO9QgBx7yh8e69H1UuCDB/UFk=; b=AGVDcewzbNUTQ50XV 3fikWiJitbXzKB5BzYN+aDPjdbqqOpKiA4A9OUpZS9KnkQ/d0JnNdIUuudLQpk0j +7sm2lbYrkG2Ssgi9bqIYGImDgd7Aq3OSrF+WecdR1tXxDfQ6KTgN2NcMikM7fmK wZe9ewUJcIcqOBTQTvZkxGlF8B9AwYRv6iEBYrJDS2vnMgF61Ae/ZliYh4dIFOfg 29kbugr4wjnkt31+yJnv1PBTXhi2J/u3eOuJIJc19jpNpHsQBhnwGi067lzyzwQ6 QpJq+U/5HOQB35IV5pbZbsCRbMK6KvS2CqdTuLjmTzWYPDLk9X5zZ5Eu98obbPjR eWxvA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=KOcIzjcfrqC0hHQAAdZO9QgBx7yh8e69H1UuCDB/U Fk=; b=qCUw8Grgc8EwQOz1oLpsY4EqBHXsKoY/AeRUez+S8Mp3eAXznx0sMgsIq SKetOHSJwexpiifoM8isrGRysNNMOphGMin98to+WKGhN76iDld/yiDEiHSAEils j1lfG0u717h/Q59BT5yKgI/y4nmUqG/7AkMY68LOeKj5KLVqokbcfCFuAMYs0y32 VUTHzw3KnTVD1pQFy2jA/qcDxacwTitVuE+ytW7U0Wk/ilTDUAIDu+UmFiikK5aB S3b5/rFi1bVq1o0yuMrCGm8KSJx7GaYXH4f72i4LeJ1ao/fF66AzLMFIP7uGR5s9 QcE3UyeFWyxVCxP02eBCRrKkB9lfA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgeeigdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtddvnecuhfhrohhmpeetlhhishhsrgcuvehoohhpvghruceorghlihhsshgrsegt ohhophgvrhifrdhinheqnecuggftrfgrthhtvghrnhepfeduhffgtefgtedvvdffiedutd ekffegvdejjedtieehfefgleefuedtledvgffgnecuffhomhgrihhnpehivghtfhdrohhr ghenucfkphepuddtkedrhedurddutddurdelkeenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhn X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 225653064680; Wed, 7 Oct 2020 14:15:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Alissa Cooper In-Reply-To: <159985566621.15440.12924528546650487167@ietfa.amsl.com> Date: Wed, 7 Oct 2020 14:15:14 -0400 Cc: gen-art@ietf.org, draft-ietf-jmap-mdn.all@ietf.org, jmap@ietf.org, last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6AF27CEE-F87A-4A2B-998B-810E925CE714@cooperw.in> References: <159985566621.15440.12924528546650487167@ietfa.amsl.com> To: Joel Halpern X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jmap] [Gen-art] Genart last call review of draft-ietf-jmap-mdn-15 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, 07 Oct 2020 18:15:24 -0000 Thanks Joel. I entered a No Objection ballot. Alissa > On Sep 11, 2020, at 4:21 PM, Joel Halpern via Datatracker = wrote: >=20 > Reviewer: Joel Halpern > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-jmap-mdn-15 > Reviewer: Joel Halpern > Review Date: 2020-09-11 > IETF LC End Date: 2020-09-18 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: This document is ready for publication as a Proposed Standard >=20 > Major issues: N/A >=20 > Minor issues: N/A >=20 > Nits/editorial comments: N/A >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Sun Oct 11 23:30:07 2020 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 5F7573A1190; Sun, 11 Oct 2020 23:30:06 -0700 (PDT) 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.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <160248420635.17717.14309365380705361853@ietfa.amsl.com> Date: Sun, 11 Oct 2020 23:30:06 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-jscontact-vcard-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, 12 Oct 2020 06:30:06 -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-01.txt Pages : 39 Date : 2020-10-11 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-vcard-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-jscontact-vcard-01 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 Sun Oct 11 23:36:05 2020 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 040D93A1280 for ; Sun, 11 Oct 2020 23:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 2xlei_g1vTzA for ; Sun, 11 Oct 2020 23:36:02 -0700 (PDT) Received: from smtp.iit.cnr.it (mx5.iit.cnr.it [146.48.98.152]) by ietfa.amsl.com (Postfix) with ESMTP id BCBF73A127E for ; Sun, 11 Oct 2020 23:36:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 1639CC0402 for ; Mon, 12 Oct 2020 08:36:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mx5.iit.cnr.it Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx5.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vs2VtbMCnT6 for ; Mon, 12 Oct 2020 08:35:57 +0200 (CEST) Received: from [192.12.193.108] (pc-loffredo.nic.it [192.12.193.108]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id E25E3C01EC for ; Mon, 12 Oct 2020 08:35:57 +0200 (CEST) References: <160248420659.17717.989852589823133708@ietfa.amsl.com> To: jmap@ietf.org From: Mario Loffredo X-Forwarded-Message-Id: <160248420659.17717.989852589823133708@ietfa.amsl.com> Message-ID: <90d7ddf2-febe-0a84-b6c7-293a7e9914b1@iit.cnr.it> Date: Mon, 12 Oct 2020 08:32:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <160248420659.17717.989852589823133708@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------CBCA7EED88C8DE224F3C4669" Content-Language: it Archived-At: Subject: [Jmap] Fwd: New Version Notification for draft-ietf-jmap-jscontact-vcard-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, 12 Oct 2020 06:36:04 -0000 This is a multi-part message in MIME format. --------------CBCA7EED88C8DE224F3C4669 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, this new version includes the link to a Java library, named jscontact-tools, supporting JSContact creation, validation, serialization/deserialization and conversion from vCard, xCard and jCard. Feedback is very appreciated. Best, Mario -------- Messaggio Inoltrato -------- Oggetto: New Version Notification for draft-ietf-jmap-jscontact-vcard-01.txt Data: Sun, 11 Oct 2020 23:30:06 -0700 Mittente: internet-drafts@ietf.org A: Mario Loffredo , Robert Stepanek A new version of I-D, draft-ietf-jmap-jscontact-vcard-01.txt has been successfully submitted by Mario Loffredo and posted to the IETF repository. Name: draft-ietf-jmap-jscontact-vcard Revision: 01 Title: JSContact: Converting from and to vCard Document date: 2020-10-11 Group: jmap Pages: 39 URL: https://www.ietf.org/id/draft-ietf-jmap-jscontact-vcard-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact-vcard/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-vcard Htmlized: https://tools.ietf.org/html/draft-ietf-jmap-jscontact-vcard-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-jscontact-vcard-01 Abstract: This document provides informational guidance for converting the contact card defined by JSContact specification, namely JSCard, from and to vCard. 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 --------------CBCA7EED88C8DE224F3C4669 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi all,

this new version includes the link to a Java library, named jscontact-tools, supporting JSContact creation, validation, serialization/deserialization and conversion from vCard, xCard and jCard.

Feedback is very appreciated.

Best,

Mario



-------- Messaggio Inoltrato --------
Oggetto: New Version Notification for draft-ietf-jmap-jscontact-vcard-01.txt
Data: Sun, 11 Oct 2020 23:30:06 -0700
Mittente: internet-drafts@ietf.org
A: Mario Loffredo <mario.loffredo@iit.cnr.it>, Robert Stepanek <rsto@fastmailteam.com>



A new version of I-D, draft-ietf-jmap-jscontact-vcard-01.txt
has been successfully submitted by Mario Loffredo and posted to the
IETF repository.

Name: draft-ietf-jmap-jscontact-vcard
Revision: 01
Title: JSContact: Converting from and to vCard
Document date: 2020-10-11
Group: jmap
Pages: 39
URL: https://www.ietf.org/id/draft-ietf-jmap-jscontact-vcard-01.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact-vcard/
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-vcard
Htmlized: https://tools.ietf.org/html/draft-ietf-jmap-jscontact-vcard-01
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-jscontact-vcard-01

Abstract:
This document provides informational guidance for converting the
contact card defined by JSContact specification, namely JSCard, from
and to vCard.



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


--------------CBCA7EED88C8DE224F3C4669-- From nobody Tue Oct 20 20:49:59 2020 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 6DAA93A0C9E for ; Tue, 20 Oct 2020 20:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=eIc++W83; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EtgDr7rK 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 IVSe6AYwWqRp for ; Tue, 20 Oct 2020 20:49:55 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50413A0C9D for ; Tue, 20 Oct 2020 20:49:55 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 8AA8ED5F for ; Tue, 20 Oct 2020 23:49:54 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Tue, 20 Oct 2020 23:49:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=VJzm6f/ lqenZQb6xvvsQXyMrYAURWguhXUygIJfuBIM=; b=eIc++W83GnewnlxBUPVGs3n pwngt11KEcqLPCl3vWMCj85JHVhFIWROdj1wZB+4VqQYzOnhygPjrFHJOUyJmwmZ +0fKNuVw2kiK5SQtqbYSXqxrNBRQ/uJFqwTIj2VzDONWgs4VuzpljSTVLXNv9dPJ 4p2JGjjR7DHQQi8R2mOycDMLyIht7fw0U0shpRrKinkz/E5RLLrs7xxqdwnBkk/X 2ECJyNuaKK40qkyaTgEQB+2GHS7Pt4WNVHvdv/i/F+A8BxQEVwNgJJNJK3KEurNn OuI7xwk8s+ZzLCeH187qs3xDWhNL5CdrtyRdWogKl6jrXrB4vRVCLx1P/Rda4ww= = 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=VJzm6f /lqenZQb6xvvsQXyMrYAURWguhXUygIJfuBIM=; b=EtgDr7rKs1Hu5X/hARz5vJ z/JnGdBwkqGSajSxalMc/KLzLDhTWUMybwTKrckPk0NYCtuzXV9tZVVlfY8nFEia HfF7rTZs2rjzLVrGYrWRaGK/ZzZxMbfCZCdW41SjnVZR1YZQRL2yBqnKqlWK+mln UlZMdeqZ+S9nWHXGMjnWXLbcYAfvWHhBDiLEQJIqJZV3agpEIbGoEeLjD30dWi0a TEwOEaQtT2Lmjn4bi8bMzS4tZtFYTFvV+cm45daRtf/jQDJDoA0cT+qjQ+c277sL e2ZJUjacACUjWohGhcEffWGjVuO3nSjOs4/li7b366wovLpN/9PvD8REvMq47bnw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeeggdejfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepheeuhfdujedtieevkedvhfffgfelfeelhfefkeehhfekleek hfefueefveffjeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C71EE1800B3; Tue, 20 Oct 2020 23:49:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-516-g928217d-fm-20201020.001-g928217d6 Mime-Version: 1.0 Message-Id: <17cefc62-502a-4832-921c-f68ac6f5dec3@dogfood.fastmail.com> In-Reply-To: <160079973219.9216.17349013185550397825@ietfa.amsl.com> References: <160079973219.9216.17349013185550397825@ietfa.amsl.com> Date: Wed, 21 Oct 2020 14:49:29 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=ebe69cef4e8d416d9486108bd105a4d7 Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-sieve-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: Wed, 21 Oct 2020 03:49:58 -0000 --ebe69cef4e8d416d9486108bd105a4d7 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Some comments on this draft: > o Do we need/want both "content" and "blobId" in the SieveScript object? It may be simpler to have just one way of specifying content and "blobId" is more versatile and doesn't require JSON- encoding of the content. Furthermore, use of the forthcoming(?) Blob/set method would avoid the extra roundtrip of having to upload the blob first. Yes, I think just blobId will probably be better for this, especially if= we have methods for manipulating textual blobs in band. General comments: 1. Is the contents of the script meant to be immutable or not? The "con= tent" property is apparently mutable, but the "blobId" property is not. = This makes no sense. 2. I find the reference to JSON in the "content" property very confusin= g. JSON is just the serialisation format and should not be relevant here= . For that matter, the discussion of Sieve encoding is also confusing; s= ince this is defined as just the raw octets of the script, why is there = extra encoding involved? Shouldn't it just be the script data? I *think*= you are just trying to remind people of how strings are written in Siev= e, but that seems needless and confusing here to me. 3. The spec says "When creating or updating a script, a client MUST inc= lude either a _content_ or a _blobId_ property." =E2=80=93 this means y= ou can't just update the name of the script. But the name does look like= it's meant to be mutable right? 4. "The id of the SieveScript to activate if the create/update/destroy = succeeds." <- Which create/update/destroy? All of them? Or just the one = referenced by onSuccessActivateScript? I'm guessing now you mean the lat= ter, but this was not clear to me initially (especially because "destroy= " is in there, which doesn't really make sense). 5. The "replaceOnCreate" arg feels a little ugly to me, but I get why i= t's there and I don't have a better suggestion. 6. I think the semantics of the "alreadyExists" SetError is appropriate= for the duplicate name issue, so no need to define a new "scriptNameExi= sts" error. 7. Similarly, I think the "tooManyScripts" error should be just a stand= ard "overQuota" error. 8. In SieveScript/validate, you specify an "invalidProperties" SetError= if no content/blobId or both. This should instead be a (method-level) i= nvalidArguments error. 9. lastVacationResponse should be of type UTCDate, not Date. (Will need= a reference for the data type too). 10. The /test example request doesn't include an accountId. Cheers, Neil. --ebe69cef4e8d416d9486108bd105a4d7 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Some comments o= n this draft:

   o  Do we need=
/want both "content" and "blobId" in the SieveScript
      object?  It may be simpler to have just one way of specifying
      content and "blobId" is more versatile and doesn't require JSON-
      encoding of the content.  Furthermore, use of the forthcoming(?)
      Blob/set method would avoid the extra roundtrip of having to
      upload the blob first.

=
Yes, I think just blobId will probably be better for this, especial= ly if we have methods for manipulating textual blobs in band.
<= div>
General comments:
  1. Is the contents of= the script meant to be immutable or not? The "content" property is appa= rently mutable, but the "blobId" property is not. This makes no sense.
  2. I find the reference to JSON in the "content" property very c= onfusing. JSON is just the serialisation format and should not be releva= nt here. For that matter, the discussion of Sieve encoding is also confu= sing; since this is defined as just the raw octets of the script, why is= there extra encoding involved? Shouldn't it just be the script data? I = think you are just trying to remind people of how strings are wri= tten in Sieve, but that seems needless and confusing here to me.
  3. The spec says "When creating or updating a script, a client MUST in= clude either a  _content_ or a _blobId_ property." =E2=80=93 this m= eans you can't just update the name of the script. But the name does loo= k like it's meant to be mutable right?
  4. "The id of the SieveS= cript to activate if the create/update/destroy succeeds." <- Which cr= eate/update/destroy? All of them? Or just the one referenced by onSucces= sActivateScript? I'm guessing now you mean the latter, but this was not = clear to me initially (especially because "destroy" is in there, which d= oesn't really make sense).
  5. The "replaceOnCreate" arg feels a= little ugly to me, but I get why it's there and I don't have a better s= uggestion.
  6. I think the semantics of the "alreadyExists" SetE= rror is appropriate for the duplicate name issue, so no need to define a= new "scriptNameExists" error.
  7. Similarly, I think the "tooMa= nyScripts" error should be just a standard "overQuota" error.
    8. In SieveScript/validate, you specify an "invalidProperties" SetError i= f no content/blobId or both. This should instead be a (method-level) inv= alidArguments error.
  8. lastVacationResponse should be of type = UTCDate, not Date. (Will need a reference for the data type too).
  9. The /test example request doesn't include an accountId.
    10. Cheers,
    Neil.
    --ebe69cef4e8d416d9486108bd105a4d7-- From nobody Thu Oct 22 08:03:03 2020 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 8D7813A0FEC for ; Thu, 22 Oct 2020 08:03:02 -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 wCvYMdvSQGVP for ; Thu, 22 Oct 2020 08:03:01 -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 355123A0FD2 for ; Thu, 22 Oct 2020 08:03:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id 9AB6FA24E for ; Thu, 22 Oct 2020 17:02:58 +0200 (CEST) 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 4fpFgvlR1Gxx for ; Thu, 22 Oct 2020 17:02:37 +0200 (CEST) Received: from [192.168.10.127] (unknown [5.158.178.25]) (Authenticated sender: joris@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id 18BFAA1F5 for ; Thu, 22 Oct 2020 17:02:37 +0200 (CEST) To: jmap@ietf.org From: Joris Baum Autocrypt: addr=joris@audriga.com; keydata= mDMEXmiiVxYJKwYBBAHaRw8BAQdAdZHr1ErnL1M6znXii/tmQdbrX2WYv7z2IOX24nQI/IK0 HkpvcmlzIEJhdW0gPGpvcmlzQGF1ZHJpZ2EuY29tPoiWBBMWCAA+FiEEcn/m2ZrBrKtT4eWN /E+o0tJIXvAFAl5oolcCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ/E+o 0tJIXvBxNwD9FTxAqK3hInm0FO8PkbKnoMs39U8uIsyWzZ6OQxNKAqoBAILUwL4+zZ27pJwr cpLaLrbGJ7jFH4gvaXD9pSsVrN4OuDgEXmiiVxIKKwYBBAGXVQEFAQEHQOwg+TuTO26r4K5V BzYwVGK9EXrx6UpBxiubgDlHdY0KAwEIB4h+BBgWCAAmFiEEcn/m2ZrBrKtT4eWN/E+o0tJI XvAFAl5oolcCGwwFCQlmAYAACgkQ/E+o0tJIXvC2HwD/VjK0qWcInLxsNA+4IpgsZeR6U3bO K0NUuXoxZLGiOG8BAJNp3V+nFFgguUohvpSzw7sI4h4QXKVuVMhpG43PHVsD Message-ID: <9c836781-81bd-1bd7-4aa7-9475040d48e0@audriga.com> Date: Thu, 22 Oct 2020 17:02:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: [Jmap] Auth schemes for JMAP Contacts/Calendars 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, 22 Oct 2020 15:03:03 -0000 Hi all, I would like to play around with several service providers that support JMAP Contacts/Calendars to push forward the JMAP standard by extending a JMAP library. While I was able to do some testing with Cyrus and Basic Auth, I was unable to use Basic Auth for Fastmail, since the app password seems to be specific for mail. Is there a preferred way to authenticate without a UI towards Fastmail? Something like an app password not tied to JMAP mail but also JMAP Contacts/Calendars? Regards, Joris Baum --=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 -------------------------------------------------------------------------= - From nobody Thu Oct 22 16:42:11 2020 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 A55A73A09A3 for ; Thu, 22 Oct 2020 16:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 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, NICE_REPLY_A=-0.247, 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=fastmail.com header.b=UCC+JDOV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RXV9Yrcq 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 jzaIHM3TTDB7 for ; Thu, 22 Oct 2020 16:42:07 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5E23A0997 for ; Thu, 22 Oct 2020 16:42:07 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 93A035C00D3; Thu, 22 Oct 2020 19:42:05 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 22 Oct 2020 19:42:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=n M2xNKI5LnDCefiNoZViuJdQYct8vPL08vSn9sqa82E=; b=UCC+JDOVRYwYHQ38L 258F+qurkpryLw7/WhvldNfH8ICaEmOaNoAIBWijH+gosWFhzLmE3fAAK3+iGQat boD+aio+nD43Ko7GFSd/oYlwqJvR//iFRaltc+UKg2pQHS61j2fGE2c1Mk9h0SzO 2KIb/Snwk+2bR8n4Z25BYGo1qP8VsNgUoM9Amvso5NAM5jZN68Z6nlrUSz4gqKMF /5B9wP65dcUKg6U61G91C/hUplPcNmMa2GIxCOtvGG4fwRKEFUNJcPRmKyMvbZmm HlIr5D84sRoTvRX2W2DhAqHCSvKHzR7YRHr0OEBsZ9CSkR2J4X3w2B1Q21ew7aUW 9LfDA== 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=nM2xNKI5LnDCefiNoZViuJdQYct8vPL08vSn9sqa8 2E=; b=RXV9Yrcqz1T/b3RQJ807TsOttacliBehTzU1s+k9hthx417td8glszQy6 SBs01mM1+3RZejJj4gBHWQeREC9wqpPOqLSZTLS+evYJlUTobCVwIZ2t7ihyQcXl AbnO1A+9/bnPbMWlS5vg034fW+d7maYO/2KDVxdPg+s3GLWYM8LmM0Nr2frAFP2I Ps3/Sko8HBNRJ5PihqtwRmvFsyXOpZZEZzhDXKDfYaVSZdTmOFvLW6+vjgyVbiW9 M21PFCZ4LbU9F63U+AC/5MWQBRhdhzvz1XEuDNCN741xZ2F20yQmQZJhDMJvnpEQ IgRXBbFRzLbzLUXI0zFFPOc75wNng== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeelgddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefmvghnucfo uhhrtghhihhsohhnuceomhhurhgthhesfhgrshhtmhgrihhlrdgtohhmqeenucggtffrrg htthgvrhhnpeehhffgteelueevuedthfefuedvueekgfekjeeuuefhtdelheetfffgvdet ueeujeenucfkphepjeegrdejjedrkeehrddvhedtnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 429963280060; Thu, 22 Oct 2020 19:42:05 -0400 (EDT) To: Joris Baum , jmap@ietf.org References: <9c836781-81bd-1bd7-4aa7-9475040d48e0@audriga.com> From: Ken Murchison Message-ID: <9c1d3345-8438-56e4-a302-beaaab6dc02a@fastmail.com> Date: Thu, 22 Oct 2020 19:42:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <9c836781-81bd-1bd7-4aa7-9475040d48e0@audriga.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] Auth schemes for JMAP Contacts/Calendars 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, 22 Oct 2020 23:42:10 -0000 Hi Joris, Fastmail currently isn't allowing public JMAP access to calendars and contacts because the standards have yet to be finalized.  Once they are finalized, and Cyrus is compliant, you can expect to have direct access to your resources via JMAP. On 10/22/20 11:02 AM, Joris Baum wrote: > Hi all, > > I would like to play around with several service providers that support > JMAP Contacts/Calendars to push forward the JMAP standard by extending a > JMAP library. While I was able to do some testing with Cyrus and Basic > Auth, I was unable to use Basic Auth for Fastmail, since the app > password seems to be specific for mail. > > Is there a preferred way to authenticate without a UI towards Fastmail? > Something like an app password not tied to JMAP mail but also JMAP > Contacts/Calendars? > > Regards, > > Joris Baum > -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Thu Oct 22 23:33:55 2020 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 85E343A02BB for ; Thu, 22 Oct 2020 23:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 LiiFL-149MAe for ; Thu, 22 Oct 2020 23:33:52 -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 46B823A02BC for ; Thu, 22 Oct 2020 23:33:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id B2959A1FF; Fri, 23 Oct 2020 08:33:37 +0200 (CEST) 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 trs5HigtxNCB; Fri, 23 Oct 2020 08:33:16 +0200 (CEST) Received: from [192.168.0.94] (HSI-KBW-46-223-162-8.hsi.kabel-badenwuerttemberg.de [46.223.162.8]) (Authenticated sender: joris@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id 6EB85A1F5; Fri, 23 Oct 2020 08:33:16 +0200 (CEST) To: Ken Murchison , jmap@ietf.org References: <9c836781-81bd-1bd7-4aa7-9475040d48e0@audriga.com> <9c1d3345-8438-56e4-a302-beaaab6dc02a@fastmail.com> From: Joris Baum Autocrypt: addr=joris@audriga.com; keydata= mDMEXmiiVxYJKwYBBAHaRw8BAQdAdZHr1ErnL1M6znXii/tmQdbrX2WYv7z2IOX24nQI/IK0 HkpvcmlzIEJhdW0gPGpvcmlzQGF1ZHJpZ2EuY29tPoiWBBMWCAA+FiEEcn/m2ZrBrKtT4eWN /E+o0tJIXvAFAl5oolcCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ/E+o 0tJIXvBxNwD9FTxAqK3hInm0FO8PkbKnoMs39U8uIsyWzZ6OQxNKAqoBAILUwL4+zZ27pJwr cpLaLrbGJ7jFH4gvaXD9pSsVrN4OuDgEXmiiVxIKKwYBBAGXVQEFAQEHQOwg+TuTO26r4K5V BzYwVGK9EXrx6UpBxiubgDlHdY0KAwEIB4h+BBgWCAAmFiEEcn/m2ZrBrKtT4eWN/E+o0tJI XvAFAl5oolcCGwwFCQlmAYAACgkQ/E+o0tJIXvC2HwD/VjK0qWcInLxsNA+4IpgsZeR6U3bO K0NUuXoxZLGiOG8BAJNp3V+nFFgguUohvpSzw7sI4h4QXKVuVMhpG43PHVsD Message-ID: <90d01e10-4a53-66f7-2fb3-409a7aec1896@audriga.com> Date: Fri, 23 Oct 2020 08:33:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <9c1d3345-8438-56e4-a302-beaaab6dc02a@fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Jmap] Auth schemes for JMAP Contacts/Calendars 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, 23 Oct 2020 06:33:54 -0000 Hi Ken, thanks a lot for your fast reply and for clarifying. Do you suggest to play around with Cyrus in the meantime until Fastmail allows access to contacts/calendars? Or is there another software you can recommend for exploring the JMAP contacts/calendars protocol? Regards, Joris On 23.10.20 01:42, Ken Murchison wrote: > Hi Joris, > > Fastmail currently isn't allowing public JMAP access to calendars and > contacts because the standards have yet to be finalized.=C2=A0 Once the= y > are finalized, and Cyrus is compliant, you can expect to have direct > access to your resources via JMAP. > > > On 10/22/20 11:02 AM, Joris Baum wrote: >> Hi all, >> >> I would like to play around with several service providers that suppor= t >> JMAP Contacts/Calendars to push forward the JMAP standard by extending= a >> JMAP library. While I was able to do some testing with Cyrus and Basic= >> Auth, I was unable to use Basic Auth for Fastmail, since the app >> password seems to be specific for mail. >> >> Is there a preferred way to authenticate without a UI towards Fastmail= ? >> Something like an app password not tied to JMAP mail but also JMAP >> Contacts/Calendars? >> >> Regards, >> >> Joris Baum >> --=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 -------------------------------------------------------------------------= - From nobody Thu Oct 22 23:54:09 2020 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 E94363A05D0 for ; Thu, 22 Oct 2020 23:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=LP8fWH9h; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ppnMjmgV 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 7SBdSLroNk9M for ; Thu, 22 Oct 2020 23:54:05 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE98A3A05A6 for ; Thu, 22 Oct 2020 23:54:04 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0A09D5C00E6 for ; Fri, 23 Oct 2020 02:54:04 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Fri, 23 Oct 2020 02:54:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=tr4SS5h o1VZWfQA4O4jUoQP+CDKN3tyJsjcJRAITZSU=; b=LP8fWH9hBk23GQag/Lw7up+ bgVPdI0cqSzaXXrs4zvk5ZL8nA09TDk+j4uQri7MejQyqCbnivGGUJEMsSUQnOr8 aGvCxfBtcUlR7rfm7J/TFT/QPv4vMhFmAdDr/J1aO2T3Y0IA07PH0sDZKREkws8P DHV1FOVfo45+se9IcsrqRqMfVv9eABcR2b4F95dTkpF6HFstnJRyxSr5gmSjOLmI /Qx2H4uMsNGTeF/R8mRbJ0uz1Hg3KWfm/86H32xf+kBtdgjRRTBLhrmpnHEg7oVd lcZnxdtSaWgQkOxfQElO/4FSMbYuiB5qrdZmRn7Mu/88orfZvgGxJD7gThL9zPA= = 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=tr4SS5 ho1VZWfQA4O4jUoQP+CDKN3tyJsjcJRAITZSU=; b=ppnMjmgV5EDQYo7DqtA9m/ CaNDXo7Wg+G93UqE4Ln+7O92ZJWCdlUKP1QFzEDleFQ35KZ6LJuJUbIRmiLVXpEA AZ5HwYtMlKy0XtrxDBSRzKiQ3uwoeliOofZr7nc858KuzNG15TrOdq2GRY9UA9P/ CniUa8w8WzKhmwoU+x7UdZWoo9UO+W57nzRNZ0LyO6Rlq06eMwUIHr8uX3hgKKNX 7pEhCtq5H7Pt1iGiuHbtLJkbuWWC7nUYWncNeLvmo2elBKnPSIFwOkeChtuu+To7 RBOZ120Fbg69o0ngtEPQqLAOkO4Gg6Nm/tUe2jd6fjuKBD1bt6hB5mmfcdWt0ckg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeelgdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnheptdeguefhfe euvefgleekteejleffteekleetiefhjeeiheevteffffeutdetleelnecuffhomhgrihhn pehgihhthhhusgdrtghomhdpjhhmrghprdhiohdprghuughrihhgrgdrtghomhdpthifih htthgvrhdrtghomhdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C15B2180094; Fri, 23 Oct 2020 02:54:02 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-529-g69105b1-fm-20201021.003-g69105b13 Mime-Version: 1.0 Message-Id: In-Reply-To: <90d01e10-4a53-66f7-2fb3-409a7aec1896@audriga.com> References: <9c836781-81bd-1bd7-4aa7-9475040d48e0@audriga.com> <9c1d3345-8438-56e4-a302-beaaab6dc02a@fastmail.com> <90d01e10-4a53-66f7-2fb3-409a7aec1896@audriga.com> Date: Fri, 23 Oct 2020 08:53:05 +0200 From: "Robert Stepanek" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=5d4495ebcd94416db90f2c459d9377c5 Archived-At: Subject: Re: [Jmap] Auth schemes for JMAP Contacts/Calendars 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, 23 Oct 2020 06:54:08 -0000 --5d4495ebcd94416db90f2c459d9377c5 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Joris, For calendars, the Cyrus master branch implements what is also currently= in use at Fastmail. It implements the CalendarEvent and Calendar JMAP o= bject types. The JSEvent implementation is close to the latest spec for = jscalendar. There is also a work-in-progress branch at https://github.com/cyrusimap/= cyrus-imapd/tree/jmap-calendars-01 which aims to implement the latest JM= AP calendars spec draft https://jmap.io/spec-calendars.html. I can't say= when we will merge that on master, but if you want to play with the bra= nch don't hesitate to contact me for any questions! For contacts, the Cyrus implementation substantially lags the latest JMA= P Contacts and JSContact spec drafts. That's because both of these draft= s haven't seen much progress in the past months, and I don't expect that= to change until the calendar specs have settled. Mario Loffredo, the co= -author of JSContact, maintains tools to convert between VCARD and the J= SContact draft object model: https://github.com/consiglionazionaledeller= icerche/jscontact-tools Cheers, Robert On Fri, Oct 23, 2020, at 8:33 AM, Joris Baum wrote: > Hi Ken, >=20 > thanks a lot for your fast reply and for clarifying. Do you suggest to= > play around with Cyrus in the meantime until Fastmail allows access to= > contacts/calendars? Or is there another software you can recommend for= > exploring the JMAP contacts/calendars protocol? >=20 > Regards, >=20 > Joris >=20 >=20 > On 23.10.20 01:42, Ken Murchison wrote: > > Hi Joris, > > > > Fastmail currently isn't allowing public JMAP access to calendars an= d > > contacts because the standards have yet to be finalized. Once they > > are finalized, and Cyrus is compliant, you can expect to have direct= > > access to your resources via JMAP. > > > > > > On 10/22/20 11:02 AM, Joris Baum wrote: > >> Hi all, > >> > >> I would like to play around with several service providers that sup= port > >> JMAP Contacts/Calendars to push forward the JMAP standard by extend= ing a > >> JMAP library. While I was able to do some testing with Cyrus and Ba= sic > >> Auth, I was unable to use Basic Auth for Fastmail, since the app > >> password seems to be specific for mail. > >> > >> Is there a preferred way to authenticate without a UI towards Fastm= ail? > >> Something like an app password not tied to JMAP mail but also JMAP > >> Contacts/Calendars? > >> > >> Regards, > >> > >> Joris Baum > >> > --=20 > Joris Baum > Tel: +49 721 170293 16 > Fax: +49 721 170293 179 >=20 > http://www.audriga.com | http://www.twitter.com/audriga >=20 > ----------------------------------------------------------------------= ---- > 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 = Happel > ----------------------------------------------------------------------= ---- >=20 >=20 > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap >=20 --5d4495ebcd94416db90f2c459d9377c5 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Hi Joris,

    For calendars, the Cyrus master branch implement= s what is also currently in use at Fastmail. It implements the CalendarE= vent and Calendar JMAP object types. The JSEvent implementation is close= to the latest spec for jscalendar.

    There i= s also a work-in-progress branch at https://github.com/cyrusimap/cyr= us-imapd/tree/jmap-calendars-01 which aims to implement the latest J= MAP calendars spec draft https://jmap.io/spec-calendars.html. I can't say when we will merge= that on master, but if you want to play with the branch don't hesitate = to contact me for any questions!

    For contac= ts, the Cyrus implementation substantially lags the latest JMAP Contacts= and JSContact spec drafts. That's because both of these drafts haven't = seen much progress in the past months, and I don't expect that to change= until the calendar specs have settled. Mario Loffredo, the co-author of= JSContact, maintains tools to convert between VCARD and the JSContact d= raft object model: https://github.com/consiglionazionaledellerice= rche/jscontact-tools

    Cheers,
    <= div>Robert

    On Fri, Oct 23, 2020, at 8:33 AM= , Joris Baum wrote:
    Hi Ken,

    thanks a lot for your fast = reply and for clarifying. Do you suggest to
    play around wi= th Cyrus in the meantime until Fastmail allows access to
    c= ontacts/calendars? Or is there another software you can recommend for
    exploring the JMAP contacts/calendars protocol?

    Regards,

    Joris


    On 23.10.20 01:42, Ken Murchison wrote:=
    > Hi Joris,
    >
    > Fast= mail currently isn't allowing public JMAP access to calendars and
    > contacts because the standards have yet to be finalized.&nb= sp; Once they
    > are finalized, and Cyrus is compliant, = you can expect to have direct
    > access to your resource= s via JMAP.
    >
    >
    > On = 10/22/20 11:02 AM, Joris Baum wrote:
    >> Hi all,
    <= /div>
    >>
    >> I would like to play around wi= th several service providers that support
    >> JMAP Co= ntacts/Calendars to push forward the JMAP standard by extending a
    >> JMAP library. While I was able to do some testing with = Cyrus and Basic
    >> Auth, I was unable to use Basic A= uth for Fastmail, since the app
    >> password seems to= be specific for mail.
    >>
    >> Is = there a preferred way to authenticate without a UI towards Fastmail?
    =
    >> Something like an app password not tied to JMAP mail= but also JMAP
    >> Contacts/Calendars?
    = >>
    >> Regards,
    >>
    >> Joris Baum
    >>
    -- <= br>
    Joris Baum
    Tel: +49 721 170293 16
    <= div>Fax: +49 721 170293 179


    -------------------------------------------------------= -------------------
    audriga GmbH | Durlacher Allee 47 | 76= 131 Karlsruhe
    Sitz der Gesellschaft: Karlsruhe - Amtsgeric= ht Mannheim - HRB 713034
    Gesch=C3=A4ftsf=C3=BChrer: Dr. Fr= ank Dengler, Dr.-Ing. Hans-J=C3=B6rg Happel
    --------------= ------------------------------------------------------------


    _______________________________________= ________
    Jmap mailing list


    --5d4495ebcd94416db90f2c459d9377c5-- From nobody Fri Oct 23 00:13:37 2020 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 CF0B83A0969 for ; Fri, 23 Oct 2020 00:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, RCVD_IN_DNSWL_BLOCKED=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 MRar8tn8uLlB for ; Fri, 23 Oct 2020 00:13:35 -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 A9CB63A0965 for ; Fri, 23 Oct 2020 00:13:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id 8FD12A1FF for ; Fri, 23 Oct 2020 09:13:32 +0200 (CEST) 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 zTnQ1SloZsaF for ; Fri, 23 Oct 2020 09:13:10 +0200 (CEST) Received: from [192.168.0.94] (HSI-KBW-46-223-162-8.hsi.kabel-badenwuerttemberg.de [46.223.162.8]) (Authenticated sender: joris@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id CF263A1F5 for ; Fri, 23 Oct 2020 09:13:10 +0200 (CEST) To: jmap@ietf.org References: <9c836781-81bd-1bd7-4aa7-9475040d48e0@audriga.com> <9c1d3345-8438-56e4-a302-beaaab6dc02a@fastmail.com> <90d01e10-4a53-66f7-2fb3-409a7aec1896@audriga.com> From: Joris Baum Autocrypt: addr=joris@audriga.com; keydata= mDMEXmiiVxYJKwYBBAHaRw8BAQdAdZHr1ErnL1M6znXii/tmQdbrX2WYv7z2IOX24nQI/IK0 HkpvcmlzIEJhdW0gPGpvcmlzQGF1ZHJpZ2EuY29tPoiWBBMWCAA+FiEEcn/m2ZrBrKtT4eWN /E+o0tJIXvAFAl5oolcCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ/E+o 0tJIXvBxNwD9FTxAqK3hInm0FO8PkbKnoMs39U8uIsyWzZ6OQxNKAqoBAILUwL4+zZ27pJwr cpLaLrbGJ7jFH4gvaXD9pSsVrN4OuDgEXmiiVxIKKwYBBAGXVQEFAQEHQOwg+TuTO26r4K5V BzYwVGK9EXrx6UpBxiubgDlHdY0KAwEIB4h+BBgWCAAmFiEEcn/m2ZrBrKtT4eWN/E+o0tJI XvAFAl5oolcCGwwFCQlmAYAACgkQ/E+o0tJIXvC2HwD/VjK0qWcInLxsNA+4IpgsZeR6U3bO K0NUuXoxZLGiOG8BAJNp3V+nFFgguUohvpSzw7sI4h4QXKVuVMhpG43PHVsD Message-ID: <38a5a33d-4402-455b-95c8-1aa599bfb3de@audriga.com> Date: Fri, 23 Oct 2020 09:13:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------072E24F98714BA68C1BCF26A" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Auth schemes for JMAP Contacts/Calendars 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, 23 Oct 2020 07:13:37 -0000 This is a multi-part message in MIME format. --------------072E24F98714BA68C1BCF26A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Robert, that already gives me quite a good overview! Thanks. However, I am still a bit confused what you mean by "spec" and "draft". The way I understand it the "specs" are what lives on https://jmap.io/spec.html and is what is supposed to be implemented by client developers (like us), while the IETF "drafts" are still heavily WIP and will gradually merge into https://jmap.io/spec.html in the coming months. Now, you mentioned "JSContact spec drafts". However, there is currently no mention of JSContact at jmap.io . Could you clarify a bit? Regards, Joris On 23.10.20 08:53, Robert Stepanek wrote: > Hi Joris, > > For calendars, the Cyrus master branch implements what is also > currently in use at Fastmail. It implements the CalendarEvent and > Calendar JMAP object types. The JSEvent implementation is close to the > latest spec for jscalendar. > > There is also a work-in-progress branch at > https://github.com/cyrusimap/cyrus-imapd/tree/jmap-calendars-01 which > aims to implement the latest JMAP calendars spec draft > https://jmap.io/spec-calendars.html. I can't say when we will merge > that on master, but if you want to play with the branch don't hesitate > to contact me for any questions! > > For contacts, the Cyrus implementation substantially lags the latest > JMAP Contacts and JSContact spec drafts. That's because both of these > drafts haven't seen much progress in the past months, and I don't > expect that to change until the calendar specs have settled. Mario > Loffredo, the co-author of JSContact, maintains tools to convert > between VCARD and the JSContact draft object model: > https://github.com/consiglionazionaledellericerche/jscontact-tools > > Cheers, > Robert > > On Fri, Oct 23, 2020, at 8:33 AM, Joris Baum wrote: >> Hi Ken, >> >> thanks a lot for your fast reply and for clarifying. Do you suggest to= >> play around with Cyrus in the meantime until Fastmail allows access to= >> contacts/calendars? Or is there another software you can recommend for= >> exploring the JMAP contacts/calendars protocol? >> >> Regards, >> >> Joris >> >> >> On 23.10.20 01:42, Ken Murchison wrote: >> > Hi Joris, >> > >> > Fastmail currently isn't allowing public JMAP access to calendars an= d >> > contacts because the standards have yet to be finalized.=C2=A0 Once = they >> > are finalized, and Cyrus is compliant, you can expect to have direct= >> > access to your resources via JMAP. >> > >> > >> > On 10/22/20 11:02 AM, Joris Baum wrote: >> >> Hi all, >> >> >> >> I would like to play around with several service providers that >> support >> >> JMAP Contacts/Calendars to push forward the JMAP standard by >> extending a >> >> JMAP library. While I was able to do some testing with Cyrus and Ba= sic >> >> Auth, I was unable to use Basic Auth for Fastmail, since the app >> >> password seems to be specific for mail. >> >> >> >> Is there a preferred way to authenticate without a UI towards >> Fastmail? >> >> Something like an app password not tied to JMAP mail but also JMAP >> >> Contacts/Calendars? >> >> >> >> Regards, >> >> >> >> Joris Baum >> >> >> --=C2=A0 >> Joris Baum >> Tel: +49 721 170293 16 >> Fax: +49 721 170293 179 >> >> http://www.audriga.com |=C2=A0http://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 = Happel >> ----------------------------------------------------------------------= ---- >> >> >> _______________________________________________ >> 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 --=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 -------------------------------------------------------------------------= - --------------072E24F98714BA68C1BCF26A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    Hi Robert,

    that already gives me quite a good overview! Thanks.

    However, I am still a bit confused what you mean by "spec" and "draft". The way I understand it the "specs" are what lives on https://jmap.io/spec.html and is what is supposed to be implemented by client developers (like us), while the IETF "drafts" are still heavily WIP and will gradually merge into https://jmap.io/spec.html in the coming months. Now, you mentioned "JSContact spec drafts". However, there is currently no mention of JSContact at jmap.io . Could you clarify a bit?

    Regards,

    Joris


    On 23.10.20 08:53, Robert Stepanek wrote:
    Hi Joris,

    For calendars, the Cyrus master branch implements what is also currently in use at Fastmail. It implements the CalendarEvent and Calendar JMAP object types. The JSEvent implementation is close to the latest spec for jscalendar.

    There is also a work-in-progress branch at https://github.com/cyrusimap/cyrus-imapd/tree/jmap-calendars-01 which aims to implement the latest JMAP calendars spec draft https://jmap.io/spec-calendars.html. I can't say when we will merge that on master, but if you want to play with the branch don't hesitate to contact me for any questions!

    For contacts, the Cyrus implementation substantially lags the latest JMAP Contacts and JSContact spec drafts. That's because both of these drafts haven't seen much progress in the past months, and I don't expect that to change until the calendar specs have settled. Mario Loffredo, the co-author of JSContact, maintains tools to convert between VCARD and the JSContact draft object model: https://github.com/consiglionazionaledellericerche/jscontact-tools

    Cheers,
    Robert

    On Fri, Oct 23, 2020, at 8:33 AM, Joris Baum wrote:
    Hi Ken,

    thanks a lot for your fast reply and for clarifying. Do you suggest to
    play around with Cyrus in the meantime until Fastmail allows access to
    contacts/calendars? Or is there another software you can recommend for
    exploring the JMAP contacts/calendars protocol?

    Regards,

    Joris


    On 23.10.20 01:42, Ken Murchison wrote:
    > Hi Joris,
    >
    > Fastmail currently isn't allowing public JMAP access to calendars and
    > contacts because the standards have yet to be finalized.  Once they
    > are finalized, and Cyrus is compliant, you can expect to have direct
    > access to your resources via JMAP.
    >
    >
    > On 10/22/20 11:02 AM, Joris Baum wrote:
    >> Hi all,
    >>
    >> I would like to play around with several service providers that support
    >> JMAP Contacts/Calendars to push forward the JMAP standard by extending a
    >> JMAP library. While I was able to do some testing with Cyrus and Basic
    >> Auth, I was unable to use Basic Auth for Fastmail, since the app
    >> password seems to be specific for mail.
    >>
    >> Is there a preferred way to authenticate without a UI towards Fastmail?
    >> Something like an app password not tied to JMAP mail but also JMAP
    >> Contacts/Calendars?
    >>
    >> Regards,
    >>
    >> Joris Baum
    >>
    -- 
    Joris Baum
    Tel: +49 721 170293 16
    Fax: +49 721 170293 179


    --------------------------------------------------------------------------
    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
    --------------------------------------------------------------------------


    _______________________________________________
    Jmap mailing list



    _______________________________________________
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
--------------------------------------------------------------------------
    --------------072E24F98714BA68C1BCF26A-- From nobody Fri Oct 23 00:37:58 2020 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 EB24D3A09C4 for ; Fri, 23 Oct 2020 00:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=HpC+NTel; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Vj+erBRN 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 U5yNsSN3GkgJ for ; Fri, 23 Oct 2020 00:37:55 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387B03A09C1 for ; Fri, 23 Oct 2020 00:37:55 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7B3DA5C00C8 for ; Fri, 23 Oct 2020 03:37:54 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Fri, 23 Oct 2020 03:37:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=sQw+T0j Sz1pcf9BCE0oWGZzA5YlEP9+wnMMDU6CsgRo=; b=HpC+NTelvqDSfKah7ZqdHDV HrMaOJFvoOzmzSxbaOf0U8IAqJkHRLqW4f59t5bHfa7BJwrlSVtIDPXlAEcjEdFk YFEz0S0u3C9GAHPEk4mzGkUw9wY9AlGXst1cLf4/7Iq1esgTttb4+3SuuLOKdrek ZwJP9wL/xfxL6gvYrGwtCpaFA2otQDLSmGBTnJlsHeOAZZQ8nIbm0RtG4CS/mwXc YySNOoRkyo1en331u822Ecv/HKHukbSlxdeoyI58eUz7G6Bx7u/tq+0HWEsnlOG2 m1mAPOXF9PyrXQKrNCFtVpRXvc+pRfEw9gHIiUdQgJSAwJFnqUGHBYfLHYFXEGw= = 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=sQw+T0 jSz1pcf9BCE0oWGZzA5YlEP9+wnMMDU6CsgRo=; b=Vj+erBRN5wOarF6hvzUivT fe85yO7tvpP+PI8xkbAMdwMVReS8od3dG2x/xKUMXEVPvf/M01paIgpj4A0Kh/UJ vdHXx4BBXlTWo493xLkCmAOFUjGx8doL1Wqs1K9jBBIHe6Ck7HrMcSquwk3yXj1+ QTD6DoHheZ6IptNb7hDr9OEZvalL1HRofdbiUy1xUmaaMqCN4rT+vfWUu7/kgKBf QC+/73QFFl8oSj8n9nctpAaEk7RKwR7zbTLAx/sWP184zG4uUTFUGD2xlIy05nLE FWWBKNt1IjGV9ziasNwciwrlj3YW/h22fEWMrgWC1YywvLuK+rBsSTuf3ou2aiVQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeelgdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepfeetgeevff ejtdehgeegffdugfeuffeivdekgeeiffefveeltddugeelffeljefhnecuffhomhgrihhn pehjmhgrphdrihhopdhivghtfhdrohhrghdpghhithhhuhgsrdgtohhmpdgruhgurhhigh grrdgtohhmpdhtfihithhtvghrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 38120180094; Fri, 23 Oct 2020 03:37:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-529-g69105b1-fm-20201021.003-g69105b13 Mime-Version: 1.0 Message-Id: In-Reply-To: <38a5a33d-4402-455b-95c8-1aa599bfb3de@audriga.com> References: <9c836781-81bd-1bd7-4aa7-9475040d48e0@audriga.com> <9c1d3345-8438-56e4-a302-beaaab6dc02a@fastmail.com> <90d01e10-4a53-66f7-2fb3-409a7aec1896@audriga.com> <38a5a33d-4402-455b-95c8-1aa599bfb3de@audriga.com> Date: Fri, 23 Oct 2020 09:37:33 +0200 From: "Robert Stepanek" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=a5b09b90b00b496c8ea82ec9ed8da281 Archived-At: Subject: Re: [Jmap] Auth schemes for JMAP Contacts/Calendars 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, 23 Oct 2020 07:37:57 -0000 --a5b09b90b00b496c8ea82ec9ed8da281 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, The Calendars and Contacts specifications at https://jmap.io/spec.html a= re drafts. For calendars, the specification at jmap.io is identical to the latest I= ETF draft https://datatracker.ietf.org/doc/html/draft-ietf-jmap-calendar= s. The JSEvent object type is defined at https://datatracker.ietf.org/do= c/html/draft-ietf-calext-jscalendar. For contacts, the specification at jmap.io is what will be the starting = point for an IETF draft in the near future. The JSContact object type is= defined at https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/ The more implementations exist for these draft specifications, the bette= r. It's the best way to identify improvements for the drafts and helps r= eaching consensus at IETF to publish the RFC. Cheers, Robert On Fri, Oct 23, 2020, at 9:13 AM, Joris Baum wrote: > Hi Robert, > that already gives me quite a good overview! Thanks. > However, I am still a bit confused what you mean by "spec" and "draft"= . The way I understand it the "specs" are what lives on https://jmap.io/= spec.html and is what is supposed to be implemented by client developers= (like us), while the IETF "drafts" are still heavily WIP and will gradu= ally merge into https://jmap.io/spec.html in the coming months. Now, you= mentioned "JSContact spec drafts". However, there is currently no menti= on of JSContact at jmap.io . Could you clarify a bit? > Regards, > Joris >=20 > On 23.10.20 08:53, Robert Stepanek wrote: >> Hi Joris, >>=20 >> For calendars, the Cyrus master branch implements what is also curren= tly in use at Fastmail. It implements the CalendarEvent and Calendar JMA= P object types. The JSEvent implementation is close to the latest spec f= or jscalendar. >>=20 >> There is also a work-in-progress branch at https://github.com/cyrusim= ap/cyrus-imapd/tree/jmap-calendars-01 which aims to implement the latest= JMAP calendars spec draft https://jmap.io/spec-calendars.html. I can't = say when we will merge that on master, but if you want to play with the = branch don't hesitate to contact me for any questions! >>=20 >> For contacts, the Cyrus implementation substantially lags the latest = JMAP Contacts and JSContact spec drafts. That's because both of these dr= afts haven't seen much progress in the past months, and I don't expect t= hat to change until the calendar specs have settled. Mario Loffredo, the= co-author of JSContact, maintains tools to convert between VCARD and th= e JSContact draft object model: https://github.com/consiglionazionaledel= lericerche/jscontact-tools >>=20 >> Cheers, >> Robert >>=20 >> On Fri, Oct 23, 2020, at 8:33 AM, Joris Baum wrote: >>> Hi Ken, >>>=20 >>> thanks a lot for your fast reply and for clarifying. Do you suggest = to >>> play around with Cyrus in the meantime until Fastmail allows access = to >>> contacts/calendars? Or is there another software you can recommend f= or >>> exploring the JMAP contacts/calendars protocol? >>>=20 >>> Regards, >>>=20 >>> Joris >>>=20 >>>=20 >>> On 23.10.20 01:42, Ken Murchison wrote: >>> > Hi Joris, >>> > >>> > Fastmail currently isn't allowing public JMAP access to calendars = and >>> > contacts because the standards have yet to be finalized. Once the= y >>> > are finalized, and Cyrus is compliant, you can expect to have dire= ct >>> > access to your resources via JMAP. >>> > >>> > >>> > On 10/22/20 11:02 AM, Joris Baum wrote: >>> >> Hi all, >>> >> >>> >> I would like to play around with several service providers that s= upport >>> >> JMAP Contacts/Calendars to push forward the JMAP standard by exte= nding a >>> >> JMAP library. While I was able to do some testing with Cyrus and = Basic >>> >> Auth, I was unable to use Basic Auth for Fastmail, since the app >>> >> password seems to be specific for mail. >>> >> >>> >> Is there a preferred way to authenticate without a UI towards Fas= tmail? >>> >> Something like an app password not tied to JMAP mail but also JMA= P >>> >> Contacts/Calendars? >>> >> >>> >> Regards, >>> >> >>> >> Joris Baum >>> >> >>> --=20 >>> Joris Baum >>> Tel: +49 721 170293 16 >>> Fax: +49 721 170293 179 >>>=20 >>> http://www.audriga.com | http://www.twitter.com/audriga >>>=20 >>> --------------------------------------------------------------------= ------ >>> 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=B6r= g Happel >>> --------------------------------------------------------------------= ------ >>>=20 >>>=20 >>> _______________________________________________ >>> Jmap mailing list >>> Jmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/jmap >>>=20 >>=20 >>=20 >> _______________________________________________ Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap >>=20 > --=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 Ha= ppel ------------------------------------------------------------------------= -- > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap >=20 --a5b09b90b00b496c8ea82ec9ed8da281 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Hi,

    The Calendars and Contacts specifications at https://jmap.io/spec.html are draf= ts.

    For calendars, the specification at jma= p.io is identical to the latest IETF draft https://datatracker.ietf.= org/doc/html/draft-ietf-jmap-calendars. The JSEvent object type is d= efined at https://datatracker.ietf.org/doc/html/draft-ietf-calext= -jscalendar.

    For contacts, the specific= ation at jmap.io is what will be the starting point for an IETF draft in= the near future. The JSContact object type is defined at https://datatr= acker.ietf.org/doc/draft-ietf-jmap-jscontact/

    The more implementations exist for these draft specifications, th= e better. It's the best way to identify improvements for the drafts and = helps reaching consensus at IETF to publish the RFC.

    <= /div>
    Cheers,
    Robert

    On F= ri, Oct 23, 2020, at 9:13 AM, Joris Baum wrote:

    Hi Robert,

    that already giv= es me quite a good overview! Thanks.

    However, I am still a bit= confused what you mean by "spec" and "draft". The way I understand it the "specs" are what lives on ht= tps://jmap.io/spec.html and is what is supposed to be implemented by client developers (like us), while the IETF "drafts" are still heavily WIP and will gradually merge into http= s://jmap.io/spec.html in the coming months. Now, you mentioned "JSContact spec drafts". However, there is currently no mention of= JSContact at jmap.io . Could you clarify a bit?

    Regards,=

    Joris


    On = 23.10.20 08:53, Robert Stepanek wrote:
    Hi Joris,
    =
    For calendars, the Cyrus master branch implements what is= also currently in use at Fastmail. It implements the CalendarEvent and Calendar JMAP object types. The JSEvent implementation is close to the latest spec for jscalendar.

    There is also a work-in-progress branch at h= ttps://github.com/cyrusimap/cyrus-imapd/tree/jmap-calendars-01 which= aims to implement the latest JMAP calendars spec draft https://jmap.io/spec-calendars.html.= I can't say when we will merge that on master, but if you want to play with the branch don't hesitate to contact me for any questions!

    For contacts, the Cyrus = implementation substantially lags the latest JMAP Contacts and JSContact spec drafts. That's because both of these drafts haven't seen much progress in the past months, and I don't expect that to change until the calendar specs have settled. Mario Loffredo, the co-author of JSContact, maintains tools to convert between VCARD and the JSContact draft= object model: https://github.com/consiglionazionaledeller= icerche/jscontact-tools

    Cheers,
    Robert

    On Fri, Oct 23, 2020, at 8:33= AM, Joris Baum wrote:
    Hi Ken,

    thanks a lot for you= r fast reply and for clarifying. Do you suggest to
    play around with Cyrus in the meantim= e until Fastmail allows access to
    contacts/calendars? Or is there= another software you can recommend for
    exploring the JMAP contacts/calend= ars protocol?

    Regards,

    Joris


    On 23.10.20 0= 1:42, Ken Murchison wrote:
    > Hi Joris,
    &g= t;
    > Fastmail currently isn't allowing public JMAP acce= ss to calendars and
    > contacts because the stand= ards have yet to be finalized.  Once they
    > are finalized, a= nd Cyrus is compliant, you can expect to have direct
    > access to your resources via= JMAP.
    >
    >
    > On 10/22= /20 11:02 AM, Joris Baum wrote:
    >> Hi all,
    =
    >>
    >> I would like to play around with se= veral service providers that support
    >> JMAP Contacts/Ca= lendars to push forward the JMAP standard by extending a
    >> JMAP library. W= hile I was able to do some testing with Cyrus and Basic
    >> Auth, I was unable= to use Basic Auth for Fastmail, since the app
    >> password seems to be spec= ific for mail.
    >>
    >> Is there a = preferred way to authenticate without a UI towards Fastmail?
    >> Something like an = app password not tied to JMAP mail but also JMAP
    >> Contacts/Calendars?<= br>
    >>
    >> Regards,
    >= ;>
    >> Joris Baum
    >>
    =
    -- 
    Joris Baum
    Tel: +49 721 170293= 16
    Fax: +49 721 170293 179

    <= a href=3D"http://www.audriga.com">http://www.audriga.com | http://www.twitter.com/audriga




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

    --=20=

Joris Baum
Tel: +49 721 170293 16
Fax: +49 721 170293 179

ht=
tp://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 Ha=
ppel
------------------------------------------------------------------------=
--
    _______________________________________________
    Jmap mailing list
    <= div>

    --a5b09b90b00b496c8ea82ec9ed8da281-- From nobody Fri Oct 23 00:50:32 2020 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 17B073A09E7 for ; Fri, 23 Oct 2020 00:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, 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 OIa9jQiqGnmB for ; Fri, 23 Oct 2020 00:50:28 -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 DAF4C3A09E4 for ; Fri, 23 Oct 2020 00:50:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id 8C53CA1FF for ; Fri, 23 Oct 2020 09:50:25 +0200 (CEST) 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 fPINHVkf3K0T for ; Fri, 23 Oct 2020 09:50:03 +0200 (CEST) Received: from [192.168.0.94] (HSI-KBW-46-223-162-8.hsi.kabel-badenwuerttemberg.de [46.223.162.8]) (Authenticated sender: joris@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id D396DA1F5 for ; Fri, 23 Oct 2020 09:50:03 +0200 (CEST) To: jmap@ietf.org References: <9c836781-81bd-1bd7-4aa7-9475040d48e0@audriga.com> <9c1d3345-8438-56e4-a302-beaaab6dc02a@fastmail.com> <90d01e10-4a53-66f7-2fb3-409a7aec1896@audriga.com> <38a5a33d-4402-455b-95c8-1aa599bfb3de@audriga.com> From: Joris Baum Autocrypt: addr=joris@audriga.com; keydata= mDMEXmiiVxYJKwYBBAHaRw8BAQdAdZHr1ErnL1M6znXii/tmQdbrX2WYv7z2IOX24nQI/IK0 HkpvcmlzIEJhdW0gPGpvcmlzQGF1ZHJpZ2EuY29tPoiWBBMWCAA+FiEEcn/m2ZrBrKtT4eWN /E+o0tJIXvAFAl5oolcCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ/E+o 0tJIXvBxNwD9FTxAqK3hInm0FO8PkbKnoMs39U8uIsyWzZ6OQxNKAqoBAILUwL4+zZ27pJwr cpLaLrbGJ7jFH4gvaXD9pSsVrN4OuDgEXmiiVxIKKwYBBAGXVQEFAQEHQOwg+TuTO26r4K5V BzYwVGK9EXrx6UpBxiubgDlHdY0KAwEIB4h+BBgWCAAmFiEEcn/m2ZrBrKtT4eWN/E+o0tJI XvAFAl5oolcCGwwFCQlmAYAACgkQ/E+o0tJIXvC2HwD/VjK0qWcInLxsNA+4IpgsZeR6U3bO K0NUuXoxZLGiOG8BAJNp3V+nFFgguUohvpSzw7sI4h4QXKVuVMhpG43PHVsD Message-ID: <71bcbdd3-c09f-263f-780d-144d390efa3c@audriga.com> Date: Fri, 23 Oct 2020 09:50:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2E7794FBFFECE4C01A3B02AB" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Auth schemes for JMAP Contacts/Calendars 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, 23 Oct 2020 07:50:30 -0000 This is a multi-part message in MIME format. --------------2E7794FBFFECE4C01A3B02AB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi, thanks for clarifying! That was the piece of information I was missing :) . Regards, Joris On 23.10.20 09:37, Robert Stepanek wrote: > Hi, > > The Calendars and Contacts specifications at https://jmap.io/spec.html > are drafts. > > For calendars, the specification at jmap.io is identical to the latest > IETF draft > https://datatracker.ietf.org/doc/html/draft-ietf-jmap-calendars. The > JSEvent object type is defined at > https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar. > > For contacts, the specification at jmap.io is what will be the > starting point for an IETF draft in the near future. The JSContact > object type is defined at > https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/ > > The more implementations exist for these draft specifications, the > better. It's the best way to identify improvements for the drafts and > helps reaching consensus at IETF to publish the RFC. > > Cheers, > Robert > > On Fri, Oct 23, 2020, at 9:13 AM, Joris Baum wrote: >> >> Hi Robert, >> >> that already gives me quite a good overview! Thanks. >> >> However, I am still a bit confused what you mean by "spec" and >> "draft". The way I understand it the "specs" are what lives on >> https://jmap.io/spec.html and is what is supposed to be implemented >> by client developers (like us), while the IETF "drafts" are still >> heavily WIP and will gradually merge into https://jmap.io/spec.html >> in the coming months. Now, you mentioned "JSContact spec drafts". >> However, there is currently no mention of JSContact at jmap.io . >> Could you clarify a bit? >> >> Regards, >> >> Joris >> >> >> On 23.10.20 08:53, Robert Stepanek wrote: >>> Hi Joris, >>> >>> For calendars, the Cyrus master branch implements what is also >>> currently in use at Fastmail. It implements the CalendarEvent and >>> Calendar JMAP object types. The JSEvent implementation is close to >>> the latest spec for jscalendar. >>> >>> There is also a work-in-progress branch at >>> https://github.com/cyrusimap/cyrus-imapd/tree/jmap-calendars-01 >>> which aims to implement the latest JMAP calendars spec draft >>> https://jmap.io/spec-calendars.html. I can't say when we will merge >>> that on master, but if you want to play with the branch don't >>> hesitate to contact me for any questions! >>> >>> For contacts, the Cyrus implementation substantially lags the latest >>> JMAP Contacts and JSContact spec drafts. That's because both of >>> these drafts haven't seen much progress in the past months, and I >>> don't expect that to change until the calendar specs have settled. >>> Mario Loffredo, the co-author of JSContact, maintains tools to >>> convert between VCARD and the JSContact draft object model: >>> https://github.com/consiglionazionaledellericerche/jscontact-tools >>> >>> Cheers, >>> Robert >>> >>> On Fri, Oct 23, 2020, at 8:33 AM, Joris Baum wrote: >>>> Hi Ken, >>>> >>>> thanks a lot for your fast reply and for clarifying. Do you suggest to >>>> play around with Cyrus in the meantime until Fastmail allows access to >>>> contacts/calendars? Or is there another software you can recommend for >>>> exploring the JMAP contacts/calendars protocol? >>>> >>>> Regards, >>>> >>>> Joris >>>> >>>> >>>> On 23.10.20 01:42, Ken Murchison wrote: >>>> > Hi Joris, >>>> > >>>> > Fastmail currently isn't allowing public JMAP access to calendars and >>>> > contacts because the standards have yet to be finalized.  Once they >>>> > are finalized, and Cyrus is compliant, you can expect to have direct >>>> > access to your resources via JMAP. >>>> > >>>> > >>>> > On 10/22/20 11:02 AM, Joris Baum wrote: >>>> >> Hi all, >>>> >> >>>> >> I would like to play around with several service providers that >>>> support >>>> >> JMAP Contacts/Calendars to push forward the JMAP standard by >>>> extending a >>>> >> JMAP library. While I was able to do some testing with Cyrus and >>>> Basic >>>> >> Auth, I was unable to use Basic Auth for Fastmail, since the app >>>> >> password seems to be specific for mail. >>>> >> >>>> >> Is there a preferred way to authenticate without a UI towards >>>> Fastmail? >>>> >> Something like an app password not tied to JMAP mail but also JMAP >>>> >> Contacts/Calendars? >>>> >> >>>> >> Regards, >>>> >> >>>> >> Joris Baum >>>> >> >>>> --  >>>> 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 >>>> -------------------------------------------------------------------------- >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> -- >> 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 >> -------------------------------------------------------------------------- >> _______________________________________________ >> 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 -- 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 -------------------------------------------------------------------------- --------------2E7794FBFFECE4C01A3B02AB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    Hi,

    thanks for clarifying! That was the piece of information I was missing :) .

    Regards,

    Joris


    On 23.10.20 09:37, Robert Stepanek wrote:
    Hi,

    The Calendars and Contacts specifications at https://jmap.io/spec.html are drafts.

    For calendars, the specification at jmap.io is identical to the latest IETF draft https://datatracker.ietf.org/doc/html/draft-ietf-jmap-calendars. The JSEvent object type is defined at https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar.

    For contacts, the specification at jmap.io is what will be the starting point for an IETF draft in the near future. The JSContact object type is defined at https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/

    The more implementations exist for these draft specifications, the better. It's the best way to identify improvements for the drafts and helps reaching consensus at IETF to publish the RFC.

    Cheers,
    Robert

    On Fri, Oct 23, 2020, at 9:13 AM, Joris Baum wrote:

    Hi Robert,

    that already gives me quite a good overview! Thanks.

    However, I am still a bit confused what you mean by "spec" and "draft". The way I understand it the "specs" are what lives on https://jmap.io/spec.html and is what is supposed to be implemented by client developers (like us), while the IETF "drafts" are still heavily WIP and will gradually merge into https://jmap.io/spec.html in the coming months. Now, you mentioned "JSContact spec drafts". However, there is currently no mention of JSContact at jmap.io . Could you clarify a bit?

    Regards,

    Joris


    On 23.10.20 08:53, Robert Stepanek wrote:
    Hi Joris,

    For calendars, the Cyrus master branch implements what is also currently in use at Fastmail. It implements the CalendarEvent and Calendar JMAP object types. The JSEvent implementation is close to the latest spec for jscalendar.

    There is also a work-in-progress branch at https://github.com/cyrusimap/cyrus-imapd/tree/jmap-calendars-01 which aims to implement the latest JMAP calendars spec draft https://jmap.io/spec-calendars.html. I can't say when we will merge that on master, but if you want to play with the branch don't hesitate to contact me for any questions!

    For contacts, the Cyrus implementation substantially lags the latest JMAP Contacts and JSContact spec drafts. That's because both of these drafts haven't seen much progress in the past months, and I don't expect that to change until the calendar specs have settled. Mario Loffredo, the co-author of JSContact, maintains tools to convert between VCARD and the JSContact draft object model: https://github.com/consiglionazionaledellericerche/jscontact-tools

    Cheers,
    Robert

    On Fri, Oct 23, 2020, at 8:33 AM, Joris Baum wrote:
    Hi Ken,

    thanks a lot for your fast reply and for clarifying. Do you suggest to
    play around with Cyrus in the meantime until Fastmail allows access to
    contacts/calendars? Or is there another software you can recommend for
    exploring the JMAP contacts/calendars protocol?

    Regards,

    Joris


    On 23.10.20 01:42, Ken Murchison wrote:
    > Hi Joris,
    >
    > Fastmail currently isn't allowing public JMAP access to calendars and
    > contacts because the standards have yet to be finalized.  Once they
    > are finalized, and Cyrus is compliant, you can expect to have direct
    > access to your resources via JMAP.
    >
    >
    > On 10/22/20 11:02 AM, Joris Baum wrote:
    >> Hi all,
    >>
    >> I would like to play around with several service providers that support
    >> JMAP Contacts/Calendars to push forward the JMAP standard by extending a
    >> JMAP library. While I was able to do some testing with Cyrus and Basic
    >> Auth, I was unable to use Basic Auth for Fastmail, since the app
    >> password seems to be specific for mail.
    >>
    >> Is there a preferred way to authenticate without a UI towards Fastmail?
    >> Something like an app password not tied to JMAP mail but also JMAP
    >> Contacts/Calendars?
    >>
    >> Regards,
    >>
    >> Joris Baum
    >>
    -- 
    Joris Baum
    Tel: +49 721 170293 16
    Fax: +49 721 170293 179


    --------------------------------------------------------------------------
    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
    --------------------------------------------------------------------------


    _______________________________________________
    Jmap mailing list



    _______________________________________________
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
--------------------------------------------------------------------------
    _______________________________________________
    Jmap mailing list



    _______________________________________________
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
--------------------------------------------------------------------------
    --------------2E7794FBFFECE4C01A3B02AB-- From nobody Fri Oct 23 14:17:42 2020 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 11A883A10C5; Fri, 23 Oct 2020 14:15:48 -0700 (PDT) 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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348774806.5087.10961523944868080170@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:15:48 -0700 Archived-At: Subject: [Jmap] jmap - Requested session has been scheduled for IETF 109 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, 23 Oct 2020 21:15:51 -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 (1:00 requested) Monday, 16 November 2020, Session II 1430-1530 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/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): 1 Hour Number of Attendees: 15 Conflicts to Avoid: Chair Conflict: calext extra Technology Overlap: uta httpbis emailcore dmarc People who must be present: Barry Leiba Alexey Melnikov Jim Fenton Neil Jenkins Bron Gondwana Resources Requested: Special Requests: ---------------------------------------------------------