[ietf-calsify] Issue RK-1 in rfc2445bis-08 (related to issue 37) [Was: IETF Review of the RFC 2446bis-07 (iTIP) draft]
reinhold at kainhofer.com
Thu Oct 16 08:39:19 PDT 2008
-----BEGIN PGP SIGNED MESSAGE-----
Am Donnerstag, 16. Oktober 2008 schrieb Bernard Desruisseaux:
> Hi Reinhold,
> > Issues in rfc2445bis-08:
> > 1. Sec. "3.6.1. Event Component" (p.54): Either make the DTSTART
> > optional in rfc2445bis again or make it REQUIRED in the REPLY,
> > REFRESH and DECLINECOUNTER methods in rfc2446bis (currently,
> > it MUST NOT be present for these methods).
> In section 188.8.131.52 Date/Time Start of RFC2445 it already specified:
> Description: Within the "VEVENT" calendar component, this property
> defines the start date and time for the event. The property is
> REQUIRED in "VEVENT" calendar components.
> In rfc2445bis we changed the ABNF to match this statement (issue 37).
> Clearly, we want to require all events to have a start time. The
> problem we have here, is that a scheduling message that contains a
> VEVENT calendar component is not an event. It is a scheduling message
> that contains all or some information about an event. As such different
> restrictions may apply to scheduling messages.
> I propose to clarify this by adding the following text at the end of
> Section 1 Introduction:
Actually, several applications/libraries refuse to load a VEVENT if it does
not adhere to the restrictions of RFC2445. So parsing schedulling messages
with these libraries would no longer be possible.
> Scheduling protocols, such as iTIP [I-D.ietf-calsify-2446bis], MAY add
> or waive restrictions on the components and properties that are
> required, optional or excluded from an iCalendar object based on its
> iCalendar object method value.
So, basically, this is like saying: "Here we define a format with several
property restrictions. But, if you are writing a parser/validator, you can't
rely on these restrictions being fulfilled, because in some circumstances and
for some uses of the format these restrictions are not really restrictions."
I don't like such an implicit statement in a standard document...
Also, by this move, we are basically forking rfc2446bis off of the iCalendar
format, which I also don't like.
The question is: Do we want rfc2445bis to be a general format, which can also
be used for schedulling, or do we want two different (although
similar-looking) formats for calendar information and for schedulling?
I would prefer a solution, which allows DTSTART to be absent from a VEVENT
syntactically, but semantically require it for VEVENTs that really describe
an event to have DTSTART present.
This would make implementation much easier. With the current spec, one cannot
simply reuse an RFC2445bis validator and check the additional restrictions in
rfc 2446bis, but has to do the validation from scratch (because valid
rfc2446bis objects are not necessarily rfc2445bis objects...)
It's much easier to check for additional restrictions than to waive some
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinhold at kainhofer.com, 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.6 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the ietf-calsify