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

From: Barry Leiba <[email-masked]>
Date: Mon, 2 Feb 2015 14:06:28 -0500

Marten and Ken, thanks for the replies.  You've both addressed some of
the same comments, so I'll try to reply in one message.

---
On point 2:
>> 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.)

Marten says...
> 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.

Ken says...
> 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.

To Marten, the point I'm making is that in order to support various
calendars correctly, implementations need to understand how to
correctly skip within each calendar anyway.  That is, all
implementations that support the Hebrew calendar will need to know
that when Adar I (5L) is not present, you have to skip forward to Adar
(6)... and they'll need to know that regardless of what default we
place on SKIP.  That means that generating a Hebrew calendar entry in
Adar I without SKIP is an error.

It seems to be inviting problems to take an attribute whose value is
fixed to the calendar, and to give it a default that is always correct
for some calendars and always wrong for others... is the wrong
approach.  Consider what happens when a buggy implementation
incorrectly omits SKIP.  Consumers of that entry will then necessarily
get things wrong for the Hebrew calendar, always (well, always for
entries in Adar I).

I think the default either has to be set appropriately for each
calendar (and Marten is right that there's a problem with that, in
that you have to have some place to make that assignment, which would
have to mean a registry for it), or to do as Ken suggests and make
SKIP=OMIT be the default.  I think I like that answer.

But making SKIP required would also work, and I'd be happy with that
alternative as well.

---
On point 7:
>> 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?

Marten says...
> 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).

Ken says...
> 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.

I understand that, while it's not needed, it's legal.  My point was
that I didn't see that this example was any different from the
previous one, so why have it?  It might actually lead a reader to
believe that BYMONTH was necessary in this case.  Thanks to both
Marten and Ken for explaining reasons to have the example.  I think
it's useful to illustrate the points that it can be there even though
it's not required, and that it can have a value > 12.  I think it
would help to have text in the example that explains both of those
points.

---
On point 8:
>> 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.

Marten says...
> 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.

Ken says...
> 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.

Indeed: there's nothing at all in the document that says that SKIP
works differently in different situations, and I think it's necessary
to have very clear text there that specifies exactly how skip works
when.

And I think this makes it more evident that "SKIP=OMIT" should be the
default... otherwise, the default for anyone who specifies
"RSCALE=GREGORIAN" will turn 29 Feb into 28 Feb.  It'd be far better
for it to work as it does today, unless SKIP is explicitly specified.

---
On point 9:

Marten says...
> #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).

Ah, but because it's defined as being case insensitive, you're *not*
able to make assumptions about the case, and you can't optimize
anything.  You don't know when you might be handed something that
doesn't follow that SHOULD, so your code has to handle it (and I'd
argue that if your code requires that it be in upper case, and doesn't
work if it's not, your code is broken).

I think we should have required upper case in the base iCalendar spec.
But the fact that we didn't is a ship that's sailed under the bridge
and through the barn door.  Sigh.  But that means that the SHOULD is
really pointless.  I'm happy if you use plain English to say that
there are advantages to using upper case, and remind readers that
iCalendar strongly recommends it.  I don't think 2119 SHOULD is
appropriate.

> I guess the same applies to the SKIP values and the "L" of leap months. Does
> this spec allow a lower case "l"?

It does, because literals in ABNF are case-insensitive (see RFC 5234).

---
Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 03 Feb 2015 12:18:41 -0500

Hi Barry,
Thanks for your review. Comments below. I have applied the fixes below to 
my working copy.

--On January 29, 2015 at 12:05:18 AM +0100 Barry Leiba 
<[email-masked]> wrote:

> 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".

Please see my answer to point #11 below.

> 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.

Additional clarifying text added, as suggested.

> 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".

Will wait on this until the outcome of the SKIP discussion.

> 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.)

Text adjusted (as per Aron Roberts alternative).

> 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.'

Text adjusted to:

    Thus ICU months 1 through 5 map to iCalendar months 1 through 5, ICU
    month 6 maps to iCalendar month "5L", and ICU months 7 through 13 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).

I just added "(from the example above)" to the end of the first sentence.

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

I propose changing the example rule to:

RRULE:RSCALE=ETHIOPIC;FREQ=MONTHLY;BYMONTH=13

That one does require the presence of BYMONTH to limit the set of dates to 
just the one month. I will also add the following to the sentence following 
the RRULE:

    Whilst there are a number of alternative ways of writing the RRULE
    above to achieve the same pattern of recurring dates, the one above was
    chosen to illustrate a BYMONTH value exceeding the limit of 12,
    previously described in iCalendar (Section 3.3.10 of [RFC5545]).

> 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.

I have changed that sentence to:

    "RSCALE" values are case-insensitive, but upper case is preferred.

That matches the descriptions used in formal syntax comments else where in 
the document.

> 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?

I changed the relevant sentence to:

    These alias values can be used as "RSCALE" values and are treated the
    same as the equivalent CLDR calendar system they are an alias for.

> 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.

Yes you are right we need advice on what to do when seeing RSCALE in 
"normal" parsing situations - not use iTIP. As a result, I think that does 
mean this specification will update iCalendar (and xCal, jCal) as it will 
be necessary (or at least good practice) for iCalendar parsers to at least 
be aware of the fact that RSCALE might appear, even if they do nothing with 
it. So that will address point #0.

I propose adding a new section before the existing iTIP section:

    6.  Compatibility

       For calendar user agents that do not support the "RSCALE" element, or
       do not support the calendar system specified by the "RSCALE" element
       value, the following behaviors are possible when processing iCalendar
       data:

       1.  The calendar user agent can reject the entire iCalendar object
           within which at least one iCalendar component uses the
           unrecognized "RSCALE" element or element value.

       2.  The calendar user agent can reject just the iCalendar components
           containing an unrecognized "RSCALE" element or element value.
           Note that any overridden components associated with those
           rejected components MUST also be rejected (i.e., any other
           components with the same "UID" property value as the one with the
           unrecognized "RSCALE" element or element value).

       3.  The calendar user agent can fallback to a non-recurring behavior
           for the iCalendar component containing the unrecognized "RSCALE"
           element or element value (effectively ignoring the "RRULE"
           property).  However, any overridden components SHOULD be rejected
           as they would represent "orphaned" instances that would seem to
           be out of place.

       In general, the best choice for a calendar user agent would be option
       (2) above, as it would be the least disruptive choice.  Note that
       when processing iTIP [RFC5546] messages, the manner of the rejection
       is covered in the next section.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Tue, 3 Feb 2015 12:36:52 -0500

> Will wait on this until the outcome of the SKIP discussion.

Indeed; lots could change... or not.

>    to iCalendar months 6 through 12.

Perfect.

> I just added "(from the example above)" to the end of the first sentence.

That works.

>    previously described in iCalendar (Section 3.3.10 of [RFC5545]).

A fine way to handle this; thanks.

> That matches the descriptions used in formal syntax comments else where in

Great!

>    same as the equivalent CLDR calendar system they are an alias for.

Also perfect.

> mean this specification will update iCalendar (and xCal, jCal) as it will be
> necessary (or at least good practice) for iCalendar parsers to at least be
> aware of the fact that RSCALE might appear, even if they do nothing with it.
> So that will address point #0.

OK; I accept that explanation.  It might be worth pointing to the new
Section 6 (below) in the introduction, where you mention the updates.

>       is covered in the next section.

This looks good.

So I think we're all set except for the outcome of the SKIP discussion.

b

---

From: Gregory Yakushev <[email-masked]>
Date: Wed, 04 Feb 2015 10:42:14 +0000

I see that most of the points are cleared, so my only comment is on the
SKIP behavior, below.

> But making SKIP required would also work, and I'd be happy with that

For completeness of this discussion I'd like to reiterate the reason we
chose BACKWARD as default, because this reason is still valid.

Defaults are nice because they conserve space for both computers and
readers. So when choosing a default it makes sense to choose the most
popular option, so most users won't need to specify it for their RRULEs to
'just work'. The BACKWARD is expected to be by far the most popular option
in most calendars (except Hebrew), so choosing this default saves effort
for the vast majority of users. Any other option would require vast
majority of users to always include extra text in RRULE.

It leaves Hebrew users with inconvenience of specifying SKIP=FORWARD for
some rules though. The only option that doesn't require this effort is to
use per-Calendar default, which implies keeping a registry just for this
purpose. I don't think this particular case is worth the effort.

I strongly oppose SKIP parameter to be required because of the above point,
and also because for many RRULEs it never matters (e.g. daily, weekly, New
Year celebrations etc.).

It is acceptable to make OMIT to be default. It will require extra text in
most RRULEs, but it simplifies the spec and is consistent with RRULE
behavior when RSCALE is not present.

To recap: my favorite default option is still BACKWARD, but OMIT is
acceptable if consensus points in this direction. I'd prefer to avoid
making SKIP required or having a per-Calendar default.

My RSCALE implementation is deployed with Google Calendar, but it is not
'officially' launched, so changing implementation slightly should be OK at
this point.

> It does, because literals in ABNF are case-insensitive (see RFC 5234).

Thanks,
Grisha

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