Subject: Re: [Ietf-calsify] Imprecise and alternative events for iCalendar andiTIP

From: "Fábio Henrique da Silva" <[email-masked]>
Date: Tue, 29 Jan 2008 21:38:12 -0300

Dear Nigel,

Thanks for the comments! Yes, I think that, even with the difficulties
presented on the appendix of the draft, we should look for solutions
preserving backward compatibility. It would be nice to hear some opinions
about these alternative design solutions you proposed =o)

I would only point that, apart from the discussion on the number of levels
(0-100 is only an initial hint based on PERCENT-COMPLETE), the concept of
rank is relevant, since some event descriptions and time ranges must be
marked as more appropriate/desired/likely to be scheduled/... than others.

But the primary purpose of the draft is that: to start a discussion on how
to give more flexibility to iCalendar in a standard way, pointing that such
mechanisms would be really useful for scheduling negotiation.

Cheers,

Fábio.

On Jan 24, 2008 3:09 PM, Nigel Swinson <[email-masked]> wrote:

>         Title           : Imprecise and alternative events for iCalendar
> and iTIP
>        Author(s)       : F. Silva, R. Drummond
>        Filename        : draft-silva-events-01.txt
>        Pages           : 55
>        Date            : 2007-12-21
>
> This has long been something that has annoyed me about digital
> calendaring, so I'm delighted to see that this work is proceeding :o)  I've
> finally found the time to read the document, and have the following
> comments.
>
> *3.1**.  Imprecise Event Component*
> Given that calendars are being shared so much between so many clients, I
> feel uneasy about the lack of backward compatibility expressed in the
> document as it stands.  Suppose I was to arrange with my mum to have
> dinner tonight, but we hadn't yet agreed a time.  I would then "guess" than
> the meal would start somewhere between 5pm and 8pm and last until midnight.
> To begin with I don't think I can say the event will last until midnight,
> regardless of it's start time, so lets assume I say it is going to last 4
> hours.  Writing this as a VIMPRECISEEVENT I think I'd have to write this
> as:
>
>         BEGIN:VIMPRECISEEVENT
>         UID:[email-masked]
>         DTSTAMP:20080124T160825Z
>         SUMMARY:Dinner with my mum
>         DURATION:PT4H
>         BEGIN:VFREEBUSY
>         UID:[email-masked]
>         DTSTAMP:20080124T160825Z
>         FREEBUSY;FBTYPE=FREE:20080124T170000Z/20080125T000000Z
>         END:VFREEBUSY
>         END:VIMPRECISEEVENT
>
> If I look at this inside a client that supports VIMPRECISEEVENT then
> perhaps it'll show it with appropriate annotation, but then when I view it
> in a client that doesn't support it I'll see absolutely nothing at all,
> implying that my evening is free.
>
> I expected imprecise events to be specified by some modifier on the
> DTSTART/DTEND properties.  ie something like this (which also allows me to
> say it ends at midnight):
>
>         BEGIN:VIMPRECISEEVENT
>         UID:[email-masked]
>         DTSTAMP:20080124T160825Z
>         SUMMARY:Dinner with my mum
>         DURATION:PT4H
>         DTSTART;RANGE=3H:20080124170000Z
>         DTEND:20081225000000Z
>         END:VIMPRECISEEVENT
>
> Now when I look at this in a client that doesn't understand the RANGE
> parameter on DTSTART, it'll show up as busy from 5pm-12pm, and in a client
> that does, it can show a "fuzzy" start from 5pm-8pm, and then definately
> busy up until 12pm.
>
> A freebusy lookup could also then return meaningful data from both
> clients, whereas you've specified that VIMPRECISEEVENT is invisible to
> free busy lookups.  The one that didn't support RANGE for DTSTART might
> return busy from 8-12, while the other could return:
>
>         BEGIN:VFREEBUSY
>         UID:[email-masked]
>         DTSTAMP:20080124T160825Z
>         FREEBUSY;FBTYPE=BUSY-TENTATIVE:20080124T170000Z/20080124T200000Z
>         FREEBUSY;FBTYPE=BUSY:20080124T200000Z/20080125T000000Z
>         END:VFREEBUSY
> Admittedly adding a RANGE parameter to DTSTART and DTEND would not be as
> flexibly as specifying a duration and a list of constraints by means of
> free/busy, but it has the advantage of being far easier to apply to an
> existing iCalendar parser, rather than having to deal with an entirely new
> iCalendar component, so I think it might get a substantially bigger uptake.
>
> WRT to an event that specifies a medical appointment that occurs
> within one of several time periods (the second example in the spec), that
> could then be implemented either by means of STATUS:TENTATIVE on an
> appointment with an RRULE, or else by using VALTERNATIVEEVENTS.
>
> *3.2**.  Alternative Events Component*
> In the interests of parser re-use, rather than specifying the default
> event properties in the alternativeeventsprop and then overridden in the
> *eventc I'd be inclined to specify them by means of a "master event"
> section, of type eventc.  Then if some new event property comes out, only
> the parser for eventc needs to be updated, rather than also the
> alternativeeventsprop collection.  One slight problem is that for a vevent
> to be valid, it must have a dtstart, so I'd suggest we just refer to one of
> our alternative events as our "master event" that contains default
> properties. The example would become something like:
>
>       BEGIN:VALTERNATIVEEVENTS
>       UID:[email-masked]
>       DTSTAMP:20071005T133225Z
>       DEFAULTPROPERTIES:[email-masked]
>       BEGIN:VEVENT
>       UID:[email-masked]
>       DTSTAMP:20071005T133225Z
>       DTSTART:20071005T133225Z
>       SUMMARY:Quick interop test
>       COMMENT:Trying the options that seem most likely to be accepted...
>       END:VEVENT
>       BEGIN:VEVENT
>       UID:[email-masked]
>       DTSTAMP:20071005T133225Z
>       DTSTART:20080406T090000Z
>       DTEND:20080405T120000Z
>       RANK:100
>       COMMENT:It would be perfect if we could meet at that same time!
>       END:VEVENT
>       BEGIN:VIMPRECISEEVENT
>       ..etc...
>       END:VIMPRECISEEVENT
>       END:VALTERNATIVEEVENTS
>
> *3.3**/3.4/3.5  Minimum/Maximum Granularity/Rank Component Property*
>
> I think these are icing that I'd be inclined to ignore in an initial
> implementation.  Even writing the gui and trying to communicate the concepts
> would be challenging.  I'm also not sure why it's worth saying that Rank is
> defined as a %.  Why not just an unsigned number?  Then if you want to
> communicate it as a % you can evaluate the max/min Rank, and convert to a
> %.  I'm sure 100 levels is plenty, but for the sake of writing a
> specification, I don't see why you couldn't just say it's an arbitrary
> number.  It would be very annoying to find you needed more levels, but the
> standard didn't permit it.
>
> Cheers
>
> Nigel
>
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: "Tim Hare" <[email-masked]>
Date: Tue, 29 Jan 2008 20:22:25 -0500

Would the "pencil in" function of a VEVENT for four hours with TRANSP:
TRANSPARENT provide a similar function to what is described in your use case
for VIMPRECISEEVENT? 
 
Similarly, for scheduling, would it be simpler to define iTIP such that a
METHOD: REQUEST for scheduling an appointment, which included VFREEBUSY
components; i.e. " I'd like to schedule an appointment, and I'm free during
these times",  would indicate the preference of the time to be scheduled by
the order of the VFREEBUSY components? That would allow for an unlimited
number of potential openings for scheduling, without having to have a
defined RANK property, and it's certainly not that difficult for
implementations to ennumerate the VFREEBUSY components in that way.

Tim Hare
Interested Bystander, Non-Inc.

  _____  

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Fábio Henrique
da Silva
Sent: Tuesday, January 29, 2008 7:38 PM
To: Nigel Swinson
Cc: [email-masked]
Subject: Re: [Ietf-calsify] Imprecise and alternative events for
iCalendarandiTIP

Dear Nigel,

Cheers,

Fábio.

       Title           : Imprecise and alternative events for iCalendar and
iTIP
       Author(s)       : F. Silva, R. Drummond
       Filename        : draft-silva-events-01.txt
       Pages           : 55 
       Date            : 2007-12-21

This has long been something that has annoyed me about digital calendaring,
so I'm delighted to see that this work is proceeding :o)  I've finally found
the time to read the document, and have the following comments.
 
3.1.  Imprecise Event Component

Given that calendars are being shared so much between so many clients, I
feel uneasy about the lack of backward compatibility expressed in the
document as it stands.  Suppose I was to arrange with my mum to have dinner
tonight, but we hadn't yet agreed a time.  I would then "guess" than the
meal would start somewhere between 5pm and 8pm and last until midnight.  To
begin with I don't think I can say the event will last until midnight,
regardless of it's start time, so lets assume I say it is going to last 4
hours.  Writing this as a VIMPRECISEEVENT I think I'd have to write this as:
 
        BEGIN:VIMPRECISEEVENT
 
If I look at this inside a client that supports VIMPRECISEEVENT then perhaps
it'll show it with appropriate annotation, but then when I view it in a
client that doesn't support it I'll see absolutely nothing at all, implying
that my evening is free.  

        BEGIN:VIMPRECISEEVENT

A freebusy lookup could also then return meaningful data from both clients,
whereas you've specified that VIMPRECISEEVENT is invisible to free busy
lookups.  The one that didn't support RANGE for DTSTART might return busy
from 8-12, while the other could return:
 
        BEGIN:VFREEBUSY

WRT to an event that specifies a medical appointment that occurs within one
of several time periods (the second example in the spec), that could then be
implemented either by means of STATUS:TENTATIVE on an appointment with an
RRULE, or else by using VALTERNATIVEEVENTS.
 
3.2.  Alternative Events Component

In the interests of parser re-use, rather than specifying the default event
properties in the alternativeeventsprop and then overridden in the *eventc
I'd be inclined to specify them by means of a "master event" section, of
type eventc.  Then if some new event property comes out, only the parser for
eventc needs to be updated, rather than also the alternativeeventsprop
collection.  One slight problem is that for a vevent to be valid, it must
have a dtstart, so I'd suggest we just refer to one of our alternative
events as our "master event" that contains default properties. The example
would become something like:
 
      BEGIN:VALTERNATIVEEVENTS

3.3/3.4/3.5  Minimum/Maximum Granularity/Rank Component Property
 
I think these are icing that I'd be inclined to ignore in an initial
implementation.  Even writing the gui and trying to communicate the concepts
would be challenging.  I'm also not sure why it's worth saying that Rank is
defined as a %.  Why not just an unsigned number?  Then if you want to
communicate it as a % you can evaluate the max/min Rank, and convert to a %.
I'm sure 100 levels is plenty, but for the sake of writing a specification,
I don't see why you couldn't just say it's an arbitrary number.  It would be
very annoying to find you needed more levels, but the standard didn't permit
it.
 
Cheers
 
Nigel