Subject: Re: [Ietf-calsify] Section 4.8.2.5 Duration: VFREEBUSY request

From: Aki Niemi <[email-masked]>
Date: Thu, 08 Nov 2007 13:25:21 +0200

[as chair]

Folks,

We need to resolve this issue, which to my knowledge is still pending.
Option a) below would require a change in rfc2445bis, which is almost
done now, so your input is needed *now*.

Cheers
Aki

ma, 2006-11-06 kello 07:25 -0800, ext Cyrus Daboo kirjoitti:
> Hi Bernard,
> 
> --On November 5, 2006 5:36:05 PM -0500 Bernard Desruisseaux 
> <[email-masked]> wrote:
> 
> >  > In a "VFREEBUSY" calendar component the property may be
> >  > used to specify the interval of free time being requested.
> >
> > Yet, section 3.3.2 REQUEST of RFC 2446 (iTIP) specifies that
> > the DURATION property is not allowed in a VFREEBUSY request.
> >
> > I see three options:
> >
> > a) Remove statement from iCalendar to be in sync with iTIP;
> >
> > b) Change iTIP to allow the DURATION property in a VFREEBUSY
> >     request and define the semantic as specified in iCalendar.
> >
> > c) Status quo.
> 
> We should rule out (c) as it represents an inconsistency between the two 
> specs. Note that 2445 does not clearly define what it means to have 
> DURATION present. e.g. is it allowed for the responder to only return free 
> times slots that are equal to or larger than the DURATION, or should they 
> still return the full list? If we can clearly specify the behavior then I 
> think (b) is reasonable, otherwise we have to do (a).
> 

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: "Tim Hare" <[email-masked]>
Date: Sat, 10 Nov 2007 08:54:55 -0500

DURATION is used in VFREEBUSY requests in the sense of "search for a
half-hour block of free time", at least according to my interpretation of
this paragraph in 3.6.4 of draft-ietf-calsify-rfc2445bis-07.txt

"When present in a "VFREEBUSY" calendar component, the "DTSTART"
      and "DTEND" properties SHOULD be specified prior to any "FREEBUSY"
      properties.  In a free time request, these properties can be used
      in combination with the "DURATION" property to represent a request
      for a duration of free time within a specified window of time." 

Since this is probably a fairly common use case when scheduling meetings,
the only choice that makes sense, in my opinion, is (b) .

To eliminate perceived vagueness, in the second sentence of the paragraph
from 3.6.4 we could change the wording to read:

"In a free tine request, the DTSTART, DTEND, and DURATION properties can be
used to represent a request to find a period of free time, of length
DURATION, within the period of time bounded inclusively by DTSTART and
DTEND."

It might also help to have one of the examples show that kind of request.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Aki Niemi
Sent: Thursday, November 08, 2007 6:25 AM
To: ext Cyrus Daboo
Cc: Calsify WG
Subject: Re: [Ietf-calsify] Section 4.8.2.5 Duration: VFREEBUSY request

[as chair]

Folks,

We need to resolve this issue, which to my knowledge is still pending.
Option a) below would require a change in rfc2445bis, which is almost done
now, so your input is needed *now*.

Cheers
Aki

ma, 2006-11-06 kello 07:25 -0800, ext Cyrus Daboo kirjoitti:
> >  > In a "VFREEBUSY" calendar component the property may be  > used 
> > to specify the interval of free time being requested.
> >
> > Yet, section 3.3.2 REQUEST of RFC 2446 (iTIP) specifies that the 
> > DURATION property is not allowed in a VFREEBUSY request.
> >
> > I see three options:
> >
> We should rule out (c) as it represents an inconsistency between the 
> two specs. Note that 2445 does not clearly define what it means to 
> have DURATION present. e.g. is it allowed for the responder to only 
> return free times slots that are equal to or larger than the DURATION, 
> or should they still return the full list? If we can clearly specify 
> the behavior then I think (b) is reasonable, otherwise we have to do (a).
>