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

From: Philipp Kewisch <[email-masked]>
Date: Thu, 03 Apr 2014 14:37:04 +0200

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Apr 2014 07:51:36 -0600

>                      ; month indicator suffix.

With my WG chair hat on, I have concerns.

Why is the RSCALE draft modifying an existing element from RFC 5545 
instead of defining a new element? How certain are we that the draft 
Cyrus and Gregory are working on will end up changing monthnum? Do we 
really want to be tracking an I-D with an uncertain future?

It seems more prudent, at this late date, to align only with RFC 5545.

Peter

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 03 Apr 2014 09:57:24 -0400

Hi Peter,

> It seems more prudent, at this late date, to align only with RFC 5545.

I would agree that jcal should not change at this point. RSCALE is still a 
draft and can be changed if real problems are encountered.

That said, the reason we chose to use the "L" suffix and chose to add a new 
element to RRULE was precisely because we want parsers to "blow-up" and not 
interpret the event incorrectly. As a general rule all parsers should 
handle illegal data formats in properties or parameters in a sane way 
(simple choice being to just ignore the entire iCalendar object being 
parsed - though keep parsing other iCalendar objects in the stream).

That choice for RSCALE is still up for debate - but that discussion should 
take place on the calsify mailing list.

-- 
Cyrus Daboo

---

From: Philipp Kewisch <[email-masked]>
Date: Thu, 03 Apr 2014 16:00:06 +0200

On 4/3/14, 3:57 PM, Cyrus Daboo wrote:
> I would agree that jcal should not change at this point. RSCALE is
> still a draft and can be changed if real problems are encountered.
>
Hi Peter, Cyrus,

thanks for letting me know. I would also prefer not to make any further
changes to jCal, I just wanted to bring it up in case someone thinks
otherwise.

Philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Apr 2014 08:45:45 -0600

> changes to jCal, I just wanted to bring it up in case someone thinks

I am glad you noticed, since it shows that you're actually writing and 
testing code. :-) But I'm also glad that Cyrus thinks it's best to leave 
jCal alone for now.

Peter

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 03 Apr 2014 10:49:35 -0400

Hi Peter,

> testing code. :-) But I'm also glad that Cyrus thinks it's best to leave

Absolutely. jCal is in good shape - I have a working implementation of it 
too and have actually made it a requirement for some web/browser-based 
prototypes I have been working on.

-- 
Cyrus Daboo