Subject: [Ietf-calsify] Re: Out of scope rule parts?

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Tue Jul 19 14:49:11 2005

Am Dienstag, 19. Juli 2005 16:58 schrieb Laird Nelson:
> RFC 2445 says:
>
>    If BYxxx rule part values are found which are beyond the available
>    scope (ie, BYMONTHDAY=30 in February), they are simply ignored.
>
> Consider this (stupid) RRULE:
>
>   RRULE:FREQ=SECONDLY;BYMONTH=2;BYYEARDAY=4;BYHOUR=9
>
> Will this *never* generate an occurrence?  That is, does the offending
> BYxxx rule part (BYYEARDAY in this case) cause the "finer grained" BYxxx
> rule parts to be ignored?  Or will the RRULE simply ignore the BYYEARDAY
> part, thus generating an occurrence on every second in the ninth hour in
> February?

Actually, I think this is one of the areas where rfc 2445 is not very clear. 
In the following I will use this example:
  DTSTART;TZID=Europe/Vienna: 20050201T120000
  RRULE:FREQ=MONTHLY;BYMONTHDAY=30;FREQ=3

In particular, what do the formulation in the rfc mean:

-) "beyond the available scope": What is the available scope? If values 
outside the possible range are given, this is clear. But the example in the 
rfc already is unclear. 
Is the bymonthday=30 out of scope at all? (The rfc gives this as example, so 
according to the rfc it should be).
Is the bymonthday in the example above beyond the available scope in february? 
Is it beyond the available scope altogether because in february it's out of 
scope (of course not, but the rfc doesn't specify the scope, so one might 
argue in this direction, too)?

-) "simply ignored": Does this mean ignored as in "treated as if that by* part 
wasn't given at all"?  Or is the resulting occurrence (which would happen at 
an invalid date) simply ignored?

In particular, in the example above, the wording allows several 
interpretations... Which should be the correct interpretation of the rfc and 
the correct resulting list of occurences:
1) Feb 1 2005, May 30 2005, Aug 30, 2005, Nov 30 2005, (February is ignored 
altogether, because BYMONTHDAY=30 is out of scope)
2)  Feb 1 2005, May 30 2005, Aug 30 2005, Nov 30 2005, Feb 1 2005 (because 
BYMONTHDAY=30 is out of scope for february; the whole BYMONTHDAY is ignored 
=> date taken from DTSTART), MAY 30 2005, ...
3) Feb 1 2005, May 1 2005, Aug 1 200, Nov 1 2005, ... (The whole BYMONTHDAY is 
ignored because it's out of scope for february)
4) Only the DTSTART (since the only given bymonthday is not possible for one 
month, the rfc says that this by** rule part *value* is ignored, leaving us 
with an empty list of bymonthdays, so no occurrences can happen after the 
dtstart)...

Intuitively, I'd say that 1) would be the most sensible interpretation... 
Point 2) is not what a user would expect, 4) is definitely not what is 
intended[1], and 3) is also counter-intuitive, since the rrule explicitly 
says that it should happen on the 30th.

Cheers,
Reinhold

PS: Back to your example: I'd say that the event doesn't recur at all (i.e. 
only the DTSTART is the only recurrence). But as I said, this is up to 
interpretation of the rfc and one can argue about the result...

PS2: Your first interpretation (no recurrence at all) is my 1), and your other 
possibility (byyearday ignored) is my 3)...

[1] This is rather a stretch of the rfc, since "BYMONTHDAY=" (a completely 
empty bymonthday rule) is not rfc2445-compliant. On the other hand, the rfc 
says that the BY** rule part *value* is ignored, not the complete BY*** rule 
part!
-- 
------------------------------------------------------------------
DI Mag. Dr. Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer lead developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050719/bdab44dc/attachment.pgp

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Jul 19 17:22:22 2005

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050719/93d9b49e/smime.bin

---

From: tantek at technorati.com (Tantek Çelik)
Date: Tue Jul 19 18:08:54 2005

On Jul 19, 2005, at 5:22 PM, Doug Royer wrote:

>
> I think that CALSIFY needs to measure what vendors really do
> at this time with iCal objects.

Agreed.  In fact, I think what vendors really do should trump/supercede 
any "simplification" effort.

E.g. vendors support DTEND interoperably.  Therefore we should keep 
DTEND, regardless of your personal opinion that it is redundant with 
DURATION.

>
> I agree that clarifying the text is essential. I also think
> that if 80% of vendors do 'A', then that is the way that
> CALSIFY needs to start with as it will be the fastest
> way to interoperability.

Agreed.

>
> The goal is to make a specification that is interoperable
> with vendors.

By "vendors", I presume you mean *current implementations from vendors*.

> This will go on for years if we re-start iCal
> and what it "should" do.

Also agreed.

>
> I hope we keep the SIMPLIFY part as alive as fixing 2445 errors.

Only if SIMPLIFY doesn't interfere with INTEROP.

INTEROP *must* take precedence over SIMPLIFY.

Thanks,

Tantek

--
Tantek ?elik
Senior Technologist, Technorati, Inc.

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Jul 19 18:23:29 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050719/02165b90/smime.bin

---

From: tantek at technorati.com (Tantek Çelik)
Date: Tue Jul 19 19:15:31 2005

On Jul 19, 2005, at 6:23 PM, Doug Royer wrote:

> Tantek ?elik wrote:
>> Agreed.  In fact, I think what vendors really do should 
>> trump/supercede any "simplification" effort.
> The problem is not if we have both. The problem is not all vendors
> support both - so it busted. And bused means we can not go
> to 'standard' status.

That is a reasonable assertion to make if you can point to specifics 
(perhaps you already have and I missed the URL).

My specifics: In my (albeit limited) experience, DTEND is supported 
just fine (have yet to find any problems with) in both Apple 
iCal.app/OSX, and Mozilla Sunbird.

> So keeping DTEND vs DURATION 'as is" means that it will
> be difficult to declare that any one object is interoperable.
>
> Even when some of the large vendors use DTEND, they calculate
> it like DURATION. Even some vendors store both DTEND and DURATION
> in their store, they only use the DURATION or calculated DURATION
> value that they have stored, ignoring time zone shifts.
>
> Its not that I 'want' DURATION, its that seems to be how
> the majority of vendors do the time math.

I'm not seeing any of the problems you speak of (probably due to my own 
ignorance / naivete / lack of experience).  How recent are the 
specifics/evidence behind your conclusions?

Admittedly perhaps I am oversimplifying the situation, BUT:

As long as I can publish DTEND properties and have common clients (e.g. 
iCal.app and Sunbird) treat it properly/accurately, why should I stop 
using DTEND?

Thanks,

Tantek