[ietf-calsify] Issue RK-1 in rfc2445bis-08 (related to issue 37) [Was: IETF Review of the RFC 2446bis-07 (iTIP) draft]

[Reinhold Kainhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Donnerstag, 16. Oktober 2008 schrieb Bernard Desruisseaux:
> Hi Reinhold,
>
> http://reinhold.kainhofer.com/Computing/Review_RFC2446bis_2008-09.html#id38
>
> > 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 4.8.2.4 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 
restrictions.

Cheers,
Reinhold
- -- 
- ------------------------------------------------------------------
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)

iD8DBQFI92AoTqjEwhXvPN0RAvw9AJ98vcjITt7t/BlLGIpbaWoVbonEIwCdGLRE
wRZgBEIHkvM3+QEWkhRcPs0=
=PS6w
-----END PGP SIGNATURE-----