Subject: [calsify] WG Last Call: draft-ietf-calext-rscale-01.txt

From: Donald Eastlake <[email-masked]>
Date: Mon, 17 Nov 2014 23:35:29 -0500

Hi,

This message starts a WG Last Call on the draft below running to two
week. If there are any final comments please post by then.

Thanks,
Donald (CoChair)
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Tue, Nov 11, 2014 at 11:03 AM,  <[email-masked]> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Calendaring Extensions Working Group of the IETF.
>
>         Title           : Non-Gregorian Recurrence Rules in iCalendar
>         Authors         : Cyrus Daboo
>                           Gregory Yakushev
>         Filename        : draft-ietf-calext-rscale-01.txt
>         Pages           : 15
>         Date            : 2014-11-11
>
> Abstract:
>    This document defines how non-Gregorian recurrence rules can be
>    specified and used in iCalendar data, and with CalDAV servers.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-calext-rscale/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-calext-rscale-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-calext-rscale-01
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

---

From: [email-masked]
Date: Tue, 18 Nov 2014 09:55:08 -0500

Reviewing this document, the first thing I notice is that the citation
[UNICODE.CLDR] is just a list of names of calendars, with no reference to
their actual rules or algorithms or behavior.  Is there no reference that
can be cited that can give implementors information about what the calendar
scales actually mean, other than "Use or duplicate the ICU implementation"?

On Monday, November 17 2014, "Donald Eastlake" wrote to "[email-masked]" saying:

> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify
> 

-- 
Jonathan Lennox
[email-masked]

---

From: Gregory Yakushev <[email-masked]>
Date: Wed, 19 Nov 2014 12:05:41 +0000

Yes, this is a big issue. I am not aware of any standards covering
calendaring computations, although it would be nice to have them.
Standardizing calendaring calculations would be a big project on its own,
way outside the scope of this WG, so in absence of such a standard we opted
to use ICU as a calendaring calculations provider.

The proposal as it stands effectively ties RSCALE to ICU, which is useful
at the moment because ICU is maintained and available on a wide range of
platforms. If in the future the calculations will be standardized, or there
will be a need to recognize calendars not supported by ICU, we can always
update the RFC.

We also maintain a golden RSCALE expansion set to synchronize our
implementations, you can find it here:
http://calconnect.org/ioptesting.shtml
Maybe its worth mentioning this golden set as an informational reference in
the draft.

Best Regards
Grisha

---

From: Ken Murchison <[email-masked]>
Date: Wed, 19 Nov 2014 08:24:26 -0500

Hi Jonathan,

> scales actually mean, other than "Use or duplicate the ICU implementation"?

Would a reference to published text be appropriate?  I'm thinking 
something like: 
http://www.amazon.com/Calendrical-Calculations-Nachum-Dershowitz/dp/0521702380/

That being said, I haven't read this text.  I used the ICU library for 
the RSCALE implementation in libical.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Gregory Yakushev <[email-masked]>
Date: Wed, 19 Nov 2014 15:32:53 +0000

> http://www.amazon.com/Calendrical-Calculations-Nachum-Dershowitz/dp/

This book is really good, but its a more generic scientific literature. It
won't tell you the implementation difference between ICU "islamic-umalqura"
and "islamic-rgsa" for example.

---

From: [email-masked]
Date: Wed, 19 Nov 2014 12:25:37 -0500

On Wednesday, November 19 2014, "Gregory Yakushev" wrote to "[email-masked], [email-masked]" saying:

> Yes, this is a big issue. I am not aware of any standards covering calendaring
> computations, although it would be nice to have them. Standardizing calendaring
> calculations would be a big project on its own, way outside the scope of this
> WG, so in absence of such a standard we opted to use ICU as a calendaring
> calculations provider.
> 
> The proposal as it stands effectively ties RSCALE to ICU, which is useful at
> the moment because ICU is maintained and available on a wide range of
> implementations, you can find it here: http://calconnect.org/ioptesting.shtml
> Maybe its worth mentioning this golden set as an informational reference in the
> draft.

My concern is that some organizations have rules that not only can their
products not contain open-source code, but additionally their implementors
can't even look at open-source code, for fear of inadvertant copyright
infringement.  This may be excessive paranoia, especially for a license as
lenient as ICU's, but go try arguing with lawyers...

That said, the relevant references shouldn't actually have to be a standard,
I think.  If ICU's public documentation (as opposed to its source code) has
sufficient detail about the different flavors of calendars, then that,
alongside a generic reference such as Reingold & Dershowitz, will hopefully
be sufficient.

For that matter, does the CLDR give references beyond just names?  The XML
document that the [UNICODE.CLDR] citation refers to is just a list of names,
but hopefully these are expanded or explained somewhere.

-- 
Jonathan Lennox
[email-masked]

---

From: Marten Gajda <[email-masked]>
Date: Wed, 19 Nov 2014 20:28:49 +0100

Hi,

the current draft doesn't say anything about jCal (RFC 7265, 
http://tools.ietf.org/html/rfc7265).

http://tools.ietf.org/html/rfc7265#section-3.6.10 defines the "byxxx" 
fields as numbers or arrays of numbers. However, that doesn't work with 
leap months.

I think it its not exactly clear how RRULEs with RSCALE and leap months 
have to be expressed in jCal. The most obvious solution would be to 
allow Strings like so:

["rrule",
     {},
     "recur",
     {
       "freq": "YEARLY",
       "rscale": "xxxxxxx",
       "count": 5,
       "bymonth": [5, "10L"]
     }
    ]

But this can result in an array of mixed types.

A similar issue exists for xCal. In that case we need an update to the 
schema.

cheers

Marten

-- 

*Marten Gajda*
Schandauer Straße 34
01309 Dresden
Germany

tel: +49 177 4427167
email: [email-masked]
twitter: twitter.com/dmfs_org

VAT Reg. No.: DE269072391

---

From: Philipp Kewisch <[email-masked]>
Date: Wed, 19 Nov 2014 20:44:16 +0100

Hey Marten,

thanks for mentioning this. jCal has multiple notes for other cases
mentioning that types should be checked anyway, so I agree the obvious
solution makes most sense. iCalendar parsers will have to be upgraded
for RSCALE anyway, the same applies to jCal parsers.

I'm not sure if the jCal syntax should be mentioned in the RSCALE
document or if a separate document should be defined, you probably know
better than me how this is usually done in the IETF.

Philipp

On 11/19/14 8:28 PM, Marten Gajda wrote:
> fields as numbers or arrays of numbers. However, that doesn't work
> with leap months.
>
> I think it its not exactly clear how RRULEs with RSCALE and leap
> months have to be expressed in jCal. The most obvious solution would
> be to allow Strings like so:
> ["rrule",
>     {},
>     "recur",
>     {
>       "freq": "YEARLY",
>       "rscale": "xxxxxxx",
>       "count": 5,
>       "bymonth": [5, "10L"]
>     }
>    ]

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 19 Nov 2014 15:01:47 -0500

Hi Philipp,

> better than me how this is usually done in the IETF.

When we discussed this before I think we were OK with the RSCALE-unaware 
jcal parser failing because it should fail regardless if an RSCALE= item is 
in the RRULE.

Perhaps it is worth adding some text specific to jCal and xCal defining the 
new behavior expected when they do support RSCALE. Something like:

X. Use with jCal

jCal parsers supporting this specification will need to:

    1. Serialize the "RSCALE" element in an "RRULE" property as an "rscale" 
JSON member in the "rrule" JSON object. The value of the "rscale" JSON 
member MUST be a boolean.

    2. Correctly parse any "rscale" JSON member in an "rrule" JSOB object.

    3. Serialize the "bymonth" JSON member in an "rrule" JSON object as a 
string value, if the equivalent iCalendar value contains the "L" character 
suffix. "bymonth" JSON members that do not use the "L" suffix continue to 
be serialized as JSON numbers.

    4. Correctly parse any "bymonth" JSON member in an "rrule" JSON object 
by recognizing either number or string values.

    5. Serialize the "SKIP" element in an "RRULE" property as a "skip" JSON 
member in the "rrule" JSON object. The value of the "skip" JSON member MUST 
be a string containing lowercased values for the "SKIP" element as defined 
by this specification.

    6. Correctly parse any "skip" JSON member in an "rrule" JSOB object.

And I will do an equivalent for xCal, defining new XML elements as needed. 
I think that should address Marten's comment.

-- 
Cyrus Daboo

---

From: Marten Gajda <[email-masked]>
Date: Wed, 19 Nov 2014 21:15:56 +0100

Why would the value of the "rscale" field be boolean? I think it should 
be a String (i.e. the identifier of the calendar scale).

Other than that it sounds good to me.

Marten

Am 19.11.2014 um 21:01 schrieb Cyrus Daboo:
> When we discussed this before I think we were OK with the 
> RSCALE-unaware jcal parser failing because it should fail regardless 
> if an RSCALE= item is in the RRULE.
>
> Perhaps it is worth adding some text specific to jCal and xCal 
> defining the new behavior expected when they do support RSCALE. 
> Something like:
>
> X. Use with jCal
>
>    1. Serialize the "RSCALE" element in an "RRULE" property as an 
> "rscale" JSON member in the "rrule" JSON object. The value of the 
> "rscale" JSON member MUST be a boolean.
>
>    3. Serialize the "bymonth" JSON member in an "rrule" JSON object as 
> a string value, if the equivalent iCalendar value contains the "L" 
> character suffix. "bymonth" JSON members that do not use the "L" 
> suffix continue to be serialized as JSON numbers.
>
>    4. Correctly parse any "bymonth" JSON member in an "rrule" JSON 
> object by recognizing either number or string values.
>
>    5. Serialize the "SKIP" element in an "RRULE" property as a "skip" 
> JSON member in the "rrule" JSON object. The value of the "skip" JSON 
> member MUST be a string containing lowercased values for the "SKIP" 
> element as defined by this specification.
>
> And I will do an equivalent for xCal, defining new XML elements as 
> needed. I think that should address Marten's comment.
>

-- 

*Marten Gajda*
Schandauer Straße 34
01309 Dresden
Germany

tel: +49 177 4427167
email: [email-masked]

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 19 Nov 2014 15:33:27 -0500

Hi Marten,

> be a String (i.e. the identifier of the calendar scale).

Sorry, mistake on my part. Yes it needs to be a string value.

> Other than that it sounds good to me.

OK.

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Mon, 24 Nov 2014 15:40:02 -0500

Hi Cyrus,

I was just checking my implementation and have a couple of comments and 
sample output below.

>    2. Correctly parse any "rscale" JSON member in an "rrule" JSOB object.

In the above to steps,  I think "rrule" JSON object should be "recur" 
JSON object.

> element as defined by this specification.

Why lowercased?  We preserve case for "freq" and "wkst", and presumably 
"byday".

> needed. I think that should address Marten's comment.

Does this look correct for an RRULE such as: 
RRULE:FREQ=YEARLY;RSCALE=CHINESE;SKIP=YES;BYMONTH=6,6L

         [
           "rrule",
           {},
           "recur",
           {
             "freq": "YEARLY",
             "rscale": "CHINESE",
             "skip": "YES",
             "bymonth": [
               6,
               "6L"
             ]
           }
         ],

           <rrule>
             <recur>
               <freq>YEARLY</freq>
               <rscale>CHINESE</rscale>
               <skip>YES</skip>
               <bymonth>6</bymonth>
               <bymonth>6L</bymonth>
             </recur>
           </rrule>