[Ietf-calsify] Items for Calsify meeting agenda

[daboo at isamet.com (Cyrus Daboo)]

Hi,
I would like to request an item on the Calsify meeting agenda to discuss 
the current status of the CalDAV draft. Whilst that is not a WG item, we 
(the authors) do plan on having an informal last call for it on the calsify 
and caldav lists (as well as suitable webdav lists) prior to submission to 
the IESG. One of the other authors will be at the meeting to discuss this - 
I get to miss out on great French cuisine this time around :-(

I would also like to request an agenda item to discuss (and bring to 
people's awareness) the issue of the proposed daylight savings time changes 
in the US. Again this is not really a WG item but its effect has serious 
repercussions for iCalendar based products, and there are some issues as to 
how best such a change might be accomplished.

-- 
Cyrus Daboo
From Dave.Thewlis at calconnect.org  Thu Jul 21 14:13:35 2005
From: Dave.Thewlis at calconnect.org (Dave Thewlis)
Date: Thu Jul 21 14:13:49 2005
Subject: [Ietf-calsify] Results of the Calconnect Recurrence Questionnaire
	are available
Message-ID: <[e-mail]>

An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050721/2d648d72/attachment.htm
From jwn2 at qualcomm.com  Thu Jul 21 14:43:35 2005
From: jwn2 at qualcomm.com (John W Noerenberg II)
Date: Thu Jul 21 14:46:52 2005
Subject: [Ietf-calsify] Bare Naked VEVENT
Message-ID: <p07000c00bf05c18cef5c@[129.46.77.33]>

Maybe I'm too stupid but I'm unclear on the interpretation of a 
collection of iCalendar objects.

Recently, I've been experimenting with collections of iCalendar that 
describe events, etc, and reading Chris' update on 2445 (Nice work, 
btw).

There's a certain, well-known, widely-used scheduling application 
that chokes if an iCalendar specification containing a VEVENT lacks a 
VTIMEZONE.  As far as I can tell from 2445 (or 2445bis) a VEVENT 
doesn't require the presence of a VTIMEZONE, but it is not definitive.

I've looked through my archives of CalSch and Calsify, but no one 
seems to have discussed this.

Is there consensus on this or did this come up in the interop testing 
to date and I've missed it?

Thanks!
-- 

john noerenberg
   ----------------------------------------------------------------------
   Statt des t?richten Ignorabimus hei?e im Gegenteil unsere L?sung:
   Wir m?ssen wissen, Wir werden wissen.
   -- David Hilbert, "Logic and the Understanding of Nature, Sep 1930
   ----------------------------------------------------------------------
From Doug at Royer.com  Thu Jul 21 15:01:58 2005
From: Doug at Royer.com (Doug Royer)
Date: Thu Jul 21 15:02:08 2005
Subject: [Ietf-calsify] Bare Naked VEVENT
In-Reply-To: <p07000c00bf05c18cef5c@[129.46.77.33]>
References: <p07000c00bf05c18cef5c@[129.46.77.33]>
Message-ID: <[e-mail]>

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/20050721/24407abd/smime.bin
From jwn2 at qualcomm.com  Thu Jul 21 16:15:50 2005
From: jwn2 at qualcomm.com (John W Noerenberg II)
Date: Thu Jul 21 16:16:53 2005
Subject: [Ietf-calsify] Bare Naked VEVENT
In-Reply-To: <[e-mail]>
References: <p07000c00bf05c18cef5c@[129.46.77.33]> <[e-mail]>
Message-ID: <p07000c03bf05d1ffca2e@[129.46.77.33]>

At 4:01 PM -0600 7/21/05, Doug Royer wrote:
>If an entry is tied to a time zone, a TZID and an associated 
>VTIMEZONE MUST BE included.  DTSTART;TZID=PST;20050101T000000 starts 
>at midnight New Years Day in the PST time zone and a PST VTIMEZONE 
>MUST BE included.
>
>So a VTIMEZONE is only supplied when any DATE or DATE-TIME
>value includes a TZID parameter. [or as Robert notes below... - jwn2]

Ah.  Very clear, Doug.  Thank you!

>
>And yes, some vendors are not 2445/2446/2447 compliant.

I'm shocked.  Shocked! :-)

At 6:03 PM -0400 7/21/05, [e-mail] wrote:
>4.6.5 Time Zone Component
>The "VTIMEZONE" calendar component MUST be present if the iCalendar
>   object contains an RRULE that generates dates on both sides of a time
>   zone shift

Yes, this is true.  I didn't make myself clear.  If an iCalendar 
object contains no VEVENT, VTODO, or VJOURNAL components that 
includes an RRULE, then a VTIMEZONE object isn't required.  But what 
about an object with an RDATE that spans a time zone shift?  Better 
here would be:

[Line 1758 of 2445bis]:	...contains an RRULE or RDATE that generates....

EXDATEs and EXRULEs con only occur if there's a recurrence rule, so 
perhaps there's no need to mention them.

-- 

john noerenberg
[e-mail]
   ----------------------------------------------------------------------
   Like the Sorcerer's Apprentice, we succeeded beyond our
   wildest dreams and our worst fears.
   -- Steve Crocker, quoted in Wired Magazine, Apr, 1999
   ----------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050721/7f24280f/attachment.html
From reinhold at kainhofer.com  Thu Jul 21 16:33:52 2005
From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Thu Jul 21 16:34:11 2005
Subject: [Ietf-calsify] Bare Naked VEVENT
In-Reply-To: <p07000c03bf05d1ffca2e@[129.46.77.33]>
References: <p07000c00bf05c18cef5c@[129.46.77.33]> <[e-mail]>
	<p07000c03bf05d1ffca2e@[129.46.77.33]>
Message-ID: <[e-mail]>

Am Freitag, 22. Juli 2005 01:15 schrieb John W Noerenberg II:
> At 6:03 PM -0400 7/21/05, [e-mail] wrote:
> >4.6.5 Time Zone Component
> >The "VTIMEZONE" calendar component MUST be present if the iCalendar
> >   object contains an RRULE that generates dates on both sides of a time
> >   zone shift

Actually, this is not really correct. If the DTSTART is a DATE value (i.e. no 
time attached), the TZID is not necessary (so it's not dates on both sides, 
but rather times on both sides).

Also notice that if DTSTART is given in UTC, there are no time zone shifts, so 
a VTIMEZONE doesn't have to be present in that case.


> Yes, this is true.  I didn't make myself clear.  If an iCalendar
> object contains no VEVENT, VTODO, or VJOURNAL components that
> includes an RRULE, then a VTIMEZONE object isn't required.  But what
> about an object with an RDATE that spans a time zone shift?  

Depends on which format you use for the RDATE. Again, the three different ways 
to represent times in iCalendar (as described by Doug) come into play. Only 
if the RDATE is relative to a time zone, then the VTIMEZONE is important.

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [e-mail], 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 maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050722/3abe1ec1/attachment-0001.pgp
From Doug at Royer.com  Thu Jul 21 17:27:03 2005
From: Doug at Royer.com (Doug Royer)
Date: Thu Jul 21 17:27:27 2005
Subject: [Ietf-calsify] Bare Naked VEVENT
In-Reply-To: <[e-mail]>
References: <p07000c00bf05c18cef5c@[129.46.77.33]>
	<[e-mail]>	<p07000c03bf05d1ffca2e@[129.46.77.33]>
	<[e-mail]>
Message-ID: <[e-mail]>

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/20050721/f7008c97/smime.bin
From Doug at Royer.com  Thu Jul 21 17:29:50 2005
From: Doug at Royer.com (Doug Royer)
Date: Thu Jul 21 17:30:04 2005
Subject: [Ietf-calsify] Bare Naked VEVENT
In-Reply-To: <p07000c03bf05d1ffca2e@[129.46.77.33]>
References: <p07000c00bf05c18cef5c@[129.46.77.33]> <[e-mail]>
	<p07000c03bf05d1ffca2e@[129.46.77.33]>
Message-ID: <[e-mail]>

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/20050721/52d8f605/smime.bin
From reinhold at kainhofer.com  Mon Jul 25 06:05:10 2005
From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Mon Jul 25 06:05:17 2005
Subject: [Ietf-calsify] Bare Naked VEVENT
In-Reply-To: <[e-mail]>
References: <p07000c00bf05c18cef5c@[129.46.77.33]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Friday 22 July 2005 02:27, Doug Royer wrote:
> Reinhold Kainhofer wrote:
> > Am Freitag, 22. Juli 2005 01:15 schrieb John W Noerenberg II:
> >>At 6:03 PM -0400 7/21/05, [e-mail] wrote:
> >>>4.6.5 Time Zone Component
> >>>The "VTIMEZONE" calendar component MUST be present if the iCalendar
> >>>  object contains an RRULE that generates dates on both sides of a time
> >>>  zone shift
>
> And that single sentence goes on to say "...  (e.g. both in
> Standard Time and Daylight Saving Time) unless the iCalendar
> object intends to convey a floating time (See the
> section "4.1.10.11 Time" for proper interpretation of floating time).

Oops, I blame my carelessness on the time (1:30 am...).

> > Actually, this is not really correct. If the DTSTART is a DATE value
> > (i.e. no time attached), the TZID is not necessary (so it's not dates on
> > both sides, but rather times on both sides).
>
> I do not think that a DATE or DATE-TIME value is what makes TZID
> optional.

Reading up a bit on the old mailing list archive, it came up every now and 
then that an event with only a DATE value is really meant as whole day, 
without a time associated. See e.g. your own post:
http://www.imc.org/ietf-calendar/archive1/msg03650.html

But yes, that's only one aspect.:

> So if you want it relative to a TZID, specify 
> a TZID and include a VTIMEZONE, else specify it in UTC which has
> no time zone shifts, or floating in which case it can be variable length
> (as seen by the wall clock to the observer).

Right, DATE events seem to need the same settings as timed events. Thanks for 
pointing this out. All three situations (UTC, relative to TZID or floating) 
also make sense for DATE events...

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [e-mail], 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 maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050725/2df93de3/attachment.pgp
From reinhold at kainhofer.com  Thu Jul 28 03:44:49 2005
From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Thu Jul 28 03:45:04 2005
Subject: [Ietf-calsify] Umlaute in Organizer field
Message-ID: <[e-mail]>

Hi guys,
It may be a bit off-topic, but still, since here are all you guys who might 
also have had this problem:

AFAICS, rfc 2445 allows special characters like the German Umlaute ??????? in 
the CN field of the organizer or the attendee (since iCalendar is UTF-8 by 
default). Is this correct? Or am I wrong in my interpretation of the rfc 
here?
Now, the problem is that Outlook 2003 refuses to accept any such invitation if 
the CN of an attendee or the organizer contains Umlauts. 

Now, clearly you want the name of the attendee in your event (only the email 
alone doesn't really tell you anything if the email is 
[e-mail] or the like), but you also want outlook to accept 
your invitations. Does anyone know if there is any way (i.e. using a 
different encoding, somehow escaping the special letters, etc.) to make 
outlook accept the invitation, while still staying rfc-compliant and keep 
interopability of iTIP with other clients?
Or is the only way to send out invitations with the CN omitted if the name 
contains special letters?

Thanks a lot,
Reinhold
-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [e-mail], 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 maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050728/49b25cd9/attachment.pgp
From daboo at isamet.com  Thu Jul 28 06:49:41 2005
From: daboo at isamet.com (Cyrus Daboo)
Date: Thu Jul 28 06:49:55 2005
Subject: [Ietf-calsify] Umlaute in Organizer field
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

Hi Reinhold,

--On July 28, 2005 12:44:49 PM +0200 Reinhold Kainhofer 
<[e-mail]> wrote:

> It may be a bit off-topic, but still, since here are all you guys who
> might  also have had this problem:
>
> AFAICS, rfc 2445 allows special characters like the German Umlaute
> ??????? in  the CN field of the organizer or the attendee (since
> iCalendar is UTF-8 by  default). Is this correct? Or am I wrong in my
> interpretation of the rfc  here?
> Now, the problem is that Outlook 2003 refuses to accept any such
> invitation if  the CN of an attendee or the organizer contains Umlauts.

Are you absolutely sure that the utf-8 charset is listed on the invitation?

> Now, clearly you want the name of the attendee in your event (only the
> email  alone doesn't really tell you anything if the email is
> [e-mail] or the like), but you also want outlook to
> accept  your invitations. Does anyone know if there is any way (i.e.
> using a  different encoding, somehow escaping the special letters, etc.)
> to make  outlook accept the invitation, while still staying rfc-compliant
> and keep  interopability of iTIP with other clients?
> Or is the only way to send out invitations with the CN omitted if the
> name  contains special letters?

I know for a fact that my implementation treats the text in CN as text 
without any special encoding etc. So if there were an encoding that worked 
with Outlook (e.g. MIME header style encoding) that would certainly break 
my client, and I suspect many others.

Have you tried doing the reverse? i.e. create an event in Outlook where the 
organiser or an attendee's name contains non-ascii and see how Outlook 
'exports' that to iCalendar?

I think this issue clearly sure that we need an area of interop dealing 
with non-ascii characters to verify proper handling of those in all 
products.

-- 
Cyrus Daboo
From reinhold at kainhofer.com  Thu Jul 28 07:03:21 2005
From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Thu Jul 28 07:03:35 2005
Subject: [Ietf-calsify] Umlaute in Organizer field
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Thursday 28 July 2005 15:49, Cyrus Daboo wrote:
> Hi Reinhold,
> <[e-mail]> wrote:
> >
> > AFAICS, rfc 2445 allows special characters like the German Umlaute
> > ??????? in  the CN field of the organizer or the attendee (since
> > iCalendar is UTF-8 by  default). Is this correct? Or am I wrong in my
> > interpretation of the rfc  here?
> > Now, the problem is that Outlook 2003 refuses to accept any such
> > invitation if  the CN of an attendee or the organizer contains Umlauts.
>
> Are you absolutely sure that the utf-8 charset is listed on the invitation?

Sorry, I don't understand this. The invitation (the iCalendar part itself) 
doesn't list any encoding, it's by default in utf-8. The encoding of the 
message is the crucial thing here. Outlook doesn't like it if the message is 
8bit, but with 7bit you can't use umlauts at all...

Till can give you the details (he's the kmail guy).

> Have you tried doing the reverse? i.e. create an event in Outlook where the
> organiser or an attendee's name contains non-ascii and see how Outlook
> 'exports' that to iCalendar?

Outlook simply doesn't send the CN in that case... Which is bad if the email 
address doesn't tell you the name of the person.

> I think this issue clearly sure that we need an area of interop dealing
> with non-ascii characters to verify proper handling of those in all
> products.

Yes, definitely.

Cheers,
Reinhold
-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [e-mail], 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 maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050728/30254ae6/attachment.pgp
From daboo at isamet.com  Thu Jul 28 07:07:09 2005
From: daboo at isamet.com (Cyrus Daboo)
Date: Thu Jul 28 07:07:32 2005
Subject: [Ietf-calsify] Umlaute in Organizer field
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

Hi Reinhold,

--On July 28, 2005 4:03:21 PM +0200 Reinhold Kainhofer 
<[e-mail]> wrote:

>> Are you absolutely sure that the utf-8 charset is listed on the
>> invitation?
>
> Sorry, I don't understand this. The invitation (the iCalendar part
> itself)  doesn't list any encoding, it's by default in utf-8. The
> encoding of the  message is the crucial thing here. Outlook doesn't like
> it if the message is  8bit, but with 7bit you can't use umlauts at all...

You are sending the iCal data via email, right? In which case what, if any, 
charset parameter is listed on the Content-Type header of the MIME part 
containing the iCal data?

> Till can give you the details (he's the kmail guy).
>
>> Have you tried doing the reverse? i.e. create an event in Outlook where
>> the organiser or an attendee's name contains non-ascii and see how
>> Outlook 'exports' that to iCalendar?
>
> Outlook simply doesn't send the CN in that case... Which is bad if the
> email  address doesn't tell you the name of the person.

Hmm, OK.

>> I think this issue clearly sure that we need an area of interop dealing
>> with non-ascii characters to verify proper handling of those in all
>> products.
>
> Yes, definitely.



-- 
Cyrus Daboo
From daboo at isamet.com  Thu Jul 28 07:13:38 2005
From: daboo at isamet.com (Cyrus Daboo)
Date: Thu Jul 28 07:13:53 2005
Subject: [Ietf-calsify] Umlaute in Organizer field
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

Hi Till,

--On July 28, 2005 3:54:16 PM +0200 Till Adam <[e-mail]> wrote:

>> Till can give you the details (he's the kmail guy).
>
> Right, this issue is not about charsets, it's about transfer encoding.
> The  characters are proper utf8, and the mime header states that
> correctly. But as  soon as non-7bit characters are detected in a mail, we
> send it using either  quoted-printable or 8bit content transfer encoding,
> depending on a user  config setting. That seems to throw OL.
> Interestingly umlauts in the summary,  which also trigger the same
> q.p./8bit content transfer encoding behavior seem  to be parsed without
> problems, by OL.

Well I guess at this point we need someone from Microsoft to step in and 
explain what's happening...

-- 
Cyrus Daboo
From helge.hess at opengroupware.org  Thu Jul 28 07:39:54 2005
From: helge.hess at opengroupware.org (Helge Hess)
Date: Thu Jul 28 07:38:55 2005
Subject: [Ietf-calsify] Umlaute in Organizer field
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Jul 28, 2005, at 16:03, Reinhold Kainhofer wrote:
>> Are you absolutely sure that the utf-8 charset is listed on the  
>> invitation?
> Sorry, I don't understand this. The invitation (the iCalendar part  
> itself)
> doesn't list any encoding, it's by default in utf-8.

The encoding of the invitation is the encoding given in the mime-type  
of the mail message as for all text/* MIME types. In the case of  
Outlook 2002 this is:
---snip---
Content-Type: text/calendar; method=REQUEST;
	charset="utf-8"
---snap---
I'm not sure what takes precedence if no charset is specified (iCal  
default or MIME default), which is why you should always specify the  
encoding explicitly.

> The encoding of the message is the crucial thing here. Outlook doesn't  
> like it if the message is 8bit, but with 7bit you can't use umlauts at  
> all...

Don't know what you mean by that. If you can only use ASCII at the  
transport (as usual with SMTP) you would just need to apply some  
content-transfer encoding (QP or base64).

Notably OL 2002 uses 8bit:
---snip---
Content-Transfer-Encoding: 8bit
---snap---

>> Have you tried doing the reverse? i.e. create an event in Outlook  
>> where the organiser or an attendee's name contains non-ascii and see  
>> how Outlook 'exports' that to iCalendar?
> Outlook simply doesn't send the CN in that case... Which is bad if the  
> email address doesn't tell you the name of the person.

I've tried with Outlook 2002 and it sends the CN, with one major bug.

It does both:

a) properly encode the CN in the To/From header
---snip---
From: "Guizmo G" <[e-mail]>
To: "=?utf-8?B?SMO2bGdlIEhlw58=?=" <[e-mail]>
---snap---
This is really base64 encoded UTF-8 (checked with recode).

b) embed the CN in the iCalendar request:
---snip---
BEGIN:VEVENT
ATTENDEE;CN="H?lge He?  
([e-mail])";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO: 
[e-mail]
ORGANIZER:MAILTO:[e-mail]
---snap---
BUT: even though OL specifies the content to be UTF-8, it actually  
sends the iCalendar body in Latin-1 ...

So, how do you like that? ;->

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org