[Jmap] Re: Mahesh Jethanandani's Discuss on draft-ietf-jmap-contacts-09: (with DISCUSS and COMMENT)

Mahesh Jethanandani <mjethanandani@gmail.com> Thu, 06 June 2024 19:00 UTC

Return-Path: <mjethanandani@gmail.com>
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 245F4C14F5F4; Thu, 6 Jun 2024 12:00:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFLCrsQj5KOu; Thu, 6 Jun 2024 12:00:08 -0700 (PDT)
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC01BC14EB17; Thu, 6 Jun 2024 12:00:08 -0700 (PDT)
Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-2c1a99b75d8so1020382a91.3; Thu, 06 Jun 2024 12:00:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717700408; x=1718305208; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=9TeaZ6f6UijMZKfgOkF3rZ5NpTM6fHFPcBYwIm0g3oQ=; b=M5xpon3w+tI23JfaQc0iYVE963FYdsZBlSGjmxMlZGrDb/GM85JXVJFENkWf62Op4r ltUb0peF0zTp2prZ3pVoyk+jrMTIug0VebM3+dU+AQ++mVGOmO+A/YMSS9QWMhUekO67 EOkhnJ5x4ADpSBhgF2PawRZNh0s5j5EYxOmR2oxe6OkUzUyTYqgf0jigQJVAfm7SPFrN Tm+S81i+aaCRzTv/BXn3X4tKUV6uYXkxZ+4IUKQwiKrU7zbHULu8Cu2zYhAui4cxq5XN uNbIdev9ZAAqHKw9CksWKl0bNwCF6JHNtZpBMUL50/Fr+INOLA8osZpkBLofnsjT9gRB nmOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717700408; x=1718305208; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9TeaZ6f6UijMZKfgOkF3rZ5NpTM6fHFPcBYwIm0g3oQ=; b=BlpaapzDsrpSrbonqJiKmpE4pj44UjvqYcCnaB73Ct9XPtc8KbveP0scOIa4DDXooN 4v+Jqna3CaxnQ2v+gF68CgUY5A2S+zFQf1mcV1Ywp3AO5OwhsDp4ER2VCn7ic1o9aYsO Jah71H6WJuM85dTfuiUNLYiDaK+kxJFt7LO2/vZ9wyPPqsp3KuNbSBFeQtVUy/bfo6VU j8Bwlxou1z+hVx9PbP9UcCu/Hk69y9BXtoZ7fczB5qubainhFzBR3Roedj5fvwVOQuJr yK8qfbphkouaXP8IQyIID99UWvJzYh0l2hBt3v0kVWbzTBFVeTycM9QbyHX9WpH/G8ht 9W2Q==
X-Forwarded-Encrypted: i=1; AJvYcCU+EZpSETt5vPl9GW3LWM6NfXXSNrh5XVrnE+W9cGS/bv9N35XrE+h16scO8KSdeBTRoPAV2ufcT6NZQjkg4VW7B/oyZE+6tB6pSr2jpX4OupVDtxHxkSBazySZiXQgOSK+sAKJdq3dqPbU+W7UISJFoyqb/PPw
X-Gm-Message-State: AOJu0YymhQmh9r5GO403G5NcwGDxxuHsE+gBxEMKmZ4op1IGEU74cBp2 LBmye615cI2TXxn7QJA25fYH+UjeQDhiqGe/L/w+7scAF3quXsw/a7mRaA==
X-Google-Smtp-Source: AGHT+IEwg/lOj7GQoG1AJprzzf8SCgIkqQlNBvzWXSldtw2evuT0ZprZXbtwWwR9JlqFCwr43C0BmQ==
X-Received: by 2002:a17:90b:2390:b0:2c2:8900:5099 with SMTP id 98e67ed59e1d1-2c2bcaf9544mr408554a91.24.1717700407939; Thu, 06 Jun 2024 12:00:07 -0700 (PDT)
Received: from smtpclient.apple ([70.234.233.187]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2c2806399fasm3999498a91.6.2024.06.06.12.00.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jun 2024 12:00:05 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <10E9B9FE-CC30-4624-8C4C-B036617945E5@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AAB6B666-9B45-4D88-A4BE-5D200C245121"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\))
Date: Thu, 06 Jun 2024 12:00:03 -0700
In-Reply-To: <757b8e8b-ef9c-461a-86ac-82f861ab9d94@dogfoodapp.fastmail.com>
To: Neil Jenkins <neilj@fastmailteam.com>
References: <171625301728.10738.743002934797335476@ietfa.amsl.com> <7a00bc9d-d339-4a31-b566-12ceaf3841d5@dogfoodapp.fastmail.com> <1962CBFE-3ECB-436D-959D-23DFD60AA303@gmail.com> <757b8e8b-ef9c-461a-86ac-82f861ab9d94@dogfoodapp.fastmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.15)
Message-ID-Hash: RTP3YQGSZDXAY7KNX3PTDD55GUL22532
X-Message-ID-Hash: RTP3YQGSZDXAY7KNX3PTDD55GUL22532
X-MailFrom: mjethanandani@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jmap.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: The IESG <iesg@ietf.org>, draft-ietf-jmap-contacts@ietf.org, jmap-chairs@ietf.org, IETF JMAP Mailing List <jmap@ietf.org>, Jim Fenton <fenton@bluepopcorn.net>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Jmap] Re: Mahesh Jethanandani's Discuss on draft-ietf-jmap-contacts-09: (with DISCUSS and COMMENT)
List-Id: JSON Message Access Protocol <jmap.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/k0kFHzKOMK7FE26jWwjCJFsMMLU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Owner: <mailto:jmap-owner@ietf.org>
List-Post: <mailto:jmap@ietf.org>
List-Subscribe: <mailto:jmap-join@ietf.org>
List-Unsubscribe: <mailto:jmap-leave@ietf.org>

Hi Neil,

> On Jun 5, 2024, at 11:02 PM, Neil Jenkins <neilj@fastmailteam.com> wrote:
> 
> On Mon, 3 Jun 2024, at 08:31, Mahesh Jethanandani wrote:
>> Thanks for that explanation. How about this?
>> 
>> OLD:
>> If false, any attempt to destroy an AddressBook that still has ContactCard in it will be rejected with an addressBookHasContentsSetError. If true, any ContactCards that were in the AddressBook will be removed from it, and if in no other AddressBooks they will be destroyed.
>> 
>> NEW:
>> If false, any attempt to destroy an AddressBook that still has ContactCard in it will be rejected with an addressBookHasContentsSetError. If true, any ContactCard that is in the AddressBook that is set to be destroyed. will be removed from it, and if the ContactCard does not exist in any other AddressBooks it will be destroyed.
> 
> Thanks. I've tweaked it slightly but kept the substance of your rephrasing:
> 
> If false, any attempt to destroy an AddressBook that still has a ContactCard in it will be rejected with an addressBookHasContents SetError. If true, any ContactCard that is in the AddressBook will be removed from it, and if such a ContactCard does not belong to any other AddressBook it will be destroyed.

Ok.

> 
>> My question is about a ContactCard that is present in multiple AddressBooks. Take your example above, Bill appears in two AddressBooks, Work and Personal. And I will take the example of Apple’s Contacts App that I use. I use the search capability in the App to find the ContactCard for Bill, find it, select it, and hit the delete button. What happens?
> 
> Well, the exact answer is that Apple's Contacts app currently only supports CardDAV, which does not support a contact card belonging to more than one address book. So this will destroy the card.
> 
> A server that supports both CardDAV and JMAP Contacts can choose either:
> To limit contacts to also only being in one address book (via the maxAddressBooksPerCard capability <https://www.ietf.org/archive/id/draft-ietf-jmap-contacts-09.html#name-addition-to-the-capabilitie>).
Kind of limiting.
> To support an implementation-specific mapping. I would expect at Fastmail for example we would implement this as just removing it from the single address book, not destroying the card and thus removing it from both.
Makes sense. 

In other words, JMAP does not want to mandate what the behavior of a ContactCard that exist in multiple AddressBooks, look like, when it is removed. That is kind of unfortunate, as the expected behavior will vary amongst implementations, with a user not sure what option is implemented. Did the WG consider the question, and agreed that it was ok with the ambiguity of the behavior?

> Similarly, if Apple's Contacts client added support for JMAP Contacts, it could make a UI decision of what to do in this instance, but that is independent of the API exposed.
> 
>> Based on all the explanations, what I understand is:
>> remove: A ContactCard can be removed from an AddressBook, but MAY NOT be destroyed.
>> destroy: Once a ContactCard is removed from the last AddressBook that it is existed it, it is destroyed
> 
> This doesn't make sense to me, perhaps because I'm coming from a JMAP core understanding first. JMAP is at it's heart a CRUD mapping. So if I have a ContactCard I can either update it (modify a property on the object) or destroy it. The AddressBook(s) that a ContactCard is in are modelled as a property on the ContactCard containing a set of AddressBook ids. A ContactCard MUST belong to at least one AddressBook.
> 
> Therefore, you can either:
> Update the contact card to add or remove AddressBook ids, i.e. to add or remove it from an address book. But you can't violate the constraint that it MUST belong to at least one address book via an update.
> Destroy the contact card.
> Does that clarify?

Yes, it does, and thanks.

> 
> Cheers,
> Neil.


Mahesh Jethanandani
mjethanandani@gmail.com