[calsify] non-CSS-named colors for events

Ricardo Signes <rjbs@semiotic.systems> Thu, 09 June 2022 16:28 UTC

Return-Path: <rjbs@semiotic.systems>
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E1BC157B4F for <calsify@ietfa.amsl.com>; Thu, 9 Jun 2022 09:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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=semiotic.systems header.b=rw4kvTHA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=j4B/qYT8
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 9S5vBOXlBG7M for <calsify@ietfa.amsl.com>; Thu, 9 Jun 2022 09:28:23 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB730C14F613 for <calsify@ietf.org>; Thu, 9 Jun 2022 09:28:23 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 85B445C00CF for <calsify@ietf.org>; Thu, 9 Jun 2022 12:28:22 -0400 (EDT)
Received: from imap43 ([10.202.2.93]) by compute4.internal (MEProxy); Thu, 09 Jun 2022 12:28:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= semiotic.systems; h=cc:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm2; t=1654792102; x=1654878502; bh=19flNGijxV FsSZvVTTFk8mj+c+ixUfsccyFFZvkR5j0=; b=rw4kvTHAWQaJaDIhN5qen47Grw JDq3reeTLbo/UzxTzdoFiIyMcPeikFEMALoHcuNSCjqaRoE4+vJRoxvu2d1AO6FN 67zlMCO2DBL3c6IUemlx7oe1J1FEI/xpp8s2/hS4zHMAeTlqHBd7a2kg7fljni8y o3UW53B2k0s96Xto8vzJkr8wZfJRFHYXl0EX++Jlw9/I/cF6EiSSNaMcWibDTBQN UZmVg0KB+IiSpzHmtGKA+2s4usvHcwpgNKYguFs4v2GPVTm6z6MoICrHjbXUQXqF pcZZmhELw13XLmGaqwvy/0v3ra/6GnV/ILOhee4Gsg1l3cwYJsCEFVZN8sDA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1654792102; x= 1654878502; bh=19flNGijxVFsSZvVTTFk8mj+c+ixUfsccyFFZvkR5j0=; b=j 4B/qYT8pT4y5mO5xMWOtjT4IgYmLWxwg/q/6OLhRmmuBxlPEWIkDcg41kJgCECyR pDlBn221IfLMrwDa2kLhqpZz+afDQn+i/CUZ/qn6UbEVhxyjovXMJEvTjb+ulGoq 8mxKNHqGdPtnSnOVKzUb8Q+maxYmpWmCsrNYJJVaN2AyeqBjQuERCrDu2uuc3Ha8 FAedhMUof7tqqLce4cWkux38Un+yidAX+TKbDegRxWTZwEw3BROZy+O/8bTlMZoC insg8Y9lWCLdzAwGkxHhHekCVUifrBnct3HD7XmyE4iUCPX57jfVE+o11qU7drXH lYKaOQqCZcZq1x6tTz7ZA==
X-ME-Sender: <xms:ph-iYmyfT4uiEYT1ImPS8054bCxzcMpZujfMaHaE2KeZzKvvc_4Xow> <xme:ph-iYiQFqMEd2uNZZTsbA62QArVAbUuI1MbwW2zgodpdpV5VzgRP0sFk03BAFqCGq lBZKi2cZk0M1MFsj3w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedruddtledgleeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedftfhitggrrhguohcuufhighhnvghsfdcuoehrjhgsshesshgv mhhiohhtihgtrdhshihsthgvmhhsqeenucggtffrrghtthgvrhhnpeeugfelgfefhfehve eukefgffffieffjeelvdfhtdeijefhvdfgjedtvdfhfedvhfenucffohhmrghinhepihgv thhfrdhorhhgpdhrfhgtqdgvughithhorhdrohhrghenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrjhgsshesshgvmhhiohhtihgtrdhshihs thgvmhhs
X-ME-Proxy: <xmx:ph-iYoXguFX06-C_E_FJbIjLw0itXGqoeCDg1hVXqqbzz_qBKRO2lQ> <xmx:ph-iYsiC7i5kLS32qQ8PEuTxfNilImPqJOv3IORlkqGj3TKTu_F4kw> <xmx:ph-iYoAjsYGKoq8JQ2QwdwkpUjKxQoXJZFVnvRdGFjnbHka26WhEQw> <xmx:ph-iYrMLNBRgSs1CFS9i0dC6xfHvqrVQZuwpqYEtZTv6mHiDrEKXcw>
Feedback-ID: idc49479b:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 566A22D40070; Thu, 9 Jun 2022 12:28:22 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-692-gb287c361f5-fm-20220603.003-gb287c361
Mime-Version: 1.0
Message-Id: <437e7037-c6d5-47a7-bde6-8fecdf9e636b@www.fastmail.com>
Date: Thu, 09 Jun 2022 12:27:55 -0400
From: Ricardo Signes <rjbs@semiotic.systems>
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary="e39ff32e23444364af226f9b2153b8dd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/V__drpWJw__6bFnT3UtsSFZZRO0>
Subject: [calsify] non-CSS-named colors for events
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Calendaring and Scheduling Standards Simplification <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jun 2022 16:28:28 -0000

Hello!

tl;dr:  I think the rarely-used COLOR should have a facility for RGB colors, not just named colors.

RFC 7986 <https://datatracker.ietf.org/doc/html/rfc7986> provides the COLOR property <https://datatracker.ietf.org/doc/html/rfc7986#section-5.9> for specifying color on a per-event basis.  It defines the value as a string that must be a named CSS3 color.

Calendar users, unsurprisingly, very often push for more control, and want a full selection of RGB colors.  This is permitted in jsCalendar, where the color <https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar/#section-4.2.11> event property can be a named color *or* an RGB hex value.  At present, there is no means to map a non-CSS-named color from jsCalendar back to iCalendar.

Erratum 5449 <https://www.rfc-editor.org/errata/eid5449> was filed, suggesting that RFC 7986's COLOR property should have allowed for "rgb(r,g,b)" formatted hex colors.  This erratum was not accepted.

We (Fastmail) plan to support RGB color for events using JMAP for Calendars and jsCalendar, and so need to map these values back to iCalendar.  I am not familiar with any existing clients that use the COLOR property, but would be happy to be pointed at some, and at how they may handle this problem.  In the meantime, here are options we have been thinking about:

 1. act like the erratum was accepted and use "rgb(r,g,b)"; maybe somebody else has done the same, but parsing that, especially given the structural commas, is not appealing
 2. just put #RRGGBB into COLOR as needed; any human would understand what is happening and could adjust accordingly; file a proposed update;  nice and simple, directly maps to jsCalendar
 3. like the above, but add an attribute to the property:  `COLOR;VALUE=HEX:FF0000`
 4. store weird colors in some experimental property; this is unappealing, as it seems like a bit of a dead end
 5. store weird colors in CATEGORIES, which Fantastical does, but is otherwise as unappealing as using an experimental property
-- 
rjbs