Subject: [Ietf-calsify] Some more issues with RFC 2445

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Sun Jan 28 15:22:34 2007

This weekend, I realized some more minor problems with RFC 2445 in its current 
form:

1) The grammar for VALARM does not allow any iana-registered properties, only 
x-props...

2) One of the biggest obstacles for interoperabilty between applications (data 
exchange using files) currently is that Outlook only imports icalendar files, 
when they have METHOD:PUBLISH set. On the other hand, rfc says in section 
4.8.4.1 (Attendees):
 "This property MUST
   NOT be specified in an iCalendar object when publishing the calendar
   information (e.g., NOT in an iCalendar object that specifies the
   publication of a calendar user's busy time, event, to-do or journal)."
So, when using METHOD:PUBLISH, one cannot export any attendees.
This means that when you want to export all data for outlook, you can either 
generate non-compliant iCalendar files (including attendees and 
METHOD:PUBLISH), or you generate compliant files and loose all attendee 
information!
Some application choose to use the first and generate non-compliant files, 
while others (e.g. KOrganizer/Kontact) generate standards-compliant files, 
which cannot be imported into Outlook.
My suggestion now would be to simply scratch that restriction and allow the 
attendee property also when publishing a calendar. Of course, noone has to 
list the attendees when exporting, but why shouldn't we be allowed to?

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

---

From: TimHare at comcast.net (Tim Hare)
Date: Sun Jan 28 15:52:38 2007

I think (and this is just opinion) that METHOD:PUBLISH was intended
primarily for publishing event data (team schedules and the like); if you
are importing or receiving a datastream to set up a meeting shouldn't
METHOD: be REQUEST?

Also, in 3.7.2 it states: 
>      No methods are defined by this specification.  This is the subject
>      of other specifications, such as the iCalendar Transport-
>      independent Interoperability Protocol (iTIP) defined by
>      [I-D.ietf-calsify-2446bis].

So perhaps this is an issue for 2446? Admittedly this _is_ one element of
confusion that I haven't seen addressed (maybe I've missed it); the 2445
text doesn't specify all of the possible values for components or
properties, this being one of the prime examples.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Reinhold
Kainhofer
Sent: Sunday, January 28, 2007 6:22 PM
To: CALSIFY Mailinglist
Subject: [Ietf-calsify] Some more issues with RFC 2445

This weekend, I realized some more minor problems with RFC 2445 in its
current
form:

1) The grammar for VALARM does not allow any iana-registered properties,
only x-props...

2) One of the biggest obstacles for interoperabilty between applications
(data exchange using files) currently is that Outlook only imports icalendar
files, when they have METHOD:PUBLISH set. On the other hand, rfc says in
section
4.8.4.1 (Attendees):
 "This property MUST

Cheers,
Reinhold
- --
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien,
http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP
SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFvS/8TqjEwhXvPN0RAvKiAJ93fgCGaN08wS+Du99kWouuEjZEVACgiTv1
QSaFv8fUtgBbMhGsO7C/0n8=
=lRKG
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Mon Jan 29 06:34:37 2007

> are importing or receiving a datastream to set up a meeting shouldn't

I'm mainly thinking of two scenarios:

1) about data im/export when switching calendar applications (e.g. when you 
have to switch to windows in your new job). In that case, all information 
should be preserved to the utmost extent. 

2) about publishing e.g. a meeting or conference talk, where the discussion 
panel / speakers are added as attendees to the event, but anyone can listen 
to the talk. I would publish such an event on a web page or on a mailing list 
with METHOD:PUBLISH (because it is publishing, not requesting the event). Why 
shouldn't there be attendees allowed?

> confusion that I haven't seen addressed (maybe I've missed it); 

Right. Thanks for the pointer. So although rfc 2445 does not specify what 
publishing means, it disallows a certain property for this. rfc 2446 already 
has that restriction, so I think it's save to remove that restriction from 
rfc 2445.

Cheers,
Reinhold

- --

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Mon Jan 29 07:30:24 2007

Reinhold Kainhofer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Actually, no components allow iana-registered properties. RFC 2445
neglected to define 'iana-prop'.

While discussing issue 61 during the Jabber session last Friday, we
have agreed to define the following ABNF rules:

   iana-prop = iana-token *(";" other-param) ":" text CRLF
   ; Some other IANA registered iCalendar property.

   other-prop = (iana-prop / x-prop)

and to change 'x-prop' by 'other-prop' in all the component's ABNF

We have also agreed to define the following ABNF rule:

   other-param = (ianaparam / xparam)

and to change 'xparam' to 'other-param' in all the properties' ABNF.

I'll probably rename 'ianaparam' to 'iana-param' and 'xparam' to
'x-param' at the same time for consistency sake...

Cheers,
Bernard