Subject: [calsify] AD review of draft-ietf-calext-rscale-03

From: Barry Leiba <[email-masked]>
Date: Thu, 29 Jan 2015 00:05:18 +0100

The chairs requested publication of the subject document, and I've
done my AD review of it.  See the review below, with points numbered
for reference.

0. I asked Donald, in his role as document shepherd, about the use of
"updates" metadata with respect to the iCalendar, xCal, and jCal
specs.  Here's his response:

> The document changes iCalendar, xCal, and jCal by performing surgery
> on the language syntax in a way not anticipated when the base
> documents were written. See the three indented one-sentence paragraphs
> at the end of Section 1. Sorry we failed to change the word "extend"
> to "change" in the first of those. That would be easy to fix.

But that's the thing: I don't believe it does.  There's nothing done
here that requires all iCalendar implementations to support it.  This
is an extension... if you don't know about the extension, then you
don't support the extension, but I don't think this qualifies as
"updates".

We've often been fluffy and inconsistent about whether we should use
"updates" for extensions, and, for example, IMAP does this
particularly badly: it's pretty arbitrary when you look at which IMAP
extensions "update" 3501, and which don't.  But we (the IESG, at
least) are trying to be more consistent about when we use that label.

If y'all have a strong objection to removing the "updates" tags, I'll
stop objecting, and see if any other ADs bring it up.

1. Section 2
Where you explain the {C} (etc.) notation, it'd probably help to be
explicitly clear that it's only for illustrative purposes, and that
{X} never appears in actual iCalendar objects.

2. Section 4
It seems funny that SKIP has a fixed default, rather than being
dependent upon the RSCALE.  For the Hebrew calendar, for example, the
default is wrong, and one always needs SKIP=FORWARD.  It seems likely
that there'll be lots of errors involved in forgetting the SKIP and
having the default be wrong for the calendar that's being used, which
will cause interoperability problems that would be avoided if the
default depended on the calendar.  (See also my comment #8 below
about Section 4.2.4.)

3. Also, I don't want to break existing implementations, but
"SKIP=YES" doesn't seem to be the right way to put it... something
parallel to "BACKWARD" and "FORWARD" would be better.  Perhaps
"SKIP=OMIT".

4. Also also, in the grammar, please make this change:
OLD
; and MUST only be present if "RSCALE" is present.
NEW
; and MUST NOT be present if "RSCALE" is not present.

(I don't think the "MUST only" construct is clear, especially to all
varieties of non-native speakers.)

5. Section 4.1
In the last paragraph, I suggest being even clearer in the final
sentence, to avoid misunderstandings on the mapping: 'In iCalendar,
this would map to months 1 through 12 with "5L" as the leap month (ICU
month 6).  ICU months 7 through 13 would map to iCalendar months 6
through 12.'

6. Section 4.2.1
It seemed odd to me at first that you were repeating the example.
Maybe explicitly saying that will make it less odd: "Consider the
Chinese New Year example above:" (and then go ahead and repeat the
example).

7. Section 4.2.2
I don't understand why this example needs the BYMONTH value, and why
FREQ=YEARLY isn't enough.  Isn't this exactly the same as the example
in 4.2.1, where "BYMONTH=1" isn't needed?

8. Section 4.2.4
Ooh, this seems completely wrong unless SKIP is redefined to be
dependent upon the calendar.  In 4.2.3, you're showing me how
SKIP=FORWARD turns 5L-08 into 6-08, but then here you tell me that the
same SKIP=FORWARD turns 2-29 into 3-01, rather than 3-29.  Of course,
that's what we want to happen, but how can I know that from the
explanation of SKIP?  More to the point, it's clear from these two
examples that the behaviour of SKIP has to depend upon the calendar
that's in effect, and trying to define it to be independent doesn't
work.

Or have I missed something?

9. Section 5
I have never understood the statement that things in iCalendar are
case insensitive, but "SHOULD be in upper case."  If they're case
insensitive, why does it matter?  And, certainly, why does it matter
at a SHOULD level?  What's this "for consistency" thing?  Does that
mean that it's nicer, when humans read it, to have things in a
consistent case?  If so, that's a fine thing to say, but it's not an
interoperability SHOULD.

10. Where you talk about CLDR alias values, you say they 'MUST be
treated as valid "RSCALE" element values.'  Of course they must, as I
presume they're syntactically valid.  The point you want is that the
aliases MUST be treated as the same calendar as what they alias, yes?

11. Section 6
I don't understand why this section is only for iTIP.  The iTIP
responses are, sure, but what to do if you encounter an RSCALE with a
calendar you don't support is not, and advice on that needs to be
given more generally.

--
I think points 2, 7, and 8 are ones that we need to sort out before I
send it out for last call.  Any others we fix now is/are/am great too.
So let's please discuss.  I'll take responses from the authors and/or
from any working group participants (and chairs) who would like to get
involved.  Obviously, changes such as what I propose in points 2, 3,
8, and 9 need to have the working group's agreement behind them, if
they are to be made.

Barry, Applications AD

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 28 Jan 2015 16:28:05 -0800

Hi Barry,

> done my AD review of it.  See the review below, with points numbered

Thanks for your review. I am at the CalConnect meeting this week so I will 
provide a detailed reply once I get back.

-- 
Cyrus Daboo

---

From: Aron Roberts <[email-masked]>
Date: Wed, 28 Jan 2015 20:49:01 -0800

With apologies in advance for this brief dive into this conversation, since
I'm not currently an active member of the Calendering and Scheduling
communities. (I attended one CalConnect event years ago, in a previous
position.)

Barry Leiba suggested, in his comment number 4, pertaining to "4. Extended
RRULE Property" in http://tools.ietf.org/html/draft-ietf-calext-rscale-03,
that as a possible alternative to the second line here:

; Optional, with default value "BACKWARD",
; and MUST only be present if "RSCALE" is present.

the following wording might be clearer, especially to non-native readers:

I proposed this additional alternative to Barry, in a private communication:

; and MUST NOT be present unless "RSCALE" is present.

And he kindly considered this and responded:
"Yes, your version with "unless" works too, and captures my concern in the
same way as my suggestion.  I'm equally happy with either one."

FYI,

Aron Roberts
OCIO - Research IT
University of California, Berkeley

On Wed, Jan 28, 2015 at 3:05 PM, Barry Leiba <[email-masked]>
wrote:

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

---

From: Marten Gajda <[email-masked]>
Date: Wed, 28 Jan 2015 23:43:12 -0800

Hi Barry,

in general I agree with most of your points, except for the ones below:

#2:
Having the same default value for all calendar scales at least 
guarantees consistent results among different implementations when you 
forget the SKIP value. IMHO, having per-calendar-scale default values 
adds unnecessary complexity and it's questionable if you can find 
consensus on what the default should be for various scales (I don't 
think that the CLDR has defined default skip values so far).
Also, I think the likelihood of implementing  the per-calendar-scale 
default values wrong, is probably just as high as forgetting a SKIP value.

Setting the default to "SKIP=YES" (or "SKIP=OMIT", which sounds 
reasonable to me) would be the simplest solution, because it's the 
current behavior anyway.

#7:
True, it's not necessary to specify BYMONTH and BYMONTHDAY in sections 
4.2.2 and 4.2.3. But according to RFC 5545 it's completely valid and you 
can see many rules like that in the wild.
The purpose of an example is to show how an RRULE could look like in 
real life and how you have to interpret it. To me it perfectly makes 
sense to give examples of both types of rules (i.e. with and without 
redundant BYMONTH and BYMONTHDAY parts).

#8:
The idea is: If you skip a leap month, you go forward (or backwards) by 
one month. If you skip a leap day you go forward (or backwards) by one day.
I guess that should be pointed out somewhere.

#9:
I think that part has been added after I asked about the 
case-sensitivity of the RSCALE value. In general most calendar 
applications tend to use the upper-case representation of names and 
tokens, but the CLDR calendar scale names are defined in lower case (as 
in http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml).
I know it's just an implementation detail rather than being relevant for 
this standard, but being able to make assumptions about the case allows 
for certain optimization that wouldn't be possible otherwise. On a 
mobile device with very limited resources that can make a difference.
In this context I think "for consistency" means consistency between 
implementations, i.e. ideally all implementations would use the 
upper-case version, even though the standard doesn't enforce it (because 
most things in RFC 5545 are, by definition, case-insensitive).
I guess the same applies to the SKIP values and the "L" of leap months. 
Does this spec allow a lower case "l"?

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: Ken Murchison <[email-masked]>
Date: Thu, 29 Jan 2015 14:54:58 -0500

Hi Barry,

My comments/suggestions to select points are inline.  For the others I 
either agree with your assessment/suggestion or don't have a strong 
opinion and would be fine with any changes on those.

On 01/28/2015 06:05 PM, Barry Leiba wrote:
> ...

No objection here.

> default depended on the calendar.  (See also my comment #8 below

Perhaps an alternative to having a per-calendar default would be to make 
SKIP mandatory in the presence of RSCALE, thereby forcing the 
user/client to be explicit in their expectations.

> parallel to "BACKWARD" and "FORWARD" would be better.  Perhaps

Grisha (co-author) and I both have running code, but I personally don't 
have an issue with this change due to the fact that my RSCALE 
implementation in Libical hasn't been officially released yet.  I don't 
know the status of Grisha's deployment, so I will let him protest on his 
own if need be.

> in 4.2.1, where "BYMONTH=1" isn't needed?

As you point out, BYMONTH technically isn't needed.  I had suggested 
this example to Cyrus to illustrate to readers the fact that BYMONTH can 
take a value > 12 depending on the calendar.  If you feel that 
illustrating this point isn't necessary, or feel that a better example 
should be considered, I'm fine either way.

> that's in effect, and trying to define it to be independent doesn't

I'd be in favor of additional text clarifying that the effect of SKIP 
depends on whether the recurrence falls on an intercalary day or month.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University