Subject: [Ietf-calsify] conference call Thusday this week at 10:00am EDT

From: lear at cisco.com (Eliot Lear)
Date: Mon Apr 30 02:38:38 2007

Dear all,

We would like to hold a brief conference call on Thursday, May 3rd, at 
10:00am EDT.  Please see the instructions below to access the meeting.  
If you plan to attend, please send me an email so I can ensure we have 
enough ports.  Any technical discussions that are discussed will be 
raised on the mailing list.  The primary purpose of the meeting, 
however, is to establish times for Jabber sessions, and to understand 
scope of remaining work.

Thanks,

Eliot

*Global Access Numbers:*
*http://cisco.com/en/US/about/doing_business/conferencing/index.html*

   * US/Canada:*  +1.866.432.9903   * United Kingdom:*   +44.20.8824.0117
   * India:*      +91.80.4103.3979  * Germany:*          +49.619.6773.9002
   * Japan:*      +81.3.5763.9394   * China:*            +86.10.8515.5666

*TO ATTEND A WEB AND VOICE CONFERENCE*

*CISCO INTRANET ATTENDEES*
*Join the Web & Voice Conference**
1. Go to* http://meetingplaceinternal.cisco.com/join.asp?312147852*
2. Enter your* CEC User ID* &* Password* then click* OK*
- Accept any security warnings you receive and wait for the Meeting Room 
to initialize
3. Click on* CONNECT* from the Meeting Room to join the Voice Conference 
portion of the meeting

*EXTERNAL ATTENDEES* -* Outside the Cisco Intranet***
*Join the Web & Voice Conference**
1. Go to* http://meetingplace.cisco.com/join.asp?312147852*
2. Fill in the* My Name is* field then click* Attend Meeting*
- If you have a* CEC User ID*, click on the* Cisco icon*
- Accept any security warnings you receive and wait for the Meeting Room 
to initialize
3. Click on* CONNECT* from the Meeting Room to join the Voice Conference 
portion of the meeting

***If this is your first time attending a Web Conference, disable any 
pop-up blockers and visit* 
http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp* to 
test your web browser for compatibility with the Web Conference.

****Not all meetings are scheduled to allow external attendees into the 
Web Conference portion of the meeting, if the URL does not work, please 
follow the Voice only Conference instructions below to attend.

*TO ATTEND A VOICE ONLY CONFERENCE*
1. Dial into Cisco Unified MeetingPlace (view the Access Numbers or link 
above)
2. Press* 1* to attend the meeting
3. Follow the prompts to enter the Meeting ID* 312147852* and join the 
meeting

*SUPPORT*
*Information about this Conference:* Contact Eliot Lear, 41448787525
*Cisco IT Support Center:* Attend the Voice Conference and then press #0 
on your phone keypad

*GLOBAL ACCESS NUMBERS*

*COUNTRY            LOCATION           LOCAL NUMBER            TOLL 
FREE-FREEFONE*
*AMERICAS*          
*United States*      East               +1.919.392.3330         
1.866.349.3520
                   West               +1.408.525.6800         
1.866.432.9903
*Argentina*          Buenos Aires       +54.11.4341.0101
*Brazil*             Brasilia           +55.613.424.0220
                   Rio de Janeiro     +55.21.2483.6302
                   Sao Paulo          +55.11.5508.6311
*Canada*             Calgary            +1.403.514.2435
                   Edmonton           +1.780.441.3715
                   Halifax            +1.902.474.0214
                   Kanata             +1.613.254.0005
                   Markham            +1.905.470.4810
                   Montreal           +1.514.847.6875
                   Ottawa             +1.613.788.7250
                   Quebec             +1.418.634.5645
                   Regina             +1.306.566.6410
                   Toronto            +1.416.306.7230
                   Vancouver          +1.604.647.2350
                   Winnipeg           +1.204.336.6610
*Chile*              Santiago           +56.2.431.4936
*Costa Rica*         San Jose           +506.201.3617
*Colombia*           Bogota             +57.1.325.6065
*Dominican Republic* Santo Domingo      +1.809.683.1222
*Mexico*             Guadalajara        +52.33.3770.1206
                   Mexico City        +52.55.5267.1800
                   Monterrey          +52.818.221.2462   
*Peru*               Lima               +51.1.215.5101
*Puerto Rico*        San Juan           +1.787.620.1865
*Venezuela*          Caracas            +58.212.902.0210
*EUROPE*              
*Austria*            Vienna             +43.12.4030.6022
*Belgium*            Diegem             +32.2.704.5072
*Bulgaria*           Sofia              +359.2.937.5938
*Croatia*            Zagreb             +385.1.462.8908
*Czech Republic*     Prague             +420.22.143.5100
*Denmark*            Aabyhoj            +45.8.939.7131
                   Copenhagen         +45.3.958.5010
*Estonia*            Tallinn            +358.204.70.6227
*Finland*            Espoo              +358.204.70.6227
*France*             Paris              +33.15.804.3116
*Germany*            Eschborn           +49.619.6773.9002
                   Hallbergmoos       +49.811.554.3016
*Greece*             Athens             +30.210.638.1303
*Hungary*            Budapest           +36.1.225.4621
*Ireland*            Dublin             +353.1.819.2717
*Israel*             Netanya            +972.9.892.7026
*Italy*              Rome               +39.06.5164.4006
*Latvia*             Riga               +358.204.70.6227
*Netherlands*        Amsterdam          +31.20.357.1487
*Norway*             Oslo               +47.23.27.3647
*Poland*             Warsaw             +48.22.572.2615
*Portugal*           Lisbon             +351.21.446.8756
*Slovakia*           Bratislava         +421.2.5825.5309
*South Africa*       Cape Town          +27.21.413.4502
                   Johannesburg       +27.11.267.1011
                   Pretoria           +27.12.844.7401
*Spain*              Barcelona          +34.93.393.4037
                   Madrid             +34.91.201.2149
*Sweden*             Gothenburg         +46.31.63.4409
                   Stockholm          +46.8.685.9035
*Switzerland*        Glattzentrum       +41.44.878.7335
*Turkey*             Istanbul           +90.212.335.0208
*United Arab*
*Emirates* (UAE)     Dubai              +971.4.390.7840
*United Kingdom*     Bedfont Lakes      +44.20.8824.0117
                   Edinburgh          +44.131.561.3643
                   London City        +44.20.7496.3743
*ASIA PACIFIC*
*Australia*          Canberra           +61.2.6216.0643          86.16.0643
                   Melbourne          +61.3.9659.4173
                   North Sydney       +61.2.8446.5260
*China*              Beijing            +86.10.8515.5666
                   Shanghai           +86.21.2302.4200
*Hong Kong*          Hong Kong          +852.3414.1802
*India*              Bangalore          +91.80.4103.3979
                   Hyderabad          +91.40.4022.3450
                   Mumbai IL & FS     +91.22.4043.4030
                   New Delhi          +91.11.4261.1088
*Indonesia*          Jakarta            +62.21.7854.7476
*Japan*              Tokyo Akasaka      +81.3.5763.9394
*South Korea*        Seoul Asem         +82.2.3429.8102
*Malaysia*           Kuala Lumpur       +60.3.7723.8620
                   Penang             +60.4.631.5125
*New Zealand*        Auckland           +64.9.355.1968
                   Wellington         +64.4.496.5554
*Philippines*        Makati (Manila)    +63.2.750.5886
*Singapore*          Singapore Capital  +65.6317.7088
*Taiwan*             Taipei             +886.2.8758.7088
*Thailand*           Bangkok            +66.2.263.7008
*Vietnam*            Hanoi              +84.4.974.6250
                   Ho Chi Minh City   +84.8.823.3418
                   (Saigon)                  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070430/a62fcca8/attachment-0001.html

Date: Mon, 30 Apr 2007 11:36:41 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>
Subject: [Ietf-calsify] conference call Thusday this week at 10:00am EDT

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

Dear all,

We would like to hold a brief conference call on Thursday, May 3rd, at 
10:00am EDT.  Please see the instructions below to access the meeting.  
If you plan to attend, please send me an email so I can ensure we have 
enough ports.  Any technical discussions that are discussed will be 
raised on the mailing list.  The primary purpose of the meeting, 
however, is to establish times for Jabber sessions, and to understand 
scope of remaining work.

Thanks,

Eliot

*Global Access Numbers:*
*http://cisco.com/en/US/about/doing_business/conferencing/index.html*

   * US/Canada:*  +1.866.432.9903   * United Kingdom:*   +44.20.8824.0117
   * India:*      +91.80.4103.3979  * Germany:*          +49.619.6773.9002
   * Japan:*      +81.3.5763.9394   * China:*            +86.10.8515.5666

*TO ATTEND A WEB AND VOICE CONFERENCE*

*CISCO INTRANET ATTENDEES*
*Join the Web & Voice Conference**
1. Go to* http://meetingplaceinternal.cisco.com/join.asp?312147852*
2. Enter your* CEC User ID* &* Password* then click* OK*
- Accept any security warnings you receive and wait for the Meeting Room 
to initialize
3. Click on* CONNECT* from the Meeting Room to join the Voice Conference 
portion of the meeting

*EXTERNAL ATTENDEES* -* Outside the Cisco Intranet***
*Join the Web & Voice Conference**
1. Go to* http://meetingplace.cisco.com/join.asp?312147852*
2. Fill in the* My Name is* field then click* Attend Meeting*
- If you have a* CEC User ID*, click on the* Cisco icon*
- Accept any security warnings you receive and wait for the Meeting Room 
to initialize
3. Click on* CONNECT* from the Meeting Room to join the Voice Conference 
portion of the meeting

***If this is your first time attending a Web Conference, disable any 
pop-up blockers and visit* 
http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp* to 
test your web browser for compatibility with the Web Conference.

****Not all meetings are scheduled to allow external attendees into the 
Web Conference portion of the meeting, if the URL does not work, please 
follow the Voice only Conference instructions below to attend.

*TO ATTEND A VOICE ONLY CONFERENCE*
1. Dial into Cisco Unified MeetingPlace (view the Access Numbers or link 
above)
2. Press* 1* to attend the meeting
3. Follow the prompts to enter the Meeting ID* 312147852* and join the 
meeting

*SUPPORT*
*Information about this Conference:* Contact Eliot Lear, 41448787525
*Cisco IT Support Center:* Attend the Voice Conference and then press #0 
on your phone keypad

*GLOBAL ACCESS NUMBERS*

*COUNTRY            LOCATION           LOCAL NUMBER            TOLL 
FREE-FREEFONE*
*AMERICAS*          
*United States*      East               +1.919.392.3330         
1.866.349.3520
                   West               +1.408.525.6800         
1.866.432.9903
*Argentina*          Buenos Aires       +54.11.4341.0101
*Brazil*             Brasilia           +55.613.424.0220
                   Rio de Janeiro     +55.21.2483.6302
                   Sao Paulo          +55.11.5508.6311
*Canada*             Calgary            +1.403.514.2435
                   Edmonton           +1.780.441.3715
                   Halifax            +1.902.474.0214
                   Kanata             +1.613.254.0005
                   Markham            +1.905.470.4810
                   Montreal           +1.514.847.6875
                   Ottawa             +1.613.788.7250
                   Quebec             +1.418.634.5645
                   Regina             +1.306.566.6410
                   Toronto            +1.416.306.7230
                   Vancouver          +1.604.647.2350
                   Winnipeg           +1.204.336.6610
*Chile*              Santiago           +56.2.431.4936
*Costa Rica*         San Jose           +506.201.3617
*Colombia*           Bogota             +57.1.325.6065
*Dominican Republic* Santo Domingo      +1.809.683.1222
*Mexico*             Guadalajara        +52.33.3770.1206
                   Mexico City        +52.55.5267.1800
                   Monterrey          +52.818.221.2462   
*Peru*               Lima               +51.1.215.5101
*Puerto Rico*        San Juan           +1.787.620.1865
*Venezuela*          Caracas            +58.212.902.0210
*EUROPE*              
*Austria*            Vienna             +43.12.4030.6022
*Belgium*            Diegem             +32.2.704.5072
*Bulgaria*           Sofia              +359.2.937.5938
*Croatia*            Zagreb             +385.1.462.8908
*Czech Republic*     Prague             +420.22.143.5100
*Denmark*            Aabyhoj            +45.8.939.7131
                   Copenhagen         +45.3.958.5010
*Estonia*            Tallinn            +358.204.70.6227
*Finland*            Espoo              +358.204.70.6227
*France*             Paris              +33.15.804.3116
*Germany*            Eschborn           +49.619.6773.9002
                   Hallbergmoos       +49.811.554.3016
*Greece*             Athens             +30.210.638.1303
*Hungary*            Budapest           +36.1.225.4621
*Ireland*            Dublin             +353.1.819.2717
*Israel*             Netanya            +972.9.892.7026
*Italy*              Rome               +39.06.5164.4006
*Latvia*             Riga               +358.204.70.6227
*Netherlands*        Amsterdam          +31.20.357.1487
*Norway*             Oslo               +47.23.27.3647
*Poland*             Warsaw             +48.22.572.2615
*Portugal*           Lisbon             +351.21.446.8756
*Slovakia*           Bratislava         +421.2.5825.5309
*South Africa*       Cape Town          +27.21.413.4502
                   Johannesburg       +27.11.267.1011
                   Pretoria           +27.12.844.7401
*Spain*              Barcelona          +34.93.393.4037
                   Madrid             +34.91.201.2149
*Sweden*             Gothenburg         +46.31.63.4409
                   Stockholm          +46.8.685.9035
*Switzerland*        Glattzentrum       +41.44.878.7335
*Turkey*             Istanbul           +90.212.335.0208
*United Arab*
*Emirates* (UAE)     Dubai              +971.4.390.7840
*United Kingdom*     Bedfont Lakes      +44.20.8824.0117
                   Edinburgh          +44.131.561.3643
                   London City        +44.20.7496.3743
*ASIA PACIFIC*
*Australia*          Canberra           +61.2.6216.0643          86.16.0643
                   Melbourne          +61.3.9659.4173
                   North Sydney       +61.2.8446.5260
*China*              Beijing            +86.10.8515.5666
                   Shanghai           +86.21.2302.4200
*Hong Kong*          Hong Kong          +852.3414.1802
*India*              Bangalore          +91.80.4103.3979
                   Hyderabad          +91.40.4022.3450
                   Mumbai IL & FS     +91.22.4043.4030
                   New Delhi          +91.11.4261.1088
*Indonesia*          Jakarta            +62.21.7854.7476
*Japan*              Tokyo Akasaka      +81.3.5763.9394
*South Korea*        Seoul Asem         +82.2.3429.8102
*Malaysia*           Kuala Lumpur       +60.3.7723.8620
                   Penang             +60.4.631.5125
*New Zealand*        Auckland           +64.9.355.1968
                   Wellington         +64.4.496.5554
*Philippines*        Makati (Manila)    +63.2.750.5886
*Singapore*          Singapore Capital  +65.6317.7088
*Taiwan*             Taipei             +886.2.8758.7088
*Thailand*           Bangkok            +66.2.263.7008
*Vietnam*            Hanoi              +84.4.974.6250
                   Ho Chi Minh City   +84.8.823.3418
                   (Saigon)                  

--------------000007000402020103020400
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Dear all,<br>
<br>
We would like to hold a brief conference call on Thursday, May 3rd, at
10:00am EDT.  Please see the instructions below to access the meeting. 
If you plan to attend, please send me an email so I can ensure we have
enough ports.  Any technical discussions that are discussed will be
raised on the mailing list.  The primary purpose of the meeting,
however, is to establish times for Jabber sessions, and to understand
scope of remaining work.<br>
<br>
Thanks,<br>
<br>
Eliot<br>
<br>
<p><b><font face="Courier New" size="2">Global Access Numbers:</font></b>
<br>
<b><font face="Courier New" size="2"><a
 href="http://cisco.com/en/US/about/doing_business/conferencing/index.html">http://cisco.com/en/US/about/doing_business/conferencing/index.html</a></font></b>
</p>
<p><font face="Courier New" size="2">   </font><b> <font
 face="Courier New" size="2">US/Canada:</font></b><font
 face="Courier New" size="2">  +1.866.432.9903   </font><b> <font
 face="Courier New" size="2">United Kingdom:</font></b><font
 face="Courier New" size="2">   +44.20.8824.0117</font>
<br>
<font face="Courier New" size="2">   </font><b> <font
 face="Courier New" size="2">India:</font></b><font face="Courier New"
 size="2">      +91.80.4103.3979  </font><b> <font face="Courier New"
 size="2">Germany:</font></b><font face="Courier New" size="2">         
+49.619.6773.9002</font>
<br>
<font face="Courier New" size="2">   </font><b> <font
 face="Courier New" size="2">Japan:</font></b><font face="Courier New"
 size="2">      +81.3.5763.9394   </font><b> <font face="Courier New"
 size="2">China:</font></b><font face="Courier New" size="2">           
+86.10.8515.5666</font>
</p>
<p><b><font face="Courier New" size="2">TO ATTEND A WEB AND VOICE
CONFERENCE</font></b>
</p>
<p><b><font color="#008080" face="Courier New" size="2">CISCO INTRANET
ATTENDEES</font></b>
<br>
<b><font face="Courier New" size="2">Join the Web &amp; Voice Conference</font><font
 color="#0000ff" face="Courier New" size="2">*</font></b>
<br>
<font face="Courier New" size="2">1. Go to</font><b> <font
 face="Courier New" size="2"><a
 href="http://meetingplaceinternal.cisco.com/join.asp?312147852">http://meetingplaceinternal.cisco.com/join.asp?312147852</a></font></b>
<br>
<font face="Courier New" size="2">2. Enter your</font><b> <font
 face="Courier New" size="2">CEC User ID</font></b><font
 face="Courier New" size="2"> &amp;</font><b> <font face="Courier New"
 size="2">Password</font></b><font face="Courier New" size="2"> then
click</font><b> <font face="Courier New" size="2">OK</font></b>
<br>
<font face="Courier New" size="2">- Accept any security warnings you
receive and wait for the Meeting Room to initialize</font>
<br>
<font face="Courier New" size="2">3. Click on</font><b> <font
 face="Courier New" size="2">CONNECT</font></b><font face="Courier New"
 size="2"> from the Meeting Room to join the Voice Conference portion
of the meeting</font>
</p>
<p><b><font color="#008080" face="Courier New" size="2">EXTERNAL
ATTENDEES</font></b><font color="#008080" face="Courier New" size="2"> -</font><b>
<font color="#008080" face="Courier New" size="2">Outside the Cisco
Intranet</font><font color="#0000ff" face="Courier New" size="2">**</font></b>
<br>
<b><font face="Courier New" size="2">Join the Web &amp; Voice Conference</font><font
 color="#0000ff" face="Courier New" size="2">*</font></b>
<br>
<font face="Courier New" size="2">1. Go to</font><b> <font
 face="Courier New" size="2"><a
 href="http://meetingplace.cisco.com/join.asp?312147852">http://meetingplace.cisco.com/join.asp?312147852</a></font></b>
<br>
<font face="Courier New" size="2">2. Fill in the</font><b> <font
 face="Courier New" size="2">My Name is</font></b><font
 face="Courier New" size="2"> field then click</font><b> <font
 face="Courier New" size="2">Attend Meeting</font></b>
<br>
<font face="Courier New" size="2">- If you have a</font><b> <font
 face="Courier New" size="2">CEC User ID</font></b><font
 face="Courier New" size="2">, click on the</font><b> <font
 face="Courier New" size="2">Cisco icon</font></b>
<br>
<font face="Courier New" size="2">- Accept any security warnings you
receive and wait for the Meeting Room to initialize</font>
<br>
<font face="Courier New" size="2">3. Click on</font><b> <font
 face="Courier New" size="2">CONNECT</font></b><font face="Courier New"
 size="2"> from the Meeting Room to join the Voice Conference portion
of the meeting</font>
</p>
<p><b><font color="#0000ff" face="Courier New" size="2">*</font></b><font
 face="Courier New" size="2">If this is your first time attending a Web
Conference, disable any pop-up blockers and visit</font><b> <font
 face="Courier New" size="2"><a
 href="http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp">http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp</a></font></b><font
 face="Courier New" size="2"> to test your web browser for
compatibility with the Web Conference.</font></p>
<p><b><font color="#0000ff" face="Courier New" size="2">**</font></b><font
 face="Courier New" size="2">Not
all meetings are scheduled to allow external attendees into the Web
Conference portion of the meeting, if the URL does not work, please
follow the Voice only Conference instructions below to attend.</font></p>
<p><b><font face="Courier New" size="2">TO ATTEND A VOICE ONLY
CONFERENCE</font></b>
<br>
<font face="Courier New" size="2">1. Dial into Cisco Unified
MeetingPlace (view the Access Numbers or link above)</font>
<br>
<font face="Courier New" size="2">2. Press</font><b> <font
 face="Courier New" size="2">1</font></b><font face="Courier New"
 size="2"> to attend the meeting</font>
<br>
<font face="Courier New" size="2">3. Follow the prompts to enter the
Meeting ID</font><b> <font face="Courier New" size="2">312147852</font></b><font
 face="Courier New" size="2"> and join the meeting</font>
</p>
<p><b><font face="Courier New" size="2">SUPPORT</font></b>
<br>
<b><font face="Courier New" size="2">Information about this Conference:</font></b><font
 face="Courier New" size="2"> Contact Eliot Lear, 41448787525</font>
<br>
<b><font face="Courier New" size="2">Cisco IT Support Center:</font></b><font
 face="Courier New" size="2"> Attend the Voice Conference and then
press #0 on your phone keypad</font>
</p>
<p><b><font color="#008080" face="Courier New" size="2">GLOBAL ACCESS
NUMBERS</font></b>
</p>
<p><b><font color="#000000" face="Courier New" size="2">COUNTRY           
LOCATION           LOCAL NUMBER            TOLL FREE-FREEFONE</font></b>
<br>
<b><font color="#800000" face="Courier New" size="2">AMERICAS</font></b><font
 face="Courier New" size="2">           </font>
<br>
<b><font face="Courier New" size="2">United States</font></b><font
 face="Courier New" size="2">      East              
+1.919.392.3330         1.866.349.3520</font>
<br>
<font face="Courier New" size="2">                   West              
+1.408.525.6800         1.866.432.9903</font>
<br>
<b><font face="Courier New" size="2">Argentina</font></b><font
 face="Courier New" size="2">          Buenos Aires      
+54.11.4341.0101</font>
<br>
<b><font face="Courier New" size="2">Brazil</font></b><font
 face="Courier New" size="2">             Brasilia          
+55.613.424.0220</font>
<br>
<font face="Courier New" size="2">                   Rio de Janeiro    
+55.21.2483.6302</font>
<br>
<font face="Courier New" size="2">                   Sao Paulo         
+55.11.5508.6311</font>
<br>
<b><font face="Courier New" size="2">Canada</font></b><font
 face="Courier New" size="2">             Calgary           
+1.403.514.2435</font>
<br>
<font face="Courier New" size="2">                   Edmonton          
+1.780.441.3715</font>
<br>
<font face="Courier New" size="2">                   Halifax           
+1.902.474.0214</font>
<br>
<font face="Courier New" size="2">                   Kanata            
+1.613.254.0005</font>
<br>
<font face="Courier New" size="2">                   Markham           
+1.905.470.4810</font>
<br>
<font face="Courier New" size="2">                   Montreal          
+1.514.847.6875</font>
<br>
<font face="Courier New" size="2">                   Ottawa            
+1.613.788.7250</font>
<br>
<font face="Courier New" size="2">                   Quebec            
+1.418.634.5645</font>
<br>
<font face="Courier New" size="2">                   Regina            
+1.306.566.6410</font>
<br>
<font face="Courier New" size="2">                   Toronto           
+1.416.306.7230</font>
<br>
<font face="Courier New" size="2">                   Vancouver         
+1.604.647.2350</font>
<br>
<font face="Courier New" size="2">                   Winnipeg          
+1.204.336.6610</font>
<br>
<b><font face="Courier New" size="2">Chile</font></b><font
 face="Courier New" size="2">              Santiago          
+56.2.431.4936</font>
<br>
<b><font face="Courier New" size="2">Costa Rica</font></b><font
 face="Courier New" size="2">         San Jose           +506.201.3617</font>
<br>
<b><font face="Courier New" size="2">Colombia</font></b><font
 face="Courier New" size="2">           Bogota            
+57.1.325.6065</font>
<br>
<b><font face="Courier New" size="2">Dominican Republic</font></b><font
 face="Courier New" size="2"> Santo Domingo      +1.809.683.1222</font>
<br>
<b><font face="Courier New" size="2">Mexico</font></b><font
 face="Courier New" size="2">             Guadalajara       
+52.33.3770.1206</font>
<br>
<font face="Courier New" size="2">                   Mexico City       
+52.55.5267.1800</font>
<br>
<font face="Courier New" size="2">                   Monterrey         
+52.818.221.2462    </font>
<br>
<b><font face="Courier New" size="2">Peru</font></b><font
 face="Courier New" size="2">               Lima              
+51.1.215.5101</font>
<br>
<b><font face="Courier New" size="2">Puerto Rico</font></b><font
 face="Courier New" size="2">        San Juan           +1.787.620.1865</font>
<br>
<b><font face="Courier New" size="2">Venezuela</font></b><font
 face="Courier New" size="2">          Caracas           
+58.212.902.0210</font>
<br>
<b><font color="#800000" face="Courier New" size="2">EUROPE</font></b><font
 face="Courier New" size="2">               </font>
<br>
<b><font face="Courier New" size="2">Austria</font></b><font
 face="Courier New" size="2">            Vienna            
+43.12.4030.6022</font>
<br>
<b><font face="Courier New" size="2">Belgium</font></b><font
 face="Courier New" size="2">            Diegem            
+32.2.704.5072</font>
<br>
<b><font face="Courier New" size="2">Bulgaria</font></b><font
 face="Courier New" size="2">           Sofia             
+359.2.937.5938</font>
<br>
<b><font face="Courier New" size="2">Croatia</font></b><font
 face="Courier New" size="2">            Zagreb            
+385.1.462.8908</font>
<br>
<b><font face="Courier New" size="2">Czech Republic</font></b><font
 face="Courier New" size="2">     Prague             +420.22.143.5100</font>
<br>
<b><font face="Courier New" size="2">Denmark</font></b><font
 face="Courier New" size="2">            Aabyhoj           
+45.8.939.7131</font>
<br>
<font face="Courier New" size="2">                   Copenhagen        
+45.3.958.5010</font>
<br>
<b><font face="Courier New" size="2">Estonia</font></b><font
 face="Courier New" size="2">            Tallinn           
+358.204.70.6227</font>
<br>
<b><font face="Courier New" size="2">Finland</font></b><font
 face="Courier New" size="2">            Espoo             
+358.204.70.6227</font>
<br>
<b><font face="Courier New" size="2">France</font></b><font
 face="Courier New" size="2">             Paris             
+33.15.804.3116</font>
<br>
<b><font face="Courier New" size="2">Germany</font></b><font
 face="Courier New" size="2">            Eschborn          
+49.619.6773.9002</font>
<br>
<font face="Courier New" size="2">                   Hallbergmoos      
+49.811.554.3016</font>
<br>
<b><font face="Courier New" size="2">Greece</font></b><font
 face="Courier New" size="2">             Athens            
+30.210.638.1303</font>
<br>
<b><font face="Courier New" size="2">Hungary</font></b><font
 face="Courier New" size="2">            Budapest          
+36.1.225.4621</font>
<br>
<b><font face="Courier New" size="2">Ireland</font></b><font
 face="Courier New" size="2">            Dublin            
+353.1.819.2717</font>
<br>
<b><font face="Courier New" size="2">Israel</font></b><font
 face="Courier New" size="2">             Netanya           
+972.9.892.7026</font>
<br>
<b><font face="Courier New" size="2">Italy</font></b><font
 face="Courier New" size="2">              Rome              
+39.06.5164.4006</font>
<br>
<b><font face="Courier New" size="2">Latvia</font></b><font
 face="Courier New" size="2">             Riga              
+358.204.70.6227</font>
<br>
<b><font face="Courier New" size="2">Netherlands</font></b><font
 face="Courier New" size="2">        Amsterdam          +31.20.357.1487</font>
<br>
<b><font face="Courier New" size="2">Norway</font></b><font
 face="Courier New" size="2">             Oslo              
+47.23.27.3647</font>
<br>
<b><font face="Courier New" size="2">Poland</font></b><font
 face="Courier New" size="2">             Warsaw            
+48.22.572.2615</font>
<br>
<b><font face="Courier New" size="2">Portugal</font></b><font
 face="Courier New" size="2">           Lisbon            
+351.21.446.8756</font>
<br>
<b><font face="Courier New" size="2">Slovakia</font></b><font
 face="Courier New" size="2">           Bratislava        
+421.2.5825.5309</font>
<br>
<b><font face="Courier New" size="2">South Africa</font></b><font
 face="Courier New" size="2">       Cape Town          +27.21.413.4502</font>
<br>
<font face="Courier New" size="2">                   Johannesburg      
+27.11.267.1011</font>
<br>
<font face="Courier New" size="2">                   Pretoria          
+27.12.844.7401</font>
<br>
<b><font face="Courier New" size="2">Spain</font></b><font
 face="Courier New" size="2">              Barcelona         
+34.93.393.4037</font>
<br>
<font face="Courier New" size="2">                   Madrid            
+34.91.201.2149</font>
<br>
<b><font face="Courier New" size="2">Sweden</font></b><font
 face="Courier New" size="2">             Gothenburg        
+46.31.63.4409</font>
<br>
<font face="Courier New" size="2">                   Stockholm         
+46.8.685.9035</font>
<br>
<b><font face="Courier New" size="2">Switzerland</font></b><font
 face="Courier New" size="2">        Glattzentrum       +41.44.878.7335</font>
<br>
<b><font face="Courier New" size="2">Turkey</font></b><font
 face="Courier New" size="2">             Istanbul          
+90.212.335.0208</font>
<br>
<b><font face="Courier New" size="2">United Arab</font></b>
<br>
<b><font face="Courier New" size="2">Emirates</font></b><font
 face="Courier New" size="2"> (UAE)     Dubai             
+971.4.390.7840</font>
<br>
<b><font face="Courier New" size="2">United Kingdom</font></b><font
 face="Courier New" size="2">     Bedfont Lakes      +44.20.8824.0117</font>
<br>
<font face="Courier New" size="2">                   Edinburgh         
+44.131.561.3643</font>
<br>
<font face="Courier New" size="2">                   London City       
+44.20.7496.3743</font>
<br>
<b><font color="#800000" face="Courier New" size="2">ASIA PACIFIC</font></b>
<br>
<b><font face="Courier New" size="2">Australia</font></b><font
 face="Courier New" size="2">          Canberra          
+61.2.6216.0643          86.16.0643<br>
                   Melbourne          +61.3.9659.4173</font>
<br>
<font face="Courier New" size="2">                   North Sydney      
+61.2.8446.5260</font>
<br>
<b><font face="Courier New" size="2">China</font></b><font
 face="Courier New" size="2">              Beijing           
+86.10.8515.5666</font>
<br>
<font face="Courier New" size="2">                   Shanghai          
+86.21.2302.4200</font>
<br>
<b><font face="Courier New" size="2">Hong Kong</font></b><font
 face="Courier New" size="2">          Hong Kong          +852.3414.1802</font>
<br>
<b><font face="Courier New" size="2">India</font></b><font
 face="Courier New" size="2">              Bangalore         
+91.80.4103.3979</font>
<br>
<font face="Courier New" size="2">                   Hyderabad         
+91.40.4022.3450</font>
<br>
<font face="Courier New" size="2">                   Mumbai IL &amp;
FS     +91.22.4043.4030</font>
<br>
<font face="Courier New" size="2">                   New Delhi         
+91.11.4261.1088</font>
<br>
<b><font face="Courier New" size="2">Indonesia</font></b><font
 face="Courier New" size="2">          Jakarta           
+62.21.7854.7476</font>
<br>
<b><font face="Courier New" size="2">Japan</font></b><font
 face="Courier New" size="2">              Tokyo Akasaka     
+81.3.5763.9394</font>
<br>
<b><font face="Courier New" size="2">South Korea</font></b><font
 face="Courier New" size="2">        Seoul Asem         +82.2.3429.8102</font>
<br>
<b><font face="Courier New" size="2">Malaysia</font></b><font
 face="Courier New" size="2">           Kuala Lumpur      
+60.3.7723.8620</font>
<br>
<font face="Courier New" size="2">                   Penang            
+60.4.631.5125</font>
<br>
<b><font face="Courier New" size="2">New Zealand</font></b><font
 face="Courier New" size="2">        Auckland           +64.9.355.1968</font>
<br>
<font face="Courier New" size="2">                   Wellington        
+64.4.496.5554</font>
<br>
<b><font face="Courier New" size="2">Philippines</font></b><font
 face="Courier New" size="2">        Makati (Manila)    +63.2.750.5886</font>
<br>
<b><font face="Courier New" size="2">Singapore</font></b><font
 face="Courier New" size="2">          Singapore Capital  +65.6317.7088</font>
<br>
<b><font face="Courier New" size="2">Taiwan</font></b><font
 face="Courier New" size="2">             Taipei            
+886.2.8758.7088</font>
<br>
<b><font face="Courier New" size="2">Thailand</font></b><font
 face="Courier New" size="2">           Bangkok           
+66.2.263.7008</font>
<br>
<b><font face="Courier New" size="2">Vietnam</font></b><font
 face="Courier New" size="2">            Hanoi             
+84.4.974.6250</font>
<br>
<font face="Courier New" size="2">                   Ho Chi Minh City  
+84.8.823.3418</font>
<br>
<font face="Courier New" size="2">                  
(Saigon)                   </font>
</p>
<br>
<br>
</body>
</html>

--------------000007000402020103020400--

Date: Sat, 28 Apr 2007 15:36:28 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Minor issues in 2445bis
Cc: [email-masked]

Cyrus Daboo wrote:
> Hi,
> Some issues with -06 draft:
> 
> 1) It would be nice if the VTIMEZONE example on page 63/64 had its 
> sub-components ordered by DTSTART so as to match the table on page 61 
> for ease of understanding. If we do that, the example text description 
> should include a statement to the effect that the actual ordering of 
> STANDARD/DAYLIGHT sub-components is arbitrary.

I sorted to table based on the time of the first observance of each rule.
I changed the example to follow the same order as the table.

> 2) The description for the example at the top of page 66 is wrong. The 
> "on or later than" time is wrong - it uses 2007 - but the VTIMEZONE is 
> 1997/1998.

Fixed.  The text and the example now make reference to 2007-2008.

> 3) In the "fictitious" examples starting at the bottom of page 66 until 
> page 68, they are described as being "for the Eastern United States". I 
> would rather prefer " for a locality with a standard time offset of -0500".

Changed the text to say "set of rules for a fictitious time zone".

> 4) The example text description at the bottom of page 66 should indicate 
> it is "fictitious".

I updated the example with the current information for New York City
instead.

> 5) There is an extraneous space before the period at the end of the 
> paragraph immediately after the list on page 64. There were a couple of 
> other like that in the document - do a search for " .", and also " ," 
> and " :" while you are at it.

Done.

Thanks,
Bernard

Date: Sat, 28 Apr 2007 14:16:08 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.8.7.2 Date/Time Stamp: Purpose of DTSTAMP in the context of calendaring

In section 4.8.7.2 Date/Time Stamp of RFC 2445 it says:

 > Purpose: The property indicates the date/time that the instance of
 > the iCalendar object was created.
 >
 > [...]
 >
 > Description: The value MUST be specified in the UTC time format.
 >
 > This property is also useful to protocols such as [IMIP] that have
 > inherent latency issues with the delivery of content. This property
 > will assist in the proper sequencing of messages containing iCalendar
 > objects.
 >
 > This property is different than the "CREATED" and "LAST-MODIFIED"
 > properties. These two properties are used to specify when the
 > particular calendar data in the calendar store was created and last
 > modified. This is different than when the iCalendar object
 > representation of the calendar service information was created or
 > last modified.

As was discussed at the Calsify WG meeting in Prague, I believe we
need to clarify the purpose of the "DTSTAMP" property.

I believe the current definition of the "DTSTAMP" property make
sense in the context of scheduling, but not so for calendaring
(i.e., calendar access).

According to the current definition, a CalDAV server that doesn't
store the iCalendar representation of calendar resources should
always return iCalendar objects with the "DTSTAMP" property set to
the current time with the consequence that the ETag (see section
3.11 Entity Tags of RFC 2616) of all the calendar resources would
change every second! Clearly, no serious CalDAV server implementation
would do such a thing. Returning iCalendar objects with the "DTSTAMP"
property set to the last modification time of the calendar resource
would seem more appropriate.

One way to address this issue would be to make the "DTSTAMP" property
optional in all calendar components in the iCalendar specifications,
but to make it mandatory in all calendar components in the iTIP
specification. Actually, it might have been the original intent.
RFC 2445 was ambiguous on whether "DTSTAMP" is mandatory or optional.
(see issues 37, 38, 39 and 40). iTIP, on the other hand, was clear
that "DTSTAMP" is required in all calendar components.

In my opinion, we should not go back on the consensus made earlier
by this WG to clarify that "DTSTAMP" is required in all calendar
components. Some calendaring applications may actually find it useful
to always have a "DTSTAMP" property in all calendar components.
Remember that the "LAST-MODIFIED" property is optional in all calendar
components.

In order to address this issue in a way that preserves backward
compatibility with existing iCalendar applications, I propose to
modify the definition of the "DTSTAMP" property to specify that in
the context of calendaring (i.e., iCalendar object with no "METHOD"
property) its value may be set to the date and time that the calendar
component was last revised in the calendar store (i.e., same
definition as LAST-MODIFIED), but that in the context of scheduling
its value should be set to the date and time where the scheduling
message (i.e., iCalendar object with a METHOD property) was created.

Cheers,
Bernard

Date: Thu, 19 Apr 2007 21:08:28 -0300
From: "=?ISO-8859-1?Q?F=E1bio_Henrique_da_Silva?=" <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] VEVENT cardinality on COUNTER

------=_Part_134235_4311487.1177027708701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi all,

A question about iTIP: shouldn't 1+ VEVENTs be allowed on a COUNTER message=
?
Since a REQUEST can include several VEVENTs to differently describe specifi=
c
instances, it would seem that COUNTER should be able to do the same... Have
I misunderstood something?

Cheers,

F=E1bio Silva.

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

Hi all,<br><br>A question about iTIP: shouldn&#39;t 1+ VEVENTs be allowed o=
n a COUNTER message? Since a REQUEST can include several VEVENTs to differe=
ntly describe specific instances, it would seem that COUNTER should be able=
 to do the same... Have I misunderstood something?
<br><br>Cheers,<br><br>F=E1bio Silva.<br>

------=_Part_134235_4311487.1177027708701--

Date: Thu, 19 Apr 2007 16:54:00 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] [Fwd: my review of draft-ietf-calsify-rfc2445bis-06.txt]

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

Dear all,

The chairs asked for and received an apps-area review of RFC2445-bis.  
Please see the attached.  Please understand that the review is a service 
of the apps-area to us.  Mr. Claudio Allocchio took considerable time to 
review the document.  We may disagree on some review points, but I think 
you will find merit in many of them.  The chairs ask that working group 
participants consider the comments that are attached, and address them 
to this list.

Thank you for your efforts!

Eliot & Aki

--------------010208070502090302090009
Content-Type: message/rfc822;
	name="my review of draft-ietf-calsify-rfc2445bis-06.txt.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
	filename*0="my review of draft-ietf-calsify-rfc2445bis-06.txt.eml"

Date: Thu, 19 Apr 2007 11:27:11 +0200 (CEST)
From: Claudio Allocchio <[email-masked]>
To: [email-masked]
cc: Eric Burger <[email-masked]>, Eliot Lear <[email-masked]>
Subject: my review of draft-ietf-calsify-rfc2445bis-06.txt

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-1060990078-1176974818=:538
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Hallo all,

attached is my review of draft-ietf-calsify-rfc2445bis-06.txt. I added my 
considerations directlu inside the txt draft, maked with

[***.... bla bla.... ***]

hoping to make them closer to the discussed prose and specification.

I would also add a general remark for the whole specification, which might 
become a concern when (and if) the specification is moving up in the 
standard process, and needs to undergo interoperability testing procedures 
among different implementions. I noted that in a number of cases there are 
really different combination of elements of the specification which can 
produce in the end the same result, or even more ways to specify the same 
thing (wfor example when secifying "time" or "time zones"). These are all 
variants, all valid, and when it comes to implement and test 
interoperability, these varians shall all be included. From previous 
experiences where many variants were allowed for the same information, I 
can tell that this creates a large buden of work, and enhance greatly the 
danger of non interoperable implementations.... ok that we human like 
variety... but do machines need it? I would, if at all possible, suggest 
reducing the number of allowed equivalent variants to the minimum.

I hope it helps in progressing it!

Best regards!

Claudio

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                          Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

             PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca
--0-1060990078-1176974818=:538
Content-Type: TEXT/plain; charset=US-ASCII;
	name="draft-ietf-calsify-rfc2445bis-revCA-06.txt"
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: attachment;
	filename="draft-ietf-calsify-rfc2445bis-revCA-06.txt"

--0-1060990078-1176974818=:538--

--------------010208070502090302090009--

Content-return: prohibited
Date: Fri, 13 Apr 2007 16:33:25 +0200
From: Arnaud Quillaud <[email-masked]>
Subject: RE : [Ietf-calsify] Issue 27: DURATION/DTEND ?
Sender: [email-masked]
To: Reinhold Kainhofer <[email-masked]>, [email-masked]

> -----Message d'origine-----
> De : [email-masked]
> [mailto:[email-masked]] De la part de=20
> Reinhold Kainhofer
> Envoy=E9 : mardi 10 avril 2007 18:38
> =C0 : [email-masked]
> Objet : Re: [Ietf-calsify] Issue 27: DURATION/DTEND ?
>=20
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Am Dienstag, 10. April 2007 schrieb Arnaud Quillaud:
> > With the new rule (use the "computed duration of the first
> instance"
> > for all instances), one can no longer create a recurring event th=
at
> > *always* starts at 22:00 and always ends at 6:00 the next day.
>=20
> That has never been possible anyway! It is not a new rule,
> but has always been=20
> the case.=20

OK. It is not a *new* rule. I should have said "With the proposed int=
erpretation of recurring events duration". But other interpretations =
have always existed. For example, some of the most widely deployed ca=
lendar softwares interpret:

=09DTSTART;TZID=3DAmerica/Montreal:20070309T220000
=09DTEND;TZID=3DAmerica/Montreal:20070310T060000
=09RRULE:FREQ=3DDAILY;COUNT=3D5;INTERVAL=3D1

as having 5 instances, all of which end at 06:00, even if there is a =
DST change on 20070311.

Having all instances end at 06:00 seems to me like a more natural int=
erpretation from an end user perspective. In addition, the other beha=
vior (1 instance ends at 07:00 on DST change) can always be generated=
 by using DURATION: PT8H instead of DTEND.
=20

> E.g. how would you determine the events for
>    DTSTART;TZID=3DAmerica/Montreal:20070311T000000
>    DTEND;TZID=3DAmerica/Montreal:20070312T000000
>    RRULE:FREQ=3DHOURLY;COUNT=3D5;INTERVAL=3D12
> if not by taking the duration of the initial event as the
> event for all=20
> remaining occurrences?

Indeed, there is no other way. But in that case, the same set of inst=
ances can be generated by using DURATION:PT23H.=20

If we come back to the end user need, there are some real life calend=
ar objects (e.g. working shifts) that:
* are recurring,
* always start at the same time of day **and** end at the same time o=
f day.
Other recurring objects are usually expressed using a duration (days,=
 hours, minutes, seconds).

Translated into ical this means that the use of DTSTART+DTEND (with V=
ALUE=3DDATETIME) in recurring event should be reserved to express the=
 first type of objects. All other recurring objects should use DTSTAR=
T+DURATION or DTSTART+DTEND (with VALUE=3DDATE).

In other words recurring events using DTSTART+DTEND (with VALUE=3DDAT=
ETIME):
1) should not contain HOURLY/MINUTELY/SECONDLY, or BYHOUR/BYMINUTE/BY=
SECOND element in their RRULE definition.
2)should generate valid end time for all instances (RDATE can be used=
 to specify problematic instances).
3) should have all RDATE specified with a value type of PERIOD.

Each instance end is calculated by:
1) adding to the instance start the number of days betweeen DTEND and=
 DTSTART date part,
2) setting the time part to the same time of day as the original DTEN=
D.

Recurring events using DTSTART+DTEND (with VALUE=3DDATE) are equivale=
nt to recurring events using DTSTART + DURATION where the duration is=
 expressed in number of days.

I think most existing recurring events using DTSTART+DTEND more or le=
ss already comply with the rules above (I have yet to see a cal clien=
t that would let you create HOURLY/MINUTELY/SECONDLY).Nevertheless we=
 may want to provide a fallback mechanism (e.g. use the duration of t=
he first instance).

Arnaud Q
>=20
> Cheers,
> Reinhold
>=20
> - --
> - -----------------------------------------------------------------=
-
> Reinhold Kainhofer, Vienna University of Technology, Austria
> email: [email-masked], http://reinhold.kainhofer.com/
>  * Financial and Actuarial Mathematics, TU Wien,=20
> http://www.fam.tuwien.ac.at/
>  * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
>  * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>=20
> iD8DBQFGG71lTqjEwhXvPN0RAkoEAKC2r0P4jyao8zxxyrK8x6CZrEIP3gCgnwPQ
> nMQ/zCCNITiIgXchZOPTyXQ=3D
> =3Ds1PR
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]=20
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>=20

Content-class: urn:content-classes:calendarmessage
Date: Fri, 13 Apr 2007 14:33:55 +0200
Priority: Urgent
Importance: high
From: <[email-masked]>
Sender: "Eliot Lear (elear)" <[email-masked]>
To: "CALSIFY Mailinglist" <[email-masked]>, "Aki Niemi" <[email-masked]>, "Cyrus Daboo" <[email-masked]>, "Alexey Melnikov" <[email-masked]>, "Bernard Desruisseaux" <[email-masked]>
Subject: [Ietf-calsify] Canceled: IETF Calsify Discussion

This is a multi-part message in MIME format.

------_=_NextPart_001_01C77DC8.00E12F0D
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

When: Friday, April 13, 2007 3:00 PM-4:00 PM (GMT+01:00) Amsterdam, =
Berlin, Bern, Rome, Stockholm, Vienna.
Where: by phone: details to those who RSVP

*~*~*~*~*~*~*~*~*~*

Just in case you didn't see the email.

------_=_NextPart_001_01C77DC8.00E12F0D
Content-class: urn:content-classes:calendarmessage
Content-Type: text/calendar;
	method=CANCEL;
	name="meeting.ics"
Content-Transfer-Encoding: 8bit

BEGIN:VCALENDAR
METHOD:CANCEL
PRODID:Microsoft CDO for Microsoft Exchange
VERSION:2.0
BEGIN:VTIMEZONE
TZID:GMT +0100 (Standard) / GMT +0200 (Daylight)
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T030000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20070413T123354Z
DTSTART;TZID="GMT +0100 (Standard) / GMT +0200 (Daylight)":20070413T150000
SUMMARY:Canceled: IETF Calsify Discussion
UID:50BC02AA-1FD9-4976-A719-D1FBA832DA3A
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="CALSIFY M
 ailinglist":MAILTO:[email-masked]
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Aki Niemi
 ":MAILTO:[email-masked]
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Cyrus Dab
 oo":MAILTO:[email-masked]
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Alexey Me
 lnikov":MAILTO:[email-masked]
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Bernard D
 esruisseaux":MAILTO:[email-masked]
ORGANIZER;CN="[email-masked]":MAILTO:[email-masked]
LOCATION:by phone: details to those who RSVP
DTEND;TZID="GMT +0100 (Standard) / GMT +0200 (Daylight)":20070413T160000
DESCRIPTION:Just in case you didn't see the email.\N\N
SEQUENCE:0
PRIORITY:1
CLASS:
CREATED:20070413T123356Z
LAST-MODIFIED:20070413T123356Z
STATUS:CANCELLED
TRANSP:OPAQUE
X-MICROSOFT-CDO-BUSYSTATUS:FREE
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-CDO-INTENDEDSTATUS:FREE
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:2
X-MICROSOFT-CDO-OWNERAPPTID:-1
X-MICROSOFT-CDO-APPT-SEQUENCE:1
X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20070413T123354Z
X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20070413T123354Z
END:VEVENT
END:VCALENDAR

------_=_NextPart_001_01C77DC8.00E12F0D--

Date: Thu, 12 Apr 2007 16:46:35 +0200
From: Eliot Lear <[email-masked]>
To: Aki Niemi <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] No meeting tomorrow

Dear all,

We didn't receive very many responses to the meeting invitation (4), and 
the participant mix was wrong.  Hence I propose we cancel tomorrow's 
call.  Can people please hold the following dates?

Tuesday, April 17 9:00am EDT

Friday, April 20 9:00am EDT

Monday, April 23 9:00am EDT

And let me know which you prefer or if none work for you?

Thanks,

Eliot

Date: Tue, 10 Apr 2007 17:49:04 +0000
From: [email-masked]
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Ietf-calsify] Event Request: IETF Calsify Discussion

This is a multi-part message in MIME format.

--Boundary_(ID_lxQVUbgyh+iParQ7QYDjKA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

    Summary: IETF Calsify Discussion
      Start: Friday, April 13, 2007 6:00:00 AM PDT
        End: Friday, April 13, 2007 7:00:00 AM PDT
   Location: by phone: details to those who RSVP

Description: 
Dear all, please join us for an organizational discussion on Calsify.  Primary topics will be moving RFC 2445 and 2446 forward at this point, when to have jabber sessions, and whatever else gets added in agenda bashing.If you are interested, please RSVP to me and I will provide call-in information.

--Boundary_(ID_lxQVUbgyh+iParQ7QYDjKA)
Content-type: multipart/alternative;
	boundary="Boundary_(ID_BeMJdMEfmwxpvNbbk82mRw)"

This is a multi-part message in MIME format.

--Boundary_(ID_BeMJdMEfmwxpvNbbk82mRw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<pre>
    Summary: IETF Calsify Discussion
      Start: Friday, April 13, 2007 6:00:00 AM PDT
        End: Friday, April 13, 2007 7:00:00 AM PDT
   Location: by phone: details to those who RSVP

Description: 
Dear all, please join us for an organizational discussion on Calsify.  Primary topics will be moving RFC 2445 and 2446 forward at this point, when to have jabber sessions, and whatever else gets added in agenda bashing.If you are interested, please RSVP to me and I will provide call-in information.
</pre>

--Boundary_(ID_BeMJdMEfmwxpvNbbk82mRw)
Content-type: text/calendar; method=REQUEST; charset=UTF-8;
	name=request_6d2f7f896d2f7f89.ics
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=request_6d2f7f896d2f7f89.ics

BEGIN:VCALENDAR
PRODID:-//Sun/Calendar Server//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER;CN=Anil Srivastava:mailto:[email-masked]
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:mailto:[email-masked]
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:mailto:[email-masked]
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:mailto:[email-masked]
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:mailto:[email-masked]
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:mailto:[email-masked]
DTSTAMP:20070410T174904Z
DTSTART:20070413T130000Z
DTEND:20070413T140000Z
SUMMARY:IETF Calsify Discussion
UID:50BC02AA-1FD9-4976-A719-D1FBA832DA3A
SEQUENCE:0
LOCATION:by phone: details to those who RSVP
CLASS:PUBLIC
PRIORITY:0
GEO:0.000000;0.000000
DESCRIPTION:Dear all, please join us for an organizational discussion on Calsify.  Primary topics will be moving RFC 2445 and 2446 forward at this point, when to have jabber sessions, and whatever else gets added in agenda bashing.  If you are interested, please RSVP to me and I will provide call-in information.
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

--Boundary_(ID_BeMJdMEfmwxpvNbbk82mRw)--

--Boundary_(ID_lxQVUbgyh+iParQ7QYDjKA)
Content-type: text/calendar; method=REQUEST; charset=UTF-8;
	name=request_6d2f7f896d2f7f89.ics
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=request_6d2f7f896d2f7f89.ics

BEGIN:VCALENDAR
PRODID:-//Sun/Calendar Server//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER;CN=Anil Srivastava:mailto:[email-masked]
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:mailto:[email-masked]
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:mailto:[email-masked]
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:mailto:[email-masked]
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:mailto:[email-masked]
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:mailto:[email-masked]
DTSTAMP:20070410T174904Z
DTSTART:20070413T130000Z
DTEND:20070413T140000Z
SUMMARY:IETF Calsify Discussion
UID:50BC02AA-1FD9-4976-A719-D1FBA832DA3A
SEQUENCE:0
LOCATION:by phone: details to those who RSVP
CLASS:PUBLIC
PRIORITY:0
GEO:0.000000;0.000000
DESCRIPTION:Dear all, please join us for an organizational discussion on Calsify.  Primary topics will be moving RFC 2445 and 2446 forward at this point, when to have jabber sessions, and whatever else gets added in agenda bashing.  If you are interested, please RSVP to me and I will provide call-in information.
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

--Boundary_(ID_lxQVUbgyh+iParQ7QYDjKA)
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT

--Boundary_(ID_lxQVUbgyh+iParQ7QYDjKA)--

To: CALSIFY Mailinglist <[email-masked]>
From: Eliot Lear <[email-masked]>
Date: Tue, 10 Apr 2007 19:26:17 +0200
Subject: [Ietf-calsify] iCal event update: IETF Calsify Discussion

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

Eliot Lear has updated to the iCal event: IETF Calsify Discussion,  
scheduled for April 13, 2007 at 9:00 AM (US/Eastern). To acknowledge  
this invitation, click the link below.

--Apple-Mail-1-350282453
Content-Transfer-Encoding: quoted-printable
Content-Type: text/calendar; x-unix-mode=0644; name=iCal-20070410-192617.ics
Content-Disposition: attachment;
	filename=iCal-20070410-192617.ics

BEGIN:VCALENDAR=0D=0APRODID:-//Apple=20Computer\,=20Inc//iCal=202.0//EN=0D=
=0AMETHOD:REQUEST=0D=0ACALSCALE:GREGORIAN=0D=0AVERSION:2.0=0D=0A=
BEGIN:VTIMEZONE=0D=0ATZID:US/Eastern=0D=0ALAST-MODIFIED:20070410T172617Z=0D=
=0ABEGIN:DAYLIGHT=0D=0ADTSTART:20070311T070000=0D=0ATZOFFSETTO:-0400=0D=0A=
TZOFFSETFROM:+0000=0D=0ATZNAME:EDT=0D=0AEND:DAYLIGHT=0D=0AEND:VTIMEZONE=0D=
=0ABEGIN:VEVENT=0D=0AATTENDEE;CN=3D"CALSIFY=20=
Mailinglist";PARTSTAT=3DNEEDS-ACTION;RSVP=3DTRUE:mailto=0D=0A=20=
:[email-masked]=0D=0AATTENDEE;CN=3D"Aki=20=
Niemi";PARTSTAT=3DNEEDS-ACTION;RSVP=3DTRUE:mailto:aki.niemi=0D=0A=20=
@nokia.com=0D=0AATTENDEE;CN=3D"Cyrus=20=
Daboo";PARTSTAT=3DNEEDS-ACTION;RSVP=3DTRUE:mailto:daboo@i=0D=0A=20=
samet.com=0D=0AATTENDEE;CN=3D"Alexey=20=
Melnikov";PARTSTAT=3DNEEDS-ACTION;RSVP=3DTRUE:mailto:Ale=0D=0A=20=
[email-masked]=0D=0AATTENDEE;CN=3D"Bernard=20=
Desruisseaux";PARTSTAT=3DNEEDS-ACTION;RSVP=3DTRUE:mailt=0D=0A=20=
o:[email-masked]=0D=0ALOCATION:by=20phone:=20details=20=
to=20those=20who=20RSVP=0D=0ADTSTAMP:20070410T172614Z=0D=0A=
UID:50BC02AA-1FD9-4976-A719-D1FBA832DA3A=0D=0ASEQUENCE:16=0D=0A=
DTSTART;TZID=3DUS/Eastern:20070413T090000=0D=0ASUMMARY:IETF=20Calsify=20=
Discussion=0D=0ADTEND;TZID=3DUS/Eastern:20070413T100000=0D=0A=
DESCRIPTION:Dear=20all\,=20please=20join=20us=20for=20an=20=
organizational=20discussion=20o=0D=0A=20n=20Calsify.=20=20Primary=20=
topics=20will=20be=20moving=20RFC=202445=20and=202446=20forward=20at=20t=0D=
=0A=20his=20point\,=20when=20to=20have=20jabber=20sessions\,=20and=20=
whatever=20else=20gets=20added=20=0D=0A=20in=20agenda=20bashing.\n\nIf=20=
you=20are=20interested\,=20please=20RSVP=20to=20me=20and=20I=20wi=0D=0A=20=
ll=20provide=20call-in=20information.=0D=0AORGANIZER;CN=3D"Eliot=20=
Lear":mailto:[email-masked]=0D=0AEND:VEVENT=0D=0AEND:VCALENDAR=0D=0A=

--Apple-Mail-1-350282453--

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 27: DURATION/DTEND ?
Date: Tue, 10 Apr 2007 18:37:54 +0200

Am Dienstag, 10. April 2007 schrieb Arnaud Quillaud:
> With the new rule (use the "computed duration of the first instance" for
> all instances), one can no longer create a recurring event that *always*
> starts at 22:00 and always ends at 6:00 the next day.

That has never been possible anyway! It is not a new rule, but has always been 
the case. 
E.g. how would you determine the events for
   DTSTART;TZID=America/Montreal:20070311T000000
   DTEND;TZID=America/Montreal:20070312T000000
   RRULE:FREQ=HOURLY;COUNT=5;INTERVAL=12
if not by taking the duration of the initial event as the event for all 
remaining occurrences?

Cheers,
Reinhold

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

Content-return: prohibited
Date: Tue, 10 Apr 2007 18:23:15 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [Ietf-calsify] Issue 27: DURATION/DTEND ?

Hello,

I have finally made the link between my comment regarding the latest draft (http://lists.osafoundation.org/pipermail/ietf-calsify/2007-April/001665.html) and Issue 27: DURATION/DTEND.

The main scenario that was discussed before changing the text for DTSTART/DTEND was (http://lists.osafoundation.org/pipermail/ietf-calsify/2006-October/001306.html):

<<
Example 2:

   DTSTART;TZID=America/Montreal:20070311T000000
   DTEND;TZID=America/Montreal:20070312T000000
   RRULE:FREQ=DAILY;COUNT=2

   The first instance start at midnight on March 11th, 2007 and is
   specified to end at midnight on March 12th, 2007. Given that on
   that day there is shift from standard time to daylight saving time,
   this instance will actually last 23 hours.

   I believe the duration of the recurrence instance on March 12th,
   2006 should be the "computed duration of the first instance",
   that is, 23 hours.

While this scenario helps to explain what problem we are trying to clarify, it is nevertheless a corner case since the first instance is on a DST boundary. 
Most of the time (more or less 99% of the time), people create recurring events starting on a day where no DST change occurs, and if they specify a start/end time, they expect this start/end time to be the same for all occurrences.

With the new rule (use the "computed duration of the first instance" for all instances), one can no longer create a recurring event that *always* starts at 22:00 and always ends at 6:00 the next day.

My feedback may come really late but I think this is fairly important + from my testing, the new text would also "break" Microsoft Outlook and Apple iCal.

Arnaud Q

Content-return: prohibited
Date: Tue, 10 Apr 2007 15:48:14 +0200
From: Arnaud Quillaud <[email-masked]>
Subject: RE : [Ietf-calsify] new section in recurrence rule definition (exact duration versus nominal duration)
Sender: [email-masked]
To: Tim Hare <[email-masked]>, [email-masked]

> -----Message d'origine-----
> De : [email-masked]=20
> [mailto:[email-masked]] De la part de Tim H=
are
> Envoy=E9 : vendredi 6 avril 2007 04:18
> =C0 : [email-masked]
> Objet : RE: [Ietf-calsify] new section in recurrence rule=20
> definition (exact duration versus nominal duration)
>=20
>=20
> =20
> Proposed language changes to solve some of the vagueness.=20
> Feel free to correct any errors, or improve upon this text:
>=20
> 3.8.2.2 (DTEND)  Add a paragraph to the description which reads:
>=20
> =09DTEND can be used with DTSTART to calculate the=20
> duration of an component. The duration of a component is the=20
> difference between the DTEND time and the DTSTART time. If=20
> the interval from DTSTART to DTEND crosses a timezone shift,=20
> and VALUE parameter is DATE-TIME for DTSTART, then the=20
> calculated duration must account for the time which is gained=20
> or lost during the shift.

Sounds good. Same could be said about DTSTART + DUE properties althou=
gh VTODO with a DUE but no DTSTART are allowed.

>=20
> 3.8.2.5 (DURATION) add a paragraph to the description which reads:
> =09DURATION can be used to calculate the ending date and=20
> time of a component, by adding DURATION to DTSTART. If the=20
> resulting calculation results in an endpoint which is across=20
> a timezone shift from DTSTART, then the endpoint should be=20
> adjusted to account for the time which is gained or lost=20
> during the shift so that the actual duration is equal to that=20
> requested.

This is only true I think if you have a duration only expressed in te=
rms of hours, minutes, seconds.
We need to define the behavior for the 3 cases:
 - a duration expressed in hours, minutes, seconds (dur-time) results=
 in the same exact duration, regardless of the DTSTART
 - a duration expressed in days or weeks (dur-day, dur-week) may resu=
lt in different exact duration depending on the DTSTART
 - duration expressed in a mix of days + hours, minutes, seconds (dur=
-date): same as for days or weeks since one would add days first, the=
n hours/minutes/seconds.

>=20
> 3.8.5.3 (RECURRENCE RULE)
> =09If the duration of the recurring component is specified=20
> with the "DTEND" or "DUE" property, and the VALUE parameter=20
> is DATE-TIME, then the duration applied to all members of the=20
> recurrence set should be calculated as specified for the=20
> "DTEND" component of the first member of the recurrence set,=20
> including adjusting the duration because of the timezone=20
> shift. If the duration is specified with the "DURATION"=20
> property, then the duration should be that specified for the=20
> "DURATION" property, and any calculations to determine the=20
> end date and time of the member must make adjustments for any=20
> timezone shift. For example, expansion of recurrence rules=20
> with a DURATION property of one hour should always result in=20
> individual members of the set with a duration of one hour,=20
> and should not shrink to zero hours or expand to two hours=20
> because of timezone changes.

With the changes above, that make sense.

Arnaud Q
>=20
> Tim Hare
> Interested Bystander, Non-Inc.
>=20
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of=20
> Arnaud Quillaud
> Sent: Thursday, April 05, 2007 3:23 PM
> To: [email-masked]
> Subject: [Ietf-calsify] new section in recurrence rule=20
> definition (exact duration versus nominal duration)
>=20
> Hello,
>=20
> I'm having a hard time trying to understand the following new=20
> section in the recurrence rule definition at:=20
> http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#se
> ction-3.8.5.3
>=20
> <<
> If the duration of the recurring component is specified with the
>       "DTEND" or "DUE" property, then the same exact duration=20
> will apply
>       to all the members of the generated recurrence set. =20
> Else, if the
>       duration of the recurring component is specified with the
>       "DURATION" property, then the same nominal duration=20
> will apply to
>       all the members of the generated recurrence set and the exact
>       duration of each recurrence instance will depend on its speci=
fic
>       start time.  For example, recurrence instances of a nominal
>       duration of one day will have an exact duration of more or le=
ss
>       than 24 hours on a day where a time zone shift occurs.  The
>       duration of a specific recurrence may be modified in an=20
> exception
>       component or simply by using an "RDATE" property of PERIOD va=
lue
>       type.
> >>
>=20
> While browsing the archives, I have found the following=20
> example (from=20
> http://lists.osafoundation.org/pipermail/ietf-calsify/2005-Apr
> il/000482.html
> ) which summarized quite well my layman undestanding of the=20
> difference between using DTSTART+DTEND versus=20
> DTSTART+DURATION in a recurring event.
>=20
> <<
> Case a:
>=20
>   A shift of work: 10pm - 6am. This is when I work, those=20
> times being in
>   my local timezone. Most days my shift will be 8 hours long, on
>   occaisonal days it will be 7, and on others it will 9.
>  =20
> Maybe my company will pay me for the 8 hours on days I only=20
> work 7, thats an accounting issue, not a scheduling issue.=20
> Either way, they don't have two chairs at the security desk=20
> that I work at, there is no point me standing there looking=20
> over the other guards shoulder. Our shifts do not overlap, on any d=
ay.
>=20
> This is an example of when DTEND would be used. DTSTART is=20
> when I start work, DTEND is when I end work, very simple,=20
> always right.
>=20
>=20
> Case b:
>=20
>   My lunch break: it is at 1 AM, and I am allowed 1 hour. I don't g=
et
>   more or less.
>=20
> This is an example of when DURATION would be used.
> >>
>=20
> What I thought was a clear example is in opposition with the=20
> new calsify section, especially with the DTEND part:
>=20
> "If the duration of the recurring component is specified with=20
> the "DTEND" or "DUE" property, then the same exact duration=20
> will apply to all the members of the generated recurrence set."
>=20
> Has the meaning of a DTSTART/DTEND recurring event changed ?=20
> Or is the example above plain wrong ? Or maybe I don't=20
> understand the meaning of "exact duration" ?=20
>=20
> About the DURATION part, I think it would really help to=20
> state (e.g. in the duration definition) what we mean by=20
> nominal duration, for example (taking almost verbatim from=20
> the ISO 8601 definition):
>=20
> <<
> Duration can be expressed by a combination of components with=20
> accurate duration (hour, minute and second) and components=20
> with nominal duration (week and day).
>=20
> The duration of a calendar week or a calendar day depends on=20
> its position in the calendar. Therefore, the exact duration=20
> of a nominal duration can only be evaluated if the duration=20
> of the calendar years, calendar months, calendar weeks or=20
> calendar days used are known.
> >>
>=20
> Finally, in most cases, a DURATION will contain only accurate=20
> durations and hence, all instances will have the same exact=20
> duration. A few extra words could clarify that I think.=20
> Something like:
>=20
>       If the
>       duration of the recurring component is specified with the
>       "DURATION" property, then **that same duration** will apply t=
o
>       all the members of the generated recurrence set. **If=20
> this duration contains values with nominal duration**, the exact
>       duration of each recurrence instance will depend on its speci=
fic
>       start time.  For example, recurrence instances of a nominal
>       duration of one day will have an exact duration of more or le=
ss
>       than 24 hours on a day where a time zone shift occurs...
>=20
>=20
> Arnaud Q
>=20
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]=20
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>=20
>=20
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]=20
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>=20

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] new section in recurrence rule definition (exact duration versus nominal duration)
Date: Thu, 5 Apr 2007 22:18:06 -0400

Proposed language changes to solve some of the vagueness. Feel free to
correct any errors, or improve upon this text:

3.8.2.2 (DTEND)  Add a paragraph to the description which reads:

	DTEND can be used with DTSTART to calculate the duration of an
component. The duration of a component is the difference between the DTEND
time and the DTSTART time. If the interval from DTSTART to DTEND crosses a
timezone shift, and VALUE parameter is DATE-TIME for DTSTART, then the
calculated duration must account for the time which is gained or lost during
the shift.

3.8.2.5 (DURATION) add a paragraph to the description which reads:
	DURATION can be used to calculate the ending date and time of a
component, by adding DURATION to DTSTART. If the resulting calculation
results in an endpoint which is across a timezone shift from DTSTART, then
the endpoint should be adjusted to account for the time which is gained or
lost during the shift so that the actual duration is equal to that
requested.

3.8.5.3 (RECURRENCE RULE)
	If the duration of the recurring component is specified with the
"DTEND" or "DUE" property, and the VALUE parameter is DATE-TIME, then the
duration applied to all members of the recurrence set should be calculated
as specified for the "DTEND" component of the first member of the recurrence
set, including adjusting the duration because of the timezone shift. If the
duration is specified with the "DURATION" property, then the duration should
be that specified for the "DURATION" property, and any calculations to
determine the end date and time of the member must make adjustments for any
timezone shift. For example, expansion of recurrence rules with a DURATION
property of one hour should always result in individual members of the set
with a duration of one hour, and should not shrink to zero hours or expand
to two hours because of timezone changes.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Arnaud Quillaud
Sent: Thursday, April 05, 2007 3:23 PM
To: [email-masked]
Subject: [Ietf-calsify] new section in recurrence rule definition (exact
duration versus nominal duration)

Hello,

I'm having a hard time trying to understand the following new section in the
recurrence rule definition at:
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.8.5.3

<<
If the duration of the recurring component is specified with the
      "DTEND" or "DUE" property, then the same exact duration will apply
      to all the members of the generated recurrence set.  Else, if the
      duration of the recurring component is specified with the
      "DURATION" property, then the same nominal duration will apply to
      all the members of the generated recurrence set and the exact
      duration of each recurrence instance will depend on its specific
      start time.  For example, recurrence instances of a nominal
      duration of one day will have an exact duration of more or less
      than 24 hours on a day where a time zone shift occurs.  The
      duration of a specific recurrence may be modified in an exception
      component or simply by using an "RDATE" property of PERIOD value
      type.

While browsing the archives, I have found the following example (from
http://lists.osafoundation.org/pipermail/ietf-calsify/2005-April/000482.html
) which summarized quite well my layman undestanding of the difference
between using DTSTART+DTEND versus DTSTART+DURATION in a recurring event.

<<
Case a:

  A shift of work: 10pm - 6am. This is when I work, those times being in
  my local timezone. Most days my shift will be 8 hours long, on
  occaisonal days it will be 7, and on others it will 9.
  
Maybe my company will pay me for the 8 hours on days I only work 7, thats an
accounting issue, not a scheduling issue. Either way, they don't have two
chairs at the security desk that I work at, there is no point me standing
there looking over the other guards shoulder. Our shifts do not overlap, on
any day.

This is an example of when DTEND would be used. DTSTART is when I start
work, DTEND is when I end work, very simple, always right.

Case b:

  My lunch break: it is at 1 AM, and I am allowed 1 hour. I don't get
  more or less.

This is an example of when DURATION would be used.

What I thought was a clear example is in opposition with the new calsify
section, especially with the DTEND part:

"If the duration of the recurring component is specified with the "DTEND" or
"DUE" property, then the same exact duration will apply to all the members
of the generated recurrence set."

Has the meaning of a DTSTART/DTEND recurring event changed ? Or is the
example above plain wrong ? Or maybe I don't understand the meaning of
"exact duration" ? 

About the DURATION part, I think it would really help to state (e.g. in the
duration definition) what we mean by nominal duration, for example (taking
almost verbatim from the ISO 8601 definition):

<<
Duration can be expressed by a combination of components with accurate
duration (hour, minute and second) and components with nominal duration
(week and day).

The duration of a calendar week or a calendar day depends on its position in
the calendar. Therefore, the exact duration of a nominal duration can only
be evaluated if the duration of the calendar years, calendar months,
calendar weeks or calendar days used are known.

Finally, in most cases, a DURATION will contain only accurate durations and
hence, all instances will have the same exact duration. A few extra words
could clarify that I think. Something like:

      If the
      duration of the recurring component is specified with the
      "DURATION" property, then **that same duration** will apply to
      all the members of the generated recurrence set. **If this duration
contains values with nominal duration**, the exact
      duration of each recurrence instance will depend on its specific
      start time.  For example, recurrence instances of a nominal
      duration of one day will have an exact duration of more or less
      than 24 hours on a day where a time zone shift occurs...

Arnaud Q

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

Content-return: prohibited
Date: Thu, 05 Apr 2007 21:22:48 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [Ietf-calsify] new section in recurrence rule definition (exact duration versus nominal duration)

Hello,

I'm having a hard time trying to understand the following new section in the recurrence rule definition at: http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.8.5.3

<<
If the duration of the recurring component is specified with the
      "DTEND" or "DUE" property, then the same exact duration will apply
      to all the members of the generated recurrence set.  Else, if the
      duration of the recurring component is specified with the
      "DURATION" property, then the same nominal duration will apply to
      all the members of the generated recurrence set and the exact
      duration of each recurrence instance will depend on its specific
      start time.  For example, recurrence instances of a nominal
      duration of one day will have an exact duration of more or less
      than 24 hours on a day where a time zone shift occurs.  The
      duration of a specific recurrence may be modified in an exception
      component or simply by using an "RDATE" property of PERIOD value
      type.

While browsing the archives, I have found the following example (from http://lists.osafoundation.org/pipermail/ietf-calsify/2005-April/000482.html) which summarized quite well my layman undestanding of the difference between using DTSTART+DTEND versus DTSTART+DURATION in a recurring event.

<<
Case a:

  A shift of work: 10pm - 6am. This is when I work, those times being in
  my local timezone. Most days my shift will be 8 hours long, on
  occaisonal days it will be 7, and on others it will 9.
  
Maybe my company will pay me for the 8 hours on days I only work 7,
thats an accounting issue, not a scheduling issue. Either way, they
don't have two chairs at the security desk that I work at, there is no
point me standing there looking over the other guards shoulder. Our
shifts do not overlap, on any day.

This is an example of when DTEND would be used. DTSTART is when I start
work, DTEND is when I end work, very simple, always right.

Case b:

  My lunch break: it is at 1 AM, and I am allowed 1 hour. I don't get
  more or less.

This is an example of when DURATION would be used.

What I thought was a clear example is in opposition with the new calsify section, especially with the DTEND part:

"If the duration of the recurring component is specified with the "DTEND" or "DUE" property, then the same exact duration will apply to all the members of the generated recurrence set."

Has the meaning of a DTSTART/DTEND recurring event changed ? Or is the example above plain wrong ? Or maybe I don't understand the meaning of "exact duration" ? 

About the DURATION part, I think it would really help to state (e.g. in the duration definition) what we mean by nominal duration, for example (taking almost verbatim from the ISO 8601 definition):

<<
Duration can be expressed by a combination of components with accurate duration (hour, minute and second)
and components with nominal duration (week and day).

The duration of a calendar week or a calendar day depends on its position
in the calendar. Therefore, the exact duration of a nominal duration can only be evaluated if the duration of the calendar
years, calendar months, calendar weeks or calendar days used are known.

Finally, in most cases, a DURATION will contain only accurate durations and hence, all instances will have the same exact duration. A few extra words could clarify that I think. Something like:

      If the
      duration of the recurring component is specified with the
      "DURATION" property, then **that same duration** will apply to
      all the members of the generated recurrence set. **If this duration contains values with nominal duration**, the exact
      duration of each recurrence instance will depend on its specific
      start time.  For example, recurrence instances of a nominal
      duration of one day will have an exact duration of more or less
      than 24 hours on a day where a time zone shift occurs...

Arnaud Q

Date: Wed, 04 Apr 2007 15:33:49 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Aki Niemi <[email-masked]>
Subject: Re: [Ietf-calsify] 2445bis Abstract
Cc: [email-masked]

I've updated the draft with the text proposed by Cyrus.

Cheers,
Bernard

Aki Niemi wrote:
> On Mon, 2007-03-26 at 13:06 -0400, ext Cyrus Daboo wrote:
>> I would prefer something like the following:
>>
>>    This document defines the iCalendar data format for representing and
>>    exchanging calendaring and scheduling information such as events, to-
>>    dos, journal entries and free/busy information, independent of any
>>    particular calendar service or protocol.
> 
> +1
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Subject: Re: [Ietf-calsify] 2445bis Abstract
From: Aki Niemi <[email-masked]>
To: ext Cyrus Daboo <[email-masked]>
Organization: Nokia
Date: Wed, 04 Apr 2007 15:19:04 +0300
Cc: [email-masked]

On Mon, 2007-03-26 at 13:06 -0400, ext Cyrus Daboo wrote:
> I would prefer something like the following:
> 
>    This document defines the iCalendar data format for representing and
>    exchanging calendaring and scheduling information such as events, to-
>    dos, journal entries and free/busy information, independent of any
>    particular calendar service or protocol.

+1

Date: Tue, 03 Apr 2007 14:23:26 +0200
From: Arnaud Quillaud <[email-masked]>
Subject: Re: [Ietf-calsify] iTIP and overridden instances
Sender: [email-masked]
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]

Cyrus Daboo wrote:
> Hi folks,
> Here's a question about iTIP and overridden instances. Example, an 
> organizer sends out a weekly recurring meeting to a set of attendees, 
> using SEQUENCE:0. At some later point the organizer decides to add 
> another attendee to one instance of that meeting only. What does the 
> organizer now do in terms of iTIP messaging? Clearly the organizer 
> would send a copy of that single overridden instance in an iTIP 
> REQUEST to the new attendee. But what should the SEQUENCE be
(the following is not based on any actual implementation)

If it is the only change, I would say , keep it to 0.
If you bump it to 1 and assuming that some other attendees have not 
responded yet, those attendees may later on send a response with 
sequence 0. It is now hard to decide whether you should accept those 
"outdated" responses or discard them since there are other cases where 
you really want to discard them (e.g. change in start time).
> on that? Should the other attendees be notified of the change by also 
> sending a new REQUEST to them, and if so what is the SEQUENCE number?

Ideally, you could send a REQUEST with sequence 0 and RSVP set to false 
(for all attendees who have already replied) which would be silently 
merged by the attendees CUA with their own copy but in fact, most of the 
time, the REQUEST appears as a new invitation in the mail/calendar 
client on the attendee side. As an end user, I consider this to be an 
annoyance, especially for large meetings.

For what it is worth, Outlook is popping up a dialog box ("send only to 
new attendee or send to all ?"). This is probably the best option as 
only the end user can really determine whether a change is worth an update.

Arnaud Q

>
> I am going to pose some more questions about SEQUENCE number with 
> other scheduling scenarios to try and get a better understanding of 
> what people believe it is meant to do, so that it can better be 
> defined in the spec.
>