Dave Thewlis | 3 Oct 21:40 2005

Results from CalConnect Timezone Questionnaire

TC-TIMEZONE, the TIMEZONE Technical Committee of the Calendaring and Scheduling Consortium, has published the results of the Timezone Questionnaire it conducted earlier
this year. The document is available on the CalConnect web site at http://www.calconnect.org/publications/resultsfrom timezonequestionnairev1.0.pdf or by going to http://www.calconnect.org and selecting "Work Products" from the sidebar index.
--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis <at> calconnect.org
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Dave Thewlis | 3 Oct 22:26 2005

Error in link to Timezone Questionnaire Results Document

I made an error in transcribing the URL to the Timezone Questionnaire Results document in my previous posting.  The correct link is:

http://www.calconnect.org/publications/resultsfromtimezonequestionnairev1.0.pdf.

You may also retrief the document by going to http://www.calconnect.org and selecting "Work Products" from the sidebar.

Apologies,

Dave Thewlis
--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis <at> calconnect.org
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Doug Royer | 4 Oct 00:12 2005

New xCal draft sent to the IETF


I have sent -02 of xCal to the IETF, copies at:

	http://inet-consulting.com/draft-royer-calsch-xcal-02.txt
	http://inet-consulting.com/draft-royer-calsch-xcal-02.html
	http://inet-consulting.com/draft-royer-calsch-xcal-02.xml

Namespace to urn:ietf:params:xml:ns:xcal

I removed unneeded namespace prefixes in examples.

The iCalendar LANGUAGE parameter is now xml:lang

I specified, standard XML encoding, rather than
specifically sayiing 'entity' encoding.

I updated the XSLT (xml -> iCal translator) on SourceForge
(http://sourceforge.net/projects/icalendar/) to translate
xml:lang -> LANGUAGE.

--

-- 

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

               We Do Standards - You Need Standards

Attachment (Doug.vcf): text/x-vcard, 332 bytes
Attachment (smime.p7s): application/x-pkcs7-signature, 6127 bytes
_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Jeffrey Harris | 4 Oct 01:41 2005

What is the appropriate serialization for a recurring event with one event changed?

Hi Folks,

I've been working a bit with Oracle's CalDAV server and Apple's iCal,
and they have pretty different behaviors when serializing a recurring
event with a change to one event.

Lets take, for example, a daily event, starting Monday at 9AM, last
occurrence Friday at 9AM.  If I change Wednesday's event to 11AM, what
should the resulting stream look like?

iCal exports this as two VEVENTs, one has (omitting lots of other lines):

DTSTART;TZID=US/Pacific:20051003T090000
RRULE:FREQ=DAILY;COUNT=5

the other VEVENT has

RECURRENCE-ID:20051005T160000Z          #Wednesday at 9AM PDT (in UTC)
DTSTART;TZID=US/Pacific:20051005T110000 #Wednesday at 11AM PDT

Oracle's stream also has two VEVENTs:

DTSTART;TZID=US/Pacific:20051003T090000
RRULE:FREQ=DAILY;COUNT=5
EXDATE:20051005T160000Z                #Wednesday at 9AM PDT (in UTC)

the other VEVENT has

RECURRENCE-ID:20051005T180000Z         #Wednesday at *11AM* PDT (in UTC)
DTSTART;TZID=US/Pacific:20051005T110000

Is one of these more correct than the other?  Is an EXDATE appropriate
for the original time if an event's time has been moved?  What does it
mean for a RECURRENCE-ID to reference a time that isn't already in the
recurrence set?

Sincerely,
Jeffrey
Bernard Desruisseaux | 4 Oct 03:35 2005
Picon

[Fwd: I-D ACTION:draft-dusseault-caldav-08.txt]

We submitted CalDAV draft -08 to the IETF last Friday.
It is now available at the following URL:

http://www.ietf.org/internet-drafts/draft-dusseault-caldav-08.txt

We are planning to submit a new revision in a few weeks for
an informal Last-Call on the ietf-caldav, ietf-calsify and
w3c-dist-auth (WebDAV) mailing lists before we actually submit
it to the IESG.

Please review the draft and send us feedback/questions/comments.

Thanks,
Bernard

B.1.  Changes in -08

    a.  Removed statement that said that client SHOULD always request
        DAV:getetag in calendar REPORTs.

    b.  Removed redefiniton of DAV:response.

    c.  Removed XML elements CALDAV:calendar-data-only.

    d.  Removed resource type CALDAV:calendar-home.

    e.  Moved the CALDAV:calendar-data element in the DAV:prop element in
        requests, and in the DAV:propstat element in responses.

    f.  Further defined the request body of MKCALENDAR to allow clients
        to set properties at calendar collection creation time.

    g.  Renamed CALDAV:calendar-home-URL to CALDAV:calendar-home-set

    h.  Clarified the fact that calendar collections may only contain
        calendar object resources and ordinary collections.

    i.  Clarified that calendar REPORTs should only be applied to
        calendar object resources contained in calendar collections.

    j.  Changed the CALDAV:calendar-component-restriction-set and CALDAV:
        calendar-restriction properties to always be protected.

    k.  Changed to use existing postcondition DAV:needs-privileges
        instead of a new CALDAV:insufficient-privilege postcondition.

    l.  Added example for limit-recurrence-set.

    m.  Added example for expand-recurrence-set.

    n.  Moved CALDAV:calendar-address-set in the calendar-schedule draft
        and renamed it to CALDAV:calendar-user-address-set.

    o.  Added guidelines on attachments and alarms.

-------- Original Message --------
Subject: I-D ACTION:draft-dusseault-caldav-08.txt
Date: Mon, 03 Oct 2005 15:50:02 -0400
From: Internet-Drafts <at> ietf.org
Reply-To: internet-drafts <at> ietf.org
To: i-d-announce <at> ietf.org

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

	Title		: Calendaring Extensions to WebDAV (CalDAV)
	Author(s)	: L. Dusseault, et al.
	Filename	: draft-dusseault-caldav-08.txt
	Pages		: 75
	Date		: 2005-10-3
	
This document specifies a set of methods, headers, message bodies,
    properties, and reports that define calendar access extensions to the
    WebDAV protocol.  The new protocol elements are intended to make
    WebDAV-based calendaring and scheduling an interoperable standard
    that supports calendar access, calendar management, calendar sharing,
    and calendar publishing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-dusseault-caldav-08.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org 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-dusseault-caldav-08.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:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-dusseault-caldav-08.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.

Attachment (draft-dusseault-caldav-08.txt): message/external-body, 274 bytes
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Reinhold Kainhofer | 4 Oct 09:24 2005

Re: What is the appropriate serialization for a recurring event with one event changed?


Am Dienstag, 4. Oktober 2005 01:41 schrieb Jeffrey Harris:
> Hi Folks,
>
> I've been working a bit with Oracle's CalDAV server and Apple's iCal,
> and they have pretty different behaviors when serializing a recurring
> event with a change to one event.
>
> Lets take, for example, a daily event, starting Monday at 9AM, last
> occurrence Friday at 9AM.  If I change Wednesday's event to 11AM, what
> should the resulting stream look like?
>
> iCal exports this as two VEVENTs, one has (omitting lots of other lines):
>
> DTSTART;TZID=US/Pacific:20051003T090000
> RRULE:FREQ=DAILY;COUNT=5
>
> the other VEVENT has
>
> RECURRENCE-ID:20051005T160000Z          #Wednesday at 9AM PDT (in UTC)
> DTSTART;TZID=US/Pacific:20051005T110000 #Wednesday at 11AM PDT

> Oracle's stream also has two VEVENTs:
>
> DTSTART;TZID=US/Pacific:20051003T090000
> RRULE:FREQ=DAILY;COUNT=5
> EXDATE:20051005T160000Z                #Wednesday at 9AM PDT (in UTC)
>
> the other VEVENT has
>
> RECURRENCE-ID:20051005T180000Z         #Wednesday at *11AM* PDT (in UTC)
> DTSTART;TZID=US/Pacific:20051005T110000

I think that's wrong. This RECURRENCE-ID specifies the occurrence of the RRULE 
that is changed by that VEVENT. Since Wed  11 AM PDT is not part of the 
RRULE, I'm not sure how this should be interpreted by a client... Shall it 
still occur? Or shall it simply be ignored because that RECURRENCE-ID does 
not exist in the RRULE.

The correct way is iCal's way, where no EXDATE is necessary (since the 
RECURRENCE-ID already says that that specific event on October 5 was changed 
from 9AM to 11AM).

> Is one of these more correct than the other?

Yes, iCal's is correct, I think.

> Is an EXDATE appropriate 
> for the original time if an event's time has been moved?  

No, that's not needed, since RECURRENCE-ID should give the original time of 
the occurrence.

> What does it 
> mean for a RECURRENCE-ID to reference a time that isn't already in the
> recurrence set?

That's the question... How shall clients interpret such VEVENTS?

Cheers,
Reinhold

--

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: reinhold <at> kainhofer.com, 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
Doug Royer | 4 Oct 10:09 2005

Re: What is the appropriate serialization for a recurring event with one event changed?


These are some of the reasons for iTIP-bis. We can observe
what some vendors do, we must document 'the' way it needs
to be done.

I think that both are wrong as shown, for the following reasons:

The Apple way (as you described it) is also wrong as it depends
on the iCal parser being a one pass parser (read and process in
order). A two pass parser that sorts by UID/SEQUENCE/DTSTAMP and
follows the iTIP rules may get a different answer than Apple
when SEQUENCE and DTSTAMP are the same or missing.

Apple in your example DOES NOT depend on the SEQUENCE/DTSTAMP
of objects and the METHOD.

If you have a:
	
	METHOD:REQUEST
	DTSTART;TZID=US/Pacific:20051003T090000
	RRULE:FREQ=DAILY;COUNT=5

And have a:

	METHOD:REQUEST
	SEQUENCE: <larger than above with same UID>
	RECURRENCE-ID:20051005T160000Z
	DTSTART;TZID=US/Pacific:20051005T110000

It means replace the 9am  appointment with the new value.

If they have the same SEQUENCE, then the one with the
newer DTSTAMP obsoletes the other (iTIP 2.1.5).

If no SEQUENCE is provided, the default is ZERO
and the one with the newer DTSTAMP wins as 'the' object
for that UID.

If they have different SEQUENCE values:
A CUA can process the above two METHOD:REQUESTs and
produce a valid METHOD:PUBLISH calendar that could have:

	METHOD:PUBLISH
	DTSTART;TZID=US/Pacific:20051003T090000
	RRULE:FREQ=DAILY;COUNT=5
	EXDATE:20051005T160000Z
	RDATE:;TZID=US/Pacific:20051005T110000

  -OR-

If you have a:

  	DTSTART;TZID=US/Pacific:20051003T090000
	RRULE:FREQ=DAILY;COUNT=5
	EXDATE:20051005T160000Z

And have a:

	RECURRENCE-ID:20051005T180000Z(in UTC)
	SEQUENCE: <larger than above with same UID>
	DTSTART;TZID=US/Pacific:20051005T110000

Then the sending CUA is busted, as there is no such
instance to replace

RECURRENCE-ID has little meaning in a PUBLISH calendar as there
is no ordering to objects. One parser might read them in order and
then write them sorted by UID or something. Making
the RECURRENCE-ID usless without SEQUENCE/DTSTAMP. (Perhaps your
examples had them and you did not provide them?)

 > Is one of these more correct than the other?  Is an EXDATE appropriate
 > for the original time if an event's time has been moved?  What does it
 > mean for a RECURRENCE-ID to reference a time that isn't already in the
 > recurrence set?

> I think that's wrong. This RECURRENCE-ID specifies the occurrence of the RRULE 
> that is changed by that VEVENT. Since Wed  11 AM PDT is not part of the 
> RRULE, I'm not sure how this should be interpreted by a client... Shall it 
> still occur? Or shall it simply be ignored because that RECURRENCE-ID does 
> not exist in the RRULE.

> The correct way is iCal's way, where no EXDATE is necessary (since the 
> RECURRENCE-ID already says that that specific event on October 5 was changed 
> from 9AM to 11AM).

I agree, if the SEQUENCE number in the 1st one is lower than
the SEQUENCE number in the 2nd one.

If the SEQUENCE/DTSTAMP numbers are the same (no SEQUENCE is zero and
DTSTAMP is the same), then the 2nd is simply bogus as it has no
meaning to have a RECURRENCE-ID with no previous object.

--

-- 

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

               We Do Standards - You Need Standards

Attachment (Doug.vcf): text/x-vcard, 332 bytes
Attachment (smime.p7s): application/x-pkcs7-signature, 6127 bytes
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Simon Vaillancourt | 4 Oct 16:14 2005
Picon

Re: What is the appropriate serialization for a recurring event with one event changed?

Hello Jeffrey,
   This is a bug in our product where we don't add an RDATE to the main 
event (It's already on our todo list). You should have seen something like :

DTSTART;TZID=US/Pacific:20051003T090000
RRULE:FREQ=DAILY;COUNT=5
EXDATE:20051005T160000Z                #Wednesday at 9AM PDT (in UTC)
RDATE:20051005T180000Z

the other VEVENT has

RECURRENCE-ID:20051005T180000Z         #Wednesday at *11AM* PDT (in UTC)
DTSTART;TZID=US/Pacific:20051005T110000

As far as "Is an EXDATE appropriate for the original time if an event's 
time has been moved?".  Ideally, the meeting you store on a CalDAV 
server would remain unchanged when you retrieve it later on, but when 
plugging a CalDAV interface on top of an existing calendar store(Like we 
do at Oracle) it's a different story. For the Oracle product, we 1) 
Convert the iCalendar meeting to our internal format, 2)Do a diff of 
both meeting representations and send the detected changes to our 
calendar backend.  This conversion and diff process might explain the 
differences you see between the meeting you put in and the meeting you 
retrieve later on. I'm sure many would argue that "moving" a recurrence 
vs "deleting and creating" a recurrence is very different even if the 
expanded end result in a standard calendar UI is the same,  that's why 
we're still working on perfecting our diff and conversion algorithms.

Regards,
Simon

Jeffrey Harris wrote:

>Hi Folks,
>
>I've been working a bit with Oracle's CalDAV server and Apple's iCal,
>and they have pretty different behaviors when serializing a recurring
>event with a change to one event.
>
>Lets take, for example, a daily event, starting Monday at 9AM, last
>occurrence Friday at 9AM.  If I change Wednesday's event to 11AM, what
>should the resulting stream look like?
>
>iCal exports this as two VEVENTs, one has (omitting lots of other lines):
>
>DTSTART;TZID=US/Pacific:20051003T090000
>RRULE:FREQ=DAILY;COUNT=5
>
>the other VEVENT has
>
>RECURRENCE-ID:20051005T160000Z          #Wednesday at 9AM PDT (in UTC)
>DTSTART;TZID=US/Pacific:20051005T110000 #Wednesday at 11AM PDT
>
>Oracle's stream also has two VEVENTs:
>
>DTSTART;TZID=US/Pacific:20051003T090000
>RRULE:FREQ=DAILY;COUNT=5
>EXDATE:20051005T160000Z                #Wednesday at 9AM PDT (in UTC)
>
>the other VEVENT has
>
>RECURRENCE-ID:20051005T180000Z         #Wednesday at *11AM* PDT (in UTC)
>DTSTART;TZID=US/Pacific:20051005T110000
>
>Is one of these more correct than the other?  Is an EXDATE appropriate
>for the original time if an event's time has been moved?  What does it
>mean for a RECURRENCE-ID to reference a time that isn't already in the
>recurrence set?
>
>Sincerely,
>Jeffrey
>_______________________________________________
>Ietf-calsify mailing list
>Ietf-calsify <at> osafoundation.org
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>  
>
Mike Douglass | 6 Oct 15:33 2005
Picon

Specifying language

I was looking into maintaining different language values in the calendar 
so we could have something like that given as an example in the rfc

     LOCATION;LANGUAGE=en:Germany
     LOCATION;LANGUAGE=no:Tyskland

Is it possible/legal to deliver two locations given that location should 
only appear once in an event? Likewise for any other text field.

--

-- 

Mike Douglass                           douglm <at> rpi.edu
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
Lisa Dusseault | 11 Oct 19:59 2005

<1 week to draft deadline


We have less than one week until the new-draft deadline for Vancouver 
IETF.
http://www.ietf.org/meetings/cutoff_dates_64.html

With this in mind, CALSIFY authors may have to just make proposals 
(straw man solutions) right in the Internet-Drafts, submit that for the 
archives, and then discuss on the list and in the meeting.  Any 
proposals in the internet-drafts can then be changed in future versions 
of those drafts if necessary.

Lisa

Gmane