Re: [Jmap] Representing default calendar/identity

Joris Baum <joris@audriga.com> Wed, 22 February 2023 17:03 UTC

Return-Path: <joris@audriga.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 97362C1522AB for <jmap@ietfa.amsl.com>; Wed, 22 Feb 2023 09:03:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 mrY0gxywEJ2D for <jmap@ietfa.amsl.com>; Wed, 22 Feb 2023 09:03:12 -0800 (PST)
Received: from mail.audriga.com (mail.audriga.com [176.221.42.35]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 EF143C151522 for <jmap@ietf.org>; Wed, 22 Feb 2023 09:03:11 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id 903B1A2A2; Wed, 22 Feb 2023 18:03:08 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mail.audriga.com
Received: from mail.audriga.com ([127.0.0.1]) by localhost (mail.audriga.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnXuN2lBXU5X; Wed, 22 Feb 2023 18:03:06 +0100 (CET)
Received: from [192.168.10.127] (ip-109-090-161-242.um36.pools.vodafone-ip.de [109.90.161.242]) (Authenticated sender: joris@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id 080C5A180; Wed, 22 Feb 2023 18:03:06 +0100 (CET)
Content-Type: multipart/alternative; boundary="------------D9Pgrh5dR6wgNtzQWzm9cc8P"
Message-ID: <54bf3a6f-d7fa-6549-87c6-b08cadfb4481@audriga.com>
Date: Wed, 22 Feb 2023 18:03:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0
From: Joris Baum <joris@audriga.com>
To: Neil Jenkins <neilj=40fastmailteam.com@dmarc.ietf.org>
References: <e2ee7c8a-8e1c-49f1-b5f7-f1e23eb686c5@dogfoodapp.fastmail.com> <9eda9411-923c-6cb4-92fb-e5dab57f10ef@audriga.com> <1d3014cd-05d5-43c5-bfec-f0c425659816@dogfoodapp.fastmail.com>
Content-Language: en-US
Cc: IETF JMAP Mailing List <jmap@ietf.org>
In-Reply-To: <1d3014cd-05d5-43c5-bfec-f0c425659816@dogfoodapp.fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/tU68Up4HEaqWV0f5MYUHGKRTO0o>
Subject: Re: [Jmap] Representing default calendar/identity
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Feb 2023 17:03:16 -0000

Hi Neil,


On 30.01.23 04:57, Neil Jenkins wrote:
>
>
>> I agree with you and like that it is less heavyweight now. However, I 
>> still do not like that we have two ways of defining roles when JMAP 
>> Mail already uses a property "role" for the same purpose [1].
>
> I guess the key question here is whether it is the same purpose or 
> not. I'm not convinced "isDefault" is a role, especially not when it 
> comes to ParticipantIdentity.

OK. I am merely talking about Calendar Folders here, not 
ParticipantIdentity.

I have not seen it from that angle. My thought was that a calendar with 
a special role (like "birthdays") would not be the default calendar.

So what you are saying is that we are talking about separate things: I 
am suggesting to have different roles for calendars (like the commonly 
seen "contact birthdays" calendar) while you are suggesting to have a 
way to identify the default folder. If I understand you correctly you 
are suggesting that the default calendar may additionally have a special 
role/purpose as well.

I think that is quite uncommon, but I think it would be fine to model it 
in JMAP Calendars as two different properties.

> Do you have any other roles in mind? What would a "birthdays" role 
> mean (how would it be treated differently by a client)?

Another role that I have in mind is "holidays". Typically, 
special-purpose calendar folders are automatically generated and need to 
be handled differently from a normal calendar. Identifying them via a 
special property helps client to avoid identifying them by calendar 
folder names (which are typically localized and vendor-specific).

A "birthday" role would mean that the CalendarEvents in the calendar are 
merely contact birthdays. Clients can then use that CalendarEvent data 
to link that with contacts present on a device or provide users with a 
special preference for upcoming birthday notifications.


I think that having a way to identify special purpose calendars would 
not only be important for us but also for various other vendors. If we 
do not come up with a standardized way in JMAP Calendars vendors are 
likely to either use the calendar folder name as a workaround or come up 
with their own extension.


Regards,


Joris

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

http://www.audriga.com  |http://www.twitter.com/audriga

--------------------------------------------------------------------------
audriga GmbH | Alter Schlachthof 57 | 76137 Karlsruhe
Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
--------------------------------------------------------------------------