[Jcardcal] Last Minute jCal changes? RSCALE extension might mess with data type

Philipp Kewisch <kewisch@gmail.com> Thu, 03 April 2014 13:20 UTC

Return-Path: <kewisch@gmail.com>
X-Original-To: jcardcal@ietfa.amsl.com
Delivered-To: jcardcal@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13261A01F8 for <jcardcal@ietfa.amsl.com>; Thu, 3 Apr 2014 06:20:38 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 2RX8vFQFavSC for <jcardcal@ietfa.amsl.com>; Thu, 3 Apr 2014 06:20:34 -0700 (PDT)
Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0201A01FC for <jcardcal@ietf.org>; Thu, 3 Apr 2014 06:20:33 -0700 (PDT)
Received: by mail-bk0-f49.google.com with SMTP id my13so168866bkb.36 for <jcardcal@ietf.org>; Thu, 03 Apr 2014 06:20:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type; bh=LodAmlTYbU+YRsMBCoFBr+5ZVJlAGD9VypaL9Ctya6g=; b=zj2yB5BHRrkfD1Y0nUB+9onuHxMuS3PWdGVAZD4nKu6esoepQ3QNDGRfo1qbqdf8o5 h09nJlYDyYWdDPR5L9h96Q24xFwhpcEvxveTgPmsMnwtXMueU/XNVnybY7yYeK9x53xW DQuJEcHBd6h9hTO0I8KZk+poKSFtyQTw3NI0yfhmSVqI3h6oxM6hmHmyh8wNJFJuZ8aM AjaV8lEhPCQjW2RHrdHc2lotFM6Lpm7fMGybkjY7PTu/zoybyBH5ObC2O2Uzd7oVNGFy x4nO8fytGI8wOkuIW6D++HvrUJ2xajWAhyDpwHPsIrUWW0IN75u0y9TqyR2lPB3IuwhD WqMA==
X-Received: by 10.205.46.196 with SMTP id up4mr1803340bkb.40.1396531229330; Thu, 03 Apr 2014 06:20:29 -0700 (PDT)
Received: from oskar.fritz.box (dslb-188-108-000-171.pools.arcor-ip.net. [188.108.0.171]) by mx.google.com with ESMTPSA id ew15sm5321832bkb.1.2014.04.03.06.20.16 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Apr 2014 06:20:28 -0700 (PDT)
Message-ID: <533D55F0.6020608@gmail.com>
Date: Thu, 03 Apr 2014 14:37:04 +0200
From: Philipp Kewisch <kewisch@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0
MIME-Version: 1.0
To: Pete Resnick <presnick@qti.qualcomm.com>, bert.greevenbosch@huawei.com
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative; boundary="------------090206090503040608060605"
Archived-At: http://mailarchive.ietf.org/arch/msg/jcardcal/JdaOpEiiqQskg3vITEvK0lvfp-w
Cc: draft-daboo-icalendar-rscale@tools.ietf.org, "jcardcal@ietf.org" <jcardcal@ietf.org>
Subject: [Jcardcal] Last Minute jCal changes? RSCALE extension might mess with data type
X-BeenThere: jcardcal@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: JSON data formats for vCard and iCalendar WG <jcardcal.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jcardcal>, <mailto:jcardcal-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jcardcal/>
List-Post: <mailto:jcardcal@ietf.org>
List-Help: <mailto:jcardcal-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jcardcal>, <mailto:jcardcal-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Apr 2014 13:20:39 -0000

Hi Folks,

this is very late in the game, but I just came across this today while
updating my ical.js library. Taking a look at the RSCALE draft:
http://tools.ietf.org/html/draft-daboo-icalendar-rscale-03 I noticed
that possible values for monthnum can now contain a string too instead
of just digits:

monthnum        = [plus / minus] 1*2DIGIT  ["L"]
                    ; Existing element modified to include a positive
                    ; or negative offset capability, as well as a leap
                    ; month indicator suffix.

This is how a such rule could look like:

RRULE:RSCALE=ISLAMIC-CIVIL;FREQ=YEARLY;BYMONTH=9L

Which could translate into jCal like this. Note that bymonth is now a
string instead of a number:

[ "rrule", {}, "recur", { "rscale": "ISLAMIC-CIVIL", "freq": "YEARLY", "bymonth": "9L" } ]

It seems quite intuitive, but in jCal we write this:

      *  The following rule parts can have one or more numeric values:
         "bysecond", "byminute", "byhour", "bymonthday", "byyearday",
         "byweekno", "bymonth", and "bysetpos".  If a rule part contains
         multiple values, an array of numbers MUST be used for that rule
         part.  Single-valued rule parts can be represented either using
         a single number value, omitting the array completely, or an
         array with one number element.  A jCal parser MUST be able to
         understand both data types.


There it must be a number. Is there anything we want to do about this?
Cyrus, is this possibly something you want to change in the RSCALE draft
to avoid compatiblity issues for parsers that think that BYMONTH only
has numbers? I could imagine either making the leap month a separate
parameter (BYLEAPMONTH) or adding explicit text to the RSCALE draft on
how it should be handled in jCal and possibly xCal. Or should we add
some text to jCal saying that extensions might change the data type of
the by* parts?

Philipp