Subject: [Ietf-calsify] Recurrence rule - COUNT ]/ UNTIL vs RDATE

From: Doug at Royer.com (Doug Royer)
Date: Sat Jan 29 13:40:23 2005

With bounded recurrences, how about in itip-next we deprecace UNTIL and 
COUNT?

No real point as they can be replaced with a list of RDATE.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)612-4638
http://Royer.com               | Fax:    (866)594-8574
                                | Cell:   (208)520-4044

               We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050129/f3808ac0/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Jan 31 12:45:29 2005

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050131/67587be8/smime.bin

Date: Mon, 31 Jan 2005 13:45:11 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Recurrence rule - COUNT  ]/ UNTIL vs RDATE
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean

This is a cryptographically signed message in MIME format.

--------------ms050000010605050300060609
Content-Type: multipart/mixed; boundary="------------030309010503080305040608"

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

Sorry - I was asleep at the computer when I wrote this - dumb idea as 
pointed out to me on an IRC channel.

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

-- 

--------------030309010503080305040608
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-Consuiting.com
adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-612-4638
tel;fax:866-494-8574
tel;cell:208-520-4044
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------030309010503080305040608--

--------------ms050000010605050300060609
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

--------------ms050000010605050300060609--

Date: Sat, 29 Jan 2005 14:40:09 -0700
From: Doug Royer <[email-masked]>
To: [email-masked]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
Subject: [Ietf-calsify] Recurrence rule - COUNT  ]/ UNTIL vs RDATE
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms040107030007040501010300
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

-- 

--------------ms040107030007040501010300
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

--------------ms040107030007040501010300--

Date: Mon, 17 Jan 2005 12:12:48 -0700
From: Doug Royer <[email-masked]>
To: Jonathan Lennox <[email-masked]>
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: [email-masked], CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Re: IANA  Time Zone Registration
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 17 Jan 2005 19:13:28 -0000

This is a cryptographically signed message in MIME format.

--------------ms030108000109080403050606
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Thank you - I just sent the email.

Jonathan Lennox wrote:
> On Sunday, January 16 2005, "Doug Royer" wrote to "[email-masked], [email-masked], CalDAV DevList" saying:
> 
> 
>>A couple of years ago there was talk on the CALSCH mailing list
>>to have an IANA time zone registration process. I have submitted
>>a proposal for that registry to the IETF.
> 
> 
> This proposal should also be shared with the TZ mailing list,
> <[email-masked]>.
> 
> I note that your list of time zone names is out of date with respect
> to the current version of tzdata (2005b).
> 

-- 

--------------ms030108000109080403050606
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

--------------ms030108000109080403050606--

From: Jonathan Lennox <[email-masked]>
Date: Mon, 17 Jan 2005 12:40:11 -0500
To: Doug Royer <[email-masked]>
Cc: [email-masked], CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Re: IANA  Time Zone Registration

On Sunday, January 16 2005, "Doug Royer" wrote to "[email-masked], [email-masked], CalDAV DevList" saying:

> A couple of years ago there was talk on the CALSCH mailing list
> to have an IANA time zone registration process. I have submitted
> a proposal for that registry to the IETF.

This proposal should also be shared with the TZ mailing list,
<[email-masked]>.

I note that your list of time zone names is out of date with respect
to the current version of tzdata (2005b).

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu

Date: Sun, 16 Jan 2005 16:10:45 -0700
From: Doug Royer <[email-masked]>
To: "[email-masked]" <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
Subject: [Ietf-calsify] IANA  Time Zone Registration
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Sun, 16 Jan 2005 23:10:55 -0000

This is a cryptographically signed message in MIME format.

--------------ms040804090802090308080209
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

]
A couple of years ago there was talk on the CALSCH mailing list
to have an IANA time zone registration process. I have submitted
a proposal for that registry to the IETF.

A copy can be found at:

	http://inet-consulting.com/draft-royer-timezone-registry-00.txt

And an HTML version:

	http://inet-consulting.com/draft-royer-timezone-registry-00.html

I am adding the POLYGON property targeted for the -01 version
that has an ADD/DELETE parameter to allow for the optional
inclusion of latitude/longitude geographic areas to be included
that include (add) and exclude (delete) areas from the time zone
geographic region (again from the CALSCH mailing list discussions).

-- 

--------------ms040804090802090308080209
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

--------------ms040804090802090308080209--

Date: Sun, 16 Jan 2005 14:11:43 -0700
From: Doug Royer <[email-masked]>
To: "[email-masked]" <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
Subject: [Ietf-calsify] draft-royer-ical-basic-01.txt - sent to IETF
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Sun, 16 Jan 2005 21:12:11 -0000

This is a cryptographically signed message in MIME format.

--------------ms010605090304020907010903
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I send -01 of iCal-Basis to the IETF. It fixed some problems and
typos that were sent to me and the lists. It also deprecates DTEND and
replaced the examples and ABNF with DURATION.

Copy at:

	http://inet-consulting.com/draft-royer-ical-basic-01.txt

And HTML version at:

	http://inet-consulting.com/draft-royer-ical-basic-01.html
	
-- 

--------------ms010605090304020907010903
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

--------------ms010605090304020907010903--

Date: Mon, 10 Jan 2005 14:06:01 -0700
From: Doug Royer <[email-masked]>
To: "[email-masked]" <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
Subject: [Ietf-calsify] [Fwd: I-D ACTION:draft-royer-ical-basic-00.txt]
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 10 Jan 2005 21:06:20 -0000

This is a cryptographically signed message in MIME format.

--------------ms040000010404040105070301
Content-Type: multipart/mixed; boundary="------------090801060904050606000008"

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

FYI

-------- Original Message --------
Subject: I-D ACTION:draft-royer-ical-basic-00.txt
Date: Mon, 03 Jan 2005 15:40:02 -0500
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Basic Internet Calendaring and Scheduling Core
			  Object Specification (iCalendar Basic)
	Author(s)	: D. Royer
	Filename	: draft-royer-ical-basic-00.txt
	Pages		: 104
	Date		: 2005-1-3
	
This is the second release of a iCalendar.  After having learned from
    RFC-2445.  This document represents the common objects needed for
    calendaring.  VTODO, VJOURNAL, VTIMEZONE, recurrence rules, and
    scheduling and their associated properties have been removed.  These
    removals are expected to appear in new memos at a later time and will
    be independent extensions of this specification.  The new EXTENSIONS
    property will exist to allow for compatible sets of extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-royer-ical-basic-00.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-royer-ical-basic-00.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-royer-ical-basic-00.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.

-- 

--------------090801060904050606000008
Content-Type: Message/External-body;
 name="draft-royer-ical-basic-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-royer-ical-basic-00.txt"

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

--------------090801060904050606000008
Content-Type: text/plain;
 name="file:///tmp/nsmail.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="file:///tmp/nsmail.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------------090801060904050606000008--

--------------ms040000010404040105070301
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

--------------ms040000010404040105070301--

Date: Sat, 08 Jan 2005 21:40:58 -0700
From: Doug Royer <[email-masked]>
To: [email-masked]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] iCal and DTEND/DURATION
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Sun, 09 Jan 2005 04:41:10 -0000

This is a cryptographically signed message in MIME format.

--------------ms010104050404010609040504
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Reinhold Kainhofer wrote:
> Am Sonntag, 9. Januar 2005 02:19 schrieb Doug Royer:
> 
>>>I think it's really best to have DTSTART+DURATION in iCal-Basic, and in
>>>iCal-Extended we need to allow DTSTART+DTEND (since it makes a difference
>>>with recurring event).
>>
>>I am still not convinced that it results in any different block of time
>>to the ATTENDEEs that got your iCalendar object. Everyone would still
>>show up at the same time and expect to leave at the same time relative
>>to each other.
> 
> 
> No, it makes a difference. See my two examples. The group which uses 
> DTSTART+DURATION+recurrence would expect that the event ends one hour 
> earlier/later than the group that uses DTSTART+DURATION+recurrence. Of course 
> only if a DST shift happens while the event takes place (yes, that's a 
> borderline case, but a standard that works only in 99% of all cases is 
> useless. So ical-extended needs to specify it).
> 

( it has been a long day for me, so pleas double check this!!)

To see this you have to compare instances in UTC and you will
see they always match this:

   end-time-UTC - start-time-UTC always == DURATION.

Assuming they did the RECURRENCE-ID per iTIP and you are given
the DTSTART and DTEND and the TZID parameter is "TZ-X'.

   start_tzoffset for DTEND is (-7 per TZ-X)
   end_tzoffset for DTSTART is (-7 per TZ-X)

   recurrence_id_tzoffset for RECURRENCE-ID is (-6 per TZ-X)
   (because the instance time is across a time zone DST change).

   orignal_end_time_utc = DTEND +  end_tzoffset.

   original_start_time_utc = DTSTART + start_tzoffset.

   recurr_id_start_time_utc = RECURRENCE-ID + recurrence_id_tzoffset.

   Then,

     event_duration = original_end_time_utc - original_start_time_utc

   Now as the RECURRENCE-ID is the start time of the instance, so

   instance_start_time_utc = recur_id_start_time_utc

   instance_end_time_utc = instance_start_time_utc + event_duration.

   If the duration  of the ORIGINAL instance is computed in UTC
   and you use iTIP RECURRENCE-ID values, the above math always
   works and dtend - dtstart == duration even when to the casual
   observer the values to the right of the COLON for DTSTART and
   DTEND do not.

   They always equal!

Now if you do what a couple of vendors do and ALWAYS set the 
RECURRENCE-ID value equal to the DTSTART value (not per iTIP), then
the following math will show they are always equal.

Often they do the math only with the instance and not the original iTIP 
object, so that is how I will do the math.

   start_tzoffset for DTSTART is (-7 per TZ-X)
   (They toss the original DTSTART and replace it with the
   instance start time.)

   end_tzoffset for DTEND is (-6 per TZ-X)
   (They toss the original DTEND and replace it with the
   computed end time of the instance.)

   And recurrence_id_tzoffset for RECURRENCE-ID exactly the same
   as the start_tzoffset (because they always set RECURRENCE-ID
   equal to DTSTART).

   instance_end_time_utc = DTEND +  end_tzoffset.

   instance_start_time_utc = DTSTART + start_tzoffset.

   recurr_id_start_time_utc = instance_start_time_utc
   (Because they always set it to the DTSTART value).

   Then event_duration = instance_end_time_utc - instance_start_time_utc

   So is always true that (because the live above this is the same
   formula.)

     instance_end_time_utc - instance_start_time_utc == event_duration.

A GUI has to do the correct thing and stretch the GUI, show two 2-AM's
or drop 2-AM (or whenever your time zone change). However the data
when compared in UTC always matches.

It appears to fail because:

   instance_DTEND_in_tz_X - instance_DTSTART_in_tz_X  !=  DURATION

   (4am - 1am == 3 hours,  EXCEPT on nights when the time changes)

However the following is always true:

   instance_DTEND_in_utc - instance_DTSTART_in_utc == DURATION

> 
>>If your talking about an appointment for which there is never going to
>>be a  PUBLISH or REQUEST sent, then the point is moot as you are always
>>free to store your data that is not going to be sent to someone else any
>>way you wish.
> 
> 
> Ahm, are we talking about a revision of RFC 2445 or only of 2446? 

There is no document, draft, or RFC that I am aware of that talks
about how to exchange non-iTIP (2446) iCalendar objects.

> 
> iCalendar (2445) is not only a format for group scheduling, but a general 
> format for calendar data exchange. In particular, lots of calendaring 
> applications use iCalendar as their standardized storage format (actually, 
> all larger free/open source software packages, like KOrganizer, Evolution, 
> Mozilla sunbird; and also Apple's iCal), which is very important for 
> interopability and data im/export! 

It may be used that way. It is not per spec. That is why some
implementations use the ABNF in 2445 and create objects with
property and parameter values that can not be exchanged without error.
The core specification (2445) specifies many of the permutations of
objects, not how to put them together to exchange calendaring information.

2446 is the 'iCalendar Transport-Independent Interoperability Protocol'.

> 
> So, in other words, rfc2445 defines a general calendar format that can and 
> should be used for moving calendar data across applications systems  
> (im-/export, or only drag'n'dropping calendar data, or simply storing 
> calendar data).

No, 2445 specifies the data format, not the exchange protocol.
If you look you can find many objects that you can create with 2445
that are bogus. It is not meant as a specification for exchanging data
between vendors, that is iTIP's job. Your talking about iTIP PUBLISH
which is the non-scheduling way to transport an object and say 'here it 
is', use it or not.

> The second paragraph states that it also provides the definitions for 
> scheduling, but the wording implies for me that the rfc is mainly meant to be 
> used as a calendar storage format. rfc 2446 talks about how the storage 
> format defined in 2445 can be used for scheduling.

There has not been a draft or RFC that talks about storage format.
That was specifically off-topic.

> 
> The same wording can also be found in your draft. So, in your draft you say 
> that ical-Basic is meant as a format to exchange data (not necessarily 
> scheduling) between apps or systems (which means it's meant also for example 
> to copy your whole calendar to another computer and just use that file there. 
> From your draft: "allows for the capture and exchange of information normally 
> stored within a calendaring and scheduling application; such as a Personal 
> Information Manager (PIM)"), while in your mail you state it's only about 
> scheduling. 

Much of the text comes from 2445. And yes iCal-Basic is meant to find
and fix the holes in the usage. I'll add that one to the list.

> If iCal-Basic is just about scheduling, wouldn't this also run counter to the 
> introduction, where you (and the original rfc) talk about enhancing 
> interopability? 
> 

iCal-Basic is not about scheduling at all.
That will be iTIP-Basic - that where the fun starts.

iCal-Basic is about tossing 2445 core objects in the trash that are
miss used, busted, or never used.

-- 

--------------ms010104050404010609040504
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

--------------ms010104050404010609040504--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] iCal-Basic - draft 00
Date: Sun, 9 Jan 2005 04:01:06 +0100

--nextPart1949890.As98Rs1nTP
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Sonntag, 9. Januar 2005 02:19 schrieb Doug Royer:
> > I think it's really best to have DTSTART+DURATION in iCal-Basic, and in
> > iCal-Extended we need to allow DTSTART+DTEND (since it makes a differen=
ce
> > with recurring event).
>
> I am still not convinced that it results in any different block of time
> to the ATTENDEEs that got your iCalendar object. Everyone would still
> show up at the same time and expect to leave at the same time relative
> to each other.

No, it makes a difference. See my two examples. The group which uses=20
DTSTART+DURATION+recurrence would expect that the event ends one hour=20
earlier/later than the group that uses DTSTART+DURATION+recurrence. Of cour=
se=20
only if a DST shift happens while the event takes place (yes, that's a=20
borderline case, but a standard that works only in 99% of all cases is=20
useless. So ical-extended needs to specify it).

> If your talking about an appointment for which there is never going to
> be a  PUBLISH or REQUEST sent, then the point is moot as you are always
> free to store your data that is not going to be sent to someone else any
> way you wish.

Ahm, are we talking about a revision of RFC 2445 or only of 2446?=20

iCalendar (2445) is not only a format for group scheduling, but a general=20
format for calendar data exchange. In particular, lots of calendaring=20
applications use iCalendar as their standardized storage format (actually,=
=20
all larger free/open source software packages, like KOrganizer, Evolution,=
=20
Mozilla sunbird; and also Apple's iCal), which is very important for=20
interopability and data im/export!=20

Also note that RFC 2445 does explicitly say that it is meant not only as a=
=20
format for scheduling, but for general calendar data interopability. In=20
particular, from the Introduction of rfc2445:

   The iCalendar format is suitable as an exchange format between
   applications or systems. The format is defined in terms of a MIME
   content type. This will enable the object to be exchanged using
   several transports, including but not limited to SMTP, HTTP, a file
   system, desktop interactive protocols such as the use of a memory-
   based clipboard or drag/drop interactions, point-to-point
   asynchronous communication, wired-network transport, or some form of
   unwired transport such as infrared might also be used.

   The memo also provides for the definition of iCalendar object methods
   that will map this content type to a set of messages for supporting
   calendaring and scheduling operations such as requesting, replying

So, in other words, rfc2445 defines a general calendar format that can and=
=20
should be used for moving calendar data across applications systems =20
(im-/export, or only drag'n'dropping calendar data, or simply storing=20
calendar data).
The second paragraph states that it also provides the definitions for=20
scheduling, but the wording implies for me that the rfc is mainly meant to =
be=20
used as a calendar storage format. rfc 2446 talks about how the storage=20
format defined in 2445 can be used for scheduling.

The same wording can also be found in your draft. So, in your draft you say=
=20
that ical-Basic is meant as a format to exchange data (not necessarily=20
scheduling) between apps or systems (which means it's meant also for exampl=
e=20
to copy your whole calendar to another computer and just use that file ther=
e.=20
=46rom your draft: "allows for the capture and exchange of information norm=
ally=20
stored within a calendaring and scheduling application; such as a Personal=
=20
Information Manager (PIM)"), while in your mail you state it's only about=20
scheduling.=20

If iCal-Basic is just about scheduling, wouldn't this also run counter to t=
he=20
introduction, where you (and the original rfc) talk about enhancing=20
interopability?=20

Or do I misunderstand anything about your goals?

Cheers,
Reinhold

=2D-=20
=2D-----------------------------------------------------------------
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 / KPilot maintain=
er

--nextPart1949890.As98Rs1nTP
Content-Type: application/pgp-signature

--nextPart1949890.As98Rs1nTP--

Date: Sat, 08 Jan 2005 18:19:44 -0700
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] iCal-Basic - draft 00
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Sun, 09 Jan 2005 01:19:56 -0000

This is a cryptographically signed message in MIME format.

--------------ms020807020902040908070106
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Reinhold Kainhofer wrote:
> Am Samstag, 8. Januar 2005 23:46 schrieb Doug Royer:
> 
>>Does anyone really need the first one (#1 below)? 
> 
> 
> Sure, why not? The example I gave was really just meant as an example where 
> it's easy to see the difference. I'm sure there are lots of events that are 
> defined by their end date, not their duration. E.g. if you need to catch the 
> train every morning, and you enter your sleeping time as a recurring event in 
> your calendar (because during that time you want your f/b list to show you as 
> busy, or for some other reason). 
>

Your GUI might do that for you, however I can still calculate one
from the other - so I am not convinced that when we send an iCalendar
object to another CUA, that it cares why we elected to select that 
length of time or end time. The chances are that it will convert it to 
its favorite way (DURATION or LENGTH) anyway.

> 
>>In addition - iCal-Basic does not have recurring rules, so
>>would DURATION be sufficient?
> 
> 
> Yes, that's a good argument. I also had a long discussion over this with Helge 
> Hess (from OpenGroupware.org).
> As long as no recurrences are involved, DTSTART and DURATION is the right 
> solution in our eyes. In particular, if you move an event, you only have to 
> adjust the DTSTART and the end date will be correct. If you used DTSTART and 
> DTEND, you'll have to adjust both if you want to move the event. 
> Additionally, if you just use the same offset to the DTSTART and the DTEND, 
> you'll again run into the same problems when the time zone shift appears 
> between these two times...

Unless someone comes up with a reason iCal-Basic-01 will drop DTEND.

> 
> I think it's really best to have DTSTART+DURATION in iCal-Basic, and in 
> iCal-Extended we need to allow DTSTART+DTEND (since it makes a difference 
> with recurring event). 

I am still not convinced that it results in any different block of time 
to the ATTENDEEs that got your iCalendar object. Everyone would still 
show up at the same time and expect to leave at the same time relative 
to each other.

If your talking about an appointment for which there is never going to 
be a  PUBLISH or REQUEST sent, then the point is moot as you are always 
free to store your data that is not going to be sent to someone else any 
way you wish.

-- 

--------------ms020807020902040908070106
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

--------------ms020807020902040908070106--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] iCal-Basic - draft 00
Date: Sun, 9 Jan 2005 01:58:06 +0100

--nextPart9794832.JYhHsSTT6x
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Samstag, 8. Januar 2005 23:46 schrieb Doug Royer:
> Does anyone really need the first one (#1 below)?=20

Sure, why not? The example I gave was really just meant as an example where=
=20
it's easy to see the difference. I'm sure there are lots of events that are=
=20
defined by their end date, not their duration. E.g. if you need to catch th=
e=20
train every morning, and you enter your sleeping time as a recurring event =
in=20
your calendar (because during that time you want your f/b list to show you =
as=20
busy, or for some other reason).=20

> In addition - iCal-Basic does not have recurring rules, so
> would DURATION be sufficient?

Yes, that's a good argument. I also had a long discussion over this with He=
lge=20
Hess (from OpenGroupware.org).
As long as no recurrences are involved, DTSTART and DURATION is the right=20
solution in our eyes. In particular, if you move an event, you only have to=
=20
adjust the DTSTART and the end date will be correct. If you used DTSTART an=
d=20
DTEND, you'll have to adjust both if you want to move the event.=20
Additionally, if you just use the same offset to the DTSTART and the DTEND,=
=20
you'll again run into the same problems when the time zone shift appears=20
between these two times...

I think it's really best to have DTSTART+DURATION in iCal-Basic, and in=20
iCal-Extended we need to allow DTSTART+DTEND (since it makes a difference=20
with recurring event).=20

Cheers,
Reinhold
=2D-=20
=2D-----------------------------------------------------------------
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 / KPilot maintain=
er

--nextPart9794832.JYhHsSTT6x
Content-Type: application/pgp-signature

--nextPart9794832.JYhHsSTT6x--

Date: Sat, 08 Jan 2005 15:46:35 -0700
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] iCal-Basic - draft 00
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Sat, 08 Jan 2005 22:46:43 -0000

This is a cryptographically signed message in MIME format.

--------------ms060809090908040503010208
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

There are two effects - I agree.

Does anyone really need the first one (#1 below)? Or did they really
want a DURATION ? Having worked 3rd shift in he past, I still
only worked 8 hours, no more, no less. Do people have their 3rd
shift work one hour shorter/longer? I'll bet they still work
DTSTART + DURATION and just make sure everyone knows what time
the clock will say at the end.

In addition - iCal-Basic does not have recurring rules, so
would DURATION be sufficient?

Reinhold Kainhofer wrote:
> Am Samstag, 8. Januar 2005 18:39 schrieb Doug Royer:
> 
>>I know that there was a large debate on having both DURATION
>>and DTEND years ago that resulted in 2445. Now that we are trying
>>to simplify down to  the basics. Can we pick just one?
>>
>> DTSTART and optionally DURATION (no  DTEND in spec)
>>or
>> DTSTART and optionally DTEND. (no DURATION in spec)
> 
> 
> There's a small difference between these two. They are identical most of the 
> time, except for those two times a year when DST switches occur. If you have 
> a recurring event that falls on these switch times, you can easily see the 
> difference:
> 
> 1) You have nightshifts from 22:00 until 06:00 every day, so when the DST 
> switch happens, your nightshift will be one hour longer/shorter than the 
> usual 8 hours. => DTSTART and DTEND needed
> 
> 2) On the other hand, if you need to operate a machine or some other 
> mechanical process for, say, 15 hours over night, then the date end needs to 
> differ for the night when the DST switch occurs. => DTSTART and DURATION 
> needed
> 
> Cheers,
> Reinhold
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

-- 

--------------ms060809090908040503010208
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

--------------ms060809090908040503010208--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] iCal-Basic - draft 00
Date: Sat, 8 Jan 2005 19:28:27 +0100

--nextPart1746318.8LJWONkWeH
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Samstag, 8. Januar 2005 18:39 schrieb Doug Royer:
> I know that there was a large debate on having both DURATION
> and DTEND years ago that resulted in 2445. Now that we are trying
> to simplify down to  the basics. Can we pick just one?
>
>  DTSTART and optionally DURATION (no  DTEND in spec)
> or
>  DTSTART and optionally DTEND. (no DURATION in spec)

There's a small difference between these two. They are identical most of th=
e=20
time, except for those two times a year when DST switches occur. If you hav=
e=20
a recurring event that falls on these switch times, you can easily see the=
=20
difference:

1) You have nightshifts from 22:00 until 06:00 every day, so when the DST=20
switch happens, your nightshift will be one hour longer/shorter than the=20
usual 8 hours. =3D> DTSTART and DTEND needed

2) On the other hand, if you need to operate a machine or some other=20
mechanical process for, say, 15 hours over night, then the date end needs t=
o=20
differ for the night when the DST switch occurs. =3D> DTSTART and DURATION=
=20
needed

Cheers,
Reinhold

--nextPart1746318.8LJWONkWeH
Content-Type: application/pgp-signature

--nextPart1746318.8LJWONkWeH--

Date: Sat, 08 Jan 2005 10:39:02 -0700
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] iCal-Basic - draft 00
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Sat, 08 Jan 2005 17:39:15 -0000

This is a cryptographically signed message in MIME format.

--------------ms090007060100090304020706
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I know that there was a large debate on having both DURATION
and DTEND years ago that resulted in 2445. Now that we are trying
to simplify down to  the basics. Can we pick just one?

	DTSTART and optionally DURATION (no  DTEND in spec)

or

	DTSTART and optionally DTEND. (no DURATION in spec)

This is an data format for exchanging calendar information, it has
nothing to do with how any implementation stores the data. Is the
reason that both existed because the WG could not decide? Or
was there another reason?

-- 

--------------ms090007060100090304020706
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

--------------ms090007060100090304020706--