Subject: [Ietf-calsify] Quiet - must be good?

From: Doug at Royer.com (Doug Royer)
Date: Fri May 27 13:28:13 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/20050527/4edf0143/smime.bin

Date: Fri, 27 May 2005 14:27:56 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-calsify] Quiet - must be good?
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms000909000801060703030306
Content-Type: multipart/mixed; boundary="------------020609030701030705040505"

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

As I have not seen any issues here, I am going to update draft
iCal-Basic with the DURATION discussion here plus the other
iCal issues that were posted here.

It should be out in a week or so..

-- 

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

               We Do Standards - You Need Standards

--------------020609030701030705040505
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:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------020609030701030705040505--

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

--------------ms000909000801060703030306--

Date: Fri, 20 May 2005 13:32:50 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] Help Needed again - Questionnaire on Implementation of Timezones - Calconnect and Calsify
Reply-To: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<pre wrap="">Dear IETF-CALSIFY,

This e-mail is going to several Calendaring discussion lists, so my apologies if you get it more than once (which you probably will).

This is the second questionnaire distributed by Calconnect - The Calendaring and Scheduling Consortium - as part of our work to collect specific information on how actual C&amp;S products implement various portions of iCalendar and the related specifications.  Our TIMEZONE Technical Committee asks for your help in responding to this questionnaire to determine how Timezones are handled in actual calendaring applications.

The information collected will be analyzed and the results, with specific product identifications eliminated, will be transmitted to the incipient CALSIFY Working Group of the IETF as soon as possible.  The results will also be made generally available on the Consortium website, and will be input to Technical Committee recommendations to be formulated once the results are available.

If you are willing to help, please fill out the questionnaire below.  This is absolutely NOT limited to Consortium members; we need responses for as many products and implementations as possible for the results to be of maximum value.  

We would appreciate your response no later than 10 June 2005.

Thank you very much for your help.

<b>Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium</b>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)
<a href="http://www.calconnect.org%3E">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>

------------------------------------------------------------------------------------------
Questionnaire on Timezones in iCalendar

Introduction:

This questionnaire is being used to determine support for iCalendar
(RFC2445) timezone support. The specific sections in RFC2445 that
are being queried are:

4.6.5       Time Zone Component
4.8.2.4     Date/Time Start
4.8.3       Time Zone Component Properties
     ( and sub-sections )
4.8.5.3     Recurrence Date/Times
4.8.5.4     Recurrence Rule
4.8.7.3     Last Modified
4.8.8.1     Non-standard Properties

These may involve reference to other sections.

How to answer:

Please copy the text from the '-------' divider below to the end of
this message into a new message and address it to:

    <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;mailto:[email-masked]&gt;</a>

To fill it out:

For 'y/n/o':

    'y' means yes
    'n' means no
    'o' means other or not applicable

    Delete two letters to leave the one for your answer.
    If you have specific comments you can add about your answers,
    please do so at the end and reference the question number to which
    the comment applies.
    
For _____________________: enter text for the answer.

-------

Product Details:

P1:		Product/Implementation Name:
        
        _____________________

Components supported:

                                   Consume         Produce
Q1:     VTIMEZONE                   y/n/o           y/n/o
Q1.1:   STANDARD                    y/n/o           y/n/o
Q1.2:   DAYLIGHT                    y/n/o           y/n/o

Properties supported:
                                
        In VTIMEZONE
                                   Consume         Produce
Q2.1:   TZID                        y/n/o           y/n/o
Q2.2:   LAST-MODIFIED               y/n/o           y/n/o
Q2.3:   TZURL                       y/n/o           y/n/o
Q2.4:   XPROP                       y/n/o           y/n/o

        In STANDARD
                                   Consume         Produce
Q3.1:   DTSTART                     y/n/o           y/n/o
Q3.2:   TZOFFSETTO                  y/n/o           y/n/o
Q3.3:   TZOFFSETFROM                y/n/o           y/n/o
Q3.4:   COMMENT                     y/n/o           y/n/o
Q3.5:   RDATE                       y/n/o           y/n/o
Q3.6:   RRULE                       y/n/o           y/n/o
Q3.7:   TZNAME                      y/n/o           y/n/o
Q3.8:   XPROP                       y/n/o           y/n/o

        In DAYLIGHT
                                   Consume         Produce
Q4.1:   DTSTART                     y/n/o           y/n/o
Q4.2:   TZOFFSETTO                  y/n/o           y/n/o
Q4.3:   TZOFFSETFROM                y/n/o           y/n/o
Q4.4:   COMMENT                     y/n/o           y/n/o
Q4.5:   RDATE                       y/n/o           y/n/o
Q4.6:   RRULE                       y/n/o           y/n/o
Q4.7:   TZNAME                      y/n/o           y/n/o
Q4.8:   XPROP                       y/n/o           y/n/o

General:
    
Q5:  Do you always send DATE-TIME
     values with a timezone?         y/n/o

Q6:  Do you always send DATE-TIME
     values in UTC or floating?      y/n/o

Q7:  Do you provide a standard
     set of timezones built-in
     to your product?                y/n/o

     if yes to Q7, then
     {
Q8:     Where did you get your
        timezone definitions?
        
        _____________________
        
Q9:     How many timezone
        definitions do you have?
        
        _____________________
        
Q10:    Do you have a special
        naming scheme for TZIDs,
        and if so what is it?
        
        _____________________
        
Q11:    Do you provide a mechanism
        for updating built-in
        timezones?                  y/n/o
        
        if yes to Q11, then
        {
Q12:        Do you adjust future
            times to account for
            timezone definition
            changes?                y/n/o
        }

     }
    
Q13: Do you accept and use
     timezone definitions from
     imported iCalendar data?       y/n/o

     if yes to Q13, then
     {   
Q14:    Do you attempt to merge
        timezone definitions with the
        same TZID when importing
        iCalendar data?             y/n/o
     }
    
Q15: When exporting timezones in
     iCalendar data (either to a file
     or via iTIP) do you send the entire
     timezone definition or just the
     set of dates needed for coverage
     of the event?

     _____________________
    
Q16: Would you use timezone
     definitions from a standard
     timezone registry if one
     were created?                   y/n/o
    
Q17: What problems would be
     involved in changing a
     timezone definition if DST
     was changed at some point
     in the future?
    
     _____________________

C1:  Comments on specific answers (include Q number for cross-reference
     to original question):

     _____________________

C2:  Comments on the format and ease of use of this questionnaire:

     _____________________

C3:  Are there any additional questions we should be asking, and if
     so what are they?

     _____________________

</pre>
<br>
<div class="moz-signature"><br>
</div>
</body>
</html>

Date: Fri, 20 May 2005 13:55:31 -0400
To: "ietf-calsify-osafoundation.org" <[email-masked]>, "[email-masked]" <[email-masked]>
From: Tim Hare <[email-masked]>
Cc: 
Subject: [Ietf-calsify] draft-hare-xcalendar-03 has been published.

Draft-hare-xcalendar-03 has been made available at the Internet Drafts 
site.  This revision of the document adds some template coding to the XSLT 
example to try to quote some of the items which need to be "quoted", 
according to section 4.3.11 (which was pointed out to me by Dan Connolly of 
the W3C- Thanks Dan).  Note: these templates haven't been adequately 
tested; I ran into some delays and wanted to get the document submitted 
before -02 expired, during the same time period I had to update my Windows 
OS and lost my Java which I was using for XSLT testing. Which is all a 
long-winded way of saying "use at your own risk".

As always, I hope this draft is of some use to those contemplating XML for 
calendar items; and remember it's not intended as a standards-track 
document but as a guideline.

Tim Hare
Interested Bystander, Non-Inc. 

Date: Fri, 20 May 2005 12:15:37 +0200
From: Daniele Tiles <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] About TZID...
Reply-To: Daniele Tiles <[email-masked]>

Hi!
I'm a student graduating at the University of Bologna (Italy) and I have to 
develop a WS able to convert the lesson's timetable into an iCalendar...I've 
some problems understanding the TimeZone Identifier: I've read that 

"...Implementers may want to use the naming conventions defined in existing 
time zone specifications such as the public-domain Olson database [TZ]"

I've searched through Internet, but I'm not able to understand: do I have to 
install this database? How does it work? Where can I find the correct lists 
of TZID?
Do you think it's better to define a VTimeZone component?

Thanks to everyone

Daniele

P.S.: If someone is interested why a lesson's timetable should have a 
TZID...well, it may happen that the timetables have been defined when a 
professor is abroad for a convention...so I thought it's quite important...

P.P.S.: I've got another problem: most of the professor at my university use 
Outlook2003...and I've discovered with my mentor that some optional rfc2445 
properties are required properties for this program...do you know where I 
could find the Microsoft specification for iCalendar?

Date: Thu, 19 May 2005 11:04:48 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] Status of Calconnect Recurrence Questionnaire results, and future questionnaires
Reply-To: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<i>This message is going to all of the lists where I posted our
original request for responses to the Consortium Recurrence
Questionnaire, so many of you will see it more than once.&nbsp; My apologies
for the duplications.<br>
</i><br>
At the beginning of April, Calconnect - The Calendaring and Scheduling
Consortium - distributed a questionnaire on Recurrence implementations,
and more recently I posted an update saying that we hoped to publish
our results soon.<br>
<br>
We've delayed publishing because we are still waiting for a couple of
promised responses which will add considerably to the value of our
results, but we have decided we have to cutoff by next Friday the
27th.&nbsp; So I expect to have the results ready in early June, following
the Calconnect Roundtable meeting at Duke University at the beginning
of June.&nbsp; I will distribute yet another note when the results are
available telling everyone where to find them.<br>
<br>
Meantime, we have our second questionnaire ready to go and I'll be
posting it later today.&nbsp; This one is on Timezones, and we certainly
hope everyone will be as helpful in responding to this questionnaire as
they were for our Recurrence questionnaire.&nbsp; <br>
<br>
We're trying something different this time: the questionnaire is being
distributed in e-mail format so it can be answered offline and
responded to via e-mail as well.&nbsp; We hope that, in your comments, you
will tell us how useful the e-mail format is as opposed to the
web-based form we used for the first questionnaire.<br>
<br>
Once again, we would like to thank everyone on these discussion lists,
and especially everyone who responded to our Recurrence questionnaire.&nbsp;
<br>
<br>
Best regards,<br>
<br>
Dave Thewlis<br>
<br>
<div class="moz-signature">-- <br>
<b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org%3E">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</div>
</body>
</html>

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ?
Date: Sat, 14 May 2005 02:44:01 +0200

--nextPart3994635.n2XghWykIc
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Samstag, 14. Mai 2005 01:30 schrieb Sam Roberts:
> Quoting [email-masked], on Thu, May 12, 2005 at 05:48:30PM -0700:
> > Well I tried MacOSX iCal.app 1.5.5 (v670) and was disheartened to learn
> > that it looks like it has NO SUPPORT FOR RDATE.  :(
> >
> > I'm beginning to understand the pain some of the veterans of this list
> > have been dealing with.
>
> Some of those veterans are trying to deprecate RRULE (which iCal.app
> does support) in favor of always using RDATE. Its not clear that this
> will cause a decrease in pain.

KOrganizer also doesn't support RDATE (it simply doesn't fit the typical=20
recurrence pattern that an ordinary user would use).

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

--nextPart3994635.n2XghWykIc
Content-Type: application/pgp-signature

--nextPart3994635.n2XghWykIc--

Date: Fri, 13 May 2005 17:37:34 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ?
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms070508050601000903090102
Content-Type: multipart/mixed; boundary="------------030907070709040808040800"

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

Sam Roberts wrote:
> Quoting [email-masked], on Thu, May 12, 2005 at 05:48:30PM -0700:
> 
>>Well I tried MacOSX iCal.app 1.5.5 (v670) and was disheartened to learn 
>>that it looks like it has NO SUPPORT FOR RDATE.  :(
>>
>>I'm beginning to understand the pain some of the veterans of this list 
>>have been dealing with.
> 
> 
> Some of those veterans are trying to deprecate RRULE (which iCal.app
> does support) ...

However not fully, so no, they do not support RRULE, they support
part of RRULE as defined in 2445/2446

> ... in favor of always using RDATE. Its not clear that this
> will cause a decrease in pain.

-- 

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

               We Do Standards - You Need Standards

--------------030907070709040808040800
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:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------030907070709040808040800--

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

--------------ms070508050601000903090102--

Date: Fri, 13 May 2005 19:30:39 -0400
From: Sam Roberts <[email-masked]>
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ?
Mail-Followup-To: Calsify <[email-masked]>

Quoting [email-masked], on Thu, May 12, 2005 at 05:48:30PM -0700:
> Well I tried MacOSX iCal.app 1.5.5 (v670) and was disheartened to learn 
> that it looks like it has NO SUPPORT FOR RDATE.  :(
> 
> I'm beginning to understand the pain some of the veterans of this list 
> have been dealing with.

Some of those veterans are trying to deprecate RRULE (which iCal.app
does support) in favor of always using RDATE. Its not clear that this
will cause a decrease in pain.

Cheers,
Sam

Date: Thu, 12 May 2005 22:33:38 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ?
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms050709000301000303020503
Content-Type: multipart/mixed; boundary="------------010904090607040609050300"

This is a multi-part message in MIME format.
--------------010904090607040609050300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Yes - that is the way the IETF works. Make a firm proposal
and you find the truth! :-)

> Reinhold said something that made it immediately obvious to me why this=
=20
> made sense.
>=20
> On May 12, 2005, at 3:53 PM, Reinhold Kainhofer wrote:
>=20
>> Am Freitag, 13. Mai 2005 00:42 schrieb Tantek =C7elik:
>>
>>> The spec says that exact RRULE/RDATE event instance duplicates are
>>> supposed to be tossed, but says nothing about having the same meeting=

>>> take place twice at the same time which makes no sense.  Why is it
>>> useful for the spec to allow this?
>>
>>
>> Because an event is not neccessarily a meeting, where you can only att=
end
>> once...
>>
>> Reinhold
>=20
>=20
> Thanks Reinhold.  Your explanation made me think of the following examp=
le:
>=20
> A museum tour that leaves on the hour every hour while the museum is=20
> open, from the information desk, and lasts two hours, with the last one=
=20
> of the day leaving two hours before the museum closing time.
>=20
> Doug, what do you think, would that be a reasonable use of overlapping =

> repeating event times?

--=20

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

               We Do Standards - You Need Standards

--------------010904090607040609050300
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:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------010904090607040609050300--

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

--------------ms050709000301000303020503--

From: =?ISO-8859-1?Q?Tantek_=C7elik?= <[email-masked]>
Subject: Re: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ?
Date: Thu, 12 May 2005 17:48:30 -0700
To: Calsify <[email-masked]>

Thanks for the answers Doug.  Some follow up below.

On May 12, 2005, at 5:29 PM, Doug Royer wrote:

>
>
> Tantek Çelik wrote:
>> But look at the times.
>> The first instance overlaps the other two entirely.
>> Are you saying that is valid?
>
> Yes.
>
>> And if so, how is a CUA possibly expected to represent that in some 
>> meaningful form to the user?
>
> Odd - yes. Valid - yes.
>
>> Warn them that two or more instances of the same meeting are 
>> occurring at the same time?
>
> That's up to the CUA.
>
>> The spec says that exact RRULE/RDATE event instance duplicates are 
>> supposed to be tossed, but says nothing about having the same meeting 
>> take place twice at the same time which makes no sense.  Why is it 
>> useful for the spec to allow this?
>
> I do not recall there being a discussion on this topic.
>
> Might be a good discussion.
>
> Where iCal-Basic says (4.10.3  Recurrence Date/Times,
> page 82):
>
>
>   ...Where duplicate instances are generated by the "RDATE"
>   properties, only one recurrence is considered. ...
>
>
> If iCal-Basic said:
>
>   ...Where duplicate instances are generated by the "RDATE"
>   properties, only one recurrence is considered.
>   All instance times in a "VEVENT" component with the
>   same "UID" property value MUST NOT overlap each other.
>   ...
>
> (I need to spend more time on the exact language)
>
> Would anyone object?

Reinhold said something that made it immediately obvious to me why this 
made sense.

On May 12, 2005, at 3:53 PM, Reinhold Kainhofer wrote:

> Am Freitag, 13. Mai 2005 00:42 schrieb Tantek Çelik:
>> The spec says that exact RRULE/RDATE event instance duplicates are
>> supposed to be tossed, but says nothing about having the same meeting
>> take place twice at the same time which makes no sense.  Why is it
>> useful for the spec to allow this?
>
> Because an event is not neccessarily a meeting, where you can only 
> attend
> once...
>
> Reinhold

Thanks Reinhold.  Your explanation made me think of the following 
example:

A museum tour that leaves on the hour every hour while the museum is 
open, from the information desk, and lasts two hours, with the last one 
of the day leaving two hours before the museum closing time.

Doug, what do you think, would that be a reasonable use of overlapping 
repeating event times?

>> How do implementations handle/display/edit this VEVENT?
>
> You would have to try different CUA's to find out.

Well I tried MacOSX iCal.app 1.5.5 (v670) and was disheartened to learn 
that it looks like it has NO SUPPORT FOR RDATE.  :(

I'm beginning to understand the pain some of the veterans of this list 
have been dealing with.

Tantek

--
Tantek Çelik
Senior Technologist, Technorati, Inc.
[email-masked]

Date: Thu, 12 May 2005 18:29:38 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ?
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms080208000204010701000702
Content-Type: multipart/mixed; boundary="------------050301080705040602080602"

This is a multi-part message in MIME format.
--------------050301080705040602080602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Tantek =C7elik wrote:
> But look at the times.
>=20
> The first instance overlaps the other two entirely.
>=20
> Are you saying that is valid?

Yes.

> And if so, how is a CUA possibly expected to represent that in some=20
> meaningful form to the user?

Odd - yes. Valid - yes.

> Warn them that two or more instances of the same meeting are occurring =

> at the same time?

That's up to the CUA.

> The spec says that exact RRULE/RDATE event instance duplicates are=20
> supposed to be tossed, but says nothing about having the same meeting=20
> take place twice at the same time which makes no sense.  Why is it=20
> useful for the spec to allow this?

I do not recall there being a discussion on this topic.

Might be a good discussion.

Where iCal-Basic says (4.10.3  Recurrence Date/Times,
page 82):

   ...Where duplicate instances are generated by the "RDATE"
   properties, only one recurrence is considered. ...

If iCal-Basic said:

   ...Where duplicate instances are generated by the "RDATE"
   properties, only one recurrence is considered.
   All instance times in a "VEVENT" component with the
   same "UID" property value MUST NOT overlap each other.
   ...

(I need to spend more time on the exact language)

Would anyone object?

> How do implementations handle/display/edit this VEVENT?

You would have to try different CUA's to find out.

--=20

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

               We Do Standards - You Need Standards

--------------050301080705040602080602
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:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------050301080705040602080602--

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

--------------ms080208000204010701000702--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] VTODO questions
Date: Thu, 12 May 2005 17:01:17 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>, "Calsify" <[email-masked]>
Cc: 

So far, the extent of VTODO "simplification" and "clarification" for the
purposes of interoperability have amounted to this:

Deprecation.

Tasks as a datatype, IMHO, belong in a separate specification - when and
if there is adequate interest in such a standard. Muddying the waters
with tasks is one of the things that has likely kept iCal from becoming
a standard for the past few years.

(...think of it as including your pet political hack for a kickback in
the next tax cut bill...)

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, May 10, 2005 11:59 AM
To: Calsify
Subject: [Ietf-calsify] VTODO questions

I have some questions about VTODO interoperability that I was hoping
somebody on the calsify list could help me answer.  We are currently
trying to implement todos into our server with the goal of being as
interoperable as possible with other calendar servers/clients.  I know
RFC 2445 has a lot of shortfalls regarding VTODOs, but we're willing to
live with some of these shortcomings if it increases our
interoperability.  At this point though, I am having difficulty
determining what clients and servers we would be able to interoperate
with.

Can anyone point me at some calendar clients and servers that support
assigning and responding to VTODOs with iMIP? 

Has calsify or any other group tried to quantify the level of
interoperability that exists with VTODOs?  Are there any
interoperability test reports for this?

Is calsify looking at what to do about VTODOs, or are VTODOs used so
little right now that standardization of these is considered a low
priority?  

Thanks,

Chris Bryant

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

From: =?ISO-8859-1?Q?Tantek_=C7elik?= <[email-masked]>
Subject: Re: [Ietf-calsify] RDATE vs. DTEND/DURATION clarification
Date: Fri, 13 May 2005 07:42:56 +0900
To: Calsify <[email-masked]>

But look at the times.

The first instance overlaps the other two entirely.

Are you saying that is valid?

And if so, how is a CUA possibly expected to represent that in some 
meaningful form to the user?

Warn them that two or more instances of the same meeting are occurring 
at the same time?

The spec says that exact RRULE/RDATE event instance duplicates are 
supposed to be tossed, but says nothing about having the same meeting 
take place twice at the same time which makes no sense.  Why is it 
useful for the spec to allow this?

How do implementations handle/display/edit this VEVENT?

Thanks,

Tantek

On May 13, 2005, at 7:14 AM, Doug Royer wrote:

>
> It has 3 instances, not 2.
>
> iCal-Basic deprecated DTEND, so it would be (assuming I
> did my time math correctly:
>
>  BEGIN:VEVENT
>  LOCATION:University of Technology Sydney (UTS)\, Sydney\, Australia
>  SUMMARY:Web Essentials 05
>  DTSTART:20050928T230000Z
>  DURATION:+PT34H30M
>  RDATE;VALUE=PERIOD:20050928T230000Z/PT9H,20050929T213000Z/PT20H30M
>  END:VEVENT
>
> The first instance starts at 0050928T230000Z and ends 34.5 hours later.
> The second instance starts at 20050928T230000Z and ends 9.0 hours 
> later.
> The third instance starts at 20050929T213000Z and ends 20.5 hours 
> later.
>
> Tantek Çelik wrote:
>> In my opinion it is not clear in the spec (either RFC2445 or the  
>> iCal-BASIC draft) what a CUA is supposed to do when it sees *both* an 
>>  RDATE and DTEND in a VEVENT, or both an RDATE and DURATION in a 
>> VEVENT.
>> E.g.:
>> BEGIN:VEVENT
>> LOCATION:University of Technology Sydney (UTS)\, Sydney\, Australia
>> SUMMARY:Web Essentials 05
>> DTEND:20050930T093000Z
>> DTSTART:20050928T230000Z
>> URL:http://we05.com/
>> RDATE;VALUE=PERIOD:20050928T230000Z/20050929T0800Z,20050929T213000Z/ 
>> 20050930T0930Z
>> END:VEVENT
>> The RDATE is saying this event takes place in two discrete chunks 
>> over  the course of two days.
>> The DTSTART/DTEND combo is saying the event takes place for 34.5 
>> hours  straight.
>> Which should the CUA "choose" from those two options?
>> Is this an invalid VEVENT?
>> Thanks,
>> Tantek
>> -- 
>> Tantek Çelik
>> Senior Technologist, Technorati, Inc.
>> [email-masked]
>> _______________________________________________
>> 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
>
> <Doug.vcf>_______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

--
Tantek Çelik
Senior Technologist, Technorati, Inc.
[email-masked]

Date: Thu, 12 May 2005 16:14:03 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] RDATE vs. DTEND/DURATION clarification
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms000804010504060809030607
Content-Type: multipart/mixed; boundary="------------030402040707040708070108"

This is a multi-part message in MIME format.
--------------030402040707040708070108
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

It has 3 instances, not 2.

iCal-Basic deprecated DTEND, so it would be (assuming I
did my time math correctly:

  BEGIN:VEVENT
  LOCATION:University of Technology Sydney (UTS)\, Sydney\, Australia
  SUMMARY:Web Essentials 05
  DTSTART:20050928T230000Z
  DURATION:+PT34H30M
  RDATE;VALUE=3DPERIOD:20050928T230000Z/PT9H,20050929T213000Z/PT20H30M
  END:VEVENT

The first instance starts at 0050928T230000Z and ends 34.5 hours later.
The second instance starts at 20050928T230000Z and ends 9.0 hours later.
The third instance starts at 20050929T213000Z and ends 20.5 hours later.

Tantek =C7elik wrote:
> In my opinion it is not clear in the spec (either RFC2445 or the =20
> iCal-BASIC draft) what a CUA is supposed to do when it sees *both* an  =

> RDATE and DTEND in a VEVENT, or both an RDATE and DURATION in a VEVENT.=

>=20
> E.g.:
>=20
>=20
> BEGIN:VEVENT
> LOCATION:University of Technology Sydney (UTS)\, Sydney\, Australia
> SUMMARY:Web Essentials 05
> DTEND:20050930T093000Z
> DTSTART:20050928T230000Z
> URL:http://we05.com/
> RDATE;VALUE=3DPERIOD:20050928T230000Z/20050929T0800Z,20050929T213000Z/ =

> 20050930T0930Z
> END:VEVENT
>=20
>=20
> The RDATE is saying this event takes place in two discrete chunks over =
=20
> the course of two days.
>=20
> The DTSTART/DTEND combo is saying the event takes place for 34.5 hours =
=20
> straight.
>=20
> Which should the CUA "choose" from those two options?
>=20
> Is this an invalid VEVENT?
>=20
> Thanks,
>=20
> Tantek
>=20
>=20
> --=20
> Tantek =C7elik
> Senior Technologist, Technorati, Inc.
> [email-masked]
>=20
>=20
>=20
> --=20
> Tantek =C7elik
> Technorati, Inc.
> [email-masked]
> 415-254-9656 (Mobile)
>=20
>=20
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

--=20

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

               We Do Standards - You Need Standards

--------------030402040707040708070108
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:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------030402040707040708070108--

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

--------------ms000804010504060809030607--

To: Calsify <[email-masked]>
From: =?ISO-8859-1?Q?Tantek_=C7elik?= <[email-masked]>
Date: Fri, 13 May 2005 06:39:35 +0900
Subject: [Ietf-calsify] RDATE vs. DTEND/DURATION clarification

In my opinion it is not clear in the spec (either RFC2445 or the  
iCal-BASIC draft) what a CUA is supposed to do when it sees *both* an  
RDATE and DTEND in a VEVENT, or both an RDATE and DURATION in a VEVENT.

E.g.:

BEGIN:VEVENT
LOCATION:University of Technology Sydney (UTS)\, Sydney\, Australia
SUMMARY:Web Essentials 05
DTEND:20050930T093000Z
DTSTART:20050928T230000Z
URL:http://we05.com/
RDATE;VALUE=PERIOD:20050928T230000Z/20050929T0800Z,20050929T213000Z/ 
20050930T0930Z
END:VEVENT

The RDATE is saying this event takes place in two discrete chunks over  
the course of two days.

The DTSTART/DTEND combo is saying the event takes place for 34.5 hours  
straight.

Which should the CUA "choose" from those two options?

Is this an invalid VEVENT?

Thanks,

Tantek

--
Tantek Çelik
Senior Technologist, Technorati, Inc.
[email-masked]

--
Tantek Çelik
Technorati, Inc.
[email-masked]
415-254-9656 (Mobile)

Date: Tue, 10 May 2005 14:59:22 -0400
From: [email-masked]
To: Calsify <[email-masked]>
Z-USANET-MsgId: XID225JeJs8y0380X28
Subject: [Ietf-calsify] VTODO questions

I have some questions about VTODO interoperability that I was hoping somebody
on the calsify list could help me answer.  We are currently trying to
implement todos into our server with the goal of being as interoperable as
possible with other calendar servers/clients.  I know RFC 2445 has a lot of
shortfalls regarding VTODOs, but we're willing to live with some of these
shortcomings if it increases our interoperability.  At this point though, I am
having difficulty determining what clients and servers we would be able to
interoperate with.

Can anyone point me at some calendar clients and servers that support
assigning and responding to VTODOs with iMIP? 

Has calsify or any other group tried to quantify the level of interoperability
that exists with VTODOs?  Are there any interoperability test reports for
this?

Is calsify looking at what to do about VTODOs, or are VTODOs used so little
right now that standardization of these is considered a low priority?  

Thanks,

Chris Bryant