Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-05.txt

From: Internet-Drafts at ietf.org ([email-masked])
Date: Tue Jan 30 12:51:01 2007

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: Internet Calendaring and Scheduling Core Object Specification (iCalendar)
	Author(s)	: B. Desruisseaux
	Filename	: draft-ietf-calsify-rfc2445bis-05.txt
	Pages		: 161
	Date		: 2007-1-30
	
This document defines a MIME media type for representing and
   exchanging calendaring and scheduling information such as events, to-
   dos, journal entries and free/busy information.  The definition of
   the text/calendar media type, known as iCalendar, is independent of
   any particular calendar service or protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-calsify-rfc2445bis-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
-------------- next part --------------
Skipped content of type multipart/alternative

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Wed Jan 31 06:07:19 2007

Folks,

I have uploaded the .html and .changes.html versions of the draft
on the IETF Tools web site at the following locations:

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-05.html

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-05.changes.html

Cheers,
Bernard

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

---

From: TimHare at comcast.net (Tim Hare)
Date: Wed Jan 31 18:59:36 2007

Small issue I just noticed: in the sections about registering new
properties, we are using [email-masked].  Does imc.org still want
this role? The mailing list itself has been inactive for quite some time. I
also don't see how e-mailing to IMC gets something posted to IANA but I've
never known how that worked, anyway so perhaps I just need enlightenment.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard
Desruisseaux
Sent: Wednesday, January 31, 2007 9:06 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-05.txt

Folks,

I have uploaded the .html and .changes.html versions of the draft on the
IETF Tools web site at the following locations:

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-ca
lsify-rfc2445bis-05.html

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-ca
lsify-rfc2445bis-05.changes.html

Cheers,
Bernard

[email-masked] wrote:
> This draft is a work item of the Calendaring and Scheduling Standards
Simplification Working Group of the IETF.
> logging in, type "cd internet-drafts" and then "get 
> draft-ietf-calsify-rfc2445bis-05.txt".
> 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

From: "Tim Hare" <[email-masked]>
To: "'Bernard Desruisseaux'" <[email-masked]>, <[email-masked]>
Subject: RE: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-05.txt
Date: Wed, 31 Jan 2007 21:58:17 -0500

Small issue I just noticed: in the sections about registering new
properties, we are using [email-masked].  Does imc.org still want
this role? The mailing list itself has been inactive for quite some time. I
also don't see how e-mailing to IMC gets something posted to IANA but I've
never known how that worked, anyway so perhaps I just need enlightenment.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard
Desruisseaux
Sent: Wednesday, January 31, 2007 9:06 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-05.txt

Folks,

I have uploaded the .html and .changes.html versions of the draft on the
IETF Tools web site at the following locations:

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-ca
lsify-rfc2445bis-05.html

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-ca
lsify-rfc2445bis-05.changes.html

Cheers,
Bernard

[email-masked] wrote:
> This draft is a work item of the Calendaring and Scheduling Standards
Simplification Working Group of the IETF.
> logging in, type "cd internet-drafts" and then "get 
> draft-ietf-calsify-rfc2445bis-05.txt".
> 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

Date: Wed, 31 Jan 2007 09:05:38 -0500
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-05.txt

Folks,

Cheers,
Bernard

> implementation to automatically retrieve the ASCII version of the

Date: Tue, 30 Jan 2007 21:51:37 +0100
From: Martin Kiff <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] DTSTART with assumed DTEND...

Nigel Swinson wrote:

>>>Giving just a
>>> DTSTART;VALUE=DATE:20070129
>>>without a DTEND ought to be sufficient if it wasn't for the 'assumed'
>>>DTEND. Even then the assumed 'DTEND' would be no problem if UA's did not
>>>assume that a event with an assumed DTEND was a whole day event. Perhaps
>>>the spec can be clarified here...
>>>      
>>>
>>We serialize this distinction as an X-OSAF-ANYTIME-PARAM=TRUE parameter
>>in all day DTSTARTs.  We'd be delighted to do something more
>>standardized if there's broad interest in such a thing.
>>    
>>
>
>I'd like it too, but it does sound awkward to represent in a gui.  Until it has a time, you can only render it next to the day.  I'd opted for getting the user to supply a time and mark it as Tentative.
>
>Nigel
>  
>
That might be ok when the user is noting the date (and time) in their 
own calendar, however there is also the case where the event is 
published on the web and the user wants to subscribe/copy it. If there 
was an event marked up with just:

     DTSTART;VALUE=DATE:20070129

I would expect to have _no_more_ information displayed by the UA; it 
should not give an end date, it should not show a flag saying 'all day 
event' and it should not force me to add a time. I'd also expect that if 
I saved this event elsewhere, _no_additional_information_ would be 
written (specifically it should not save 'an assumed' DTEND on my behalf)

However the above is describes the problems for the UA, I think where 
this affects this discussion is that the spec should not tempt people to 
believe that an event with simply a:

     DTSTART;VALUE=DATE:20070129

implies an all day event.

Regards, Martin

To: [email-masked]
From: [email-masked]
Date: Tue, 30 Jan 2007 15:50:02 -0500
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-05.txt 

--NextPart

	

Send a message to:
	[email-masked].
In the body type:

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-calsify-rfc2445bis-05.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 29 Jan 2007 11:28:53 -0800
From: "Mike Samuel" <[email-masked]>
To: "Nigel Swinson" <[email-masked]>
Subject: Re: [Ietf-calsify] DTSTART with assumed DTEND...
Cc: [email-masked]
Reply-To: [email-masked]

Could this fit in with anything related to negotiating a time for a meeting?

It might be easier to do negotiation-based scheduling if it's explicit
that an event is tentative, but will probably fall within a range of
times.  That range of times could be successively winnowed until an
actual time is agred upon at which point it's DTSTART becomes a
date-time and it becomes opaque.

mike

On 29/01/07, Nigel Swinson <[email-masked]> wrote:
> > > Giving just a
> > >  DTSTART;VALUE=DATE:20070129
> > > without a DTEND ought to be sufficient if it wasn't for the 'assumed'
> > > DTEND. Even then the assumed 'DTEND' would be no problem if UA's did not
> > > assume that a event with an assumed DTEND was a whole day event. Perhaps
> > > the spec can be clarified here...
> >
> > We serialize this distinction as an X-OSAF-ANYTIME-PARAM=TRUE parameter
> > in all day DTSTARTs.  We'd be delighted to do something more
> > standardized if there's broad interest in such a thing.
>
> I'd like it too, but it does sound awkward to represent in a gui.  Until it has a time, you can only render it next to the day.  I'd opted for getting the user to supply a time and mark it as Tentative.
>
> Nigel

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: b6965a6c6991f7ba3d6925c67055772c
X-Spam-Score-Summary: 2, 0, 0, c20ff51194b072a8, b95df125897952b8, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:599:601:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1539:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2198:2199:2393:2559:2562:2828:3027:3352:3865:3867:3868:3869:3870:3872:3873:3874:4250:4321:5007, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Ietf-calsify] DTSTART with assumed DTEND...
Date: Mon, 29 Jan 2007 19:18:35 -0000

> > Giving just a
> >  DTSTART;VALUE=3DDATE:20070129
> > without a DTEND ought to be sufficient if it wasn't for the =
'assumed'
> > DTEND. Even then the assumed 'DTEND' would be no problem if UA's did =
not
> > assume that a event with an assumed DTEND was a whole day event. =
Perhaps
> > the spec can be clarified here...
>=20
> We serialize this distinction as an X-OSAF-ANYTIME-PARAM=3DTRUE =
parameter
> in all day DTSTARTs.  We'd be delighted to do something more
> standardized if there's broad interest in such a thing.

I'd like it too, but it does sound awkward to represent in a gui.  Until =
it has a time, you can only render it next to the day.  I'd opted for =
getting the user to supply a time and mark it as Tentative.

Nigel

Date: Mon, 29 Jan 2007 11:08:37 -0800
From: Jeffrey Harris <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] DTSTART with assumed DTEND...

Hi Martin,

> * Specify an event with a given start and given end date and time, or
> start date and end date, where the booking is opaque. An event or an
> all-day event.
> * Specify an event as above where the booking is transparent. Useful for
> anniveraries...
> 
> However how can we specify an event which we know is on a given day, but
> is _not_ an all day event, just that we don't have details of the times?
> 
> Giving just a
>  DTSTART;VALUE=DATE:20070129
> without a DTEND ought to be sufficient if it wasn't for the 'assumed'
> DTEND. Even then the assumed 'DTEND' would be no problem if UA's did not
> assume that a event with an assumed DTEND was a whole day event. Perhaps
> the spec can be clarified here...

OSAF discovered that many people we surveyed wanted this distinction.
It's fairly subtle, but it appears there are lots of times all day and
transparent isn't quite right, it tends to suggest that the event won't
take any time.  So we added what we call an "anytime" status, which
leaves time fields visible but empty, ready to be filled out.

We serialize this distinction as an X-OSAF-ANYTIME-PARAM=TRUE parameter
in all day DTSTARTs.  We'd be delighted to do something more
standardized if there's broad interest in such a thing.

Sincerely,
Jeffrey

Date: Mon, 29 Jan 2007 19:29:56 +0100
From: Martin Kiff <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] DTSTART with assumed DTEND...

Hello list....

I've been following the recent discussion the archive and felt it was 
worth joining the list to contribute, if I cause waves let me know 
privately!

Re: DTSTART and DTEND, it seems we can:

* Specify an event with a given start and given end date and time, or 
start date and end date, where the booking is opaque. An event or an 
all-day event.
* Specify an event as above where the booking is transparent. Useful for 
anniveraries...

However how can we specify an event which we know is on a given day, but 
is _not_ an all day event, just that we don't have details of the times?

Giving just a
  DTSTART;VALUE=DATE:20070129
without a DTEND ought to be sufficient if it wasn't for the 'assumed' 
DTEND. Even then the assumed 'DTEND' would be no problem if UA's did not 
assume that a event with an assumed DTEND was a whole day event. Perhaps 
the spec can be clarified here...

Regards,
  Martin Kiff

Date: Mon, 29 Jan 2007 10:00:21 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] Some more issues with RFC 2445
Cc: CALSIFY Mailinglist <[email-masked]>

Reinhold Kainhofer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> This weekend, I realized some more minor problems with RFC 2445 in its current 
> form:
> 
> 1) The grammar for VALARM does not allow any iana-registered properties, only 
> x-props...

Actually, no components allow iana-registered properties. RFC 2445
neglected to define 'iana-prop'.

While discussing issue 61 during the Jabber session last Friday, we
have agreed to define the following ABNF rules:

   iana-prop = iana-token *(";" other-param) ":" text CRLF
   ; Some other IANA registered iCalendar property.

   other-prop = (iana-prop / x-prop)

and to change 'x-prop' by 'other-prop' in all the component's ABNF

We have also agreed to define the following ABNF rule:

   other-param = (ianaparam / xparam)

and to change 'xparam' to 'other-param' in all the properties' ABNF.

I'll probably rename 'ianaparam' to 'iana-param' and 'xparam' to
'x-param' at the same time for consistency sake...

Cheers,
Bernard

Date: Mon, 29 Jan 2007 08:08:25 -0700
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Nigel Swinson <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.1 Event Component: Default duration	ofday events
Cc: [email-masked]

Hi Bernard,

--On January 29, 2007 11:41:11 AM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

>> Says default TRANSP is OPAQUE, which makes sense in the context of events
>  > with a DTSTART of type DATE-TIME, but perhaps it doesn't make sense
> WRT to
>  > events with DTSTART DATE.  I propose we change the default TRANSP for
> DATE
>  > events to TRANSPARENT.
>
> -1
>
> What needs to be clarified is the default duration of day events.
>
> Some of the examples in RFC 2445 wrongly assumed that the default duration
> of day events was 0 seconds and that is why they mention that these events
> would not appear as opaque in search for busy time. Which is also wrong.

I agree with Bernard, the behavior of TRANSP should not be changed at this 
point. What this really means is that clients need to set TRANSP as 
appropriate for events created by users. If a client chooses to treat 
all-day events as being transparent it can add TRAN:TRANSPARENT to those 
when created. Alternatively it can provide a UI option for the user to 
control that.

-- 
Cyrus Daboo

Date: Mon, 29 Jan 2007 09:41:11 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Nigel Swinson <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.1 Event Component: Default duration ofday events
Cc: [email-masked]

Nigel Swinson wrote:
> http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-3.8.2.7
> 3.8.2.7.  Time Transparency
> 
> Says default TRANSP is OPAQUE, which makes sense in the context of events
 > with a DTSTART of type DATE-TIME, but perhaps it doesn't make sense WRT to
 > events with DTSTART DATE.  I propose we change the default TRANSP for DATE
 > events to TRANSPARENT.

-1

What needs to be clarified is the default duration of day events.

Some of the examples in RFC 2445 wrongly assumed that the default duration
of day events was 0 seconds and that is why they mention that these events
would not appear as opaque in search for busy time. Which is also wrong.

Cheers,
Bernard

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Some more issues with RFC 2445
Date: Mon, 29 Jan 2007 15:33:35 +0100

Am Montag, 29. Januar 2007 schrieb Tim Hare:
> I think (and this is just opinion) that METHOD:PUBLISH was intended
> primarily for publishing event data (team schedules and the like); if you 
> are importing or receiving a datastream to set up a meeting shouldn't
> METHOD: be REQUEST?

I'm mainly thinking of two scenarios:

1) about data im/export when switching calendar applications (e.g. when you 
have to switch to windows in your new job). In that case, all information 
should be preserved to the utmost extent. 

2) about publishing e.g. a meeting or conference talk, where the discussion 
panel / speakers are added as attendees to the event, but anyone can listen 
to the talk. I would publish such an event on a web page or on a mailing list 
with METHOD:PUBLISH (because it is publishing, not requesting the event). Why 
shouldn't there be attendees allowed?

> Also, in 3.7.2 it states:
> >      No methods are defined by this specification.  This is the subject
> >      of other specifications, such as the iCalendar Transport-
> >      independent Interoperability Protocol (iTIP) defined by
> >      [I-D.ietf-calsify-2446bis].
>
> So perhaps this is an issue for 2446? Admittedly this _is_ one element of
> confusion that I haven't seen addressed (maybe I've missed it); 

Right. Thanks for the pointer. So although rfc 2445 does not specify what 
publishing means, it disallows a certain property for this. rfc 2446 already 
has that restriction, so I think it's save to remove that restriction from 
rfc 2445.

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, 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 maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: a8858efe5f0193575834d6fb8cd86289
X-Spam-Score-Summary: 2, 0, 0, e853ca03f805a96a, f54dc553a516193a, [email-masked], , RULES_HIT:2:152:355:379:539:540:541:542:543:567:599:601:966:967:968:973:982:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1535:1587:1593:1594:1605:1676:1730:1747:1766:1792:2073:2075:2078:2196:2198:2199:2200:2379:2393:2525:2553:2559:2568:2570:2627:2682:2685:2693:2703:2857:2859:2917:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3636:3770:3865:3866:3867:3868:3869:3870:3871:3872:3874:3934:3936:3938:3941:4050:4118:4250:4321:4385:4605:5007, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.1 Event Component: Default duration ofday events
Date: Mon, 29 Jan 2007 13:51:43 -0000

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-3.8.2=
.7
3.8.2.7.  Time Transparency

Says default TRANSP is OPAQUE, which makes sense in the context of =
events with a DTSTART of type DATE-TIME, but perhaps it doesn't make =
sense WRT to events with DTSTART DATE.  I propose we change the default =
TRANSP for DATE events to TRANSPARENT.  With that in mind, the =
commentary is:

> > In section 4.6.1 Event Component of RFC 2445 it says:
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-3.6.1=

      The "VEVENT" is also the calendar component used to specify an
      anniversary or daily reminder within a calendar.  These events
      have a DATE value type for the "DTSTART" property instead of the
      default value type of DATE-TIME.  If such a "VEVENT" has a "DTEND"
      property, it MUST be specified as a DATE value also.  The
      anniversary type of "VEVENT" can span more than one date (i.e,
      "DTEND" property value is set to a calendar date after the
      "DTSTART" property value).  If such a "VEVENT" has a "DURATION"
      property, it MUST be specified as a "dur-day" or "dur-week" value.
+    The default Time Transparency for these events is "TRANSPARENT"
+    but can be changed through the "TRANSP" property.

      The "DTSTART" property for a "VEVENT" specifies the inclusive
      start of the event.  For recurring events, it also specifies the
      very first instance in the recurrence set.  The "DTEND" property
      for a "VEVENT" calendar component specifies the non-inclusive end
      of the event.  For cases where a "VEVENT" calendar component
      specifies a "DTSTART" property with a DATE value type but no
-      "DTEND" nor DURATION property, the event's duration is taken to =
be
+    "DTEND" nor "DURATION" property, the event's duration is taken to =
be
      one day.  For cases where a "VEVENT" calendar component specifies
      a "DTSTART" property with a DATE-TIME value type but no "DTEND"
      property, the event ends on the same calendar date and time of day
      specified by the "DTSTART" property.

> > > For cases where a "VEVENT" calendar component specifies a =
"DTSTART"
> > > property with a DATE data type but no "DTEND" property, the events
> > > non-inclusive end is the end of the calendar date specified by the
> > > "DTSTART" property.
> >
> > As such, the last sentence of the paragraph before the following =
example
> > is wrong. This event would actually appear as opaque in a search for =
busy
> > time.

With DTSTART of type DATE, it now has a default TRANSP of TRANSPARENT.  =
So the correction would become:

      The following is an example of the "VEVENT" calendar component
      used to represent an anniversary that will occur annually.  Since
-      it takes up no time, it will not appear as opaque in a search for
-      busy time; no matter what the value of the "TRANSP" property
-      indicates:
+    it has a "DTSTART" of type DATE, it is "TRANSPARENT" by
+    default, and therefore it takes up no time, it will not appear as =
opaque=20
+    in a search for busy time.

        BEGIN:VEVENT
        UID:[email-masked]
        DTSTAMP:19970901T130000Z
        DTSTART;VALUE=3DDATE:19971102
        SUMMARY:Our Blissful Anniversary
        CLASS:CONFIDENTIAL
        CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
        RRULE:FREQ=3DYEARLY
        END:VEVENT

> > Similarly, in section 4.8.2.4 Date/Time Start of RFC 2445 it says:
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-3.8.2=
.4
> >
> > > Description: Within the "VEVENT" calendar component, this property
> > > defines the start date and time for the event. The property is
> > > REQUIRED in "VEVENT" calendar components. Events can have a start
> > > date/time but no end date/time. In that case, the event does not =
take
> > > up any time.
> >
> > I propose to remove the last two sentences of this paragraph.

I think this makes it harder to work out what to do in this corner case, =
and would prefer we were more explicit.  I suggest:

   Description:  Within the "VEVENT" calendar component, this property
      defines the start date and time for the event.  Events can have a
-     start date/time but no end date/time.  In that case, the event
-      does not take up any time.
+    start date/time but no end date/time defined by a "DTEND" or a
+    "DURATION".  In that case, if the "DTSTART" has type DATE-TIME
+    then the event does not take up any time.  If the "DTSTART" has =
type
+    DATE, then the event has a duration of one day.

> > Finally, in section 6 Recommended Practices of RFC 2445 it says:
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-5
> >
> > > 2.  A calendar entry with a "DTSTART" property but no "DTEND"
> > >     property does not take up any time. It is intended to =
represent
> > >     an event that is associated with a given calendar date and =
time
> > >     of day, such as an anniversary. Since the event does not take =
up
> > >     any time, it MUST NOT be used to record busy time no matter =
what
> > >     the value for the "TRANSP" property.
> >
> > This is actually wrong. I would simply remove this text. The proper
> > behave is described in section 4.6.1 Event Component.

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-3.8.2=
.7

   Description:  Time Transparency is the characteristic of an event
      that determines whether it appears to consume time on a calendar.
      Events that consume actual time for the individual or resource
      associated with the calendar SHOULD be recorded as OPAQUE,
      allowing them to be detected by free-busy time searches.  Other
      events, which do not take up the individual's (or resource's) time
      SHOULD be recorded as TRANSPARENT, making them invisible to free-
      busy time searches.

In the context of "does not take up any time" being "does not take up =
any time for the individual or resource associated with the calendar", I =
think it is correct.  But with my proposed change, if there is a DTSTART =
and no DTEND, then the event either has a duration of 0 if DTSTART is =
DATE-TIME, or has a TRANSP of TRANSPARENT if DTSTART is DATE, and so =
either way will be recorded as TRANSPARENT in free-busy time searches.  =
With that said, I also think the text should be removed, as I'm not sure =
it is a recommended practice anymore, rather just a re-iteration.

An alternative to my suggestion might be to do a replace on s/does not =
take any time/does not take any time for the resource associated with =
the calendar/, and that might remove a lot of confusion.

And on a slightly related subject, I think it would be helpful to add =
this.

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-3.3.6=

+    Note that a duration of P1D may not be equivalent to P24H due to =
the=20
+    effect of daylight savings.

Nigel

From: "Tim Hare" <[email-masked]>
To: "'CALSIFY Mailinglist'" <[email-masked]>
Subject: RE: [Ietf-calsify] Some more issues with RFC 2445
Date: Sun, 28 Jan 2007 18:51:35 -0500

I think (and this is just opinion) that METHOD:PUBLISH was intended
primarily for publishing event data (team schedules and the like); if you
are importing or receiving a datastream to set up a meeting shouldn't
METHOD: be REQUEST?

Also, in 3.7.2 it states: 
>      No methods are defined by this specification.  This is the subject
>      of other specifications, such as the iCalendar Transport-
>      independent Interoperability Protocol (iTIP) defined by
>      [I-D.ietf-calsify-2446bis].

So perhaps this is an issue for 2446? Admittedly this _is_ one element of
confusion that I haven't seen addressed (maybe I've missed it); the 2445
text doesn't specify all of the possible values for components or
properties, this being one of the prime examples.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Reinhold
Kainhofer
Sent: Sunday, January 28, 2007 6:22 PM
To: CALSIFY Mailinglist
Subject: [Ietf-calsify] Some more issues with RFC 2445

This weekend, I realized some more minor problems with RFC 2445 in its
current
form:

1) The grammar for VALARM does not allow any iana-registered properties,
only x-props...

2) One of the biggest obstacles for interoperabilty between applications
(data exchange using files) currently is that Outlook only imports icalendar
files, when they have METHOD:PUBLISH set. On the other hand, rfc says in
section
4.8.4.1 (Attendees):
 "This property MUST
   NOT be specified in an iCalendar object when publishing the calendar
   information (e.g., NOT in an iCalendar object that specifies the
   publication of a calendar user's busy time, event, to-do or journal)."
So, when using METHOD:PUBLISH, one cannot export any attendees.
This means that when you want to export all data for outlook, you can either
generate non-compliant iCalendar files (including attendees and
METHOD:PUBLISH), or you generate compliant files and loose all attendee
information!
Some application choose to use the first and generate non-compliant files,
while others (e.g. KOrganizer/Kontact) generate standards-compliant files,
which cannot be imported into Outlook.
My suggestion now would be to simply scratch that restriction and allow the
attendee property also when publishing a calendar. Of course, noone has to
list the attendees when exporting, but why shouldn't we be allowed to?

Cheers,
Reinhold
- --
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, 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 maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP
SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFvS/8TqjEwhXvPN0RAvKiAJ93fgCGaN08wS+Du99kWouuEjZEVACgiTv1
QSaFv8fUtgBbMhGsO7C/0n8=
=lRKG
-----END PGP SIGNATURE-----

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: CALSIFY Mailinglist <[email-masked]>
Date: Mon, 29 Jan 2007 00:21:32 +0100
Subject: [Ietf-calsify] Some more issues with RFC 2445

This weekend, I realized some more minor problems with RFC 2445 in its current 
form:

1) The grammar for VALARM does not allow any iana-registered properties, only 
x-props...

2) One of the biggest obstacles for interoperabilty between applications (data 
exchange using files) currently is that Outlook only imports icalendar files, 
when they have METHOD:PUBLISH set. On the other hand, rfc says in section 
4.8.4.1 (Attendees):
 "This property MUST
   NOT be specified in an iCalendar object when publishing the calendar
   information (e.g., NOT in an iCalendar object that specifies the
   publication of a calendar user's busy time, event, to-do or journal)."
So, when using METHOD:PUBLISH, one cannot export any attendees.
This means that when you want to export all data for outlook, you can either 
generate non-compliant iCalendar files (including attendees and 
METHOD:PUBLISH), or you generate compliant files and loose all attendee 
information!
Some application choose to use the first and generate non-compliant files, 
while others (e.g. KOrganizer/Kontact) generate standards-compliant files, 
which cannot be imported into Outlook.
My suggestion now would be to simply scratch that restriction and allow the 
attendee property also when publishing a calendar. Of course, noone has to 
list the attendees when exporting, but why shouldn't we be allowed to?

Cheers,
Reinhold
- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, 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 maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

Date: Fri, 26 Jan 2007 16:37:31 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.3.11 Text: HTAB not allowed in TEXT values

[
  Dear chairs,

  While I understand the issue list is closed, I think
  this simple issue (that Alexey brought to my attention)
  should be addressed in RFC2445bis.
]

In section 4.3.11 Text of RFC 2445 it says:

 >  TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B
 >               %x5D-7E / NON-US-ASCII
 >     ; Any character except CTLs not needed by the current
 >     ; character set, DQUOTE, ";", ":", "\", ","

I believe TSAFE-CHAR should allow HTAB, the same way
that QSAFE-CHAR, SAFE-CHAR and VALUE-CHAR do.

Else, we wouldn't be allowed to specify an HTAB in a
DESCRIPTION property...

Proposed change:

 >  TSAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-5B
 >               %x5D-7E / NON-US-ASCII
 >  ; Any character except CTLs, DQUOTE, ";", ":", "\", ","

Cheers,
Bernard

Date: Fri, 26 Jan 2007 17:32:46 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 62: RECURRENCE-ID

Dear all,

Issue 62 says the following:

> In section 4.8.4.4 Recurrence ID of RFC 2445 it says:
>
> > When the definition of the recurrence set for a calendar component
> > changes, and hence the "SEQUENCE" property value changes, the
> > "RECURRENCE-ID" for a given recurrence instance might also change.
>
> How could one possibly correlate the specific recurrence instance
> for which the "RECURRENCE-ID" changed?
>
> When the definition of the recurrence set for a calendar component
> changes, specific recurrence instances might be added or removed
> from the recurrence set.
>
> I propose to remove the text mentioned above.

The jabber session participants propose that we remove this text and 
that this matter be revisited in the iTIP revision.  Are there any 
objections?

Thanks,

Eliot

Date: Fri, 26 Jan 2007 17:06:56 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 61: Section 4.2 Property Parameters: ianaparam

Dear all,

Regarding Issue 61 found at 
http://www.ofcourseimright.com/cgi-bin/roundup/calsify:

> From Cyrus:
>
> Suggestion: use 'other-param' here and then define:
>
> other-param = *(iana-param / x-param)
>
> That will make the ABNF a little shorter.
>
> You might also want to do the same for iana-prop/x-prop.

The proposal on the table is to accept both of these changes.  In 
addition, we will make a template for IANA, ensure that the text within 
definitions covers all restrictions (which it does already, I think), 
and create the appropriate IANA tables.  This will cover our IANA 
charter responsibility for RFC 2445.  Please I ask people to support 
this change and not object, as it could block.

Eliot

From: Matthew Willis <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.1 Event Component: Default duration of day events
Date: Fri, 26 Jan 2007 10:25:45 -0500
To: [email-masked]

I think Bernard's proposal is fine, and it resolves an issue we  
currently face in how to implement events with no DTEND and no DURATION.

-lilmatt

On Jan 26, 2007, at 10:21 AM, Eliot Lear wrote:

> Dear all,
>
> I refer you to the below issue.  We propose to close the issue as  
> Bernard suggests below.  If you have an objection, please offer an  
> alternative.  Objecting without alternative leaves a blocking  
> conflict in the draft.
>
> Thanks,
>
> Eliot
> (chair hat on)
>> In section 4.6.1 Event Component of RFC 2445 it says:
>>
>> > For cases where a "VEVENT" calendar component specifies a "DTSTART"
>> > property with a DATE data type but no "DTEND" property, the events
>> > non-inclusive end is the end of the calendar date specified by the
>> > "DTSTART" property.
>>
>> As such, the last sentence of the paragraph before the following  
>> example
>> is wrong. This event would actually appear as opaque in a search  
>> for busy
>> time.
>>
>> > The following is an example of the "VEVENT" calendar component used
>> > to represent an anniversary that will occur annually. Since it  
>> takes
>> > up no time, it will not appear as opaque in a search for busy time;
>> > no matter what the value of the "TRANSP" property indicates:
>> >
>> >   BEGIN:VEVENT
>> >   UID:[email-masked] <mailto: 
>> [email-masked]>
>> >   DTSTAMP:19970901T1300Z
>> >   DTSTART:19971102
>> >   SUMMARY:Our Blissful Anniversary
>> >   CLASS:CONFIDENTIAL
>> >   CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
>> >   RRULE:FREQ=YEARLY
>> >   END:VEVENT
>>
>> I propose to remove this sentence and to add the TRANSP property to
>> the example.
>>
>> Proposed text:
>>
>> > The following is an example of the "VEVENT" calendar component used
>> > to represent an anniversary that will occur annually.
>> >
>> >   BEGIN:VEVENT
>> >   UID:[email-masked] <mailto: 
>> [email-masked]>
>> >   DTSTAMP:19970901T1300Z
>> >   DTSTART:19971102
>> >   SUMMARY:Our Blissful Anniversary
>> >   TRANSP:TRANSPARENT
>> >   CLASS:CONFIDENTIAL
>> >   CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
>> >   RRULE:FREQ=YEARLY
>> >   END:VEVENT
>>
>> Similarly, in section 4.8.2.4 Date/Time Start of RFC 2445 it says:
>>
>> > Description: Within the "VEVENT" calendar component, this property
>> > defines the start date and time for the event. The property is
>> > REQUIRED in "VEVENT" calendar components. Events can have a start
>> > date/time but no end date/time. In that case, the event does not  
>> take
>> > up any time.
>>
>> I propose to remove the last two sentences of this paragraph.
>>
>> Proposed text:
>>
>> > Description: Within the "VEVENT" calendar component, this property
>> > defines the start date and time for the event. The property is
>> > REQUIRED in "VEVENT" calendar components.
>>
>> Finally, in section 6 Recommended Practices of RFC 2445 it says:
>>
>> > 2.  A calendar entry with a "DTSTART" property but no "DTEND"
>> >     property does not take up any time. It is intended to represent
>> >     an event that is associated with a given calendar date and time
>> >     of day, such as an anniversary. Since the event does not  
>> take up
>> >     any time, it MUST NOT be used to record busy time no matter  
>> what
>> >     the value for the "TRANSP" property.
>>
>> This is actually wrong. I would simply remove this text. The proper
>> behave is described in section 4.6.1 Event Component.
>>
>> Cheers,
>> Bernard

Date: Fri, 26 Jan 2007 16:21:45 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Section 4.6.1 Event Component: Default duration of day events

Dear all,

I refer you to the below issue.  We propose to close the issue as 
Bernard suggests below.  If you have an objection, please offer an 
alternative.  Objecting without alternative leaves a blocking conflict 
in the draft.

Thanks,

Eliot
(chair hat on)
> In section 4.6.1 Event Component of RFC 2445 it says:
>
> > For cases where a "VEVENT" calendar component specifies a "DTSTART"
> > property with a DATE data type but no "DTEND" property, the events
> > non-inclusive end is the end of the calendar date specified by the
> > "DTSTART" property.
>
> As such, the last sentence of the paragraph before the following example
> is wrong. This event would actually appear as opaque in a search for busy
> time.
>
> > The following is an example of the "VEVENT" calendar component used
> > to represent an anniversary that will occur annually. Since it takes
> > up no time, it will not appear as opaque in a search for busy time;
> > no matter what the value of the "TRANSP" property indicates:
> >
> >   BEGIN:VEVENT
> >   UID:[email-masked] <mailto:[email-masked]>
> >   DTSTAMP:19970901T1300Z
> >   DTSTART:19971102
> >   SUMMARY:Our Blissful Anniversary
> >   CLASS:CONFIDENTIAL
> >   CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
> >   RRULE:FREQ=YEARLY
> >   END:VEVENT
>
> I propose to remove this sentence and to add the TRANSP property to
> the example.
>
> Proposed text:
>
> > The following is an example of the "VEVENT" calendar component used
> > to represent an anniversary that will occur annually.
> >
> >   BEGIN:VEVENT
> >   UID:[email-masked] <mailto:[email-masked]>
> >   DTSTAMP:19970901T1300Z
> >   DTSTART:19971102
> >   SUMMARY:Our Blissful Anniversary
> >   TRANSP:TRANSPARENT
> >   CLASS:CONFIDENTIAL
> >   CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
> >   RRULE:FREQ=YEARLY
> >   END:VEVENT
>
> Similarly, in section 4.8.2.4 Date/Time Start of RFC 2445 it says:
>
> > Description: Within the "VEVENT" calendar component, this property
> > defines the start date and time for the event. The property is
> > REQUIRED in "VEVENT" calendar components. Events can have a start
> > date/time but no end date/time. In that case, the event does not take
> > up any time.
>
> I propose to remove the last two sentences of this paragraph.
>
> Proposed text:
>
> > Description: Within the "VEVENT" calendar component, this property
> > defines the start date and time for the event. The property is
> > REQUIRED in "VEVENT" calendar components.
>
> Finally, in section 6 Recommended Practices of RFC 2445 it says:
>
> > 2.  A calendar entry with a "DTSTART" property but no "DTEND"
> >     property does not take up any time. It is intended to represent
> >     an event that is associated with a given calendar date and time
> >     of day, such as an anniversary. Since the event does not take up
> >     any time, it MUST NOT be used to record busy time no matter what
> >     the value for the "TRANSP" property.
>
> This is actually wrong. I would simply remove this text. The proper
> behave is described in section 4.6.1 Event Component.
>
> Cheers,
> Bernard

Date: Fri, 26 Jan 2007 15:59:41 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] jabber starts in 5 mins

Eliot Lear wrote:
> Jabber session is [email-masked] 

oops! that's [email-masked]

Date: Fri, 26 Jan 2007 15:59:00 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] jabber starts in 5 mins

Jabber session is [email-masked]

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Date: Wed, 24 Jan 2007 20:46:53 -0500
Subject: [Ietf-calsify] Semi-off-topic question

=20
Is there a repository for calendar-specific code (such as XSLT =
transforms)
that people want to share?

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Reinhold
Kainhofer
Sent: Wednesday, January 24, 2007 6:09 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] All Day Events and DTEND

Am Mit J=E4n 24 2007 schrieb Tim Hare:
> I believe that the original authors had to choose: either the DTEND=20
> value was inclusive or it wasn't (as simple as that) - and apparently=20
> they found more use cases or made more sense of the case where DTEND=20
> meant "the event ends just before" the value.

No, to the contrary, the original authors explicitly stated in a mail =
that
the DTEND DATE value was actually the last day of the event. =
"Non-inclusive"
in this case was referring to the end of the DTEND date.=20

In particular,
DTSTART;VALUE=3DDATE:20051107
DTEND;VALUE=3DDATE:20051108
should be a two-day event.

It's only the implementors who completely misunderstood the (admittedly =
not
very clear) wording of the RFC in this case!

If you interpret the RFC that way, the contradictions suddently all =
vanish,
and the iCalendar contents is also easily understandable in clear-text.

Cheers,
Reinhold

- --
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, 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 maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP
SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFtz42TqjEwhXvPN0RAktVAKCScnc29PxwHTBsoVuPL7jbq72R1wCdFNMB
WGroCLJzBJDmBv0ncdgAOyk=3D
=3DLdwR
-----END PGP SIGNATURE-----

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] All Day Events and DTEND
Date: Wed, 24 Jan 2007 20:03:32 -0500

 Ahhh... That makes sense too when you use the two-day event example. =
And a
one-day, all-day event would then be:

DTSTART;VALUE=3DDATE:20051107
DTEND;VALUE=3DDATE:20051107

With an implied beginning of 000000Z and ending of 235959Z ?

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Reinhold
Kainhofer
Sent: Wednesday, January 24, 2007 6:09 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] All Day Events and DTEND

Am Mit J=E4n 24 2007 schrieb Tim Hare:
> I believe that the original authors had to choose: either the DTEND=20
> value was inclusive or it wasn't (as simple as that) - and apparently=20
> they found more use cases or made more sense of the case where DTEND=20
> meant "the event ends just before" the value.

No, to the contrary, the original authors explicitly stated in a mail =
that
the DTEND DATE value was actually the last day of the event. =
"Non-inclusive"
in this case was referring to the end of the DTEND date.=20

In particular,
DTSTART;VALUE=3DDATE:20051107
DTEND;VALUE=3DDATE:20051108
should be a two-day event.

It's only the implementors who completely misunderstood the (admittedly =
not
very clear) wording of the RFC in this case!

If you interpret the RFC that way, the contradictions suddently all =
vanish,
and the iCalendar contents is also easily understandable in clear-text.

Cheers,
Reinhold

- --
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, 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 maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP
SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFtz42TqjEwhXvPN0RAktVAKCScnc29PxwHTBsoVuPL7jbq72R1wCdFNMB
WGroCLJzBJDmBv0ncdgAOyk=3D
=3DLdwR
-----END PGP SIGNATURE-----

Date: Wed, 24 Jan 2007 16:26:42 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] All Day Events and DTEND
Cc: [email-masked]

Eliot,

There are two issues here:

1- Handling of DTEND for day events;
2- Default duration of day events.

The 1st issue was brought up on the list in October 2005 by Chris Stoner:

http://lists.osafoundation.org/pipermail/ietf-calsify/2005-October/000821.html

and I was under the impression that concensus was reached back then.
Check Reinhold's replies:

http://lists.osafoundation.org/pipermail/ietf-calsify/2005-October/000823.html
http://lists.osafoundation.org/pipermail/ietf-calsify/2005-October/000824.html

The 2nd issue was brought up on the list in November 2006 by myself
and it is is being tracked as issue 59 in the tracker.

http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001341.html
http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue59

Cheers,
Bernard

Eliot Lear wrote:
> While the issues list for 2445bis is officially closed, since I don't 
> see a normative change in the text coming out of this discussion, I 
> wouldn't object if someone proposed some example text to make the matter 
> clear.  Please copy Bernard and this group directly on any such text.
> 
> Eliot

Date: Wed, 24 Jan 2007 12:07:45 +0100
From: Eliot Lear <[email-masked]>
To: Andrew N Dowden <[email-masked]>
Subject: Re: [Ietf-calsify] All Day Events and DTEND
Cc: [email-masked]

While the issues list for 2445bis is officially closed, since I don't 
see a normative change in the text coming out of this discussion, I 
wouldn't object if someone proposed some example text to make the matter 
clear.  Please copy Bernard and this group directly on any such text.

Eliot

Date: Wed, 24 Jan 2007 12:07:37 +0100
From: Eliot Lear <[email-masked]>
To: Andrew N Dowden <[email-masked]>
Subject: Re: [Ietf-calsify] All Day Events and DTEND
Cc: [email-masked]

While the issues list for 2445bis is officially closed, since I don't 
see a non-normative change in the text coming out of this discussion, I 
wouldn't object if someone proposed some example text to make the matter 
clear.  Please copy Bernard and this group directly on any such text.

Eliot

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] All Day Events and DTEND
Date: Wed, 24 Jan 2007 12:08:36 +0100

Am Mit Jän 24 2007 schrieb Tim Hare:
> I believe that the original authors had to choose: either the DTEND value
> was inclusive or it wasn't (as simple as that) - and apparently they found
> more use cases or made more sense of the case where DTEND meant "the event
> ends just before" the value. 

No, to the contrary, the original authors explicitly stated in a mail that the 
DTEND DATE value was actually the last day of the event. "Non-inclusive" in 
this case was referring to the end of the DTEND date. 

In particular, 
DTSTART;VALUE=DATE:20051107
DTEND;VALUE=DATE:20051108
should be a two-day event.

It's only the implementors who completely misunderstood the (admittedly not 
very clear) wording of the RFC in this case!

If you interpret the RFC that way, the contradictions suddently all vanish, 
and the iCalendar contents is also easily understandable in clear-text.

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, 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 maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

Date: Wed, 24 Jan 2007 17:42:02 +1300
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: [email-masked]
Subject: Re: [Ietf-calsify] All Day Events and DTEND

Tim Hare wrote:
> I think we should not change the RFC to match what's in the wild unless
> what's in the wild makes sense from an end-user and also implementer
> standpoint; not to mention the fact that you have different implementations
> in the wild, so what do you choose?
>   
+1

-- 

  SoftDesign Group
  Dowden Software Associates
  P O Box 31 132, Lower Hutt 5040, NEW ZEALAND

From: "Tim Hare" <[email-masked]>
To: "'Jeffrey Harris'" <[email-masked]>, <[email-masked]>
Subject: RE: [Ietf-calsify] All Day Events and DTEND
Date: Tue, 23 Jan 2007 22:58:20 -0500

I think we should not change the RFC to match what's in the wild unless
what's in the wild makes sense from an end-user and also implementer
standpoint; not to mention the fact that you have different implementations
in the wild, so what do you choose?

I believe that the original authors had to choose: either the DTEND value
was inclusive or it wasn't (as simple as that) - and apparently they found
more use cases or made more sense of the case where DTEND meant "the event
ends just before" the value. For the simplest case I can think of, the
duration of 00:00 to 23:59 (DTEND = DTSTART +1 , NON-inclusive) when
measured in minutes equals 24 hours and 0 minutes, whereas 00:00 to 00:00
on the next day (inclusive DTEND) is a duration of 24:01. So, my
somewhat-educated guess is that this was chosen to provide easy interchange
between DURATION and DTSTART/DTEND. When VALUE=DATE it provides an all-day
event (DTEND = DTSTART + 1) with duration of 24 hours, and also for the
birthday/anniversary/make a note on the calendar case where you have DTSTART
and no DTEND and a duration of 0 hours, without having to include the time
value in either case.  

I've stated what I believe about original intent, and you've stated your
belief about existing software - but, do we have a source of facts to go to?
Does someone from CalConnect or Calsisfy-WG have documented what different
implementations do with this?

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey Harris
Sent: Tuesday, January 23, 2007 6:29 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] All Day Events and DTEND

Hi Oliver,

> I would not say that it's overriding. 4.6.1. says it ends with the day 
> and
> 4.8.2.2 says it does not take up any time, which means - if I 
> understand the term 'take up time' right (I usually don't use it) - 
> occupies no time for that day, like a birthday. So it will not appear in a
freebusy component.

I had the same idea when I read through the RFC a few years ago.
Regardless of whether that was the RFC authors' intent, I believe that most
(if not all) existing calendar software doesn't interpret all-day DTSTART
values this way.

I don't think vendors are going to shift how they handle this.  We should
clarify the RFC to reflect the way all-day events (with and without DTENDs)
are actually handled in the wild.

Sincerely,
Jeffrey

Date: Tue, 23 Jan 2007 15:29:02 -0800
From: Jeffrey Harris <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] All Day Events and DTEND

Hi Oliver,

> I would not say that it's overriding. 4.6.1. says it ends with the day and 
> 4.8.2.2 says it does not take up any time, which means - if I understand the 
> term 'take up time' right (I usually don't use it) - occupies no time for 
> that day, like a birthday. So it will not appear in a freebusy component.

I had the same idea when I read through the RFC a few years ago.
Regardless of whether that was the RFC authors' intent, I believe that
most (if not all) existing calendar software doesn't interpret all-day
DTSTART values this way.

I don't think vendors are going to shift how they handle this.  We
should clarify the RFC to reflect the way all-day events (with and
without DTENDs) are actually handled in the wild.

Sincerely,
Jeffrey

Date: Wed, 24 Jan 2007 00:12:14 +0100 (MET)
From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] All Day Events and DTEND

Hello Jeffrey,

Am Dienstag, 23. Januar 2007 22:08 schrieb Jeffrey Harris:
> > <quote>
> >    Events can have a start
> >    date/time but no end date/time. In that case, the event does not take
> >    up any time.
> > </quote>

> 4.6.1 Event Component
>
> [...]
>
>    The "DTEND" property for a "VEVENT"
>    calendar component specifies the non-inclusive end of the event. For
>    cases where a "VEVENT" calendar component specifies a "DTSTART"
>    property with a DATE data type but no "DTEND" property, the events
>    non-inclusive end is the end of the calendar date specified by the
>    "DTSTART" property.

I would not say that it's overriding. 4.6.1. says it ends with the day and 
4.8.2.2 says it does not take up any time, which means - if I understand the 
term 'take up time' right (I usually don't use it) - occupies no time for 
that day, like a birthday. So it will not appear in a freebusy component.

Best Regards,

Oliver

Date: Tue, 23 Jan 2007 13:08:11 -0800
From: Jeffrey Harris <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] All Day Events and DTEND

Hi Oliver,

>> If you just use
> 
> DTSTART;VALUE=DATE:20051107
> 
> the RFC states:
> 
> <quote>
>    Events can have a start
>    date/time but no end date/time. In that case, the event does not take
>    up any time.
> </quote>
> 
> So how is it possible to define an all day event using DATE type, if not?
> 
>> DTSTART;VALUE=DATE:20051107
>> DTEND;VALUE=DATE:20051108

Ah, but in a gloriously distributed and thus confusing fashion, this is
overridden by:

4.6.1 Event Component

[...]

   The "DTEND" property for a "VEVENT"
   calendar component specifies the non-inclusive end of the event. For
   cases where a "VEVENT" calendar component specifies a "DTSTART"
   property with a DATE data type but no "DTEND" property, the events
   non-inclusive end is the end of the calendar date specified by the
   "DTSTART" property.

Sincerely,
Jeffrey

Date: Tue, 23 Jan 2007 21:53:52 +0100 (MET)
From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] All Day Events and DTEND

Am Dienstag, 23. Januar 2007 18:37 schrieb Clint Talbert:
> In several applications an event with the DTSTART and DTEND below is
> interpreted as a one day duration, all-day event.
>
> DTSTART;VALUE=DATE:20051107
> DTEND;VALUE=DATE:20051108
>
> However, in other applications, this is interpreted as a two day
> duration, all-day event.

<quote>
4.8.2.2 Date/Time End

   Property Name: DTEND

[...]

   Description: Within the "VEVENT" calendar component, this property
   defines the date and time by which the event ends. The value MUST be
   later in time than the value of the "DTSTART" property.

[...]

</quote>

This prohibits 

DTSTART;VALUE=DATE:20051107
DTEND;VALUE=DATE:20051107

If you just use

DTSTART;VALUE=DATE:20051107

the RFC states:

<quote>
   Events can have a start
   date/time but no end date/time. In that case, the event does not take
   up any time.
</quote>

So how is it possible to define an all day event using DATE type, if not?

> DTSTART;VALUE=DATE:20051107
> DTEND;VALUE=DATE:20051108

Regards,

Oliver

-- 
Leben ist mehr als ... 
<http://www.nak-nrw.de/index.php?id=71>

Date: Tue, 23 Jan 2007 10:39:09 -0800
From: Jeffrey Harris <[email-masked]>
To: CALSIFY Mailinglist <[email-masked]>
Subject: Re: [Ietf-calsify] All Day Events and DTEND

Hi Folks,

> I hope you can help clear up a misunderstanding we have encountered 
> about DTEND values for all-day events.  A far more detailed
> discussion of the problem can be found in this bug report: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=357272.  I will attempt
> to summarize the salient points.

+1 on getting more explicit about this issue in the RFC, Chandler went
through a very similar debate to the one Mozilla outlines in that bug.

I think it's probably worth an expository paragraph given that the the
vernacular interpretation (January 23-January 24 has duration of two
days) is both completely reasonable and wrong in the context of rfc2445.

Sincerely,
Jeffrey

Date: Tue, 23 Jan 2007 11:37:18 -0600
From: Clint Talbert <[email-masked]>
To: CALSIFY Mailinglist <[email-masked]>
Subject: [Ietf-calsify] All Day Events and DTEND

I hope you can help clear up a misunderstanding we have encountered 
about DTEND values for all-day events.  A far more detailed discussion 
of the problem can be found in this bug report: 
https://bugzilla.mozilla.org/show_bug.cgi?id=357272.  I will attempt to 
summarize the salient points.

In several applications an event with the DTSTART and DTEND below is 
interpreted as a one day duration, all-day event.

DTSTART;VALUE=DATE:20051107
DTEND;VALUE=DATE:20051108

However, in other applications, this is interpreted as a two day 
duration, all-day event.

The confusion stems from two seemingly contradictory portions of RFC 2445.

The people in the one day duration camp use this bit of text as their 
justification:

The "DTEND" property for a "VEVENT"
calendar component specifies the non-inclusive end of the event.

The people in the two day duration camp use this bit of text from the 
RFC as their justification:

The "VEVENT" is also the calendar component used to specify an
anniversary or daily reminder within a calendar. These events have a
DATE value type for the "DTSTART" property instead of the default
data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it
MUST be specified as a DATE value also. The anniversary type of
"VEVENT" can span more than one date (i.e, "DTEND" property value is
set to a calendar date after the "DTSTART" property value).

Previously, it seems that this issue has come up on this list once before:
http://lists.osafoundation.org/pipermail/ietf-calsify/2005-September/000769.html

There it was decided that the DTEND should be exclusive of the event 
(i.e. the interpretation used by the one day duration camp is correct).

Could we address this conclusively with some text or some examples in 
the next revision of the RFC?  I have not read the bis-04 version yet in 
its entirety, and I apologize if this is already addressed.

Thank you very much,

Clint

To: CALSIFY Mailinglist <[email-masked]>
From: Eliot Lear <[email-masked]>
Date: Fri, 19 Jan 2007 14:12:27 -0500
Subject: [Ietf-calsify] iCal event invitation: Calsify Jabber Session

--Apple-Mail-12--199297094
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Eliot Lear has invited you to the iCal event: Calsify Jabber Session,  
scheduled for February 1, 2007 at 7:00 AM (America/Los_Angeles). To  
accept or decline this invitation, click the link below.

--Apple-Mail-12--199297094
Content-Transfer-Encoding: quoted-printable
Content-Type: text/calendar; x-unix-mode=0644; name=iCal-20070119-141218.ics
Content-Disposition: attachment;
	filename=iCal-20070119-141218.ics

BEGIN:VCALENDAR=0D=0APRODID:-//Apple=20Computer\,=20Inc//iCal=202.0//EN=0D=
=0AMETHOD:REQUEST=0D=0ACALSCALE:GREGORIAN=0D=0AVERSION:2.0=0D=0A=
BEGIN:VTIMEZONE=0D=0ATZID:America/Los_Angeles=0D=0A=
LAST-MODIFIED:20070119T191216Z=0D=0ABEGIN:STANDARD=0D=0A=
DTSTART:20061029T090000=0D=0ATZOFFSETTO:-0800=0D=0ATZOFFSETFROM:+0000=0D=0A=
TZNAME:PST=0D=0AEND:STANDARD=0D=0ABEGIN:DAYLIGHT=0D=0A=
DTSTART:20070311T010000=0D=0ATZOFFSETTO:-0700=0D=0ATZOFFSETFROM:-0800=0D=0A=
TZNAME:PDT=0D=0AEND:DAYLIGHT=0D=0AEND:VTIMEZONE=0D=0ABEGIN:VEVENT=0D=0A=
DURATION:PT1H30M=0D=0AATTENDEE;CN=3D"Bernard=20=
Desruisseaux";RSVP=3DTRUE:mailto:bernard.desruisseaux=0D=0A=20=
@oracle.com=0D=0AATTENDEE;CN=3D"Cyrus=20=
Daboo";RSVP=3DTRUE:mailto:[email-masked]=0D=0AATTENDEE;CN=3D"Alexey=20=
Melnikov";RSVP=3DTRUE:mailto:[email-masked]=0D=0A=20=0D=0A=
ATTENDEE;CN=3D"Aki=20Niemi";RSVP=3DTRUE:mailto:[email-masked]=0D=0A=
ATTENDEE;CN=3D"Lisa=20Dusseault";RSVP=3DTRUE:mailto:[email-masked]=
=0D=0AATTENDEE;CN=3D"Eliot=20=
Lear";PARTSTAT=3DACCEPTED:mailto:[email-masked]=0D=0A=
ATTENDEE;CN=3D"CALSIFY=20=
Mailinglist";RSVP=3DTRUE:mailto:Ietf-calsify@osafound=0D=0A=20ation.org=0D=
=0ALOCATION:at=[email-masked]=0D=0ADTSTAMP:20070119T191205Z=0D=
=0AUID:C37CFC39-18EE-40E2-917D-4F04A84866E2=0D=0ASEQUENCE:6=0D=0A=
ORGANIZER;CN=3D"Eliot=20Lear":mailto:[email-masked]=0D=0A=
DTSTART;TZID=3DAmerica/Los_Angeles:20070201T070000=0D=0ASUMMARY:Calsify=20=
Jabber=20Session=0D=0ADESCRIPTION:We=20will=20continue=20resolving=20=
issues=20in=20RFC2445bis.=20=20The=20tracke=0D=0A=20r=20can=20be=20found=20=
at=20http://www.ofcourseimright.com/cgi-bin/roundup/calsify=0D=0A=20.=0D=0A=
RRULE:FREQ=3DWEEKLY;INTERVAL=3D1;COUNT=3D6=0D=0AEND:VEVENT=0D=0A=
END:VCALENDAR=0D=0A=

--Apple-Mail-12--199297094--

To: CALSIFY Mailinglist <[email-masked]>
From: Eliot Lear <[email-masked]>
Date: Fri, 19 Jan 2007 14:10:06 -0500
Subject: [Ietf-calsify] iCal event invitation: Calsify Jabber Session

--Apple-Mail-6--199437971
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Eliot Lear has invited you to the iCal event: Calsify Jabber Session,  
scheduled for January 26, 2007 at 7:00 AM (America/Los_Angeles). To  
accept or decline this invitation, click the link below.

--Apple-Mail-6--199437971
Content-Transfer-Encoding: quoted-printable
Content-Type: text/calendar; x-unix-mode=0644; name=iCal-20070119-140952.ics
Content-Disposition: attachment;
	filename=iCal-20070119-140952.ics

BEGIN:VCALENDAR=0D=0APRODID:-//Apple=20Computer\,=20Inc//iCal=202.0//EN=0D=
=0AMETHOD:REQUEST=0D=0ACALSCALE:GREGORIAN=0D=0AVERSION:2.0=0D=0A=
BEGIN:VTIMEZONE=0D=0ATZID:America/Los_Angeles=0D=0A=
LAST-MODIFIED:20070119T190950Z=0D=0ABEGIN:STANDARD=0D=0A=
DTSTART:20061029T090000=0D=0ATZOFFSETTO:-0800=0D=0ATZOFFSETFROM:+0000=0D=0A=
TZNAME:PST=0D=0AEND:STANDARD=0D=0ABEGIN:DAYLIGHT=0D=0A=
DTSTART:20070311T010000=0D=0ATZOFFSETTO:-0700=0D=0ATZOFFSETFROM:-0800=0D=0A=
TZNAME:PDT=0D=0AEND:DAYLIGHT=0D=0AEND:VTIMEZONE=0D=0ABEGIN:VEVENT=0D=0A=
ATTENDEE;CN=3D"Bernard=20=
Desruisseaux";RSVP=3DTRUE:mailto:bernard.desruisseaux=0D=0A=20=
@oracle.com=0D=0AATTENDEE;CN=3D"Cyrus=20=
Daboo";RSVP=3DTRUE:mailto:[email-masked]=0D=0AATTENDEE;CN=3D"Alexey=20=
Melnikov";RSVP=3DTRUE:mailto:[email-masked]=0D=0A=20=0D=0A=
ATTENDEE;CN=3D"Aki=20Niemi";RSVP=3DTRUE:mailto:[email-masked]=0D=0A=
ATTENDEE;CN=3D"Lisa=20Dusseault";RSVP=3DTRUE:mailto:[email-masked]=
=0D=0AATTENDEE;CN=3D"Eliot=20=
Lear";PARTSTAT=3DACCEPTED:mailto:[email-masked]=0D=0A=
ATTENDEE;CN=3D"CALSIFY=20=
Mailinglist";RSVP=3DTRUE:mailto:Ietf-calsify@osafound=0D=0A=20ation.org=0D=
=0ALOCATION:at=[email-masked]=0D=0ADTSTAMP:20070119T190948Z=0D=
=0AUID:5C2087E8-206F-4B84-9A73-7B78572C75FA=0D=0ASEQUENCE:9=0D=0A=
DTSTART;TZID=3DAmerica/Los_Angeles:20070126T070000=0D=0ASUMMARY:Calsify=20=
Jabber=20Session=0D=0ADTEND;TZID=3DAmerica/Los_Angeles:20070126T083000=0D=
=0ADESCRIPTION:We=20will=20continue=20resolving=20issues=20in=20=
RFC2445bis.=20=20The=20tracke=0D=0A=20r=20can=20be=20found=20at=20=
http://www.ofcourseimright.com/cgi-bin/roundup/calsify=0D=0A=20.=0D=0A=
ORGANIZER;CN=3D"Eliot=20Lear":mailto:[email-masked]=0D=0AEND:VEVENT=0D=0A=
END:VCALENDAR=0D=0A=

--Apple-Mail-6--199437971--

Date: Fri, 19 Jan 2007 12:40:18 -0500
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-04.txt

Folks,

As some people have noticed, all the ABNFs that contain a reference
(e.g., [RFCXXXX]) are broken in the .txt version of the draft. I will
submit a draft -05 that will address this issue shortly.

As usual, the .html and .changes.html versions of the draft have been
uploaded to the IETF Tools web site at the following locations:

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-04.html

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-04.changes.html

The ABNFs are fine in the .html and .changes.html versions.

Cheers,
Bernard

[email-masked] wrote:
> 	Filename	: draft-ietf-calsify-rfc2445bis-04.txt
> 	Pages		: 162
> 	Date		: 2007-1-17
> 	
>    This document is a product of the Calendaring and Scheduling
>    Standards Simplification (Calsify) working group of the Internet
>    Engineering Task Force.  Comments on this draft are welcomed, and
>    should be addressed to the [email-masked] [1] mailing
>    list.  The issues raised on this mailing list are being tracked at
>    the following web site:
>    http://www.ofcourseimright.com/cgi-bin/roundup/calsify.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-04.txt
> 
> "get draft-ietf-calsify-rfc2445bis-04.txt".
> 
> 	"FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-04.txt".
> 	

To: [email-masked]
From: [email-masked]
Date: Wed, 17 Jan 2007 15:50:02 -0500
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-04.txt 

--NextPart

	Title		: Internet Calendaring and Scheduling Core Object Specification (iCalendar)
	Author(s)	: B. Desruisseaux
	Filename	: draft-ietf-calsify-rfc2445bis-04.txt
	Pages		: 162
	Date		: 2007-1-17
	
This document defines a MIME media type for representing and
   exchanging calendaring and scheduling information such as events, to-
   dos, journal entries and free/busy information.  The definition of
   the text/calendar media type, known as iCalendar, is independent of
   any particular calendar service or protocol.
   This document is a product of the Calendaring and Scheduling
   Standards Simplification (Calsify) working group of the Internet
   Engineering Task Force.  Comments on this draft are welcomed, and
   should be addressed to the [email-masked] [1] mailing
   list.  The issues raised on this mailing list are being tracked at
   the following web site:
   http://www.ofcourseimright.com/cgi-bin/roundup/calsify.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-calsify-rfc2445bis-04.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-04.txt".

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-calsify-rfc2445bis-04.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 16 Jan 2007 13:36:23 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Fwd: [Ietf-calsify] Issue 27: Section 4.8.5.4 Recurrence Rule: Duration of members of the,generated recurrence set]
Cc: Calsify WG <[email-masked]>

Cyrus Daboo wrote:

>>    - There are known iCalendar applications that don't even support
>>      the DURATION property today!
> 
> What do you mean by "does not support"? Surely no one ignores it? I know 
> there are some that never generate it (turning a component with 
> DTSTART/DURATION into one with DTSTART/DTEND), but no one can ignore it 
> and claim to support iCalendar.

Microsoft Outlook 2000 ignores the DURATION property on import.
Perhaps that's been fixed in more recent versions of this product.

Cheers,
Bernard

Date: Tue, 16 Jan 2007 11:40:58 -0500
From: Cyrus Daboo <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: Re: [Fwd: [Ietf-calsify] Issue 27: Section 4.8.5.4 Recurrence Rule: Duration of members of the,generated recurrence set]

Hi Bernard,
Late reply on this.

> -------- Original Message --------
> Subject: [Ietf-calsify] Issue 27: Section 4.8.5.4 Recurrence Rule:
> Duration of members of the,generated recurrence set
> Date: Thu, 19 Oct 2006 13:51:12 -0400
> From: Bernard Desruisseaux <[email-masked]>
> To: Calsify WG <[email-masked]>
>
> In section 4.8.5.4 Recurrence Rule it says:
>
>> Any duration associated with the iCalendar object applies to all
>> members of the generated recurrence set.
>
> I believe we need to clarify what is meant by "duration" here.
>
> Example 1:
>
>    DTSTART;TZID=America/Montreal:20070311T000000
>    DURATION:P1D
>    RRULE:FREQ=DAILY;COUNT=2
>
>    The first instance start at midnight on March 11th, 2007 and has
>    a duration of 1 day. Given that on that day there is a shift from
>    standard time to daylight saving time, this instance will actually
>    last 23 hours.
>
>    Should the duration of the recurrence instance that will occur on
>    March 12th, 2007 be the "computed duration of the first instance",
>    that is, 23 hours, or the "specified duration of the first instance",
>    that is, 1 day?
>
>    In my opinion, the duration of the recurrence instance on March 12th,
>    2006 should be 1 day (24 hours).

I agree.

> Example 2:
>
>    DTSTART;TZID=America/Montreal:20070311T000000
>    DTEND;TZID=America/Montreal:20070312T000000
>    RRULE:FREQ=DAILY;COUNT=2
>
>    The first instance start at midnight on March 11th, 2007 and is
>    specified to end at midnight on March 12th, 2007. Given that on
>    that day there is shift from standard time to daylight saving time,
>    this instance will actually last 23 hours.
>
>    I believe the duration of the recurrence instance on March 12th,
>    2006 should be the "computed duration of the first instance",
>    that is, 23 hours.

I agree.

> All that being said:
>
>    - I doubt that all (most?) iCalendar application will interpret
>      P1D as 23 hours or 25 hours when a time zone shift occurs.

I'm not so sure about that. It really depends on how date arithmetic has 
been implemented. In the library I wrote a while ago I kept the data 
components separate, so that doing +P1D actually meant incrementing the day 
value rather than adding a certain number of hours. More to the point is 
whether an implementation can spot that DTEND - DTSTART is actually 23 or 
25 hours during the dst shift. Again, the implementation I did would 
convert the separate date-time components into a "seconds" value and then 
subtract those, so that ought to get the correct 23/25 hour value.

Bottom line is someone should test the various libraries and see what 
happens! Libraries ought to include something like this as part of their 
unit tests.

>    - There are known iCalendar applications that don't even support
>      the DURATION property today!

What do you mean by "does not support"? Surely no one ignores it? I know 
there are some that never generate it (turning a component with 
DTSTART/DURATION into one with DTSTART/DTEND), but no one can ignore it and 
claim to support iCalendar.

-- 
Cyrus Daboo

From: "Tim Hare" <[email-masked]>
To: "'CALSIFY Mailinglist'" <[email-masked]>
Subject: RE: [Ietf-calsify] iCalendar to XML XSLT - Firefox "issue"
Date: Tue, 16 Jan 2007 08:27:05 -0500

I meant to say that Firefox opens it and produces a result document. Which
it does - and since that post my brain kicked in (this is one of those "Tim
you stupid idiot" moments I mentioned) and I realized that Firefox may be
providing default behavior for an XML document (the result document) which
contains no stylesheet. I'll have to look into that further.

Tim Hare
Interested Bystander, Non-Inc.

> This transform works using Jim Clark's XT; I am getting some odd error
messages in Internet Explorer if I try to open the XML file
> directly with an <?xml-stylesheet> processing instruction contained in the
file - still trying to track that down. 
> Firefox opens it, but doesn't output XML, rather it outputs the text of
all of the nodes. Probably something dumb that I did
> - but maybe the collective intelligence of the folks on the list will spot
it.

From: "Tim Hare" <[email-masked]>
To: "'Reinhold Kainhofer'" <[email-masked]>
Date: Mon, 15 Jan 2007 21:47:33 -0500
Cc: 'CALSIFY Mailinglist' <[email-masked]>
Subject: [Ietf-calsify] iCalendar to XML XSLT

This is a multi-part message in MIME format.

------=_NextPart_000_0075_01C738EE.C4302550
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I've attached the first public version of ICAL2XML.xsl, and XSLT stylesheet
which will take an iCalendar file wrapped in simple XML and produce an
"xCalendar" file.  The iCalendar needs to be wrapped with <?xml >
<ical_input space="preserve"> and of course </ical_input> - in other words
the minimum to make a one-node XML document with the node contents being the
entire iCalendar file.

This produces <iCalendar-stream> as the top-level node to allow for multiple
BEGIN:VCALENDAR/END:VCALENDAR pairs in the input file. I don't believe the
current RFC really allows for that, but I've seen some discussion of
iCalendar-stream on this list so included the possibility. Note that the
transform does NOT take notice of what kind of iCalendar component or
property is being processed. I think in theoretic terms you would say it
handles only the syntactic and not the semantic content of the items? In any
case, dealing with the resulting XML is left for other processes, my purpose
was to go from iCalendar to XML and this I believe does it.

You may use this file if you wish, I'd like attribution in the comments.
Opinions on design choices, better ways to do things, etcetera are welcomed
(unless they're of the "Tim you stupid idiot" variety of course, I can make
those up on my own :-) ).  

This may contain some things which worked, but could be done more elegantly
- I am not an XSLT person in my "day job" so I have hacked around until I
found something which worked, and then left it that way.  

This transform works using Jim Clark's XT; I am getting some odd error
messages in Internet Explorer if I try to open the XML file directly with an
<?xml-stylesheet> processing instruction contained in the file - still
trying to track that down. Firefox opens it, but doesn't output XML, rather
it outputs the text of all of the nodes. Probably something dumb that I did
- but maybe the collective intelligence of the folks on the list will spot
it.

In any event - I hope this is useful. Sure was fun figuring it out.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: Reinhold Kainhofer [mailto:[email-masked]] 
Sent: Monday, January 15, 2007 11:31 AM
To: Tim Hare
Cc: 'CALSIFY Mailinglist'
Subject: Re: [Ietf-calsify] What's the status of xCal?

Am Samstag, 13. Januar 2007 schrieb Tim Hare:
> I haven't updated by draft lately on guidelines for using XML with 
> calendar information, but I still have the latest draft if you want it.

Yes, that would be great!

> It wasn't
> xcalendar per se but had a lot of stuff from the original draft; also 
> had some stylesheet examples (which you probably don't need).

To the contrary, if you have some useful stylesheets already, this means
that KOraganizer can already produce that output as soon as I'm finished
with the general xCal  and subsequent XSL transformation...

BTW, does anyone know about the status for RDFCalendar? Was this ever turned
into a standard? Do we have any standardized XML format for calendars? Or
are all of them just drafts?

Thanks,
Reinhold

- --
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, 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 maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP
SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFq6xSTqjEwhXvPN0RAvWEAJ4qjzsUoBpB0EjCrGD8dgW70Z459wCgu5X7
ikOoOE1RgDdowpNEnwky8Ow=
=PREj
-----END PGP SIGNATURE-----

------=_NextPart_000_0075_01C738EE.C4302550
Content-Type: text/xml;
	name="ICAL2XML.xsl"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="ICAL2XML.xsl"

<?xml version=3D"1.0" encoding=3D"UTF-8"?>=20
<xsl:stylesheet version=3D"1.0"
	xmlns:xsl=3D"http://www.w3.org/1999/XSL/Transform"
	xmlns:ical=3D"http://www.ietf.org/rfc/rfc2445.txt"
	xmlns:itip=3D"http://www.ietf.org/rfc/rfc2446.txt"
	xmlns=3D"http://www.ietf.org/rfc/rcf2445.txt">
<!-- =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -->
<!-- ics2xml.xsl XSL transformation of iCalendar .ics file to XML file   =
     -->
<!-- Tim Hare, November 2006                                             =
     --> =20
<!-- This transformation may be freely used, attribution is appreciated  =
     -->
<!-- =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -->

<!-- define output format                                                =
     -->
<xsl:output method=3D"xml" media-type=3D"xml/calendar" indent=3D"yes" />

<!--                                                                     =
     -->
<!-- global parameters of use throughout the stylesheet                  =
     -->
<!--                                                                     =
     -->
<xsl:variable name=3D"newline"><xsl:text>
</xsl:text></xsl:variable>
<xsl:variable name=3D"linewrap"><xsl:text>
 </xsl:text></xsl:variable>
<xsl:variable name=3D"CR">&#13;</xsl:variable>
<xsl:variable name=3D"colon"><xsl:text>:</xsl:text></xsl:variable>
<xsl:variable name=3D"semicolon"><xsl:value-of =
select=3D"concat('&#59;','')" /></xsl:variable>

=20
<xsl:apply-templates select=3D"*" />
<xsl:template match=3D"/">
   <xsl:element name=3D"iCalendar_Stream">
   <xsl:call-template name=3D"convert_ics">
      <!-- "parameter" is the entire input file -->
      <xsl:with-param name=3D"icaldata">
         <!--                                                            =
      -->
         <!-- First we adjust the whitespace in the incoming document =
.ics     -->
         <!-- file. Can NOT use normalize-space() or document() because =
they   -->
         <!-- remove the the CR-LF sequence crucial to recognizing the =
end of  -->
         <!-- things in iCalendar                                        =
      -->
         <!--                                                            =
      -->
         <xsl:call-template name=3D"space_adjust">
            <xsl:with-param name=3D"icsinput">
               <xsl:value-of select=3D"current()" />
            </xsl:with-param>
         </xsl:call-template>
      </xsl:with-param>
   </xsl:call-template>
   </xsl:element>
</xsl:template>

<!-- Process recursively.                                       -->
<!-- Find Calendars and Components (BEGIN/END pairs)            -->
<!-- and then process properties with parameters                -->
<!-- try find BEGIN: then extract name and search for END:$name -->
<xsl:template name=3D"convert_ics">
   <xsl:param name=3D"icaldata" />
   <xsl:choose>
      <xsl:when test=3D"$icaldata =3D $newline">
         <!-- do nothing if it's only newline -->
      </xsl:when>
      <xsl:when test=3D"starts-with($icaldata,'BEGIN:')">
          <xsl:variable name=3D"element_name">
             <xsl:value-of =
select=3D"substring-before(substring-after($icaldata,'BEGIN:'),$newline)"=
 />
          </xsl:variable>
          <xsl:choose>
             <xsl:when =
test=3D"substring-before($icaldata,concat('END:',$element_name))">
                <xsl:value-of select=3D"$newline" />
                <xsl:element name=3D"{concat($element_name,'')}">
                   <xsl:call-template name=3D"convert_ics">
                      <xsl:with-param name=3D"icaldata">
                          <xsl:value-of =
select=3D"substring-before(substring-after($icaldata,concat('BEGIN:',$ele=
ment_name,$newline)),concat('END:',$element_name,$newline))" />
                      </xsl:with-param>
                   </xsl:call-template>
                </xsl:element>
             </xsl:when>
             <xsl:otherwise>
             </xsl:otherwise>
          </xsl:choose>
          <xsl:choose>
             <xsl:when =
test=3D"substring-after($icaldata,concat('END:',$element_name,$newline))"=
                <xsl:call-template name=3D"convert_ics">
                   <xsl:with-param name=3D"icaldata">
                      <xsl:value-of =
select=3D"substring-after($icaldata,concat('END:',$element_name,$newline)=
)" />
                   </xsl:with-param>
                </xsl:call-template>
             </xsl:when>
             <xsl:otherwise>
             </xsl:otherwise>
          </xsl:choose>
      </xsl:when>
      <xsl:otherwise>
            <!-- It isn't a BEGIN/END pair, so it's a property           =
                       -->
            <!-- each property becomes an element, each parameter an =
attribute of it            -->
            <xsl:variable name=3D"element_name">
               <xsl:choose>
                  <!-- if there's a semicolon, then the name is the =
string before the semicolon -->
                  <xsl:when =
test=3D"contains(substring-before($icaldata,$colon),$semicolon)" >
                     <xsl:value-of =
select=3D"substring-before($icaldata,$semicolon)" />
                  </xsl:when>
                  <!-- otherwise the name is the string before the colon =
-->
                  <xsl:otherwise>
                     <xsl:value-of =
select=3D"substring-before($icaldata,$colon)" />
                  </xsl:otherwise>
               </xsl:choose>
            </xsl:variable>
            <!--                                                         =
                       -->
            <!--         Now create the elements                         =
                       -->
            <!--                                                         =
                       -->
            <xsl:value-of select=3D"$newline" />
            <xsl:element name=3D"{string($element_name)}" >
               <!--                                                      =
                       -->
               <!--      If there is a semicolon, then we have property =
parameters which we     -->
               <!--      need to make into attributes of the element     =
                       -->
               <!--                                                      =
                       -->
               <xsl:if =
test=3D"contains(substring-before($icaldata,$colon),$semicolon)" >
                  <xsl:call-template name=3D"process_parameters">
                     <xsl:with-param name=3D"parameters">
                        <!--- everything from the first semicolon to the =
colon are properties   -->
                        <xsl:value-of =
select=3D"substring-after(substring-before($icaldata,$colon),$semicolon)"=
 />
                     </xsl:with-param>
                  </xsl:call-template>
               </xsl:if>
               <!--                                                      =
                       -->
               <!--  contents of the element are everything after the =
colon                     -->
               <!--  precede it with white space, to make it look better =
                       -->
               <!--                                                      =
                       -->
               <xsl:value-of =
select=3D"substring-before(substring-after($icaldata,$colon),$newline)" =
/>
            </xsl:element>
            <xsl:if test=3D"substring-after($icaldata,$newline)">
               <xsl:call-template name=3D"convert_ics">
                  <xsl:with-param name=3D"icaldata">
                     <xsl:value-of =
select=3D"substring-after($icaldata,$newline)" />
                  </xsl:with-param>
               </xsl:call-template>
            </xsl:if>
      </xsl:otherwise>
   </xsl:choose>
</xsl:template>

<xsl:template name=3D"process_parameters">
   <!--- recursively strip out parameters and make attributes of them =
-->
   <xsl:param name=3D"parameters" />
   <xsl:choose>
      <!-- if more than one parameter present they are separated by =
semicolons -->
      <xsl:when test=3D"substring-before($parameters,$semicolon)">
         <xsl:attribute =
name=3D"{substring-before(substring-before($parameters,$semicolon),'=3D')=
}">
            <xsl:value-of =
select=3D"substring-after(substring-before($parameters,$semicolon),'=3D')=
" />
         </xsl:attribute>
         <xsl:call-template name=3D"process_parameters">
            <xsl:with-param name=3D"parameters">
               <xsl:value-of =
select=3D"substring-after($parameters,$semicolon)" />
            </xsl:with-param>
         </xsl:call-template>
      </xsl:when>
      <xsl:otherwise>
          <xsl:if test=3D"contains($parameters,'=3D')">
             <xsl:attribute =
name=3D"{substring-before($parameters,'=3D')}">
                <xsl:value-of =
select=3D"substring-after($parameters,'=3D')" />
             </xsl:attribute>
          </xsl:if>
      </xsl:otherwise>
   </xsl:choose>
</xsl:template>

<xsl:template name=3D"space_adjust">
   <!--                                                                  =
                         -->
   <!-- This template removes leading spaces, and line-wrap sequences =
from the input, returning a -->
   <!-- variable which may still contain CR-LF sequences but not =
CR-LF-space                      -->
   <!-- it is invoked once as the entire iCalendar input file is turned =
into a variable           -->
   <xsl:param name=3D"icsinput" />
   <xsl:variable name=3D"special_case"><xsl:value-of =
select=3D"concat($newline,'BEGIN:')" /></xsl:variable>
   <xsl:choose>
      <xsl:when test=3D"starts-with($icsinput,$special_case)">           =
   <!--  Special case      -->
         <xsl:call-template name=3D"space_adjust">
            <xsl:with-param name=3D"icsinput">
               <xsl:value-of =
select=3D"substring-after($icsinput,$newline)" /> <!-- strip leading NL =
-->
            </xsl:with-param>
         </xsl:call-template>
      </xsl:when>
      <!--                                                               =
                         -->
      <!-- To hold down recursion depth and iterations, test for =
different lengths of leading     -->
      <!-- spaces before recursively calling this routine                =
                         -->
      <xsl:when test=3D"starts-with($icsinput,'     ')"> <!--  five =
spaces                          -->
         <xsl:call-template name=3D"space_adjust">
            <xsl:with-param name=3D"icsinput">
               <xsl:value-of select=3D"substring-after($icsinput,'     =
')" /> <!-- strip five       -->
            </xsl:with-param>
         </xsl:call-template>
      </xsl:when>
      <xsl:when test=3D"starts-with($icsinput,'    ')">  <!--  four =
spaces                          -->
         <xsl:call-template name=3D"space_adjust">
            <xsl:with-param name=3D"icsinput">
               <xsl:value-of select=3D"substring-after($icsinput,'    =
')" /> <!-- strip four        -->
            </xsl:with-param>
         </xsl:call-template>
      </xsl:when>
      <xsl:when test=3D"starts-with($icsinput,'   ')">   <!--  three =
spaces                         -->
         <xsl:call-template name=3D"space_adjust">
            <xsl:with-param name=3D"icsinput">
               <xsl:value-of select=3D"substring-after($icsinput,'   ')" =
/>  <!-- strip three       -->
            </xsl:with-param>
         </xsl:call-template>
      </xsl:when>
      <xsl:when test=3D"starts-with($icsinput,'  ')">    <!--  two =
spaces                           -->
         <xsl:call-template name=3D"space_adjust">
            <xsl:with-param name=3D"icsinput">
               <xsl:value-of select=3D"substring-after($icsinput,'  ')" =
/>   <!-- strip two         -->
            </xsl:with-param>
         </xsl:call-template>
      </xsl:when>
      <xsl:when test=3D"starts-with($icsinput,' ')">     <!--  one space =
                           -->
         <xsl:call-template name=3D"space_adjust">
            <xsl:with-param name=3D"icsinput">
               <xsl:value-of select=3D"substring-after($icsinput,' ')" =
/>    <!-- strip one         -->
            </xsl:with-param>
         </xsl:call-template>
      </xsl:when>
      <!--                                                               =
                         -->
      <!-- At this point all leading spaces should be gone, so we look =
for linewraps to remove    -->
      <!--                                                               =
                         -->
      <xsl:when test=3D"substring-before($icsinput,$linewrap)">
          <xsl:call-template name=3D"space_adjust">
             <xsl:with-param name=3D"icsinput">
                <!-- replace the linewrap with a single space            =
                         -->
                <xsl:value-of =
select=3D"concat(substring-before($icsinput,$linewrap),' =
',substring-after($icsinput,$linewrap))" />
             </xsl:with-param>
           </xsl:call-template>
      </xsl:when>
      <xsl:otherwise>
         <xsl:value-of select=3D"$icsinput" />
      </xsl:otherwise> =20
   </xsl:choose>
</xsl:template>
</xsl:stylesheet>
------=_NextPart_000_0075_01C738EE.C4302550--

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: "Tim Hare" <[email-masked]>
Subject: Re: [Ietf-calsify] What's the status of xCal?
Date: Mon, 15 Jan 2007 17:31:09 +0100
Cc: 'CALSIFY Mailinglist' <[email-masked]>

Am Samstag, 13. Januar 2007 schrieb Tim Hare:
> I haven't updated by draft lately on guidelines for using XML with calendar
> information, but I still have the latest draft if you want it. 

Yes, that would be great!

> It wasn't 
> xcalendar per se but had a lot of stuff from the original draft; also had
> some stylesheet examples (which you probably don't need).  

To the contrary, if you have some useful stylesheets already, this means that 
KOraganizer can already produce that output as soon as I'm finished with the 
general xCal  and subsequent XSL transformation...

BTW, does anyone know about the status for RDFCalendar? Was this ever turned 
into a standard? Do we have any standardized XML format for calendars? Or are 
all of them just drafts?

Thanks,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, 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 maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

Date: Mon, 15 Jan 2007 09:59:19 -0600
From: Clint Talbert <[email-masked]>
To: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] What's the status of xCal?
Cc: 'CALSIFY Mailinglist' <[email-masked]>

Hi Tim,

I would also be interested in this draft and the stylesheet to transform 
iCalendar to XML.

Thanks,

Clint Talbert

Tim Hare wrote:
> I haven't updated by draft lately on guidelines for using XML with calendar
> information, but I still have the latest draft if you want it. It wasn't
> xcalendar per se but had a lot of stuff from the original draft; also had
> some stylesheet examples (which you probably don't need).  I also have in
> final stages of development a stylesheet to take a string containing an
> iCalendar file and transform it into XML. 
>
>
> Tim Hare
> Interested Bystander, Non-Inc.
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Reinhold
> Kainhofer
> Sent: Friday, January 12, 2007 5:28 AM
> To: CALSIFY Mailinglist
> Subject: [Ietf-calsify] What's the status of xCal?
>
> Hi,
> I'm currently implementing an export function in KOrganizer that uses XSLT
> transformations to create easier output in several formats and even allows
> XSL-FO to be used for printing. For this, I need an intermediary XML format,
> and xCalendar comes in quite handy here. 
>
> However, I could only find expired drafts on the net (with various different
> namespace URIs used, so I'm not sure which is the current one). So what's
> the status of xCal?
> I found the draft
>        http://tools.ietf.org/html/draft-royer-calsch-xcal-03
> using "urn:ietf:params:xml:ns:xcal", but not using the namespace prefix
> consistently, so most of the elements are NOT in that namespace :-( (Older
> drafts use the namespace "http://ietf.org/rfc/rfcXXXX.txt", and they employ
> the xCal: prefix consistently).
> I also found the older calsch-many, but that's obviously a deprecated draft.
>
>
> Of course, once I have implemented several xsl stylesheets (maybe even to
> xsl-fo for printing/exporting a calendar to PDF in various layouts), these
> transformations won't be restricted to KOrganizer, but can be used with any
> xCalendar file produced by any application that is able to export to
> xCalendar (which are not many currently...).
>
> So is there any decision on the XML representation of iCal? Or is this dead
> and I need to come up with my own XML and other applications won't be able
> to use my stylesheets, because we don't have a standardized XML
> representation, only self-cooked ones?
>
> Thanks,
> Reinhold
>
> --
> ------------------------------------------------------------------
> Reinhold Kainhofer, Vienna University of Technology, 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 maintainer
>  * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

From: "Tim Hare" <[email-masked]>
To: "'Reinhold Kainhofer'" <[email-masked]>, "'CALSIFY Mailinglist'" <[email-masked]>
Subject: RE: [Ietf-calsify] What's the status of xCal?
Date: Fri, 12 Jan 2007 18:14:20 -0500

I haven't updated by draft lately on guidelines for using XML with calendar
information, but I still have the latest draft if you want it. It wasn't
xcalendar per se but had a lot of stuff from the original draft; also had
some stylesheet examples (which you probably don't need).  I also have in
final stages of development a stylesheet to take a string containing an
iCalendar file and transform it into XML. 

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Reinhold
Kainhofer
Sent: Friday, January 12, 2007 5:28 AM
To: CALSIFY Mailinglist
Subject: [Ietf-calsify] What's the status of xCal?

Hi,
I'm currently implementing an export function in KOrganizer that uses XSLT
transformations to create easier output in several formats and even allows
XSL-FO to be used for printing. For this, I need an intermediary XML format,
and xCalendar comes in quite handy here. 

However, I could only find expired drafts on the net (with various different
namespace URIs used, so I'm not sure which is the current one). So what's
the status of xCal?
I found the draft
       http://tools.ietf.org/html/draft-royer-calsch-xcal-03
using "urn:ietf:params:xml:ns:xcal", but not using the namespace prefix
consistently, so most of the elements are NOT in that namespace :-( (Older
drafts use the namespace "http://ietf.org/rfc/rfcXXXX.txt", and they employ
the xCal: prefix consistently).
I also found the older calsch-many, but that's obviously a deprecated draft.

Of course, once I have implemented several xsl stylesheets (maybe even to
xsl-fo for printing/exporting a calendar to PDF in various layouts), these
transformations won't be restricted to KOrganizer, but can be used with any
xCalendar file produced by any application that is able to export to
xCalendar (which are not many currently...).

So is there any decision on the XML representation of iCal? Or is this dead
and I need to come up with my own XML and other applications won't be able
to use my stylesheets, because we don't have a standardized XML
representation, only self-cooked ones?

Thanks,
Reinhold

--
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, 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 maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: CALSIFY Mailinglist <[email-masked]>
Date: Fri, 12 Jan 2007 11:28:20 +0100
Subject: [Ietf-calsify] What's the status of xCal?

Hi,
I'm currently implementing an export function in KOrganizer that uses XSLT 
transformations to create easier output in several formats and even allows 
XSL-FO to be used for printing. For this, I need an intermediary XML format, 
and xCalendar comes in quite handy here. 

However, I could only find expired drafts on the net (with various different 
namespace URIs used, so I'm not sure which is the current one). So what's the 
status of xCal?
I found the draft
       http://tools.ietf.org/html/draft-royer-calsch-xcal-03
using "urn:ietf:params:xml:ns:xcal", but not using the namespace prefix 
consistently, so most of the elements are NOT in that namespace :-(
(Older drafts use the namespace "http://ietf.org/rfc/rfcXXXX.txt", and they 
employ the xCal: prefix consistently).
I also found the older calsch-many, but that's obviously a deprecated draft.

Of course, once I have implemented several xsl stylesheets (maybe even to 
xsl-fo for printing/exporting a calendar to PDF in various layouts), these 
transformations won't be restricted to KOrganizer, but can be used with any 
xCalendar file produced by any application that is able to export to 
xCalendar (which are not many currently...).

So is there any decision on the XML representation of iCal? Or is this dead 
and I need to come up with my own XML and other applications won't be able to 
use my stylesheets, because we don't have a standardized XML representation, 
only self-cooked ones?

Thanks,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, 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 maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

From: Dan Connolly <[email-masked]>
To: [email-masked]
Organization: World Wide Web Consortium (http://www.w3.org/)
Date: Mon, 08 Jan 2007 12:57:59 -0600
Cc: RDF Calendar <[email-masked]>
Subject: [Ietf-calsify] Re: dtstart and date vs datetime (fixed; thanks)

On Fri, 2006-04-21 at 12:55 -0500, Dan Connolly wrote:
[...]
> The sections on DTSTART and DATETIME are reasonably
> clear that DTSTART:20060804 is no good...
> http://www.w3.org/2002/12/cal/rfc2445#sec4.8.2.4
> 
> But there's a DTSTART:19980205 example discussed in passing
> under 4.8.6.3 Trigger
> and another DTSTART:19971102
> 
> Those examples seem to still be there in the October 11, 2005 draft
> http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-00.txt
>
> So... what's the deal?
>   - these examples are bad data and should be fixed
> 
>   - the specification of DTSTART should be updated so that
>     the default type depends on the value given
> 
>   - the specification of the DATE-TIME data type should be
>     updated so that values like 19971102 are OK

I see a 2006-10-04 edit that adopts the 1st suggestion.
http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-03.html#rfc.change.edit-02.82

Thanks.

I haven't put test cases together yet, but I hope to soon.

> p.s. there isn't a calisfy test repository yet, is there?
> I participate in development of hCalendar test develompent.
>   http://microformats.org/wiki/hcalendar-tests
> 
> ... RDF calendar test development.
>   http://www.w3.org/2002/12/cal/test/
>   http://www.w3.org/2002/12/cal/#dev
> 
> I hope to get those two more sync'd up.
> 
> In particular, whatever answer I get from the CALSIFY WG on
> this issue, I intend to reflect in those 2 test suites.
> 
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E