[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
- [Jcardcal] Last Minute jCal changes? RSCALE exten… Philipp Kewisch
- Re: [Jcardcal] Last Minute jCal changes? RSCALE e… Peter Saint-Andre
- Re: [Jcardcal] Last Minute jCal changes? RSCALE e… Cyrus Daboo
- Re: [Jcardcal] Last Minute jCal changes? RSCALE e… Philipp Kewisch
- Re: [Jcardcal] Last Minute jCal changes? RSCALE e… Peter Saint-Andre
- Re: [Jcardcal] Last Minute jCal changes? RSCALE e… Cyrus Daboo