headers
Oliver Block | 3 Jul 2008 14:46
Picon
Favicon

VFREEBUSY

Hello everybody,

In Sec. 3.6.4. you can find the following about the properties dtend and
duration:

1. ABNF:

                   ; the following are OPTIONAL,
                   ; but MUST NOT occur more than once

                   ... / dtend / duration / ...

2. Text:

      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.

Is it intended that 'dtend' and 'duration' my both occur in a VFREEBUSY
component? Or shouldn't they be mutually exclusive?

Best Regards,

Oliver Block
Permalink | Reply | 1 comment |
headers
Oliver Block | 3 Jul 2008 23:38
Picon
Favicon

Duration Value Type

Hello everybody,

I'd like to draw your attention to the following text:

      When computing an exact duration, the greatest order time
      components MUST be added first, that is, the number of weeks MUST
      be added first, followed by the number of days, number of hours,
      number of minutes, and number of seconds.

The syntax is defined as follows:

        dur-value  = (["+"] / "-") "P" (dur-date / dur-time / dur-week)

        dur-date   = dur-day [dur-time]
        dur-time   = "T" (dur-hour / dur-minute / dur-second)
        dur-week   = 1*DIGIT "W"
        dur-hour   = 1*DIGIT "H" [dur-minute]
        dur-minute = 1*DIGIT "M" [dur-second]
        dur-second = 1*DIGIT "S"
        dur-day    = 1*DIGIT "D"

As far as I've understood the meaning of RFC2445 (not the latest draft) 
and also of the syntax above, the use of week excludes the use of 
dur-date and also of dur-time. (I don't know if there is a need of a 
mixed form of in real life time planning.) So if you want to allow 
dur-week AND dur-date/dur-time within the same value, you need to change 
the ABNF to, for example

        dur-value  = (["+"] / "-") "P" [dur-week]  (dur-date / dur-time)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tim Hare | 4 Jul 2008 00:23
Picon

RE: VFREEBUSY

I believe DTSTART and DTEND specify the endpoints of the "specified window
of time" and DURATION the amount of time requested, in a free time request.

In English "I need to find an hour of your free time sometime between 11:00
on 07/03/20008 and 17:00 on 07/11/2008". 

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: ietf-calsify-bounces <at> osafoundation.org
[mailto:ietf-calsify-bounces <at> osafoundation.org] On Behalf Of Oliver Block
Sent: Friday, July 04, 2008 4:46 PM
To: ietf-calsify <at> osafoundation.org
Subject: [Ietf-calsify] VFREEBUSY

Hello everybody,

In Sec. 3.6.4. you can find the following about the properties dtend and
duration:

1. ABNF:

                   ; the following are OPTIONAL,
                   ; but MUST NOT occur more than once

                   ... / dtend / duration / ...

2. Text:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oliver Block | 4 Jul 2008 14:03
Picon
Favicon

Re: VFREEBUSY

Am Freitag, 4. Juli 2008 00:23:28 schrieben Sie:
> I believe DTSTART and DTEND specify the endpoints of the "specified window
> of time" and DURATION the amount of time requested, in a free time request.
>
> In English "I need to find an hour of your free time sometime between 11:00
> on 07/03/20008 and 17:00 on 07/11/2008".

That's a good point. 

Best Regards,

Oliver Block
Permalink | Reply | 501 comments |
headers
Bernard Desruisseaux | 4 Jul 2008 15:04
Picon
Favicon

Re: VFREEBUSY

Hi Oliver,

This is issue 67.

http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue67

Resolution is to disallow DURATION in VFREEBUSY components.
Check logs starting at [12:59:07]:

http://jabber.ietf.org/logs/calsify/2008-03-11.txt

Or the minutes of IETF71:

http://www.ietf.org/proceedings/08mar/minutes/calsify.txt

 > Consensus on issue 67 is to go with option a): Remove statement from
RFC2445bis.

Cheers,
Bernard

Oliver Block wrote:
> Am Freitag, 4. Juli 2008 00:23:28 schrieben Sie:
>> I believe DTSTART and DTEND specify the endpoints of the "specified window
>> of time" and DURATION the amount of time requested, in a free time request.
>>
>> In English "I need to find an hour of your free time sometime between 11:00
>> on 07/03/20008 and 17:00 on 07/11/2008".
> 
> That's a good point.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Bernard Desruisseaux | 4 Jul 2008 15:06
Picon
Favicon

Re: Duration Value Type

Oliver Block wrote:
> Hello everybody,
> 
> I'd like to draw your attention to the following text:
> 
>      When computing an exact duration, the greatest order time
>      components MUST be added first, that is, the number of weeks MUST
>      be added first, followed by the number of days, number of hours,
>      number of minutes, and number of seconds.
> 
> The syntax is defined as follows:
> 
>        dur-value  = (["+"] / "-") "P" (dur-date / dur-time / dur-week)
> 
>        dur-date   = dur-day [dur-time]
>        dur-time   = "T" (dur-hour / dur-minute / dur-second)
>        dur-week   = 1*DIGIT "W"
>        dur-hour   = 1*DIGIT "H" [dur-minute]
>        dur-minute = 1*DIGIT "M" [dur-second]
>        dur-second = 1*DIGIT "S"
>        dur-day    = 1*DIGIT "D"
> 
> As far as I've understood the meaning of RFC2445 (not the latest draft) 
> and also of the syntax above, the use of week excludes the use of 
> dur-date and also of dur-time. (I don't know if there is a need of a 
> mixed form of in real life time planning.) So if you want to allow 
> dur-week AND dur-date/dur-time within the same value, you need to change 
> the ABNF to, for example
> 
>        dur-value  = (["+"] / "-") "P" [dur-week]  (dur-date / dur-time)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard Desruisseaux | 4 Jul 2008 15:52
Picon
Favicon

Re: AD review issue #1: Use of ALTREP

I don't believe the current proposal is appropriate.

As it stands, the draft (RFC2445 as well) makes it clear that ALTREP is 
only allowed on 6 specific text properties, that is, COMMENT, 
DESCRIPTION, LOCATION, RESOURCES, SUMMARY, and CONTACT. I also believe 
the meaning of ALTREP is already properly defined.

In practice though, I'm not sure there is a single calendar user agent 
that exposes it (i.e., allow an end user to set its value, or make use 
of it).

Finally, the following search on the web will only report two iCalendar 
objects that makes use of ALTREP!

http://www.google.com/search?q=ALTREP+filetype%3Aics

In the past we've discussed limiting the URI schemes allowed for 
CAL-ADDRESS but never got around to it.  Perhaps we should limit the URI 
schemed allowed both for ALTREP and CAL-ADDRESS (two sets) while we're 
at it.

On the other hand, when applications while actually start making use of 
ALTREP, I suspect the media type of the resource being pointed at might 
be the real interop issue (e.g., http URL pointing to an XHTML, HTML, 
PDF, PNG, or JPG document).

Cheers,
Bernard

Eliot Lear wrote:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bernard Desruisseaux | 4 Jul 2008 16:02
Picon
Favicon

Re: AD review issue #2: DIR parameter

Cyrus Daboo wrote:
> Hi Aki,
> 
> --On June 16, 2008 12:59:12 PM +0300 Aki Niemi <aki.niemi <at> nokia.com> wrote:
> 
>>> > Section 3.2.6, DIR parameter:  This should be limited to LDAP URLs
>>> > only, if not by requirement then at least by noting that other types
>>> > of URLs are likely to be harmful to interoperability.
>>
>> For maximum interoperability, a mandatory-to-implement choice should be
>> defined. However, is LDAP even widely enough supported in iCalendar
>> implementations to justify this? I suspect vCardDAV URLs could in the
>> future start appearing here as well.
> 
> I think at the very least HTTP/HTTPS needs to be allowed as well.
> 

cid and mid would be needed in the context of iMIP.

Here's a proposal for the mandatory-to-implement:

cid
data (e.g., to embed vCard directly?)
file
ftp
http
https
ldap
mid
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard Desruisseaux | 4 Jul 2008 16:46
Picon
Favicon

Re: AD review issue #3: Meaning of RELTYPE parameter value of SIBLING (was: Re: Re: AD review on 2445bis)

While I was about to propose that we deprecate SIBLING I found cases 
where it might be handy in the future...

1- Group multiple to-dos that don't have a parent to-do. Not a very 
important use cases I think...

2- When breaking an unbounded recurring events in two events (i.e., the 
truncated unbounded recurring events for past recurrence instances, and 
a new unbounded recurring event for the "new" future recurrence 
instances), it might be useful to link the events together with this 
relationship.

Cheers,
Bernard

Aki Niemi wrote:
> ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
>>> Section 3.2.15: RELTYPE.  What does it mean that a calendar component  
>>> referenced is the SIBLING of this one?  How is a user agent supposed  
>>> to use this information?  Is this parameter ever used except on  
>>> RELATED-TO?  Is it actually in use even there?  Health warnings at  
>>> least.
> 
> Good question. Is there a use case that requires a relationship beyond
> parent-child (which currently is the only *defined* relationship in the
> document anyway)?
> 
> Cheers,
> Aki
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard Desruisseaux | 4 Jul 2008 17:05
Picon
Favicon

Re: AD review issue #4: Supporting both VTODO and VEVENT in thesame iCalendar stream (was: Re: Re: AD review on2445bis)

It's not clear to me what Lisa is suggesting actually.

a) Warning about the fact that components type can be mixed?
b) Not to ignore unsupported component types silently?

Proposed text would be great!

Things that should be noted:

1- iTIP does not allow different component types to be mixed.

2- CalDAV provides means to get only the components types that you want.

As such, in practice we will only see mixed component types in export 
scenarios and Internet calendars (aka, webcal).

Cheers,
Bernard

Eliot Lear wrote:
> I believe we have consensus as to Lisa's suggestion.  Any disagreement?
> 
> Eliot
> 
> Tim Hare wrote:
>> As an "informed user" - i.e. not a developer, I definitely support
>> NON-silent rejection.  I can agree with non-support of certain components
>> only if I receive some notification;  due to work requirements I am now
>> journalling my time on some projects, and it would be good to know if I
>> can't import that data into another tool.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane