Re: [calsify] WGLC JSCalendar

["Neil Jenkins" <[e-mail]>]

Thanks for the review Marten.

> 4.1.4. prodId (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-20#section-4.1.4)

> In this context, what is the JSCalendar object? Is it the JSON object (or its serialized form) I'm currently looking at or is it the calendar entity that is represented by this JSON object?

> To put it in other words, should a JSCalendar serializer always insert its own "prodId" when serializing an internal representation to a JSCalendar JSON file (even if no data was changed)?

> Or is this related to the "updated" field? Should you only update "prodId" when you also update "updated"?


I think this should be whatever client last updated the event; so yes, only updating "prodId" when you also update the "updated" timestamp (which you should do whenever you make changes) is a neat way to describe it. I'll update the spec.

> 4.3.2. recurrenceRule (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-20#section-4.3.2)

> The limits mentioned for "byMonth", "byMonthDay" and "byYearDay" are specific to the Gregorian calendar scale, e.g

> But other calendar scales may other limits. We should make clear that the limits depend on the maximum values of the respective calendar scale and maybe add "for Gregorian calendars the valid values are 1 to 31 or -31 to -1".


Thanks, I have clarified this (I presume you meant byWeekNo instead of byMonth).

> 4.3.2.1. Interpreting recurrence rules (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-20#section-4.3.2.1)

> which defaults to gregorian if omitted.

> gregorian should be quoted, I guess.

Sure.

> It may also be worth stating explicitly that the "skip" parameter only affects "yearly" and "monthly" rules (IIRC RScale didn't address ambiguous/invalid times during daylight saving changes)


Sure, I've noted in the definition of the skip property that it only has an effect if the frequency is "monthly" or "yearly".

> Gregorian should be capitalized.

Thanks, done.

Cheers,
Neil.