From nobody Thu Jun 28 15:05:03 2018 Return-Path: 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 352D61310CC for ; Thu, 28 Jun 2018 15:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org 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 1x7F0oTW4doq for ; Thu, 28 Jun 2018 15:04:57 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4E01310D4 for ; Thu, 28 Jun 2018 15:04:56 -0700 (PDT) Authentication-Results: mail.aegee.org/w5SM4sGE029673; auth=pass (PLAIN) smtp.auth=didopalauzov@aegee.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1530223495; i=dkim+MSA-tls@aegee.org; r=y; bh=WaBjmSfjJwwWDNz7ywm0a4QN5Elrux9fqbRpw0sJliA=; h=Subject:From:To:Date; b=bpMX0srGRjh3Mckr/G4+62JTYGajz8tWnj7gZXBjLdfdEMeBdKpw2h0hSbS9vkW4F +faUCXI4Mmnjfp+ZIBJs0VOvhe+SvwOmEPsdWeo/SzjJo2lItwj3TTAgVRVOEpBwnM O1NIItgFVQ+OzNKUUF5oh5IPHinqzIFf2ZisThHlXNQ2QwQxKd7Zr/kHONgPmeglKv ROjXAyp15yhq2XlaXyQ60lgxI2SS9gru+O89vNqqFYup7WI121K23AT+zzBgSBlYlj RPeRePNeOCOp/sExIxRjIejr4/JHDGqdS8EVhJhbijvmMQX8cprx6NfSkOKlWvSQWV mn1BooKzOxePtE+HuNSwSToQCwBDuDsvoi00vUbam5AmbOLz3JfS6PGn6OIer3o+2M 8i7m/Z2UdLftrmpgcDOxRid9g9m5rXfuj0K5gYUNugeRlvAXB9FFcYYof/Z6AyRcyY 4DJThoJLQ5Lr7Z+eeI8ywHEcE503CeBnxcWEXFELE58dgIJqPAtmGcX+IXiCK733RH 2bR8LzbYmusUDJDrU+n+6Thd3VFVf+cCj7NqPdqJ0wk61CYxLkRuenl7TmoHRLi9r0 DJGBzEIxczeBQU+frybiu9fhIAmRH1K1HuRFBXN55AkjZC0YXFKEwIyvMp8NYLbrZR HzA35a0T+uxhcIUB2GHLclzg= Authentication-Results: mail.aegee.org/w5SM4sGE029673; dkim=none Received: from Tylan (80-110-70-89.cgn.dynamic.surfer.at [80.110.70.89]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id w5SM4sGE029673 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 Jun 2018 22:04:55 GMT Message-ID: <895f00bcf8af786b08011f8d3ee6f3cfd7f2f9f7.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: calsify@ietf.org Date: Thu, 28 Jun 2018 22:04:54 +0000 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.0 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: [calsify] Proposed Errata for RFC 7986: COLOR property with arbitrary RGB values X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 22:05:01 -0000 Hello, I would like to suggest the following Errata and welcome any comments within a month. My reading is that COLOR now cannot have the value RGB(61,211,68) Please correct me, if I am wrong. RFC 7986 (new Properties for iCalendar) Section 5.9. COLOR Property says: https://tools.ietf.org/html/rfc7986#section-5.9 Type: Technical Section: 5.9 COLOR Property Origianl text: Description: ...The value is a case-insensitive color name taken from the CSS3 set of names, defined in Section 4.3 of [W3C.REC-css3-color- 20110607]. Example: The following is an example of this property: COLOR:turquoise Corrected text: Description: ...The value is either a case-insensitive color name taken from the CSS3 set of names, defined in Section 4.3 of [W3C.REC- css3-color-20110607], or an RGB() functional notation with absolute values specified in Section 4.2.1 of the same document Examples: The following are examples of this property: COLOR:turquoise COLOR:rgb(61\,211\,68) Notes for the errata: draft-daboo-icalendar-extensions-07 removed the possibily to have RGB colours for COLOR. CSS3 included color names, that browsers at that time suppored, originating from X11's rgb.txt. The color names and values were randomly chosen. The minimal distance between the colors isn't consistent. One motivation for creating a color name were hardware capabilities - an argument which isn't valid for 20 years now. There is no reason to limit the number of possible values for COLOR. A user interface for choosing a named color has either to offer the user the possibility to choose from a pre-filled list of colors, which could clutter the interface, or let the user choose any RGB color and narrow it later to the closest color with CSS3 name. This narrowing isn't trivial and performing it seems like having an RFC running in itself. Notes for this message, outside the errata: Gnome Evolution recently added support for the COLOR property and uploaded iCalendar files by it now have: COLOR:rgb(61\,211\,68) https://www.w3.org/TR/2011/REC-css3-color-20110607/ lets also other forms: #f00 #ff0000 rgb(100%, 0%, 0%) I have no propbem to let or exclude any of the forms above. The main challenge is neither to have the user chose from a final list of colours, nor to let her choose any colour but narrow the selected colour afterwards to something. Letting more than one form of the mentioned above would be overengineering for the mentined challanage. https://github.com/w3c/csswg-drafts/issues/2813 states the colours are chosen randomly, and http://christopher.org/history-web-color-names/ proves this thesis. Randomly choosen colour values (having names coming from rgb.txt) are not suitable to achieve any aim. I haven't worked with colour terms until today, so feel free to rephrase the rgb-functional sentence. Regards Дилян From nobody Fri Jun 29 00:12:06 2018 Return-Path: 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 69F8F130E10 for ; Fri, 29 Jun 2018 00:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Sd9emL3u; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mVaFbCle 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 IW9jVgLOdPC9 for ; Fri, 29 Jun 2018 00:12:04 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6984D130E06 for ; Fri, 29 Jun 2018 00:12:04 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 84B8F212A0 for ; Fri, 29 Jun 2018 03:12:03 -0400 (EDT) Received: from imap35 ([10.202.2.85]) by compute6.internal (MEProxy); Fri, 29 Jun 2018 03:12:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=LWL+njit+qC4OeWMSiCUH6XluqU2ZM0piaH0BG/5b nk=; b=Sd9emL3uKt3xXxS5XVLwdNZA1Be9vIE/OXTyrvQjyyFWI/uhkvmysflDL dBU4tG2mxNo3USk1KyT+WrHmSIAk2Bo8PxAFpbTcesDfh/CFjY6vhRs+Y0OvTlES qZF0VndQjaHo4R1//F7CcaF+dZPBHYDBT2Df4vwkWtuaLdbeC6WGK+IDEu/qZuuv OewmA5ZPxsouroy4+AfG8UyFm6VEbRKgzPhlgQbGeCcJHX711SpGntF5PfOoYWgX B9xhtUNq9SVQpi+u4UtoxUOGWGPBYMIkiz3FcdV3wup3FstAU+IfF4qS2P00izCf 7DttjB8gUQwu0ZZAP4JCUuTP0RRSw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=LWL+njit+qC4OeWMSiCUH6XluqU2ZM0piaH0BG/5b nk=; b=mVaFbClem1uvO+npuQtmuMpu8/QlyaEXNUU+AVZ/TMmZ5bn9euYU90UqY iwOhc5gEhKqKWfgQiXQkTYPwe7BA+h2IJ8PLho5m2KlI8WVtBknasGbiKGIiFslG f2KjOOwCp36S4bBnehrnaEOttJHFWeDCYGm12OI7CHb+mUQjnOkLCOFsiCWeNWLU h19z4lx2/vINQ2UQvzS11owd/CP3KcT3C1XxC3dJLciyScGSbovIftgSV9/8KUR8 ZJGQCW2maubnqrputbDWoXgumpiwkv0lZ//XYneMPBjQqip7w5a8V17FI1dYIMgc cHlkfn6B0xRroWN6Ygt0r5dFVCOAA== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1F3BCC455B; Fri, 29 Jun 2018 03:12:03 -0400 (EDT) Message-Id: <016cbf12-c998-4f89-9151-40fb75fbbbdc@sloti35d1t03> User-Agent: Cyrus-JMAP/3.1.3-669-gf2de8ca-next x-jmap-identity-id: 64588216 In-Reply-To: <895f00bcf8af786b08011f8d3ee6f3cfd7f2f9f7.camel@aegee.org> References: <895f00bcf8af786b08011f8d3ee6f3cfd7f2f9f7.camel@aegee.org> Date: Fri, 29 Jun 2018 03:12:02 -0400 From: Neil Jenkins To: calsify@ietf.org Content-Type: multipart/alternative; boundary=9b9660dd749d496d8ecbeaf3aa661b95 Archived-At: Subject: Re: [calsify] =?utf-8?q?Proposed_Errata_for_RFC_7986=3A_COLOR_proper?= =?utf-8?q?ty_with_arbitrary_RGB_values?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 07:12:06 -0000 --9b9660dd749d496d8ecbeaf3aa661b95 Content-Type: multipart/related; boundary=a760158c33024e14bdaabb1707f07977 --a760158c33024e14bdaabb1707f07977 Content-Type: text/html
I wasn't involved in the original discussion, but I have a vague recollection from seeing the emails go by that this was intentional: the theory was clients are not going to use the actual colour you specify as they will want to pick something that goes with their branding + background + event display design, so by using names they could then choose their "version" of the colour that was closest in spirit to the name given.

Not sure I agree with this reasoning, but I think that was the idea.

Neil.
--a760158c33024e14bdaabb1707f07977-- --9b9660dd749d496d8ecbeaf3aa661b95 Content-Type: text/plain I wasn't involved in the original discussion, but I have a vague recollection from seeing the emails go by that this was intentional: the theory was clients are not going to use the actual colour you specify as they will want to pick something that goes with their branding + background + event display design, so by using names they could then choose their "version" of the colour that was closest in spirit to the name given. Not sure I agree with this reasoning, but I think that was the idea. Neil. --9b9660dd749d496d8ecbeaf3aa661b95-- From nobody Fri Jun 29 02:38:08 2018 Return-Path: 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 1202E128BAC for ; Fri, 29 Jun 2018 02:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com 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 c1o9LVode_yu for ; Fri, 29 Jun 2018 02:38:04 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2581277D2 for ; Fri, 29 Jun 2018 02:38:04 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 78400212A0 for ; Fri, 29 Jun 2018 05:38:03 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Fri, 29 Jun 2018 05:38:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=KdwdP3diAYnyxnsub3Uv9T4NutUP5 X43g3WRnrTLFQQ=; b=RHJ9BYgQMLJ1DJkelHk4xuxl4sOYZaTM65rlYdxCuUCD6 JAle5pGp7BjQFP2aQ9BWW1en9bFc4kxZn0J3Hhdr6km/VF87ZaFSb5oGtOEgAblY SryrXjwfq2/ZOZKf8un3LnIQwU7ZbGNHNjucGTK9JXV3ulCuY0WOj7Vltoo3cKZJ /WyLldKZ4y9V5rGl72rolSLDGS3B7nfV+h0elb9hZnqhVZkMKdM3bfocZzvzvHXC 4gyTY2kOt2Xh/SpIPc8Znzwr4M4Y4in6YH+DD8sOwsDJ/RrIAMi4Wh7+YonPuZIv Jas7y/FIQ4AbnzHlVP6tAOgoO0HTxzbntD0fTjHTg== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1AC729E498; Fri, 29 Jun 2018 05:38:03 -0400 (EDT) Message-Id: <1530265082.358845.1424503832.6F27ACD7@webmail.messagingengine.com> From: Robert Stepanek To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15302650823588451" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c Date: Fri, 29 Jun 2018 11:38:02 +0200 Archived-At: Subject: [calsify] JSCalendar: plain text and HTML descriptions X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 09:38:07 -0000 This is a multi-part message in MIME format. --_----------=_15302650823588451 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" For the next RFC draft we plan to reduce the description and htmlDescription properties to just a single description property. In addition, we will introduce a new descriptionContentType property, that defines the description MIME type. Several calendar services (including FastMail) already see HTML text dumped into iCalendar plain text DESCRIPTIONs and in JSCalendar we want to handle this better. However, having two properties for descriptions shows to be an issue in practice, as the contents get out of sync. As a minimum the allowed values of the descriptionContenType property (and consequently the description text format) should be text/plain and text/html without parameters (charset MUST be utf-8). In fact, we might want to allow any subtype of `text` MIME type, as RFC 2046 phrases this nicely: In the absence of appropriate interpretation software, it is reasonable to show subtypes of "text" to the user, while it is not reasonable to do so with most nontextual data. Such formatted textual data should be represented using subtypes of "text". I remember at last CalConnect someone asking for allowing arbitrary MIME types for descriptions, but I see the real risk of multipart or application content-types getting dumped into the description. This rather should go into an attachment. Do you see any reasons to allow anything else than text MIME types? Cheers, Robert --_----------=_15302650823588451 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
For the next RFC draft we plan to reduce the description and htmlDescription properties to just a single description property. In addition, we will introduce a new descriptionContentType property, that defines the description MIME type. Several calendar services (including FastMail) already see HTML text dumped into iCalendar plain text DESCRIPTIONs and in JSCalendar we want to handle this better. However, having two properties for descriptions shows to be an issue in practice, as the contents get out of sync.

As a minimum the allowed values of the descriptionContenType property (and consequently the description text format) should be text/plain and text/html without parameters (charset MUST be utf-8).

In fact, we might want to allow any subtype of `text` MIME type, as RFC 2046 phrases this nicely:

   In the absence of appropriate interpretation software, it is reasonable to
   show subtypes of "text" to the user, while it is not reasonable to do
   so with most nontextual data. Such formatted textual data should be
   represented using subtypes of "text".

I remember at last CalConnect someone asking for allowing arbitrary MIME types for descriptions, but I see the real risk of multipart or application content-types getting dumped into the description. This rather should go into an attachment.  Do you see any reasons to allow anything else than text MIME types?

Cheers,
Robert





--_----------=_15302650823588451-- From nobody Fri Jun 29 02:39:16 2018 Return-Path: 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 EDC18130E09 for ; Fri, 29 Jun 2018 02:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com 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 Y_o5EMxd4Gp6 for ; Fri, 29 Jun 2018 02:39:01 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7D41277D2 for ; Fri, 29 Jun 2018 02:39:01 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9FB8320F1D for ; Fri, 29 Jun 2018 05:39:00 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Fri, 29 Jun 2018 05:39:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=AiuBGsYc8NRdf9klCMk2Ezjzz5ZsJ LYkqTS5z/jR7tw=; b=B1ABA+KxQ5Ql3tLmJE8Sf3BSgtmQFazVEyhgvsWpnM/6d o9+uD0Oa3lom1KpbV6huF7KpjXZacyuLpCRH89xIXU1sjWjFx2lKfiPD8L1Ve9EV aXW2SG7Mc9kSwlfuJKSR30HkLWB/K6W1oYFTNRJ7Gh1AxAZViYXiuGNRz9ChDzgu hsm0iOYp30aOYh6R0U6ZtUTbJ6PEc+5sjwWOfHarH4nerduZRY3G98jFvCP9ewH/ 4FKHZOIx+GjxrVrArmR2j9hk4N1SJD5sbqXGLzavRMTtV7WHshpRfKBdlfjZA71K 0ROW2KFEuFgYyMWK4+prGSpqEU1AKmxgVPpte20YQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 5CE4C9E498; Fri, 29 Jun 2018 05:39:00 -0400 (EDT) Message-Id: <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> From: Robert Stepanek To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15302651403589890" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c Date: Fri, 29 Jun 2018 11:39:00 +0200 Archived-At: Subject: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 09:39:09 -0000 This is a multi-part message in MIME format. --_----------=_15302651403589890 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" The current JSCalendar duration definition neither is strictly normalized nor compatible with the iCalendar DURATION type. Specifically, it normalizes the zero duration to be written as P0D but does not define any other normalization. In addition, it does not support durations expressed in weeks. It might make sense to either require completely normalized durations, or to support the full value range of iCalendar durations. I lean towards the latter, and intend to: * remove the P0D restriction for zero durations * allow durations to be expressed in weeks, with the same restrictions as iCalendar and ISO 8601 durations. While normalization can provide value in some cases, it is likely to be ignored by clients and robust implementations will have to deal with them already for iCalendar. Side-note: at last CalConnect we discussed to allow all valid ISO8601 durations, including years and months. On second thought this would require implementations to handle in-existent dates in date-time arithmetic, and break iCalendar compatibility for no compelling reason. What are your thoughts? Cheers, Robert --_----------=_15302651403589890 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
The current JSCalendar duration definition neither is strictly normalized nor compatible with the iCalendar DURATION type. Specifically, it normalizes the zero duration to be written as P0D but does not define any other normalization. In addition, it does not support durations expressed in weeks.

It might make sense to either require completely  normalized durations, or to support the full value range of iCalendar durations. I lean towards the latter, and intend to:

  • remove the P0D restriction for zero durations
  • allow durations to be expressed in weeks, with the same restrictions as iCalendar and ISO 8601 durations.

While normalization can provide value in some cases, it is likely to be ignored by clients and robust implementations will have to deal with them already for iCalendar.

Side-note: at last CalConnect we discussed to allow all valid ISO8601 durations, including years and months. On second thought this would require implementations to handle in-existent dates in date-time arithmetic, and break iCalendar compatibility for no compelling reason.

What are your thoughts?

Cheers,
Robert



--_----------=_15302651403589890-- From nobody Fri Jun 29 02:40:59 2018 Return-Path: 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 9A858130DFA for ; Fri, 29 Jun 2018 02:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com 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 yPs8l7X0pI87 for ; Fri, 29 Jun 2018 02:40:56 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02BAD128BAC for ; Fri, 29 Jun 2018 02:40:56 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 69B3621D0C for ; Fri, 29 Jun 2018 05:40:55 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Fri, 29 Jun 2018 05:40:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=+q252/eNhM7vFEXudKd1ToXsLKKCT d8CjptBNRkixRs=; b=nDl34YsvBw5HbVMLH7o9PXDZ22FKXZVI+HAwcRtRSsdhJ gxs9x/oY2HQBvpLSnnk1uCtCH+DHyP0k1Bnk3mTLG+3S9+shzdxzsWQMplLZqjw2 03EoBjlTYHLUh+jK+VtpA5QKdN84f/98ri1DdKlydLyTdVGQ/c7yUEHyfkJk5vIX 0jIh9U3VocCJcN/T5hJrNci0pi9OJSkFYor/ulENXCMkIMlUL4y3sB3EEVbPzScZ 5OFVIesPV/RvCQpB2rDQHvDhUiHTreq6q29GtbdiYrRBKeanib4yRVNQR4U3wFeW VlTpBAgHRHYM0tmnY0r1QwcqdnqCCYEzSZLFrsXDA== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0E0989E498; Fri, 29 Jun 2018 05:40:54 -0400 (EDT) Message-Id: <1530265254.359215.1424505824.147D88FF@webmail.messagingengine.com> From: Robert Stepanek To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15302652543592151" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c Date: Fri, 29 Jun 2018 11:40:54 +0200 Archived-At: Subject: [calsify] JSCalendar: recurrence counts X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 09:40:58 -0000 This is a multi-part message in MIME format. --_----------=_15302652543592151 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" This came up at last CalConnect: JSCalendar objects explicitly allow to have a start date-time that doesn't match the recurrence rule. This is in contrast to iCalendar, which left handling these cases undefined. A discussion arose if such a non-matching start should count towards the recurrence rule count. The majority leaned towards only counting the instances that are generated by the RRULE. However, Neil found the following section in RFC5545: The COUNT rule part defines the number of occurrences at which to range-bound the recurrence. The "DTSTART" property value always counts as the first occurrence. We therefore won't change the current JSCalendar recurrence draft. Please let us you if you other thoughts. --_----------=_15302652543592151 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
This came up at last CalConnect:

JSCalendar objects explicitly allow to have a start date-time that doesn't match the recurrence rule.  This is in contrast to iCalendar, which left handling these cases undefined. A discussion arose if such a non-matching start should count towards the recurrence rule count. The majority leaned towards only counting the instances that are generated by the RRULE. However, Neil found the following section in RFC5545:

      The COUNT rule part defines the number of occurrences at which to
      range-bound the recurrence.  The "DTSTART" property value always
      counts as the first occurrence.

We therefore won't change the current JSCalendar recurrence draft. Please let us you if you other thoughts.
--_----------=_15302652543592151-- From nobody Fri Jun 29 09:08:28 2018 Return-Path: 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 E2A9F130DD4 for ; Fri, 29 Jun 2018 09:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.com 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 B5v6vT-GR21K for ; Fri, 29 Jun 2018 09:08:24 -0700 (PDT) Received: from pv48p67im-zteg06041101.me.com (pv48p67im-zteg06041101.me.com [17.58.5.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F64E130DC1 for ; Fri, 29 Jun 2018 09:08:24 -0700 (PDT) Received: from process-dkim-sign-daemon.pv48p67im-zteg06041101.me.com by pv48p67im-zteg06041101.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PB300O00E0GWW00@pv48p67im-zteg06041101.me.com> for calsify@ietf.org; Fri, 29 Jun 2018 16:08:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1530288503; bh=/+VR7KOtIYU9uWlY3+tWocAQtzZODbtraiwA0zX2+lc=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=k8dqw9moIx2BPRTDIPwAoGHVoDyXLvLEHdNGmDUgduAtnNUWpXiY+zELS9086Tqpd UdoXjDlllFH0W6/kKC7RMcYGZ8TjYcMcCiVvAnTMKwXBgsYwFDrsWFiDIFvobCPnST a78DfkE37pT2Ee+BTo4RV0E0VE3/sGmIMM30KcQDoy5oDZyFyNoB+lkVNMVeFeUNyo 5urWm/x/DzMlFqN6k+PtmA3F+VU5xR1PVeJ9cfyCpQW/jHy7TjXSwLsuVKaCvsxvdn FAVmM/V9ebaNu7HrSiZEwSajJGWeOAYPN936ETo/3r8MgtDRK3ytBUAz0mgdBKuKLc Rcwq3yamqIcOw== Received: from icloud.com ([127.0.0.1]) by pv48p67im-zteg06041101.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PB300GYGE5YXZ00@pv48p67im-zteg06041101.me.com>; Fri, 29 Jun 2018 16:08:23 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-06-29_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1806290174 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Andrew Laurence In-reply-to: <016cbf12-c998-4f89-9151-40fb75fbbbdc@sloti35d1t03> Date: Fri, 29 Jun 2018 09:08:20 -0700 Cc: calsify@ietf.org Content-transfer-encoding: quoted-printable Message-id: <531E76A8-D6E3-4DAB-A141-D44FC94E7583@me.com> References: <895f00bcf8af786b08011f8d3ee6f3cfd7f2f9f7.camel@aegee.org> <016cbf12-c998-4f89-9151-40fb75fbbbdc@sloti35d1t03> To: Neil Jenkins X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [calsify] Proposed Errata for RFC 7986: COLOR property with arbitrary RGB values X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 16:08:27 -0000 Users use colors to represent all sorts of known-to-them metadata. They = care *deeply* about color assignment and fidelity. When we moved from a = calendar system that let users assign colors according to criteria (Boss = is organizer? Red! Description contains "Lunch"? Green!) to one that = didn't, I heard about it for *ten* years. While preparing for the June 2017 CalConnect, I surveyed users about = issues with calendars. It came up *again*, in the context of wanting to = choose colors and have them remain the same across clients. -Andrew > On Jun 29, 2018, at 12:12 AM, Neil Jenkins = wrote: >=20 > I wasn't involved in the original discussion, but I have a vague = recollection from seeing the emails go by that this was intentional: the = theory was clients are not going to use the actual colour you specify as = they will want to pick something that goes with their branding + = background + event display design, so by using names they could then = choose their "version" of the colour that was closest in spirit to the = name given. >=20 > Not sure I agree with this reasoning, but I think that was the idea. >=20 > Neil._______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify