Subject: [Ietf-calsify] _ characters aren't allowed in field names, are they?

From: sroberts at uniserve.com (Sam Roberts)
Date: Fri Jul 29 17:16:25 2005

RFC2425:

     name         = x-name / iana-token

     iana-token   = 1*(ALPHA / DIGIT / "-")

     x-name       = "x-" 1*(ALPHA / DIGIT / "-")

ALPHA is defined in RFC 2234 as a-zA-Z.

I'm wondering because I'm finding X-LOTUS-CHILD_UID in some calendars.
The "lotus child" part is funny, but the _ is causing me to add this
character to those accepted in for group and name.

Anybody else seen this? Is it common?

Sam

-- 
Work is the curse of the climbing class.

Date: Fri, 29 Jul 2005 20:15:49 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [Ietf-calsify]  _ characters aren't allowed in field names, are they?

RFC2425:

     name         = x-name / iana-token

     iana-token   = 1*(ALPHA / DIGIT / "-")

     x-name       = "x-" 1*(ALPHA / DIGIT / "-")

ALPHA is defined in RFC 2234 as a-zA-Z.

I'm wondering because I'm finding X-LOTUS-CHILD_UID in some calendars.
The "lotus child" part is funny, but the _ is causing me to add this
character to those accepted in for group and name.

Anybody else seen this? Is it common?

Sam

-- 
Work is the curse of the climbing class.

From: Till Adam <[email-masked]>
To: "Cameron Stillion" <[email-masked]>
Subject: Re: [Ietf-calsify] Umlaute in Organizer field
Date: Thu, 28 Jul 2005 20:42:27 +0200
Cc: [email-masked]

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

On Thursday 28 July 2005 17:53, Cameron Stillion wrote:
> I'm looking into this, but if you have ical samples with variously encoded
> non-ascii characters, I'd be very happy to take attachments that will help
> my investigation.

Thanks, Cameron, and pleased to make your acquaintance. :) I've sent you an=
=20
iTip invitation which is quoted-printable encoded utf8 and has various=20
umlauts in the CN paramter of the ATTENDEE property. Does that do?

Till

--nextPart1161257.Km6SgCa9yb
Content-Type: application/pgp-signature

--nextPart1161257.Km6SgCa9yb--

Date: Thu, 28 Jul 2005 18:13:45 +0200
From: Arnaud Quillaud <[email-masked]>
Subject: RE : [Ietf-calsify] Umlaute in Organizer field
To: Cameron Stillion <[email-masked]>, Helge Hess <[email-masked]>, Reinhold Kainhofer <[email-masked]>
Cc: [email-masked], Till Adam <[email-masked]>

I'm quite off topic here but from my experience, for the same event, iCal i=
nvitations generated by Outlook + Exchange 2000 and above are usually corre=
ct when invitations generated directly by Outlook XP/2003 (in IMAP+SMTP mod=
e) are bogus (especially in terms of rescheduling e.g. Recurrence-id).

Arnaud

> -----Message d'origine-----
> De : [email-masked]=20
> [mailto:[email-masked]] De la part de=20
> Cameron Stillion
> Envoy=E9 : jeudi 28 juillet 2005 17:54
> =C0 : Helge Hess; Reinhold Kainhofer
> Cc : [email-masked]; Till Adam
> Objet : RE: [Ietf-calsify] Umlaute in Organizer field
>=20
>=20
> I'm looking into this, but if you have ical samples with=20
> variously encoded non-ascii characters, I'd be very happy to=20
> take attachments that will help my investigation.
>=20
> Thanks,
>=20
> cameron
>=20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of=20
> Helge Hess
> Sent: Thursday.28.July.2005 07.40
> To: Reinhold Kainhofer
> Cc: [email-masked]; Till Adam
> Subject: Re: [Ietf-calsify] Umlaute in Organizer field
>=20
> 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.
>=20
> The encoding of the invitation is the encoding given in the=20
> mime-type of the mail message as for all text/* MIME types.=20
> In the case of Outlook 2002 this is:
> ---snip---
> Content-Type: text/calendar; method=3DREQUEST;
> =09charset=3D"utf-8"
> ---snap---
> I'm not sure what takes precedence if no charset is specified=20
> (iCal default or MIME default), which is why you should=20
> always specify the encoding explicitly.
>=20
> > The encoding of the message is the crucial thing here.=20
> Outlook doesn't
> > like it if the message is 8bit, but with 7bit you can't use=20
> umlauts at=20
> > all...
>=20
> Don't know what you mean by that. If you can only use ASCII=20
> at the transport (as usual with SMTP) you would just need to=20
> apply some content-transfer encoding (QP or base64).
>=20
> Notably OL 2002 uses 8bit:
> ---snip---
> Content-Transfer-Encoding: 8bit
> ---snap---
>=20
> >> Have you tried doing the reverse? i.e. create an event in Outlook
> >> where the organiser or an attendee's name contains=20
> non-ascii and see=20
> >> how Outlook 'exports' that to iCalendar?
> > Outlook simply doesn't send the CN in that case... Which is=20
> bad if the
> > email address doesn't tell you the name of the person.
>=20
> I've tried with Outlook 2002 and it sends the CN, with one major bug.
>=20
> It does both:
>=20
> a) properly encode the CN in the To/From header
> ---snip---
> From: "Guizmo G" <[email-masked]>
> To: "=3D?utf-8?B?SMO2bGdlIEhlw58=3D?=3D" <[email-masked]>
> ---snap---
> This is really base64 encoded UTF-8 (checked with recode).
>=20
> b) embed the CN in the iCalendar request:
> ---snip---
> BEGIN:VEVENT
> ATTENDEE;CN=3D"H=F6lge He=DF
> ([email-masked])";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE
> :MAILTO:=20
> [email-masked]=20
> ORGANIZER:MAILTO:[email-masked]
> ---snap---
> BUT: even though OL specifies the content to be UTF-8, it=20
> actually sends the iCalendar body in Latin-1 ...
>=20
> So, how do you like that? ;->
>=20
> Greets,
>    Helge
> --
> http://docs.opengroupware.org/Members/helge/
> OpenGroupware.org
>=20
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]=20
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]=20
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>=20

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] Umlaute in Organizer field
Date: Thu, 28 Jul 2005 18:05:41 +0200
To: "Cameron Stillion" <[email-masked]>
Cc: [email-masked]

--Apple-Mail-2-378136988
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed

On Jul 28, 2005, at 17:53, Cameron Stillion wrote:
> I'm looking into this, but if you have ical samples with variously=20
> encoded non-ascii characters, I'd be very happy to take attachments=20
> that will help my investigation.

Attached is a .zip containing one meeting request sent by OL 2002=20
(incorrect body encoding) and another one with Evolution 2.0 (proper=20
UTF-8 encoding).

The CN with umlauts used is
   "H=F6lge He=DF"

In HTML entity encoding: "H&ouml;lge He&szlig;"

--Apple-Mail-2-378136988
Content-Transfer-Encoding: base64
Content-Type: application/zip;
	x-unix-mode=0644;
	name="iCal-invites.zip"
Content-Disposition: attachment;
	filename=iCal-invites.zip

--Apple-Mail-2-378136988
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org
--Apple-Mail-2-378136988--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Umlaute in Organizer field
Date: Thu, 28 Jul 2005 08:53:57 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Helge Hess" <[email-masked]>, "Reinhold Kainhofer" <[email-masked]>
Cc: [email-masked], Till Adam <[email-masked]>

I'm looking into this, but if you have ical samples with variously =
encoded non-ascii characters, I'd be very happy to take attachments that =
will help my investigation.

Thanks,

cameron

-----Original Message-----
From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Helge Hess
Sent: Thursday.28.July.2005 07.40
To: Reinhold Kainhofer
Cc: [email-masked]; Till Adam
Subject: Re: [Ietf-calsify] Umlaute in Organizer field

On Jul 28, 2005, at 16:03, Reinhold Kainhofer wrote:
>> Are you absolutely sure that the utf-8 charset is listed on the=20
>> 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=3DREQUEST;
	charset=3D"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=20
>> where the organiser or an attendee's name contains non-ascii and see=20
>> 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" <[email-masked]>
To: "=3D?utf-8?B?SMO2bGdlIEhlw58=3D?=3D" <[email-masked]>
---snap---
This is really base64 encoded UTF-8 (checked with recode).

b) embed the CN in the iCalendar request:
---snip---
BEGIN:VEVENT
ATTENDEE;CN=3D"H=F6lge He=DF
([email-masked])";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO=
:=20
[email-masked]
ORGANIZER:MAILTO:[email-masked]
---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

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

From: The IESG <[email-masked]>
To: [email-masked]
Date: Thu, 28 Jul 2005 11:50:50 -0400
Sender: [email-masked]
Cc: [email-masked]
Subject: [Ietf-calsify] WG Action: Calendaring and Scheduling Standards Simplification (calsify)

A new IETF working group has been formed in the Application Area. For additional 
information, please contact the Area Directors or the WG Chairs.

+++

Calendaring and Scheduling Standards Simplification (calsify)
=============================================================

Current Status: Active Working Group

Chair(s):
Lisa Dusseault <[email-masked]>
Aki Niemi <[email-masked]>

Applications Area Director(s):
Ted Hardie <[email-masked]>
Scott Hollenbeck <[email-masked]>

Applications Area Advisor:
Ted Hardie <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/

Description of Working Group:
The Calendaring and Scheduling standards, defined in RFC's 2445, 2446,
and 2447 were released in November 1998, and further described in RFC
3283. They were designed to progress the level of interoperability
between dissimilar calendaring and scheduling systems. The Calendaring
and Scheduling Core Object Specification, iCalendar, succeeded in
establishing itself as the common format for exchanging calendaring
information across the Internet. On the other hand, only basic
interoperability as been achieved between different scheduling systems.

The Calsify working group is chartered to:

(1) Publish the interoperability issues that have arisen between
calendaring and scheduling systems, as well as document the usage of
iCalendar by other specifications.

(2) Revise the Calendaring and Scheduling standards to advance the
state of interoperable calendaring and scheduling by addressing
the published interoperability issues. As far as it is possible, the
working group will ensure backwards compatibility with widely deployed
implementations and other specifications that use it.

(3) Clarify the registration process for iCalendar extensions (i.e.,
the current core object specification only provides a template
to register new properties).

(4) Advance the Calendaring and Scheduling standards to Draft Standard.

(5) Work on transition (upgrade or versioning) mechanisms for calendar
data exchange.

Proposing an XML representation or transformation of iCalendar
objects is out of the scope of this working group.

Goals and Milestones:
Jul 05    Submit draft documenting interoperability issues for use in progressing RFCs to Draft Standard.  
Sep 05    Submit iCalendar bis draft 00, with formatting changes from RFC2445.  
Sep 05    Submit iTIP bis draft 00  
Sep 05    Submit iMIP bis draft 00  
Oct 05    Submit revised interoperability issues draft version based on WG discussion.  
Dec 05    WG decision on what document(s) require transition mechanisms and hopefully 
          rough idea what these will look like (and add new goals if needed)  
Mar 06    WG last call on interoperability issues draft.  
May 06    Submit interoperability issues document to IESG for Informational RFC.  
May 06    Submit version of iCalendar bis draft that addresses known interoperability 
          issues from interop events.  
Jun 06    Submit versions of iTIP and iMIP that address known interoprability issues.  
Jul 06    Submit version of iCalendar draft that addresses WG open discussions.  
Sep 06    Submit version of iCalendar draft ready for WG last call.  
Nov 06    Complete WG last call of iCalendar and submit new draft.  
Nov 06    Submit versions of iTIP and iMIP ready for last call.  
Jan 07    Submit iCalendar (bis) to IESG for Draft Standard.  
Jan 07    Complete WG last call of iTIP  
Feb 07    Complete WG last call of iMIP  
Mar 07    Submit iTIP to IESG for Draft Standard.  
Apr 07    Submit iMIP to IESG for Draft Standard.  

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] Umlaute in Organizer field
Date: Thu, 28 Jul 2005 16:39:54 +0200
To: Reinhold Kainhofer <[email-masked]>
Cc: [email-masked], Till Adam <[email-masked]>

On Jul 28, 2005, at 16:03, Reinhold Kainhofer wrote:
>> Are you absolutely sure that the utf-8 charset is listed on the =20
>> invitation?
> Sorry, I don't understand this. The invitation (the iCalendar part =20
> 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 =20=

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

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

Don't know what you mean by that. If you can only use ASCII at the =20
transport (as usual with SMTP) you would just need to apply some =20
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 =20
>> where the organiser or an attendee's name contains non-ascii and see =20=

>> how Outlook 'exports' that to iCalendar?
> Outlook simply doesn't send the CN in that case... Which is bad if the =
=20
> 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/=46rom header
---snip---
From: "Guizmo G" <[email-masked]>
To: "=3D?utf-8?B?SMO2bGdlIEhlw58=3D?=3D" <[email-masked]>
---snap---
This is really base64 encoded UTF-8 (checked with recode).

b) embed the CN in the iCalendar request:
---snip---
BEGIN:VEVENT
ATTENDEE;CN=3D"H=F6lge He=DF =20
([email-masked])";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:=
=20
[email-masked]
ORGANIZER:MAILTO:[email-masked]
---snap---
BUT: even though OL specifies the content to be UTF-8, it actually =20
sends the iCalendar body in Latin-1 ...

So, how do you like that? ;->

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

Date: Thu, 28 Jul 2005 10:13:38 -0400
From: Cyrus Daboo <[email-masked]>
To: Till Adam <[email-masked]>, Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] Umlaute in Organizer field
Cc: [email-masked]

Hi Till,

--On July 28, 2005 3:54:16 PM +0200 Till Adam <[email-masked]> 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: Till Adam <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] Umlaute in Organizer field
Date: Thu, 28 Jul 2005 15:54:16 +0200
Cc: [email-masked]

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

On Thursday 28 July 2005 16:03, Reinhold Kainhofer wrote:
> On Thursday 28 July 2005 15:49, Cyrus Daboo wrote:
> > <[email-masked]> wrote:
> > > AFAICS, rfc 2445 allows special characters like the German Umlaute
> > > =D6=C4=DC=F6=E4=FC=DF in  the CN field of the organizer or the attend=
ee (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 Umlaut=
s.
> >
> > 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).

Right, this issue is not about charsets, it's about transfer encoding. The=
=20
characters are proper utf8, and the mime header states that correctly. But =
as=20
soon as non-7bit characters are detected in a mail, we send it using either=
=20
quoted-printable or 8bit content transfer encoding, depending on a user=20
config setting. That seems to throw OL. Interestingly umlauts in the summar=
y,=20
which also trigger the same q.p./8bit content transfer encoding behavior se=
em=20
to be parsed without problems, by OL.

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

And it's also what I would very much like to avoid being forced into=20
duplicating, in Kontact.

Cheerio,

Till

(Please keep me in CC, I'm not on the list, thanks)

--nextPart1537095.aWErRGCecB
Content-Type: application/pgp-signature

--nextPart1537095.aWErRGCecB--

Date: Thu, 28 Jul 2005 10:07:09 -0400
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] Umlaute in Organizer field
Cc: [email-masked], "Adam, Till" <[email-masked]>

Hi Reinhold,

--On July 28, 2005 4:03:21 PM +0200 Reinhold Kainhofer 
<[email-masked]> 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: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Umlaute in Organizer field
Date: Thu, 28 Jul 2005 16:03:21 +0200
Cc: [email-masked], "Adam, Till" <[email-masked]>

--nextPart2233818.dWH67tQ1uh
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 28 July 2005 15:49, Cyrus Daboo wrote:
> Hi Reinhold,
> <[email-masked]> wrote:
> >
> > AFAICS, rfc 2445 allows special characters like the German Umlaute
> > =C3=96=C3=84=C3=9C=C3=B6=C3=A4=C3=BC=C3=9F in  the CN field of the orga=
nizer 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 invitatio=
n?

Sorry, I don't understand this. The invitation (the iCalendar part itself)=
=20
doesn't list any encoding, it's by default in utf-8. The encoding of the=20
message is the crucial thing here. Outlook doesn't like it if the message i=
s=20
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 t=
he
> 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 emai=
l=20
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
=2D-=20
=2D-----------------------------------------------------------------
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.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer

--nextPart2233818.dWH67tQ1uh
Content-Type: application/pgp-signature

--nextPart2233818.dWH67tQ1uh--

Date: Thu, 28 Jul 2005 09:49:41 -0400
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Umlaute in Organizer field
Cc: "Adam, Till" <[email-masked]>

Hi Reinhold,

--On July 28, 2005 12:44:49 PM +0200 Reinhold Kainhofer=20
<[email-masked]> 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
> =C3=96=C3=84=C3=9C=C3=B6=C3=A4=C3=BC=C3=9F 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
> [email-masked] 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=20
without any special encoding etc. So if there were an encoding that worked=20
with Outlook (e.g. MIME header style encoding) that would certainly break=20
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=20
'exports' that to iCalendar?

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

--=20
Cyrus Daboo

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Date: Thu, 28 Jul 2005 12:44:49 +0200
Cc: "Adam, Till" <[email-masked]>
Subject: [Ietf-calsify] Umlaute in Organizer field

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

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

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

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

Thanks a lot,
Reinhold
=2D-=20
=2D-----------------------------------------------------------------
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.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer

--nextPart15838925.t59Ckn63bY
Content-Type: application/pgp-signature

--nextPart15838925.t59Ckn63bY--

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Bare Naked VEVENT
Date: Mon, 25 Jul 2005 15:05:10 +0200

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

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, [email-masked] 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=
=20
then that an event with only a DATE value is really meant as whole day,=20
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=20
> 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 f=
or=20
pointing this out. All three situations (UTC, relative to TZID or floating)=
=20
also make sense for DATE events...

Cheers,
Reinhold

=2D-=20
=2D-----------------------------------------------------------------
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.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer

--nextPart1657627.dDexMl2kzj
Content-Type: application/pgp-signature

--nextPart1657627.dDexMl2kzj--

Date: Thu, 21 Jul 2005 18:29:50 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Bare Naked VEVENT
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms030100090706030204020405
Content-Type: multipart/mixed; boundary="------------030004030906050306030009"

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

I would agree that RDATE would follow the same rules as RRULE.

John W Noerenberg II wrote:
>
> 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.

-- 

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

               We Do Standards - You Need Standards

--------------030004030906050306030009
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------030004030906050306030009--

--------------ms030100090706030204020405
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms030100090706030204020405--

Date: Thu, 21 Jul 2005 18:27:03 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Bare Naked VEVENT
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms060604020205090001090309
Content-Type: multipart/mixed; boundary="------------000900090400080701010006"

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

Reinhold Kainhofer wrote:
> Am Freitag, 22. Juli 2005 01:15 schrieb John W Noerenberg II:
> 
>>At 6:03 PM -0400 7/21/05, [email-masked] 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).

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

That is just another form of floating VEVENT. The problem is the same
one that was part of the DTEND/DURATION debate. How long and how much
space in time do you block out for that instance on your user interface?
If the time shifts, some local times may be 23, 24, or 25 hours in
length for an instance. 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).

-- 

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

               We Do Standards - You Need Standards

--------------000900090400080701010006
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------000900090400080701010006--

--------------ms060604020205090001090309
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms060604020205090001090309--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Bare Naked VEVENT
Date: Fri, 22 Jul 2005 01:33:52 +0200

--nextPart1185921.PA627UXsCt
Content-Type: text/plain;
  charset="iso-8859-6"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Freitag, 22. Juli 2005 01:15 schrieb John W Noerenberg II:
> At 6:03 PM -0400 7/21/05, [email-masked] 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=20
time attached), the TZID is not necessary (so it's not dates on both sides,=
=20
but rather times on both sides).

Also notice that if DTSTART is given in UTC, there are no time zone shifts,=
 so=20
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? =20

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

Cheers,
Reinhold

=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintain=
er

--nextPart1185921.PA627UXsCt
Content-Type: application/pgp-signature

--nextPart1185921.PA627UXsCt--

Date: Thu, 21 Jul 2005 16:15:50 -0700
To: [email-masked]
From: John W Noerenberg II <[email-masked]>
Subject: Re: [Ietf-calsify] Bare Naked VEVENT
Cc: [email-masked]

--============_-1090134691==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

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, [email-masked] 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
[email-masked]
   ----------------------------------------------------------------------
   Like the Sorcerer's Apprentice, we succeeded beyond our
   wildest dreams and our worst fears.
   -- Steve Crocker, quoted in Wired Magazine, Apr, 1999
   ----------------------------------------------------------------------
--============_-1090134691==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [Ietf-calsify] Bare Naked
VEVENT</title></head><body>
<div>At 4:01 PM -0600 7/21/05, Doug Royer wrote:</div>
<blockquote type="cite" cite>If an entry is tied to a time zone, a
TZID and an associated VTIMEZONE MUST BE included.&nbsp;
DTSTART;TZID=PST;20050101T000000 starts at midnight New Years Day in
the PST time zone and a PST VTIMEZONE MUST BE included.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>So a VTIMEZONE is only supplied when any
DATE or DATE-TIME</blockquote>
<blockquote type="cite" cite>value includes a TZID parameter. [<i>or
as Robert notes below... - jwn2</i>]</blockquote>
<div><br></div>
<div>Ah.&nbsp; Very clear, Doug.&nbsp; Thank you!</div>
<div><br></div>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>And yes, some vendors are not
2445/2446/2447 compliant.</blockquote>
<div><br></div>
<div>I'm shocked.&nbsp; Shocked! :-)</div>
<div><br></div>
<div>At 6:03 PM -0400 7/21/05, [email-masked]
wrote:</div>
<blockquote type="cite" cite><tt>4.6.5 Time Zone Component<br>
The &quot;VTIMEZONE&quot; calendar component MUST be present if the
iCalendar<br>
&nbsp; object contains an RRULE that generates dates on both sides of
a time<br>
&nbsp; zone shift</tt></blockquote>
<div><br></div>
<div>Yes, this is true.&nbsp; I didn't make myself clear.&nbsp; If an
iCalendar object contains no VEVENT, VTODO, or VJOURNAL components
that includes an RRULE, then a VTIMEZONE object isn't required.&nbsp;
But what about an object with an RDATE that spans a time zone shift?&nbsp;
Better here would be:</div>
<div><br></div>
<div>[Line 1758 of 2445bis]:<x-tab> </x-tab>...contains an RRULE or
RDATE that generates....</div>
<div><br></div>
<div>EXDATEs and EXRULEs con only occur if there's a recurrence rule,
so perhaps there's no need to mention them.</div>
<div><br></div>
<x-sigsep><pre>-- 
</pre></x-sigsep>
<div><br>
john noerenberg<br>
[email-masked]<br>
&nbsp;
----------------------------------------------------------------------<br
&nbsp; Like the Sorcerer's Apprentice, we succeeded beyond our<br>
&nbsp; wildest dreams and our worst fears.<br>
&nbsp; -- Steve Crocker, quoted in Wired Magazine, Apr, 1999<br>
&nbsp;
----------------------------------------------------------------------</div
</body>
</html>
--============_-1090134691==_ma============--

Date: Thu, 21 Jul 2005 16:01:58 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Bare Naked VEVENT
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090407080308050602060701
Content-Type: multipart/mixed; boundary="------------070809090107000906080602"

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

VEVENT times can be in UTC (Z), floating time, or relative
to a time zone.

UTC times end in Z and do not have a VTIMEZONE.
DTSTART:20050101T000000Z starts at Midnight UTC.

Floating entries cover things like New Years day that
starts and stops at a specific time unique to each time zone.
(EST New Years Day starts 4 hours earlier than PST New Years Day).
These type of entries have no VTIMEZONE and do not include 'Z'.
DTSTART:20050101T000000 starts at Midnight in each observers
time zone and is not tied to UTC or a time zone.

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.

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

John W Noerenberg II wrote:
> 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!

-- 

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

               We Do Standards - You Need Standards

--------------070809090107000906080602
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------070809090107000906080602--

--------------ms090407080308050602060701
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090407080308050602060701--

Date: Thu, 21 Jul 2005 14:43:35 -0700
To: [email-masked]
From: John W Noerenberg II <[email-masked]>
Subject: [Ietf-calsify] Bare Naked VEVENT

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

Date: Thu, 21 Jul 2005 14:13:35 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] Results of the Calconnect Recurrence Questionnaire are available
Reply-To: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Calconnect, the Calendaring and Scheduling Consortium, is happy to
announce the
availability of the Results from the Recurrence Questionnaire which we
conducted in April/May of this year.&nbsp; The results may be found on the
Consortium Website under "Work Products" or directly at <a
 href="http://www.calconnect.org/resultsfromrecurrencequestionnaire.pdf">http://www.calconnect.org/resultsfromrecurrencequestionnaire.pdf</a>.<br>
<br>
The Consortium thanks everyone who offered suggestions and especially
all of those who responded to the questionnaire.&nbsp; We hope that the
information will be of interest to you, and would welcome any feedback
or suggestions; please send to me at the e-mail below and I will ensure
that your comments are received by the Recurrence Technical Committee.<br>
<br>
We also apologize for the length of time it has taken to publish these
results since the cutoff for the questionnaire.&nbsp; We don't expect to
take as long in the future.<br>
<br>
Best regards,<br>
<br>
<br>
Dave Thewlis<br>
<br>
<div class="moz-signature">-- <br>
<b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</div>
</body>
</html>

Date: Wed, 20 Jul 2005 09:59:03 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Items for Calsify meeting agenda

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

Subject: Re: [Ietf-calsify] Fwd: I-D ACTION:draft-cstoner-rfc2445bis-00.txt
Date: Wed, 20 Jul 2005 09:06:19 -0400
To: [email-masked]
From: [email-masked]
Cc: [email-masked]

Reinhold:

I'd love to see your list, as I agree, the RRULE parts of the standard are
rather confusing and have been interpreted in many different ways.
-Chris Stoner

[email-masked] wrote on 07/19/2005 05:05:35 PM:

> Hello Lisa,
>
> Am Dienstag, 19. Juli 2005 22:16 schrieb Lisa Dusseault:
> > This is the first draft updating RFC2445 for Draft Standard.
>
> That's really great news!
> One particular field that needs a lot of care are recurrence rules. While

> implementing a full rrule system (implementing all BY* rule parts,
multiple
> RRULEs and EXRULEs, RDATEs, EXDATEs, etc.), I found lots of places where
rfc
> 2445 is really unclear and leaves things quite open for interpretation.
Since
> recurrence rules are such an integral part of calendar data exchange
(betwen
> apps, attendees and also between client and server), rfc2445bis should
really
> make this a lot clearer.
>
> Where will the discussion on the rfc2445bis happen? Here on calsify or on

> ietf-calendar?
> I'll try to generate a list of issues I think should be cleared to make
the
> rfc unambiguous as far as recurrences are concerned.
>
> Cheers,
> Reinhold
>
> --
> ------------------------------------------------------------------
> Reinhold Kainhofer, Vienna, Austria
> email: [email-masked], http://reinhold.kainhofer.com/
>  * Financial and Actuarial Mathematics, TU Wien,
http://www.fam.tuwien.ac.at
>  * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot
maintainer
> [attachment "att6elqo.dat" deleted by Chris Stoner/Westford/IBM]
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

From: =?ISO-8859-1?Q?Tantek_=C7elik?= <[email-masked]>
Subject: Re: [Ietf-calsify] Rethinking vs measuring
Date: Tue, 19 Jul 2005 19:15:32 -0700
To: Calsify <[email-masked]>

On Jul 19, 2005, at 6:23 PM, Doug Royer wrote:

>
>
> Tantek =C7elik wrote:
>> On Jul 19, 2005, at 5:22 PM, Doug Royer wrote:
>>>
>>> I think that CALSIFY needs to measure what vendors really do
>>> at this time with iCal objects.
>> Agreed.  In fact, I think what vendors really do should=20
>> trump/supercede any "simplification" effort.
>> E.g. vendors support DTEND interoperably.  Therefore we should keep=20=

>> DTEND, regardless of your personal opinion that it is redundant with=20=

>> DURATION.
>
> The problem is not if we have both. The problem is not all vendors
> support both - so it busted. And bused means we can not go
> to 'standard' status.

That is a reasonable assertion to make if you can point to specifics=20
(perhaps you already have and I missed the URL).

My specifics: In my (albeit limited) experience, DTEND is supported=20
just fine (have yet to find any problems with) in both Apple=20
iCal.app/OSX, and Mozilla Sunbird.

> So keeping DTEND vs DURATION 'as is" means that it will
> be difficult to declare that any one object is interoperable.
>
> Even when some of the large vendors use DTEND, they calculate
> it like DURATION. Even some vendors store both DTEND and DURATION
> in their store, they only use the DURATION or calculated DURATION
> value that they have stored, ignoring time zone shifts.
>
> Its not that I 'want' DURATION, its that seems to be how
> the majority of vendors do the time math.

I'm not seeing any of the problems you speak of (probably due to my own=20=

ignorance / naivete / lack of experience).  How recent are the=20
specifics/evidence behind your conclusions?

Admittedly perhaps I am oversimplifying the situation, BUT:

As long as I can publish DTEND properties and have common clients (e.g.=20=

iCal.app and Sunbird) treat it properly/accurately, why should I stop=20
using DTEND?

Thanks,

Tantek

--
Tantek =C7elik
Senior Technologist, Technorati, Inc.

Date: Tue, 19 Jul 2005 19:23:16 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Rethinking vs measuring
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms070003040000070208070305
Content-Type: multipart/mixed; boundary="------------060803080902000009060208"

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

Tantek =C7elik wrote:
> On Jul 19, 2005, at 5:22 PM, Doug Royer wrote:
>=20
>>
>> I think that CALSIFY needs to measure what vendors really do
>> at this time with iCal objects.
>=20
>=20
> Agreed.  In fact, I think what vendors really do should trump/supercede=
=20
> any "simplification" effort.
>=20
> E.g. vendors support DTEND interoperably.  Therefore we should keep=20
> DTEND, regardless of your personal opinion that it is redundant with=20
> DURATION.

The problem is not if we have both. The problem is not all vendors
support both - so it busted. And bused means we can not go
to 'standard' status.

So keeping DTEND vs DURATION 'as is" means that it will
be difficult to declare that any one object is interoperable.

Even when some of the large vendors use DTEND, they calculate
it like DURATION. Even some vendors store both DTEND and DURATION
in their store, they only use the DURATION or calculated DURATION
value that they have stored, ignoring time zone shifts.

Its not that I 'want' DURATION, its that seems to be how
the majority of vendors do the time math.

--=20

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

               We Do Standards - You Need Standards

--------------060803080902000009060208
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------060803080902000009060208--

--------------ms070003040000070208070305
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070003040000070208070305--

From: =?ISO-8859-1?Q?Tantek_=C7elik?= <[email-masked]>
Subject: Re: [Ietf-calsify] Rethinking vs measuring
Date: Tue, 19 Jul 2005 18:08:57 -0700
To: Calsify <[email-masked]>

On Jul 19, 2005, at 5:22 PM, Doug Royer wrote:

>
> I think that CALSIFY needs to measure what vendors really do
> at this time with iCal objects.

Agreed.  In fact, I think what vendors really do should trump/supercede=20=

any "simplification" effort.

E.g. vendors support DTEND interoperably.  Therefore we should keep=20
DTEND, regardless of your personal opinion that it is redundant with=20
DURATION.

>
> I agree that clarifying the text is essential. I also think
> that if 80% of vendors do 'A', then that is the way that
> CALSIFY needs to start with as it will be the fastest
> way to interoperability.

Agreed.

>
> The goal is to make a specification that is interoperable
> with vendors.

By "vendors", I presume you mean *current implementations from vendors*.

> This will go on for years if we re-start iCal
> and what it "should" do.

Also agreed.

>
> I hope we keep the SIMPLIFY part as alive as fixing 2445 errors.

Only if SIMPLIFY doesn't interfere with INTEROP.

INTEROP *must* take precedence over SIMPLIFY.

Thanks,

Tantek

--
Tantek =C7elik
Senior Technologist, Technorati, Inc.

Date: Tue, 19 Jul 2005 18:22:01 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked], [email-masked]
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-calsify] Rethinking vs measuring

This is a cryptographically signed message in MIME format.

--------------ms060807010206000907070507
Content-Type: multipart/mixed; boundary="------------090907020806040209030000"

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

I think that CALSIFY needs to measure what vendors really do
at this time with iCal objects.

I agree that clarifying the text is essential. I also think
that if 80% of vendors do 'A', then that is the way that
CALSIFY needs to start with as it will be the fastest
way to interoperability.

The goal is to make a specification that is interoperable
with vendors. This will go on for years if we re-start iCal
and what it "should" do.

I hope we keep the SIMPLIFY part as alive as fixing 2445 errors.

-- 

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

               We Do Standards - You Need Standards

--------------090907020806040209030000
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------090907020806040209030000--

--------------ms060807010206000907070507
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms060807010206000907070507--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Date: Tue, 19 Jul 2005 23:48:54 +0200
Subject: [Ietf-calsify] Re: Out of scope rule parts?

--nextPart6565253.aOlbUhLNgf
Content-Type: text/plain;
  charset="iso-8859-6"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Dienstag, 19. Juli 2005 16:58 schrieb Laird Nelson:
> RFC 2445 says:
>
>    If BYxxx rule part values are found which are beyond the available
>    scope (ie, BYMONTHDAY=3D30 in February), they are simply ignored.
>
> Consider this (stupid) RRULE:
>
>   RRULE:FREQ=3DSECONDLY;BYMONTH=3D2;BYYEARDAY=3D4;BYHOUR=3D9
>
> Will this *never* generate an occurrence?  That is, does the offending
> BYxxx rule part (BYYEARDAY in this case) cause the "finer grained" BYxxx
> rule parts to be ignored?  Or will the RRULE simply ignore the BYYEARDAY
> part, thus generating an occurrence on every second in the ninth hour in
> February?

Actually, I think this is one of the areas where rfc 2445 is not very clear=
=2E=20
In the following I will use this example:
  DTSTART;TZID=3DEurope/Vienna: 20050201T120000
  RRULE:FREQ=3DMONTHLY;BYMONTHDAY=3D30;FREQ=3D3

In particular, what do the formulation in the rfc mean:

=2D) "beyond the available scope": What is the available scope? If values=20
outside the possible range are given, this is clear. But the example in the=
=20
rfc already is unclear.=20
Is the bymonthday=3D30 out of scope at all? (The rfc gives this as example,=
 so=20
according to the rfc it should be).
Is the bymonthday in the example above beyond the available scope in februa=
ry?=20
Is it beyond the available scope altogether because in february it's out of=
=20
scope (of course not, but the rfc doesn't specify the scope, so one might=20
argue in this direction, too)?

=2D) "simply ignored": Does this mean ignored as in "treated as if that by*=
 part=20
wasn't given at all"?  Or is the resulting occurrence (which would happen a=
t=20
an invalid date) simply ignored?

In particular, in the example above, the wording allows several=20
interpretations... Which should be the correct interpretation of the rfc an=
d=20
the correct resulting list of occurences:
1) Feb 1 2005, May 30 2005, Aug 30, 2005, Nov 30 2005, (February is ignored=
=20
altogether, because BYMONTHDAY=3D30 is out of scope)
2)  Feb 1 2005, May 30 2005, Aug 30 2005, Nov 30 2005, Feb 1 2005 (because=
=20
BYMONTHDAY=3D30 is out of scope for february; the whole BYMONTHDAY is ignor=
ed=20
=3D> date taken from DTSTART), MAY 30 2005, ...
3) Feb 1 2005, May 1 2005, Aug 1 200, Nov 1 2005, ... (The whole BYMONTHDAY=
 is=20
ignored because it's out of scope for february)
4) Only the DTSTART (since the only given bymonthday is not possible for on=
e=20
month, the rfc says that this by** rule part *value* is ignored, leaving us=
=20
with an empty list of bymonthdays, so no occurrences can happen after the=20
dtstart)...

Intuitively, I'd say that 1) would be the most sensible interpretation...=20
Point 2) is not what a user would expect, 4) is definitely not what is=20
intended[1], and 3) is also counter-intuitive, since the rrule explicitly=20
says that it should happen on the 30th.

Cheers,
Reinhold

PS: Back to your example: I'd say that the event doesn't recur at all (i.e.=
=20
only the DTSTART is the only recurrence). But as I said, this is up to=20
interpretation of the rfc and one can argue about the result...

PS2: Your first interpretation (no recurrence at all) is my 1), and your ot=
her=20
possibility (byyearday ignored) is my 3)...

[1] This is rather a stretch of the rfc, since "BYMONTHDAY=3D" (a completel=
y=20
empty bymonthday rule) is not rfc2445-compliant. On the other hand, the rfc=
=20
says that the BY** rule part *value* is ignored, not the complete BY*** rul=
e=20
part!
=2D-=20
=2D-----------------------------------------------------------------
DI Mag. Dr. Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer lead developer

--nextPart6565253.aOlbUhLNgf
Content-Type: application/pgp-signature

--nextPart6565253.aOlbUhLNgf--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked], "Lisa Dusseault" <[email-masked]>
Subject: Re: [Ietf-calsify] Fwd: I-D ACTION:draft-cstoner-rfc2445bis-00.txt
Date: Tue, 19 Jul 2005 23:05:35 +0200

--nextPart1808511.Btd71cc7Oa
Content-Type: text/plain;
  charset="iso-8859-6"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello Lisa,

Am Dienstag, 19. Juli 2005 22:16 schrieb Lisa Dusseault:
> This is the first draft updating RFC2445 for Draft Standard. =20

That's really great news!=20
One particular field that needs a lot of care are recurrence rules. While=20
implementing a full rrule system (implementing all BY* rule parts, multiple=
=20
RRULEs and EXRULEs, RDATEs, EXDATEs, etc.), I found lots of places where rf=
c=20
2445 is really unclear and leaves things quite open for interpretation. Sin=
ce=20
recurrence rules are such an integral part of calendar data exchange (betwe=
n=20
apps, attendees and also between client and server), rfc2445bis should real=
ly=20
make this a lot clearer.=20

Where will the discussion on the rfc2445bis happen? Here on calsify or on=20
ietf-calendar?
I'll try to generate a list of issues I think should be cleared to make the=
=20
rfc unambiguous as far as recurrences are concerned.=20

Cheers,
Reinhold

=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintain=
er

--nextPart1808511.Btd71cc7Oa
Content-Type: application/pgp-signature

--nextPart1808511.Btd71cc7Oa--

To: [email-masked]
Date: Tue, 19 Jul 2005 13:16:30 -0700
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Cc: [email-masked], [email-masked]
Subject: [Ietf-calsify] Fwd: I-D ACTION:draft-cstoner-rfc2445bis-00.txt 

------------iPrdpKLK6geJ0hH5DqFpPp
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
Content-Transfer-Encoding: 8bit

This is the first draft updating RFC2445 for Draft Standard.  No  
substantive features have been removed yet although that's a big part of  
the work ahead of us in CALSIFY.  The first stab at revising RFC2445  
focused on reordering the spec (top-down rather than bottom up) and  
getting it published in time to discuss in Paris (and it will be on the  
agenda, as will interop results relating to future work on this draft).

The XML and HTML versions can be found here:
http://ietf.webdav.org/calsify/rfc2445bis/

Thanks to Chris for taking this on,
Lisa

------- Forwarded message -------
From: [email-masked]
To: [email-masked]
Cc:
Subject: I-D ACTION:draft-cstoner-rfc2445bis-00.txt
Date: Fri, 15 Jul 2005 12:50:01 -0700

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

	Title		: Internet Calendaring and Scheduling Core Object Specification  
(iCalendar)
	Author(s)	: C. Stoner
	Filename	: draft-cstoner-rfc2445bis-00.txt
	Pages		: 165
	Date		: 2005-7-15
	
    Calendar systems export, transport and sometimes even store calendar
    information in a standard, interoperable format.  This memo defines
    the common format for openly exchanging calendaring and scheduling
    information across the Internet, known as the iCalendar object
    format.  An iCalendar object may represent an event, to-do or task,
    or journal entry (note).

    Comments are solicited and should be addressed to the working group's
    mailing list at [email-masked] and/or the editor.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cstoner-rfc2445bis-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the  
message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the  
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-cstoner-rfc2445bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-cstoner-rfc2445bis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
------------iPrdpKLK6geJ0hH5DqFpPp
Content-Disposition: attachment; filename=attachment4244.tmp
Content-Type: application/octet-stream; name=attachment4244.tmp
Content-Transfer-Encoding: Base64

Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNS03LTE1
MTA1NzU1LkktREBpZXRmLm9yZz4NCg0KRU5DT0RJTkcgbWltZQ0KRklMRSAvaW50
ZXJuZXQtZHJhZnRzL2RyYWZ0LWNzdG9uZXItcmZjMjQ0NWJpcy0wMC50eHQNCg==

------------iPrdpKLK6geJ0hH5DqFpPp
Content-Disposition: attachment; filename=attachment4245.tmp
Content-Type: application/octet-stream; name=attachment4245.tmp
Content-Transfer-Encoding: Base64

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
CkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9y
Zw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFu
bm91bmNlDQo=

------------iPrdpKLK6geJ0hH5DqFpPp--

Date: Mon, 11 Jul 2005 10:10:42 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] CalConnect Survey on the use of online event calendars
Reply-To: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
This message is being sent to multiple calendaring lists; my apologies
if you receive it more than once.<br>
<br>
<br class="khtml-block-placeholder">
<div style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;">CalConnect – The
Calendaring and Scheduling Consortium – is conducting a study on the
use of online event calendars within organizations and the need for
more interoperability between them.</span></font></div>
<p style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;"> </span></font></p>
<div style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;">The goal of the
survey is to understand the current state of event calendaring: what
types of calendars are in use (web pages, wikis, blogs, emails, etc);
which commercial and open-source solutions are most popular; what
features are most important; and how the calendars are hosted.</span></font></div>
<p style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;"> </span></font></p>
<div style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;">Your participation
in this survey will require less than 15 minutes of your time and will
help provide the necessary data to complete the study. Thank you in
advance for taking the survey.</span></font></div>
<p style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;"> </span></font></p>
<div style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;">Click on the
following link to take the survey:  &lt;</span></font><a
 href="http://www.dartmouth.edu/%7Ecalendar/survey_reg.html"><font
 class="Apple-style-span"><span class="Apple-style-span"
 style="font-size: 16px;"><font class="Apple-style-span" color="#0023f9">http://www.dartmouth.edu/~calendar/survey_reg.html</font></span></font></a><font
 class="Apple-style-span"><span class="Apple-style-span"
 style="font-size: 16px;">&gt;</span></font></div>
<p style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;"> </span></font></p>
<div style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;">This survey is
sponsored by CalConnect – The Calendaring and Scheduling Consortium – </span></font><a
 href="http://www.calconnect.org/"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;"><font
 class="Apple-style-span" color="#0023f9">http://www.calconnect.org</font></span></font></a></div>
<p style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;"> </span></font></p>
-- <br>
<div class="moz-signature"><b>Dave Thewlis, Executive
Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> · <a
 href="mailto:[email-masked]">[email-masked]</a>
</div>
</body>
</html>

Date: Fri, 08 Jul 2005 12:23:22 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: "[email-masked]" <[email-masked]>
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: [email-masked]
Subject: [Ietf-calsify] TZ: multiple names for same TZID
Reply-To: "[email-masked]" <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms030401070502020208080004
Content-Type: multipart/mixed; boundary="------------020803070108050700060408"

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

Search for the word 'alias' in the draft.

> - Many client application, when using timezones on a server would 
> benefit greatly if they could map the currently selected Operating 
> System timezone to a registry timezone, some support for time zone 
> aliases could possibly bring a solution to this issue.

-- 

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

               We Do Standards - You Need Standards

--------------020803070108050700060408
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------020803070108050700060408--

--------------ms030401070502020208080004
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms030401070502020208080004--

Date: Fri, 08 Jul 2005 13:54:42 -0400
From: Simon Vaillancourt <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] TZ: polygon
Cc: Calsify <[email-masked]>

I'm saying it breaks RFC2445 because the formal definition of a 
VTIMEZONE component does not include anything allowing the addition of 
such property, if the formal definition had a iana-token, then it could 
be added.

--Simon

Doug Royer wrote:

>
> So in other words, you do not know if breaks anything?
> You just think they would break?
>
> Simon Vaillancourt wrote:
>
>> Hello,
>>
>> Doug Royer wrote:
>>
>>>
>>> Any parser that it breaks is not 2445 compliant (unless you
>>> have some specific reason or bug in the draft
>>> you have not yet stated)..
>>>
>>
>> Maybe I missed something in 2445 but, in section 4.6.5, the formal 
>> definition of a VTIMEZONE object does not seem to contain anything 
>> allowing the addition of new non-"x-prop" parameters in a VTIMEZONE 
>> component(i.e.: iana-token). So if you do a parser and it validates 
>> the data using the formal definitions i will break (But yes most 
>> parsers are more forgiving than that).
>>

Date: Fri, 08 Jul 2005 13:23:16 -0400
From: Simon Vaillancourt <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] TZ: registery vs server
Cc: [email-masked]

Doug Royer wrote:

>
>
> Simon Vaillancourt wrote:
>
>> ... I don't believe that specifying the protocol to transfer the 
>> timezones should be included in a registry draft.
>
>
> So your reversing your request that it be HTTP?
>

That's not the point, the first "request" was if it was specified in the 
draft it'd rather be http,  but clearly separating both the concept of 
registry and service is the best option IMO and the current draft is 
mixing both.

--Simon

Date: Fri, 08 Jul 2005 11:18:59 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] TZ: polygon
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: Calsify <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms060600020502060702050608
Content-Type: multipart/mixed; boundary="------------000209060700060309040506"

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

So in other words, you do not know if breaks anything?
You just think they would break?

Simon Vaillancourt wrote:
> Hello,
> 
> Doug Royer wrote:
> 
>>
>> Any parser that it breaks is not 2445 compliant (unless you
>> have some specific reason or bug in the draft
>> you have not yet stated)..
>>
> 
> Maybe I missed something in 2445 but, in section 4.6.5, the formal 
> definition of a VTIMEZONE object does not seem to contain anything 
> allowing the addition of new non-"x-prop" parameters in a VTIMEZONE 
> component(i.e.: iana-token). So if you do a parser and it validates the 
> data using the formal definitions i will break (But yes most parsers are 
> more forgiving than that).
> 
-- 

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

               We Do Standards - You Need Standards

--------------000209060700060309040506
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------000209060700060309040506--

--------------ms060600020502060702050608
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms060600020502060702050608--

Date: Fri, 08 Jul 2005 11:16:08 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] TZ: registery vs server
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: [email-masked]
Reply-To: "[email-masked]" <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms060709030100070904030308
Content-Type: multipart/mixed; boundary="------------050501080409080004020408"

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

Simon Vaillancourt wrote:
> ... I don't believe that 
> specifying the protocol to transfer the timezones should be included in 
> a registry draft.

So your reversing your request that it be HTTP?

-- 

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

               We Do Standards - You Need Standards

--------------050501080409080004020408
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------050501080409080004020408--

--------------ms060709030100070904030308
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms060709030100070904030308--

Date: Fri, 08 Jul 2005 13:15:56 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] TZ: polygon
Cc: Calsify <[email-masked]>

Hi Doug,

--On Friday, July 08, 2005 11:03:09 AM -0600 Doug Royer <[email-masked]> 
wrote:

>> The point is POLYGON is not defined in 2445 - it something new and we
>> should have some solid justification for adding new things to iCalendar
>> right now.
>
> It is not being proposed as part of CALSIFY.
>
> I simply replied to the email on this list.
> I have redirected it to calsch to avoid the confusion.

Well strictly speaking calsify has taken over from calsch. Certainly in 
this case 2445 is clear that new properties have to be registered and it 
does describe an approval process for doing that, but does not define the 
registry itself. That would certainly have to be fixed BEFORE you could 
even define POLYGON etc in your draft. If I am mistaken, one of calsify's 
jobs was to formalise the property/parameter etc registry.

I believe we should not wait for that registry to be setup. We need to get 
a timezone registry up and running as it might be crucial for helping 
vendors and users migrate their timezone definitions if the US government 
ultimately decides to proceed with its plan to change the definition of 
daylight savings time in the US next year. If you're not aware of what I am 
talking about see:

<http://www.calconnect.org/dstadvisorynotice.html>

My preference is to remove POLYGON etc from the timezone registry draft and 
move that forward quickly. Once calsify has defined a viable process for 
creating new standard parameters/properties, POLYGON etc can be defined in 
another draft and IANA can choose to include those in its definitions. But 
until then they should be left out.

-- 
Cyrus Daboo

Date: Fri, 08 Jul 2005 11:12:57 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] TZ: Registry vs authority
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: [email-masked]
Reply-To: "[email-masked]" <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms070201030601040404020903
Content-Type: multipart/mixed; boundary="------------020905080605040202080608"

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

Cyrus Daboo wrote:
> Hi Doug,
> 
> --On July 7, 2005 6:44:53 PM -0600 Doug Royer <[email-masked]> wrote:
> 
>> BEEP profiles can be registered by anyone. I see a similar
>> process for time zones. Time zone definitions will be registered
>> so that the definitions can be shared independent of the
>> authority that originally defined them.
 >
> 
> Allowing anyone to register timezones will mean that no one will trust 
> the registry. It must be a clear who is in charge of or defining the 
> registry information.

Interesting, but that is not the way it works. Any political
organization like a city, state, or county in the US can specify
their time zones. And a few have in our own history.

In addition, the Microsoft OSs do not use the same names for time
zones as UNIX. I see no reason the time zones used by Microsoft
can not also be registered in this registry.

> You bring up the point that maybe there will be more than one 'official' 
> authority in addition to Olson.

That time zone database is also not the authority. They do not claim
to be official or authoritative . The only official time zones are
those defined by the national and regional governments of the word.

> In that case I would want to know the 
> source of the data in the registry.

If I use the FOO time zone, it does not matter who defined it. It
matters that everyone can tell in a standard way when the meetings
will take place. Authority is irrelevant. Consistency between
vendors is relevant in iCal.

-- 

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

               We Do Standards - You Need Standards

--------------020905080605040202080608
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------020905080605040202080608--

--------------ms070201030601040404020903
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070201030601040404020903--

Date: Fri, 08 Jul 2005 11:03:09 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] TZ: polygon
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: Calsify <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms040300010601050506000702
Content-Type: multipart/mixed; boundary="------------060700030604040204010600"

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

Cyrus Daboo wrote:

>>
>> It does NOT break 2445. If anyone thinks it does, point out how.
> 
> 
> The point is POLYGON is not defined in 2445 - it something new and we 
> should have some solid justification for adding new things to iCalendar 
> right now.

It is not being proposed as part of CALSIFY.

I simply replied to the email on this list.
I have redirected it to calsch to avoid the confusion.

-- 

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

               We Do Standards - You Need Standards

--------------060700030604040204010600
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------060700030604040204010600--

--------------ms040300010601050506000702
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040300010601050506000702--

Date: Fri, 08 Jul 2005 10:04:12 -0400
From: Simon Vaillancourt <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] TZ: polygon

Hello,

Doug Royer wrote:

>
> Any parser that it breaks is not 2445 compliant (unless you
> have some specific reason or bug in the draft
> you have not yet stated)..
>

Maybe I missed something in 2445 but, in section 4.6.5, the formal 
definition of a VTIMEZONE object does not seem to contain anything 
allowing the addition of new non-"x-prop" parameters in a VTIMEZONE 
component(i.e.: iana-token). So if you do a parser and it validates the 
data using the formal definitions i will break (But yes most parsers are 
more forgiving than that).

--Simon

Date: Fri, 08 Jul 2005 09:38:07 -0400
From: Simon Vaillancourt <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] TZ: registery vs server

Hello Doug,

Doug Royer wrote:

>
> Step one is create the registry. Then I think that we can decide
> how to write a protocol to get the data as you suggest.
>
> I am not sure if IANA wants to provide a time zone 'server' anyway.
>
>
I agree with you that the first step is to create a registry. But don't 
you think that specifying that the VTIMEZONE objects in ICS files 
located in a well defined path scheme and using the ftp protocol sounds 
a lot like defining a time zone server? I just started reading about 
IANA so I might have missed it but is IANA already providing a similar 
service? At first I would have thought that IANA would maintain a big 
Timezone file(with many VTIMEZONES) or files in a tar(1 VTIMEZONE per 
file), with versioning included and implementors would download that 
file and use it as a base for their services. I don't believe that 
specifying the protocol to transfer the timezones should be included in 
a registry draft. But if I'm wrong please point me to some references, 
I'd be interesed in reading them.

Thanks

--Simon

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] TZ: polygon
Date: Fri, 8 Jul 2005 10:29:32 +0200

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

On Friday 08 July 2005 03:00, Doug Royer wrote:
> Simon Vaillancourt wrote:
> > Hello,
> >   We (CalConnect) sent a time zone questionnaire to many vendors (The
> > results should be available shortly) and preliminary results seem to
> > indicate a great interest in having a standardized time zone registry.
> > Here are some comments from the Timezone Technical Committee of
> > CalConnect about the timezone registry draft
> > (http://www.ietf.org/internet-drafts/draft-royer-timezone-registry-01.t=
xt
> >):
> >
> >
> > - The paragraphs about POLYGON and AREA should be dropped as they add
> > complexity to the draft for a feature that would rarely be used and
> > breaks RFC2445.

Just two non-related comments about POLYGON from my two-second look at the=
=20
draft:

1) The example in section 12 in the draft reads:
        POLYGON;AREA=3DINCLUDE:43.336600,116.13.370000,
What the heck should the second thing mean (I'm not calling it decimal numb=
er,=20
because it's no...)? Same for the EXCLUDE...

2) In section 12 there is the sentence
   Property Parameters: The "AREA" parameter is the only parameter
   allowed.
However, a few lines below, you give the bnf
        polytzparam =3D  area  *( ";" "VALUE" "=3D" "URI" )
and the example=20
   POLYGON;AREA=3DINCLUDE;VALUE=3DURI:http://iana.org/xxx/America/New_York.=
geo
   POLYGON;AREA=3DEXCLUDE:VALUE=3DURI:http://iana.org/xxx/America/Indiana/K=
nox.geo
Both clearly also allow the VALUE parameter...

3) If POLYGON is to stay, why not say that if no AREA parameter is given, i=
t's=20
assumed to be include?=20

Cheers,
Reinhold

=2D-=20
=2D-----------------------------------------------------------------
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.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer

--nextPart1568899.q50FmbMYnv
Content-Type: application/pgp-signature

--nextPart1568899.q50FmbMYnv--

Date: Thu, 07 Jul 2005 23:50:15 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] TZ: Registry vs authority

Hi Doug,

--On July 7, 2005 6:44:53 PM -0600 Doug Royer <[email-masked]> wrote:

> BEEP profiles can be registered by anyone. I see a similar
> process for time zones. Time zone definitions will be registered
> so that the definitions can be shared independent of the
> authority that originally defined them.

Allowing anyone to register timezones will mean that no one will trust the 
registry. It must be a clear who is in charge of or defining the registry 
information.

You bring up the point that maybe there will be more than one 'official' 
authority in addition to Olson. In that case I would want to know the 
source of the data in the registry. One way to do that would be to modify 
the TZID naming scheme to include the name of the authority. e.g.:

        tzid               = "TZID" tzidpropparam ":"
                              ianatzidprefix
                          "/" tzauthority
                          "/" tzregion *( "/" tzregion )
                          "/" tzcity
                          "/" tzrev CRLF

Giving an example of:

TZID:/IANA.ORG/Olson/Indian/Reunion/20050115T112522Z

Each authority token would have to be registered and defined by an RFC that 
receives appropriate peer review. Your current draft would define the 
'Olson' authority.

-- 
Cyrus Daboo

Date: Thu, 07 Jul 2005 23:37:23 -0400
From: Cyrus Daboo <[email-masked]>
To: Doug Royer <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] TZ: registery vs server

Hi Doug,

--On July 7, 2005 6:55:11 PM -0600 Doug Royer <[email-masked]> wrote:

>> - Could the concept of registry be clarified more? Isn't IANA used more
>> as a
>  > reference than as a service? Maybe efforts should first be invested in
>  > defining that registry and then creating another RFC for a timezone
>  > service (Possible extension to CalDAV?).
>
> I think that both of these are talking about a Time Zone server and
> not a registry.
>
> Step one is create the registry. Then I think that we can decide
> how to write a protocol to get the data as you suggest.
>
> I am not sure if IANA wants to provide a time zone 'server' anyway.
>

Right, but currently sections 8 & 9 in the draft describe a mechanism for 
'fetching' timezone info using ftp - i.e. a service. Has IANA actually said 
that they would make the data available via ftp in that way?

-- 
Cyrus Daboo

Date: Thu, 07 Jul 2005 23:10:00 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] TZ: polygon

Hi Doug,

--On July 7, 2005 7:00:40 PM -0600 Doug Royer <[email-masked]> wrote:

>> - The paragraphs about POLYGON and AREA should be dropped as they add
>> complexity to the draft for a feature that would rarely be used and
>> breaks RFC2445.
>
> It does NOT break 2445. If anyone thinks it does, point out how.

The point is POLYGON is not defined in 2445 - it something new and we 
should have some solid justification for adding new things to iCalendar 
right now.

>> If included in an ICS file, it would break many
>> iCalendar file parsers.
>
> Any parser that it breaks is not 2445 compliant (unless you
> have some specific reason or bug in the draft
> you have not yet stated)..

I would like to see a valid use case for POLYGON etc backed up by support 
from implementers before considering what amounts to a new iCalendar 
'feature'.

-- 
Cyrus Daboo

Date: Thu, 07 Jul 2005 19:12:24 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] TZ: polygon
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms050303000208080501020907
Content-Type: multipart/mixed; boundary="------------090503050606070809030308"

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

I also forgot. With the 'server' protocol that I was thinking about.
You can optionally enter your location and the server returns a
list of TZID's that are in that area. (some of this may be on
the older iCalendar mailing list. It has been discussed, I forget
which list).

Doug Royer wrote:
> 
> 
> Simon Vaillancourt wrote:
> 
>> Hello,
>>   We (CalConnect) sent a time zone questionnaire to many vendors (The 
>> results should be available shortly) and preliminary results seem to 
>> indicate a great interest in having a standardized time zone registry. 
>> Here are some comments from the Timezone Technical Committee of 
>> CalConnect about the timezone registry draft 
>> (http://www.ietf.org/internet-drafts/draft-royer-timezone-registry-01.txt): 
>>
>>
>>
>> - The paragraphs about POLYGON and AREA should be dropped as they add 
>> complexity to the draft for a feature that would rarely be used and 
>> breaks RFC2445.
> 
> 
> It does NOT break 2445. If anyone thinks it does, point out how.
> 
>> If included in an ICS file, it would break many  iCalendar file parsers.
> 
> 
> Any parser that it breaks is not 2445 compliant (unless you
> have some specific reason or bug in the draft
> you have not yet stated)..
> 
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

-- 

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

               We Do Standards - You Need Standards

--------------090503050606070809030308
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------090503050606070809030308--

--------------ms050303000208080501020907
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050303000208080501020907--

Date: Thu, 07 Jul 2005 19:00:40 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-calsify] TZ: polygon
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms030903080101010205070504
Content-Type: multipart/mixed; boundary="------------040903010000040209050307"

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

Simon Vaillancourt wrote:
> Hello,
>   We (CalConnect) sent a time zone questionnaire to many vendors (The 
> results should be available shortly) and preliminary results seem to 
> indicate a great interest in having a standardized time zone registry. 
> Here are some comments from the Timezone Technical Committee of 
> CalConnect about the timezone registry draft 
> (http://www.ietf.org/internet-drafts/draft-royer-timezone-registry-01.txt):
> 
>
> - The paragraphs about POLYGON and AREA should be dropped as they add 
> complexity to the draft for a feature that would rarely be used and 
> breaks RFC2445.

It does NOT break 2445. If anyone thinks it does, point out how.

> If included in an ICS file, it would break many  
> iCalendar file parsers.

Any parser that it breaks is not 2445 compliant (unless you
have some specific reason or bug in the draft
you have not yet stated)..

-- 

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

               We Do Standards - You Need Standards

--------------040903010000040209050307
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------040903010000040209050307--

--------------ms030903080101010205070504
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms030903080101010205070504--

Date: Thu, 07 Jul 2005 18:55:11 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked], [email-masked]
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-calsify] TZ: registery vs server

This is a cryptographically signed message in MIME format.

--------------ms050107030902040308060407
Content-Type: multipart/mixed; boundary="------------070807010007000808070407"

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

Simon Vaillancourt wrote:
> Hello,
>   We (CalConnect) sent a time zone questionnaire to many vendors (The 
> results should be available shortly) and preliminary results seem to 
> indicate a great interest in having a standardized time zone registry. 
> Here are some comments from the Timezone Technical Committee of 
> CalConnect about the timezone registry draft 
> (http://www.ietf.org/internet-drafts/draft-royer-timezone-registry-01.txt):
> 
> - It would be useful to retrieve a time zone so that it covers only a 
> specified time range (i.e. Most vendors don't care about ranges before 
> 1970 and it can represent a significant amount of data).
> ,,,
> - Could the concept of registry be clarified more? Isn't IANA used more as a
 > reference than as a service? Maybe efforts should first be invested in
 > defining that registry and then creating another RFC for a timezone
 > service (Possible extension to CalDAV?).

I think that both of these are talking about a Time Zone server and
not a registry.

Step one is create the registry. Then I think that we can decide
how to write a protocol to get the data as you suggest.

I am not sure if IANA wants to provide a time zone 'server' anyway.

-- 

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

               We Do Standards - You Need Standards

--------------070807010007000808070407
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------070807010007000808070407--

--------------ms050107030902040308060407
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050107030902040308060407--

Date: Thu, 07 Jul 2005 18:50:14 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Simon Vaillancourt <[email-masked]>
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: [email-masked]
Subject: [Ietf-calsify] TZ: List of registery contents.

This is a cryptographically signed message in MIME format.

--------------ms080505080204000009010407
Content-Type: multipart/mixed; boundary="------------010008090809070309030007"

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

Simon Vaillancourt wrote:
> Hello,
>   We (CalConnect) sent a time zone questionnaire to many vendors (The 
> results should be available shortly) and preliminary results seem to 
> indicate a great interest in having a standardized time zone registry. 
> Here are some comments from the Timezone Technical Committee of 
> CalConnect about the timezone registry draft 
> (http://www.ietf.org/internet-drafts/draft-royer-timezone-registry-01.txt):
> 
>
> - Should there be a way to list all available timezone names? Or should 
> the draft be updated when a new timezone name gets added/removed?

The registry uses FTP, so issue a DIR command and look.
This works with FTP tools and browsers.

I do not think the draft should be updated. In fact I think
the next rev (coming soon) will not list any in the draft
other that examples which may list names that happen to
be real.

-- 

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

               We Do Standards - You Need Standards

--------------010008090809070309030007
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------010008090809070309030007--

--------------ms080505080204000009010407
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms080505080204000009010407--

Date: Thu, 07 Jul 2005 18:44:53 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-calsify] TZ: Registry vs authority
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms000509020605080408000508
Content-Type: multipart/mixed; boundary="------------060601070508040506010603"

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

Simon Vaillancourt wrote:
> Hello,
>   We (CalConnect) sent a time zone questionnaire to many vendors (The 
> results should be available shortly) and preliminary results seem to 
> indicate a great interest in having a standardized time zone registry. 
> Here are some comments from the Timezone Technical Committee of 
> CalConnect about the timezone registry draft 
> (http://www.ietf.org/internet-drafts/draft-royer-timezone-registry-01.txt):
> 
> - Security issues regarding "who should be updating the registry" should 
> be addressed in the draft.

The issues here is registry versus authority.

Nether the IETF or IANA is the authority for time zone definitions.
I think that all time zone definitions are a political
decisions based on technical input.

My idea was that the registry only register time zones and
not decide if they are authoritative.

BEEP profiles can be registered by anyone. I see a similar
process for time zones. Time zone definitions will be registered
so that the definitions can be shared independent of the
authority that originally defined them.

The idea is that the Time Zone definitions (formally called
the Olson database) be used as a source for the initial
definitions and for updates.

I took a tool that was based on 'zic' (a UNIX time zone
compiler) that takes the Time Zone database as input
and was updated to produce iCal VTIMEZONE definitions.

I would give the IANA folks the tool and source so that they
can run it and create new versions of the registry when
ever the Time Zone database is updated.

My intention was that the draft describe the public
definition and access methods to the registry. I would think
that the process of keeping it updated would be flexible
within IANA.

I am not sure if I answered that point. I am trying to
say that the draft is not a process document for IANA.

Specific suggestions welcome!

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

               We Do Standards - You Need Standards

--------------060601070508040506010603
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------060601070508040506010603--

--------------ms000509020605080408000508
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms000509020605080408000508--

Date: Thu, 07 Jul 2005 15:15:39 -0400
From: Simon Vaillancourt <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [Ietf-calsify] draft-royer-timezone-registry-01 comments

Hello,
   We (CalConnect) sent a time zone questionnaire to many vendors (The 
results should be available shortly) and preliminary results seem to 
indicate a great interest in having a standardized time zone registry. 
Here are some comments from the Timezone Technical Committee of 
CalConnect about the timezone registry draft 
(http://www.ietf.org/internet-drafts/draft-royer-timezone-registry-01.txt):

- Security issues regarding "who should be updating the registry" should 
be addressed in the draft.
- Should there be a way to list all available timezone names? Or should 
the draft be updated when a new timezone name gets added/removed?
- It would be useful to retrieve a time zone so that it covers only a 
specified time range (i.e. Most vendors don't care about ranges before 
1970 and it can represent a significant amount of data).
- Many client application, when using timezones on a server would 
benefit greatly if they could map the currently selected Operating 
System timezone to a registry timezone, some support for time zone 
aliases could possibly bring a solution to this issue.
- The paragraphs about POLYGON and AREA should be dropped as they add 
complexity to the draft for a feature that would rarely be used and 
breaks RFC2445.  If included in an ICS file, it would break many  
iCalendar file parsers.
- Could the concept of registry be clarified more? Isn't IANA used more 
as a reference than as a service? Maybe efforts should first be invested 
in defining that registry and then creating another RFC for a timezone 
service (Possible extension to CalDAV?).
- In the draft the protocol used to transfer the timezones is ftp, many 
people would prefer http or a caldav extension(as previously mentioned 
another draft focusing on the "service" part might be interesting).

Thanks!

--Simon