Subject: [Ietf-calsify] Re: [Ietf-caldav] xCal - resubmitted.

From: hildjj at gmail.com (Joe Hildebrand)
Date: Mon Sep 26 11:51:02 2005

On namespace URIs: We went through this on XMPP.  It turned out that
URIs of this form were the winner:

urn:ietf:params:xml:ns:xmpp-tls
urn:ietf:params:xml:ns:xmpp-sasl

(See RFC 3920)

I also agree that <iCalendar/> needs to be in a namespace.  I'm not
sure why it needs to be in a different namespace than <vcalendar/>,
unless you wanted to be able to put other things inside a calendar. 
I'd suggest that having two different namespaces would be unnecessary
complexity.

>From 2.7, xmlns isn't really an attribute.  You shouldn't call out how
namespaces work.  And PLEASE don't imply that prefixes are required,
or that they must take on some special value.  I want to be able to
use a doc like this:

<iCalendar xmlns='urn:ietf:params:xml:ns:xcal'>
  <vcalendar>
    <version>2.0</version>
  </vcalendar>
</iCalendar>

which is semantically identical (assuming that iCalendar moves into
the namespace).  Writing your examples in this format might make them
easier to read, as well.

If the language attribute could be mapped (special-case) on to
xml:lang, it would be great, since there are some tools that already
deal with xml:lang.

In 2.9, specifying that invalid XML characters MUST be entity encoded
prohibits <![CDATA[ ]]> escapes.   You might just refer to standard
XML escaping mechanisms.

I don't think 2.10 adds value.  People using XML should understand
[XMLNS] at this point.  No need to be remedial.

It might be nice to have a section about extensibility.
- extend with any XML you want, as long as it's in its own namespace
- MUST ignore any extensions you don't understand
- MUST NOT expect extensions to survive round-tripping to ical.

Once some of the namspace issues are worked out, it looks like you're
on the right track.

On 8/9/05, Julian Reschke <[email-masked]> wrote:
> Dan Connolly wrote:
> > On Tue, 2005-08-09 at 11:08 +0200, Julian Reschke wrote:
> > [...]
> >
> >>>Copies of the draft at:
> >>>
> >>>    http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt
> >>>    http://INET-Consulting.com/draft-royer-calsch-xcal-01.html
> >>>    http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml
> >>
> >>Just two quick formal comments...:
> >>
> >>1) Is it intentional that in the examples, the iCalendar container
> >>element is in no namespace?
> >>
> >>2) I don't think the IETF will let you use something like
> >>"http://ietf.org/rfc/rfcXXXX.txt" as namespace name;
> >
> >
> > Right; I gather Best Current Practice is...
> >
> > [[[
> > If the registrant wishes to
> >    have a URI assigned, then a URN of the form
> >
> >       urn:ietf:params:xml:<class>:<id>
> >
> >    will be assigned where <class> is the type of the document being
> >    registered (see below).
> > ]]]
> >  -- http://www.faqs.org/rfcs/rfc3688.html
> 
> One could probably also use: <urn:ietf:rfc:NNNN> (see
> <http://ietf.org/rfc/rfc2648>).
> 
> > ...
> 
> Best regards, Julian
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> 

-- 
Joe Hildebrand

Date: Wed, 21 Sep 2005 00:26:52 -0600
From: Joe Hildebrand <[email-masked]>
To: [email-masked], "[email-masked]" <[email-masked]>, [email-masked], Doug Royer <[email-masked]>, CalDAV DevList <[email-masked]>, [email-masked]
Subject: [Ietf-calsify] Re: [Ietf-caldav] xCal - resubmitted.
Reply-To: [email-masked]

On namespace URIs: We went through this on XMPP.  It turned out that
URIs of this form were the winner:

urn:ietf:params:xml:ns:xmpp-tls
urn:ietf:params:xml:ns:xmpp-sasl

(See RFC 3920)

I also agree that <iCalendar/> needs to be in a namespace.  I'm not
sure why it needs to be in a different namespace than <vcalendar/>,
unless you wanted to be able to put other things inside a calendar.=20
I'd suggest that having two different namespaces would be unnecessary
complexity.

>From 2.7, xmlns isn't really an attribute.  You shouldn't call out how
namespaces work.  And PLEASE don't imply that prefixes are required,
or that they must take on some special value.  I want to be able to
use a doc like this:

<iCalendar xmlns=3D'urn:ietf:params:xml:ns:xcal'>
  <vcalendar>
    <version>2.0</version>
  </vcalendar>
</iCalendar>

which is semantically identical (assuming that iCalendar moves into
the namespace).  Writing your examples in this format might make them
easier to read, as well.

If the language attribute could be mapped (special-case) on to
xml:lang, it would be great, since there are some tools that already
deal with xml:lang.

In 2.9, specifying that invalid XML characters MUST be entity encoded
prohibits <![CDATA[ ]]> escapes.   You might just refer to standard
XML escaping mechanisms.

I don't think 2.10 adds value.  People using XML should understand
[XMLNS] at this point.  No need to be remedial.

It might be nice to have a section about extensibility.
- extend with any XML you want, as long as it's in its own namespace
- MUST ignore any extensions you don't understand
- MUST NOT expect extensions to survive round-tripping to ical.

Once some of the namspace issues are worked out, it looks like you're
on the right track.

On 8/9/05, Julian Reschke <[email-masked]> wrote:
> Dan Connolly wrote:
> > On Tue, 2005-08-09 at 11:08 +0200, Julian Reschke wrote:
> > [...]
> >
> >>>Copies of the draft at:
> >>>
> >>>    http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt
> >>>    http://INET-Consulting.com/draft-royer-calsch-xcal-01.html
> >>>    http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml
> >>
> >>Just two quick formal comments...:
> >>
> >>1) Is it intentional that in the examples, the iCalendar container
> >>element is in no namespace?
> >>
> >>2) I don't think the IETF will let you use something like
> >>"http://ietf.org/rfc/rfcXXXX.txt" as namespace name;
> >
> >
> > Right; I gather Best Current Practice is...
> >
> > [[[
> > If the registrant wishes to
> >    have a URI assigned, then a URN of the form
> >
> >       urn:ietf:params:xml:<class>:<id>
> >
> >    will be assigned where <class> is the type of the document being
> >    registered (see below).
> > ]]]
> >  -- http://www.faqs.org/rfcs/rfc3688.html
>=20
> One could probably also use: <urn:ietf:rfc:NNNN> (see
> <http://ietf.org/rfc/rfc2648>).
>=20
> > ...
>=20
> Best regards, Julian
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>=20

--=20
Joe Hildebrand

Subject: Re: [Ietf-calsify] Multiple iCalendar Objects
Date: Thu, 8 Sep 2005 09:47:25 -0400
To: [email-masked]
From: [email-masked]
Cc: [email-masked]

Right, I think that's where Doug was going with his post.  I think PUBLISH
is a good Use Case for multiple calendar objects.

Thanks everyone-
CS

             Tim Hare                                                      
             <TimHare@comcast.                                             
             net>                                                       To 
             Sent by:                  [email-masked]      
             ietf-calsify-boun                                          cc 
             ces@osafoundation                                             
             .org                                                  Subject 
                                       Re: [Ietf-calsify] Multiple         
                                       iCalendar Objects                   
             09/07/2005 08:51                                              
             PM                                                            

One other use case of multiple calendar objects is the very common
METHOD:PUBLISH use case, for example an events calendar, is it not? Or am I

misinterpreting this part?

BEGIN:VCALENDAR
METHOD:PUBLISH
BEGIN:VEVENT
END:VEVENT
BEGIN:VEVENT
END:VEVENT
--- etcetera ---
END:VCALENDAR

In any case, I don't see any real programming problems dealing even with
multiple VCALENDARs in one file; if it's a memory constraint problem, read
the file until the first END:VCALENDAR, or END:VEVENT for that matter,
process what you have, and then move on. Of course, my roots are in the
mainframe world where thinking of files in a sequential manner is perhaps
more common, but I believe this would work...

At 07:40 PM 9/7/2005, you wrote:
>That may be, but I will note that there are many calendar programs
>currently on the market that can't handle multiple VCALENDAR objects
>within a single file - I wrote about this in 2003 at
>
>http://staff.washington.edu/oren/weblog2/archives/2003/12/
>more_on_ical_or.html
>
>- Oren
>
>On Sep 7, 2005, at 12:43 PM, Doug Royer wrote:
>
>>
>>
>>[email-masked] wrote:
>>
>>>That's a good point.  So you mean that if I have a handheld device
>>>and I
>>>want to pull down my January 2006 calendar, I would want to
>>>tranfer in one
>>>shot with many iCalendar objects, each having a method param
>>>telling me how
>>>to display this?
>>
>>Yes. I do not know of a handheld that does iTIP yet. It however
>>is accurate for my laptop synchronizing with my desktop.
>>
>>So the existing 2445 text looks accurate to me.
>>
>>--
>>
>>Doug Royer                     | http://INET-Consulting.com
>>-------------------------------|-----------------------------
>>
>>               We Do Standards - You Need Standards
>>
>>
>><Doug.vcf>
>>_______________________________________________
>>Ietf-calsify mailing list
>>[email-masked]
>>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc.

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

Date: Wed, 07 Sep 2005 20:23:06 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Oren Sreebny <[email-masked]>
Subject: Re: [Ietf-calsify] Multiple iCalendar Objects
Cc: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms090102060409020407030406
Content-Type: multipart/mixed; boundary="------------060000050400090003090207"

This is a multi-part message in MIME format.
--------------060000050400090003090207
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

And those are generally non-iTIP capable products, so that makes sense.
And all of those that I have found use iCal in non documented ways. So
that in itself is not that compelling.

Oren Sreebny wrote:
> That may be, but I will note that there are many calendar programs  
> currently on the market that can't handle multiple VCALENDAR objects   
> within a single file - I wrote about this in 2003 at
> 
-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------060000050400090003090207
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------060000050400090003090207--

--------------ms090102060409020407030406
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090102060409020407030406--

Date: Wed, 07 Sep 2005 20:51:24 -0400
To: [email-masked]
From: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] Multiple iCalendar Objects

One other use case of multiple calendar objects is the very common 
METHOD:PUBLISH use case, for example an events calendar, is it not? Or am I 
misinterpreting this part?

BEGIN:VCALENDAR
METHOD:PUBLISH
BEGIN:VEVENT
END:VEVENT
BEGIN:VEVENT
END:VEVENT
--- etcetera ---
END:VCALENDAR

In any case, I don't see any real programming problems dealing even with 
multiple VCALENDARs in one file; if it's a memory constraint problem, read 
the file until the first END:VCALENDAR, or END:VEVENT for that matter, 
process what you have, and then move on. Of course, my roots are in the 
mainframe world where thinking of files in a sequential manner is perhaps 
more common, but I believe this would work...

At 07:40 PM 9/7/2005, you wrote:
>That may be, but I will note that there are many calendar programs
>currently on the market that can't handle multiple VCALENDAR objects
>within a single file - I wrote about this in 2003 at
>
>http://staff.washington.edu/oren/weblog2/archives/2003/12/ 
>more_on_ical_or.html
>
>- Oren
>
>On Sep 7, 2005, at 12:43 PM, Doug Royer wrote:
>
>>
>>
>>[email-masked] wrote:
>>
>>>That's a good point.  So you mean that if I have a handheld device
>>>and I
>>>want to pull down my January 2006 calendar, I would want to
>>>tranfer in one
>>>shot with many iCalendar objects, each having a method param
>>>telling me how
>>>to display this?
>>
>>Yes. I do not know of a handheld that does iTIP yet. It however
>>is accurate for my laptop synchronizing with my desktop.
>>
>>So the existing 2445 text looks accurate to me.
>>
>>--
>>
>>Doug Royer                     | http://INET-Consulting.com
>>-------------------------------|-----------------------------
>>
>>               We Do Standards - You Need Standards
>>
>>
>><Doug.vcf>
>>_______________________________________________
>>Ietf-calsify mailing list
>>[email-masked]
>>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 

From: Oren Sreebny <[email-masked]>
Subject: Re: [Ietf-calsify] Multiple iCalendar Objects
Date: Wed, 7 Sep 2005 16:40:18 -0700
To: Calsify <[email-masked]>

That may be, but I will note that there are many calendar programs  
currently on the market that can't handle multiple VCALENDAR objects   
within a single file - I wrote about this in 2003 at

http://staff.washington.edu/oren/weblog2/archives/2003/12/ 
more_on_ical_or.html

- Oren

On Sep 7, 2005, at 12:43 PM, Doug Royer wrote:

>
>
> [email-masked] wrote:
>
>> That's a good point.  So you mean that if I have a handheld device  
>> and I
>> want to pull down my January 2006 calendar, I would want to  
>> tranfer in one
>> shot with many iCalendar objects, each having a method param  
>> telling me how
>> to display this?
>>
>
> Yes. I do not know of a handheld that does iTIP yet. It however
> is accurate for my laptop synchronizing with my desktop.
>
> So the existing 2445 text looks accurate to me.
>
> -- 
>
> Doug Royer                     | http://INET-Consulting.com
> -------------------------------|-----------------------------
>
>               We Do Standards - You Need Standards
>
>
> <Doug.vcf>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

Date: Wed, 07 Sep 2005 13:43:19 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Multiple iCalendar Objects
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms030803060704070602030602
Content-Type: multipart/mixed; boundary="------------070903060804060909020803"

This is a multi-part message in MIME format.
--------------070903060804060909020803
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

[email-masked] wrote:
> That's a good point.  So you mean that if I have a handheld device and I
> want to pull down my January 2006 calendar, I would want to tranfer in one
> shot with many iCalendar objects, each having a method param telling me how
> to display this?

Yes. I do not know of a handheld that does iTIP yet. It however
is accurate for my laptop synchronizing with my desktop.

So the existing 2445 text looks accurate to me.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------070903060804060909020803
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------070903060804060909020803--

--------------ms030803060704070602030602
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms030803060704070602030602--

Subject: Re: [Ietf-calsify] Multiple iCalendar Objects
To: Calsify <[email-masked]>
Date: Wed, 7 Sep 2005 15:01:03 -0400
From: [email-masked]

That's a good point.  So you mean that if I have a handheld device and I
want to pull down my January 2006 calendar, I would want to tranfer in one
shot with many iCalendar objects, each having a method param telling me how
to display this?

Is that paraphrased about right?  Seems like a good use case to me!
-CS

[email-masked] wrote on 09/07/2005 02:28:55 PM:

>
> Multiple iCalendar objects in one object is essential when
> copying calendars that have METHOD properties in them.
> Otherwise, there is no way to transport them in a single transfer.
>
> Its needed in both synchronization and when transferring
> a calendar in iCal format.
>
>
>    BEGIN:VCALENDAR
>    METHOD:PUBLISH
>    ...
>    END:VCALENDAR
>    BEGIN:VCALENDAR
>    METHOD:ADD
>    ...
>    END:VCALENDAR
>    ...
>
>
> [email-masked] wrote:
> > RFC 2445 allows for multiple iCalendar objects, but I'm not so sure
this is
> > a good idea.  Does anyone know of an implementation that makes use of
> > multiple iCalendar objects?
> >
> > I would like to change: "Typically, this information will consist of a
> > single iCalendar object. However, multiple iCalendar objects can be
> > sequentially grouped together. "
> >
> > ...to read this instead: "This information will consist of a single
> > iCalendar object."
> >
> > Thoughts on this?
> > -Chris Stoner
> >
> >
> > 6. iCalendar Objects
> >
> >
> > The Calendaring and Scheduling Core Object is a collection of
calendaring
> > and scheduling information. Typically, this information will consist of
a
> > single iCalendar object. However, multiple iCalendar objects can be
> > sequentially grouped together. The first line and last line of the
> > iCalendar object MUST contain a pair of iCalendar object delimiter
strings.
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Ietf-calsify mailing list
> > [email-masked]
> > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> --
>
> Doug Royer                     | http://INET-Consulting.com
> -------------------------------|-----------------------------
>
>                We Do Standards - You Need Standards
>
> [attachment "Doug.vcf" deleted by Chris Stoner/Westford/IBM]
> [attachment "smime.p7s" deleted by Chris Stoner/Westford/IBM]
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Wed, 7 Sep 2005 11:31:23 -0700 (PDT)
Subject: Re: [Ietf-calsify] Multiple iCalendar Objects
From: "Peter Jacobson" <[email-masked]>
To: [email-masked]
Importance: Normal
Reply-To: [email-masked]

this is my first post to this list so forgive me if I misinterpret your
comment.

I'm building a Web app that in part deals with film and video equipment
rentals. A customer can look up availability of and book equipment using a
calendar interface. Their order corresponds to an iCalendar object.
However, customers can book equipment for more than one occasion at a
time, which would in our case be represented by two separate orders, or
calendars, both of which are associated with that customer.

In addition, each piece of equipment has its own iCalendar (so you can
look up that video camera to see when it is available).

Does that example fit the case?

Peter Jacobson

<quote who="[email-masked]">
> RFC 2445 allows for multiple iCalendar objects, but I'm not so sure this
> is
> a good idea.  Does anyone know of an implementation that makes use of
> multiple iCalendar objects?
>
> I would like to change: "Typically, this information will consist of a
> single iCalendar object. However, multiple iCalendar objects can be
> sequentially grouped together. "
>
> ...to read this instead: "This information will consist of a single
> iCalendar object."
>
> Thoughts on this?
> -Chris Stoner
>
>
> 6. iCalendar Objects
>
>
> The Calendaring and Scheduling Core Object is a collection of calendaring
> and scheduling information. Typically, this information will consist of a
> single iCalendar object. However, multiple iCalendar objects can be
> sequentially grouped together. The first line and last line of the
> iCalendar object MUST contain a pair of iCalendar object delimiter
> strings.
>
>
>
>
>
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>

......................................................
Linking Arts Web Development
www.linkingarts.com

Date: Wed, 07 Sep 2005 12:28:55 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Multiple iCalendar Objects
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms030901090705050908040301
Content-Type: multipart/mixed; boundary="------------070909000805060701070409"

This is a multi-part message in MIME format.
--------------070909000805060701070409
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Multiple iCalendar objects in one object is essential when
copying calendars that have METHOD properties in them.
Otherwise, there is no way to transport them in a single transfer.

Its needed in both synchronization and when transferring
a calendar in iCal format.

	BEGIN:VCALENDAR
	METHOD:PUBLISH
	...
	END:VCALENDAR
	BEGIN:VCALENDAR
	METHOD:ADD
	...
	END:VCALENDAR
	...

[email-masked] wrote:
> RFC 2445 allows for multiple iCalendar objects, but I'm not so sure this is
> a good idea.  Does anyone know of an implementation that makes use of
> multiple iCalendar objects?
> 
> I would like to change: "Typically, this information will consist of a
> single iCalendar object. However, multiple iCalendar objects can be
> sequentially grouped together. "
> 
> ...to read this instead: "This information will consist of a single
> iCalendar object."
> 
> Thoughts on this?
> -Chris Stoner
> 
> 
> 6. iCalendar Objects
> 
> 
> The Calendaring and Scheduling Core Object is a collection of calendaring
> and scheduling information. Typically, this information will consist of a
> single iCalendar object. However, multiple iCalendar objects can be
> sequentially grouped together. The first line and last line of the
> iCalendar object MUST contain a pair of iCalendar object delimiter strings.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------070909000805060701070409
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------070909000805060701070409--

--------------ms030901090705050908040301
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms030901090705050908040301--

To: [email-masked]
Date: Wed, 7 Sep 2005 13:51:28 -0400
From: [email-masked]
Subject: [Ietf-calsify] Multiple iCalendar Objects

RFC 2445 allows for multiple iCalendar objects, but I'm not so sure thi=
s is
a good idea.  Does anyone know of an implementation that makes use of
multiple iCalendar objects?

I would like to change: "Typically, this information will consist of a
single iCalendar object. However, multiple iCalendar objects can be
sequentially grouped together. "

...to read this instead: "This information will consist of a single
iCalendar object."

Thoughts on this?
-Chris Stoner

6.=A0iCalendar Objects

The Calendaring and Scheduling Core Object is a collection of calendari=
ng
and scheduling information. Typically, this information will consist of=
 a
single iCalendar object. However, multiple iCalendar objects can be
sequentially grouped together. The first line and last line of the
iCalendar object MUST contain a pair of iCalendar object delimiter stri=
ngs.

=

Date: Mon, 05 Sep 2005 18:42:45 -0400
To: [email-masked], [email-masked]
From: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] Sync: Was Question on VFREEBUSY

I think if we are going to discuss sync we need a draft which documents how 
we can fit with SyncML or other generalized synchronization efforts to 
avoid reinventing the wheel.

At 02:08 PM 9/5/2005, Doug Royer wrote:

>In addition to those, synchronization information needs to
>be defined. As how to merge if both sides edited the same
>VEVENT.
>
>This is not a calsify issue as it has not been covered in any
>spec I have seen. I think this would have to be a new draft.
>
>
>Timi Soinio wrote:
>>ext Lisa Dusseault wrote:
>>
>>>These are good questions... my gut feel is that we certainly need 
>>>separate documents, perhaps more separate documents than we already 
>>>have. In practice, iCalendar is used for 3 separate purposes:
>>>- import and export -- where you don't worry about saving VFREEBUSY 
>>>information that duplicates event start/end times
>>>- invitation
>>>- CalDAV (or other access/sharing)
>>
>>In addition to these three usage purposes, I would also consider 
>>synchronization (with e.g. OMA DS) as a fourth important purpose for 
>>using iCalendar. Technically, it resembles import and export cases but it 
>>can contain some iCal properties that normally are left out from simple 
>>import/export (PUBLISH?) cases, e.g. ATTENDEE information.
>>-Timi
>>_______________________________________________
>>Ietf-calsify mailing list
>>[email-masked]
>>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>--
>
>Doug Royer                     | http://INET-Consulting.com
>-------------------------------|-----------------------------
>
>               We Do Standards - You Need Standards
>
>
>
>
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 

Date: Mon, 05 Sep 2005 12:08:37 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: [Ietf-calsify] Sync: Was Question on VFREEBUSY
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090903080000020206000009
Content-Type: multipart/mixed; boundary="------------040906010607040001090302"

This is a multi-part message in MIME format.
--------------040906010607040001090302
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

In addition to those, synchronization information needs to
be defined. As how to merge if both sides edited the same
VEVENT.

This is not a calsify issue as it has not been covered in any
spec I have seen. I think this would have to be a new draft.

Timi Soinio wrote:
> ext Lisa Dusseault wrote:
> 
>> These are good questions... my gut feel is that we certainly need 
>> separate documents, perhaps more separate documents than we already 
>> have. In practice, iCalendar is used for 3 separate purposes:
>> - import and export -- where you don't worry about saving VFREEBUSY 
>> information that duplicates event start/end times
>> - invitation
>> - CalDAV (or other access/sharing)
> 
> 
> In addition to these three usage purposes, I would also consider 
> synchronization (with e.g. OMA DS) as a fourth important purpose for 
> using iCalendar. Technically, it resembles import and export cases but 
> it can contain some iCal properties that normally are left out from 
> simple import/export (PUBLISH?) cases, e.g. ATTENDEE information.
> 
> -Timi
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------040906010607040001090302
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------040906010607040001090302--

--------------ms090903080000020206000009
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090903080000020206000009--

Date: Mon, 05 Sep 2005 12:01:18 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] DTEND for day events
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms020108020503070903090804
Content-Type: multipart/mixed; boundary="------------060501000606050405000802"

This is a multi-part message in MIME format.
--------------060501000606050405000802
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I have never seen any.

Mike Douglass wrote:
> Slightly related, is a vevent DATE DTEND allowed with a DATE-TIME 
> DTSTART and if so what does it mean?
> 
> I could only find that a DATE DTSTART requires a DATE DTEND if present.
> 

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------060501000606050405000802
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------060501000606050405000802--

--------------ms020108020503070903090804
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020108020503070903090804--

Date: Mon, 05 Sep 2005 09:02:25 +0300
From: Timi Soinio <[email-masked]>
To: ext Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Question on VFREEBUSY
Cc: [email-masked]

ext Lisa Dusseault wrote:

> These are good questions... my gut feel is that we certainly need 
> separate documents, perhaps more separate documents than we already 
> have. In practice, iCalendar is used for 3 separate purposes:
> - import and export -- where you don't worry about saving VFREEBUSY 
> information that duplicates event start/end times
> - invitation
> - CalDAV (or other access/sharing)

In addition to these three usage purposes, I would also consider 
synchronization (with e.g. OMA DS) as a fourth important purpose for 
using iCalendar. Technically, it resembles import and export cases but 
it can contain some iCal properties that normally are left out from 
simple import/export (PUBLISH?) cases, e.g. ATTENDEE information.

-Timi

Date: Sun, 04 Sep 2005 21:21:20 -0400
From: Mike Douglass <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ietf-calsify] DTEND for day events

Slightly related, is a vevent DATE DTEND allowed with a DATE-TIME 
DTSTART and if so what does it mean?

I could only find that a DATE DTSTART requires a DATE DTEND if present.

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

Date: Sat, 03 Sep 2005 20:19:58 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: [Ietf-calsify] iCalendar Source Forge Project - new

This is a cryptographically signed message in MIME format.

--------------ms030502060600040401020900
Content-Type: multipart/mixed; boundary="------------010704080309030704000201"

This is a multi-part message in MIME format.
--------------010704080309030704000201
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I have created a new http://SourceForge.net project - iCalendar

	https://sourceforge.net/projects/icalendar

I released the XSLT files that transform an xCal object into
an iCalendar object.

I want to open this SourceForge project open to any iCalendar
open source work.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------010704080309030704000201
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------010704080309030704000201--

--------------ms030502060600040401020900
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms030502060600040401020900--

Date: Fri, 02 Sep 2005 21:32:34 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: [Ietf-calsify] Import / Export
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090101030300050507040709
Content-Type: multipart/mixed; boundary="------------070607050301090406070608"

This is a multi-part message in MIME format.
--------------070607050301090406070608
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

.
You would have to know if or to what level the other endpoint
understood recurrence rules, how they used DTEND (As date
or fixed duration).

iCal-Basic is as far as I can tell the minimum set of interchange
information that works with most vendors. With iCal-Basic you
do not assume the other end knows RRULE or EXRULE. And you do not
need to guess how they handle the length of 2nd and up instances
across a time zone change as all instances specify the duration.

Lisa Dusseault wrote:
> ..., but I'm unaware of specific
> guidance for import/export even though that should probably exist (any 
> volunteers?).  There are probably minor areas of iTIP workflow and 
> iCalendar usage where we can make the separation cleaner, but as a basic 
> document structure it's always seemed sensible to me the way the 
> documents are divided.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------070607050301090406070608
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------070607050301090406070608--

--------------ms090101030300050507040709
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090101030300050507040709--

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Question on VFREEBUSY
Date: Fri, 2 Sep 2005 14:51:35 -0700
To: Doug Royer <[email-masked]>
Cc: [email-masked]

These are good questions... my gut feel is that we certainly need 
separate documents, perhaps more separate documents than we already 
have.  In practice, iCalendar is used for 3 separate purposes:
  - import and export -- where you don't worry about saving VFREEBUSY 
information that duplicates event start/end times
  - invitation
  - CalDAV (or other access/sharing)

The CalDAV spec already has and requires some guidance on how to use 
parts of iCalendar in that context, and iTIP has some guidance for how 
to use iCalendar for invitation workflow, but I'm unaware of specific 
guidance for import/export even though that should probably exist (any 
volunteers?).  There are probably minor areas of iTIP workflow and 
iCalendar usage where we can make the separation cleaner, but as a 
basic document structure it's always seemed sensible to me the way the 
documents are divided.

Still, if anybody has other proposals for how the information should be 
factored into documents (or major sections within docs), speak up early 
rather than late.

Lisa

On Sep 2, 2005, at 1:55 PM, Doug Royer wrote:

>
> The original idea was that 2445 was the object dictionary.
> And 2446 was how to use 2445 objects. Many implementations
> ignore 2446 and just send 2445 objects and they ignore the
> 2446 restrictions.
>
> I agree with you. Bruce fought very hard to keep VFREEBUSY
> from being different than a 100% mapping of OPAQUE components
> in a calendar. So there was no point in having them in a 2445 object
> as the 2445 objects had exactly the same OPAQUE time blocks.
>
> VFREEBUSY existed so that you could make quick guess as to when
> someone was available.
>
> Your supposed to publish both your calendar and your VFREEBUSY
> calendars. Almost no one does that.
>
>
> Cyrus Daboo wrote:
>> Hi folks,
>> According to 2445 VFREEBUSY components are only supposed to be used 
>> in iTIP publish/request/reply methods. For some reason I was under 
>> the impression that I could use VFREEBUSY in a 'regular' calendar to 
>> indicate my own busy time without having to create a 'dummy' event to 
>> block out the time. What do other people think about the use of 
>> VFREEBUSY?
>> If its really the case that VFREEBUSY is only used by iTIP, then 
>> would it not make sense to move it to the iTIP bis document and drop 
>> it from 2445bis? That would remove VFREEBUSY and the FREEBUSY 
>> property from 2445bis.
>
> Is what is really the case is that ALL of 2445 is supposed to be used
> in iTIP only. Almost all calendar implementations out there PUBLISH
> their calendars, and yet do not add the METHOD:PUBLISH property and
> value.
>
>> Another thing: the FREEBUSY property contains three 'busy' types: 
>> BUSY, BUSY-TENTATIVE and BUSY-UNAVAILABLE. The first two are fairly 
>> easy to understand - they are based on the STATUS of VEVENTs within 
>> the busy-time period request. However, I can't see how a calendar 
>> user is supposed to indicate BUSY-UNAVAILABLE in their own calendar 
>> so that busy-time requests will generate that. That is, unless 
>> VFREEBUSY components could be created in 'regular' calendars in which 
>> case BUSY-UNAVAILABLE could be set and returned.
>
>
> BUSY-UNAVAILABE - example: Non-working hours. No VEVENT associated
> with it at all. They are not useless. And I agree with you that
> they should not be tied 100% to OPAQUE components in the calendar.
>
>
> So, should 2445 remain the data dictionary Or does it become a
> standalone document? If standalone I think you will find MANY issues
> like this that will force 2445 and 2446 to have a lot of rewrite.
>
>
>
> -- 
>
> Doug Royer                     | http://INET-Consulting.com
> -------------------------------|-----------------------------
>
>               We Do Standards - You Need Standards
>
> <Doug.vcf>_______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Fri, 02 Sep 2005 14:55:22 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Question on VFREEBUSY
Cc: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010005050805040304000409
Content-Type: multipart/mixed; boundary="------------030902050702070703060400"

This is a multi-part message in MIME format.
--------------030902050702070703060400
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

The original idea was that 2445 was the object dictionary.
And 2446 was how to use 2445 objects. Many implementations
ignore 2446 and just send 2445 objects and they ignore the
2446 restrictions.

I agree with you. Bruce fought very hard to keep VFREEBUSY
from being different than a 100% mapping of OPAQUE components
in a calendar. So there was no point in having them in a 2445 object
as the 2445 objects had exactly the same OPAQUE time blocks.

VFREEBUSY existed so that you could make quick guess as to when
someone was available.

Your supposed to publish both your calendar and your VFREEBUSY
calendars. Almost no one does that.

Cyrus Daboo wrote:
> Hi folks,
> According to 2445 VFREEBUSY components are only supposed to be used in 
> iTIP publish/request/reply methods. For some reason I was under the 
> impression that I could use VFREEBUSY in a 'regular' calendar to 
> indicate my own busy time without having to create a 'dummy' event to 
> block out the time. What do other people think about the use of VFREEBUSY?
> 
> If its really the case that VFREEBUSY is only used by iTIP, then would 
> it not make sense to move it to the iTIP bis document and drop it from 
> 2445bis? That would remove VFREEBUSY and the FREEBUSY property from 
> 2445bis.

Is what is really the case is that ALL of 2445 is supposed to be used
in iTIP only. Almost all calendar implementations out there PUBLISH
their calendars, and yet do not add the METHOD:PUBLISH property and
value.

> Another thing: the FREEBUSY property contains three 'busy' types: BUSY, 
> BUSY-TENTATIVE and BUSY-UNAVAILABLE. The first two are fairly easy to 
> understand - they are based on the STATUS of VEVENTs within the 
> busy-time period request. However, I can't see how a calendar user is 
> supposed to indicate BUSY-UNAVAILABLE in their own calendar so that 
> busy-time requests will generate that. That is, unless VFREEBUSY 
> components could be created in 'regular' calendars in which case 
> BUSY-UNAVAILABLE could be set and returned.

BUSY-UNAVAILABE - example: Non-working hours. No VEVENT associated
with it at all. They are not useless. And I agree with you that
they should not be tied 100% to OPAQUE components in the calendar.

So, should 2445 remain the data dictionary Or does it become a
standalone document? If standalone I think you will find MANY issues
like this that will force 2445 and 2446 to have a lot of rewrite.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------030902050702070703060400
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------030902050702070703060400--

--------------ms010005050805040304000409
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms010005050805040304000409--

Date: Fri, 2 Sep 2005 09:11:18 -0700
From: "Carsten Guenther" <[email-masked]>
Sender: "Carsten Guenther" <[email-masked]>
To: Jeffrey Harris <[email-masked]>
Subject: Re: [Ietf-calsify] DTEND for day events
Cc: [email-masked]

>We should probably find out what different implementations are doing
>what with VALUE=DATE events at the upcoming CalConnect...  Perhaps if
>it's just iCal, we could special case anything old iCal data, but that
>sounds like a nightmare to me.
>
Unfortunately it's not just iCal. Just to name a few others that do the 
same thing: Evolution, Sunbird, Outlook/MSN and the next release of the 
Scalix server. Some vendors (Microsoft for example) also introduced 
their own property to explicitely mark an event as all-day.

Carsten

From: "Chris Bryant" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>, "Jeffrey Harris" <[email-masked]>, "Reinhold Kainhofer" <[email-masked]>
Subject: Re: [Ietf-calsify] DTEND for day events
Date: Fri, 2 Sep 2005 12:06:14 -0400
Organization: USA.NET
Z-USANET-MsgId: XID123JiBqgm0173X38
Cc: [email-masked]

----- Original Message ----- 
From: "Cyrus Daboo" <[email-masked]>
Sent: Friday, September 02, 2005 11:49 AM
Subject: Re: [Ietf-calsify] DTEND for day events

> I treat DTEND as always being exclusive in iCalendar data - even for 
> date-only values. However, when a user edits or creates an 'all-day' 
> event, the displayed end time is actually the inclusive end. So I 
> basically map between inclusive/exclusive values for display purposes 
> because I found inclusive end to be more intuitive for users. i.e it makes 
> more sense that a two day event starts on Monday and ends on Tuesday, than 
> it does to start on Monday and end on Wednesday (the exclusive option).
>

We also handle DTEND like Cyrus described above.

Chris 

Date: Fri, 02 Sep 2005 11:49:38 -0400
From: Cyrus Daboo <[email-masked]>
To: Jeffrey Harris <[email-masked]>, Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] DTEND for day events
Cc: [email-masked]

Hi Jeffrey,

--On September 2, 2005 8:11:27 AM -0700 Jeffrey Harris 
<[email-masked]> wrote:

> If we followed what I believe iCal is doing (and what I have done in
> Chandler, following iCal, but Chandler's not shipping so it can change
> however we want), there would be no semantic difference between the
> three examples above.
>
> I'll freely admit I have lots of special casing in Chandler to deal with
> this oddity, I'd be delighted to get rid of it.  Unfortunately, I think
> given how widespread the above (admittedly not the intended by the
> authors) interpretation is in actual use, we need to work with it for
> VERSION:2.0 iCalendar.
>
> We should probably find out what different implementations are doing
> what with VALUE=DATE events at the upcoming CalConnect...  Perhaps if
> it's just iCal, we could special case anything old iCal data, but that
> sounds like a nightmare to me.

I treat DTEND as always being exclusive in iCalendar data - even for 
date-only values. However, when a user edits or creates an 'all-day' event, 
the displayed end time is actually the inclusive end. So I basically map 
between inclusive/exclusive values for display purposes because I found 
inclusive end to be more intuitive for users. i.e it makes more sense that 
a two day event starts on Monday and ends on Tuesday, than it does to start 
on Monday and end on Wednesday (the exclusive option).

-- 
Cyrus Daboo

Date: Fri, 02 Sep 2005 08:11:27 -0700
From: Jeffrey Harris <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] DTEND for day events
Cc: [email-masked]

Hi Folks,

>>>"When a DATE value is used for DTEND no time during the given day is
>>>included in the component, so
>>>
>>>DTSTART;VALUE=DATE:20050101
>>>DTEND;VALUE=DATE:20050102
>>>
>>>represents a 24 hour period."
> 
> 
> The problem then is that DTEND and DURATION are not required. If you have only 
> a DTSTART, e.g. 
> 
> DTSTART;VALUE=DATE:20050101
> 
> the above quote says that this is equivalent to
> 
> DTSTART;VALUE=DATE:20050101
> DTEND;VALUE=DATE:20050101
> 
> How would you have to understand this? And what would be the difference to
> 
> 
> DTSTART;VALUE=DATE:20050101
> DTEND;VALUE=DATE:20050102

If we followed what I believe iCal is doing (and what I have done in
Chandler, following iCal, but Chandler's not shipping so it can change
however we want), there would be no semantic difference between the
three examples above.

I'll freely admit I have lots of special casing in Chandler to deal with
this oddity, I'd be delighted to get rid of it.  Unfortunately, I think
given how widespread the above (admittedly not the intended by the
authors) interpretation is in actual use, we need to work with it for
VERSION:2.0 iCalendar.

We should probably find out what different implementations are doing
what with VALUE=DATE events at the upcoming CalConnect...  Perhaps if
it's just iCal, we could special case anything old iCal data, but that
sounds like a nightmare to me.

Sincerely,
Jeffrey

Date: Fri, 02 Sep 2005 10:34:50 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Question on VFREEBUSY

Hi folks,
According to 2445 VFREEBUSY components are only supposed to be used in iTIP 
publish/request/reply methods. For some reason I was under the impression 
that I could use VFREEBUSY in a 'regular' calendar to indicate my own busy 
time without having to create a 'dummy' event to block out the time. What 
do other people think about the use of VFREEBUSY?

If its really the case that VFREEBUSY is only used by iTIP, then would it 
not make sense to move it to the iTIP bis document and drop it from 
2445bis? That would remove VFREEBUSY and the FREEBUSY property from 2445bis.

Another thing: the FREEBUSY property contains three 'busy' types: BUSY, 
BUSY-TENTATIVE and BUSY-UNAVAILABLE. The first two are fairly easy to 
understand - they are based on the STATUS of VEVENTs within the busy-time 
period request. However, I can't see how a calendar user is supposed to 
indicate BUSY-UNAVAILABLE in their own calendar so that busy-time requests 
will generate that. That is, unless VFREEBUSY components could be created 
in 'regular' calendars in which case BUSY-UNAVAILABLE could be set and 
returned.

-- 
Cyrus Daboo

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: Jeffrey Harris <[email-masked]>
Subject: Re: [Ietf-calsify] DTEND for day events
Date: Fri, 2 Sep 2005 13:03:11 +0200
Cc: [email-masked]

Am Donnerstag, 1. September 2005 23:28 schrieb Jeffrey Harris:
> > Then please see the following mail by Frank Dawson, who is one of the
> > original authors of rfc 2445:
> > http://www.imc.org/ietf-calendar/archive1/msg03648.html
> >
> > In particular:
> > 'We explicitly got feedback to add the "non-inclusive" term. It means up
> > to "T235959".'
>
> Wow.  You're right, it looks like their intention was for non-inclusive
> to mean not including the last minute of but including the rest of the
> day.  That's sure not the way I read that language, so lets come up with
> better language for 2445bis as Lisa suggests.

But there are other places in rfc 2445 which suggest that the DTEND is the 
last date of the event:

Sec 4.6.1: "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)."

In particular that last sentence says that it's a multi-day event if DTEND is 
not eqal to DTSTART, so your example from below is a two-day event.

Sec 4.6.1: "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.

This last sentence is a strong indication that "non-inclusive" was intended to 
be understood the way Frank explained.

> It seems to me that there's lots of iCal data out there with the
> "doesn't include the whole day" interpretation, I suspect Outlook does
> the same thing.  So I'd suggest we change the language in 2445bis to say
> something like:
>
> "When a DATE value is used for DTEND no time during the given day is
> included in the component, so
>
> DTSTART;VALUE=DATE:20050101
> DTEND;VALUE=DATE:20050102
>
> represents a 24 hour period."

The problem then is that DTEND and DURATION are not required. If you have only 
a DTSTART, e.g. 

DTSTART;VALUE=DATE:20050101

the above quote says that this is equivalent to

DTSTART;VALUE=DATE:20050101
DTEND;VALUE=DATE:20050101

How would you have to understand this? And what would be the difference to

DTSTART;VALUE=DATE:20050101
DTEND;VALUE=DATE:20050102

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer maintainer

Date: Thu, 01 Sep 2005 14:28:12 -0700
From: Jeffrey Harris <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] DTEND for day events
Cc: [email-masked]

> Then please see the following mail by Frank Dawson, who is one of the original 
> authors of rfc 2445:
> http://www.imc.org/ietf-calendar/archive1/msg03648.html
> 
> In particular:
> 'We explicitly got feedback to add the "non-inclusive" term. It means up to 
> "T235959".'

Wow.  You're right, it looks like their intention was for non-inclusive
to mean not including the last minute of but including the rest of the
day.  That's sure not the way I read that language, so lets come up with
better language for 2445bis as Lisa suggests.

> So, the question is now what to do about this. Shall we stick to the 
> interpretation that "non-inclusive" means that DTEND needs to be first date 
> after the item? Or shall we use the correct interpretation from now on? 
> 
> The reason I'm asking is that we are releasing KDE 3.5 shortly, and currently 
> I fixed it to use Frank's interpretation. 

It seems to me that there's lots of iCal data out there with the
"doesn't include the whole day" interpretation, I suspect Outlook does
the same thing.  So I'd suggest we change the language in 2445bis to say
something like:

"When a DATE value is used for DTEND no time during the given day is
included in the component, so

DTSTART;VALUE=DATE:20050101
DTEND;VALUE=DATE:20050102

represents a 24 hour period."

It's too bad there's data in the wild that means this, I really think
dates for dtends would adhere to common usage better if they were
inclusive, but ce la vies.

Sincerely,
Jeffrey Harris

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] DTEND for day events
Date: Thu, 1 Sep 2005 22:46:28 +0200

Am Donnerstag, 1. September 2005 20:15 schrieb Carsten Guenther:
> Afaik RFC 2445 does not say anything about allday events, but in all
> implementations I have seen so far the DTEND is exclusive.

Then please see the following mail by Frank Dawson, who is one of the original 
authors of rfc 2445:
http://www.imc.org/ietf-calendar/archive1/msg03648.html

In particular:
'We explicitly got feedback to add the "non-inclusive" term. It means up to 
"T235959".'

I found this mail only recently, and so far (from KDE 3.1 until 3.4.2) we 
(=Korganizer and Kontact resp.)also interpreted non-inclusive to mean that 
DTEND should be the first date after the event. A while ago I also talked 
with one of the evolution developers and he agreed that if Frank's mail is 
true, we might have misunderstood rfc 2445.

So, the question is now what to do about this. Shall we stick to the 
interpretation that "non-inclusive" means that DTEND needs to be first date 
after the item? Or shall we use the correct interpretation from now on? 

The reason I'm asking is that we are releasing KDE 3.5 shortly, and currently 
I fixed it to use Frank's interpretation. 

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer maintainer

From: Olivier Gutknecht <[email-masked]>
Subject: Re: [Ietf-calsify] DTEND for day events
Date: Thu, 1 Sep 2005 21:58:58 +0200
To: Jeffrey Harris <[email-masked]>
Cc: [email-masked]

Hi Jeffrey,

On Sep 1, 2005, at 8:20 PM, Jeffrey Harris wrote:
>> rfc2445 is unclear if the DTEND is inclusive or exclusive when  
>> both the
>> DTSTART and DTEND are DATEs.
>>
>
> To find the language about this, you have to look in the (not
> intuitively located) VEVENT definition.  It says:
>
> 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.
>
> It doesn't say anything specific about DATE valued events, so DTEND is
> always exclusive.

Which also makes sense with the DATETIME case (i.e. a 'ponctual' event):
"For cases where a "VEVENT" calendar component
    specifies a "DTSTART" property with a DATE-TIME data type but no
    "DTEND" property, the event ends on the same calendar date and time
    of day specified by the "DTSTART" property.

> In practice, Apple's iCal always exports one-day all-day events  
> with an
> explicit DTEND of the day after the start.  I scratched my head about
> that for a while, too, till I looked in VEVENT.

I'm not sure it's 'always'. I think that with our implementation you  
might get in
some cases a  one-day DATE valued event without a DTEND.

Ol.

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] DTEND for day events
Date: Thu, 1 Sep 2005 12:44:25 -0700
To: Jeffrey Harris <[email-masked]>
Cc: [email-masked]

Anybody have text to propose for RFC2445 bis to improve the clarity of 
this?

lisa

On Sep 1, 2005, at 11:20 AM, Jeffrey Harris wrote:

> Hi Neal,
>
>> rfc2445 is unclear if the DTEND is inclusive or exclusive when both 
>> the
>> DTSTART and DTEND are DATEs.
>
> To find the language about this, you have to look in the (not
> intuitively located) VEVENT definition.  It says:
>
> 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.
>
> It doesn't say anything specific about DATE valued events, so DTEND is
> always exclusive.
>
> In practice, Apple's iCal always exports one-day all-day events with an
> explicit DTEND of the day after the start.  I scratched my head about
> that for a while, too, till I looked in VEVENT.
>
> Sincerely,
> Jeffrey Harris
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Thu, 01 Sep 2005 11:20:02 -0700
From: Jeffrey Harris <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [Ietf-calsify] DTEND for day events

Hi Neal,

> rfc2445 is unclear if the DTEND is inclusive or exclusive when both the 
> DTSTART and DTEND are DATEs.

To find the language about this, you have to look in the (not
intuitively located) VEVENT definition.  It says:

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.

It doesn't say anything specific about DATE valued events, so DTEND is
always exclusive.

In practice, Apple's iCal always exports one-day all-day events with an
explicit DTEND of the day after the start.  I scratched my head about
that for a while, too, till I looked in VEVENT.

Sincerely,
Jeffrey Harris

Date: Thu, 1 Sep 2005 11:15:10 -0700
From: "Carsten Guenther" <[email-masked]>
Sender: "Carsten Guenther" <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] DTEND for day events
Cc: Calsify <[email-masked]>

Afaik RFC 2445 does not say anything about allday events, but in all  
implementations I have seen so far the DTEND is exclusive.

Example for a one day allday event on Jul 15:

DTSTART;VALUE=DATE:20050715
DTEND;VALUE=DATE:20050716

Think of this being another form for midnight to midnight local time:

DTSTART:20050715T000000
DTEND:20050716T000000

Carsten

On Sep 1, 2005, at 11:08 AM, Neal Gafter wrote:

> rfc2445 is unclear if the DTEND is inclusive or exclusive when both  
> the DTSTART and DTEND are DATEs.
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

Date: Thu, 1 Sep 2005 11:08:06 -0700
From: Neal Gafter <[email-masked]>
To: Calsify <[email-masked]>
Subject: [Ietf-calsify] DTEND for day events
Reply-To: [email-masked]

------=_Part_2093_525179.1125598086456
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

rfc2445 is unclear if the DTEND is inclusive or exclusive when both the=20
DTSTART and DTEND are DATEs.

------=_Part_2093_525179.1125598086456
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

rfc2445 is unclear if the DTEND is inclusive or exclusive when both the DTS=
TART and DTEND are DATEs.<br>

------=_Part_2093_525179.1125598086456--