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

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 16 Oct 2008 10:33:55 -0400

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:

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.

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

---

From: Reinhold Kainhofer <[email-masked]>
Date: Thu, 16 Oct 2008 17:39:19 +0200

> I propose to clarify this by adding the following text at the end of

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.

> 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: [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/
_______________________________________________
ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Reinhold Kainhofer <[email-masked]>
Date: Thu, 16 Oct 2008 18:12:46 +0200

> http://reinhold.kainhofer.com/Computing/Review_RFC2446bis_2008-09.html#id38
[...]

BTW, would it still make sense if I went through rfc2445bis-08 like I did with 
rfc2446bis-07, or is it too late already for that ?

Cheers,
Reinhold
- --

---

From: Eliot Lear <[email-masked]>
Date: Thu, 16 Oct 2008 10:12:22 -0700

Reinhold,

On 10/16/08 9:12 AM, Reinhold Kainhofer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

We have already been through last call on rfc2445bis-08 and I would 
rather not go through that process again.  We need to bring the process 
to a close.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 16 Oct 2008 10:16:28 -0700

> format, which I also don't like.

I would agree with this concern.

> It's much easier to check for additional restrictions than to waive some

Can you provide a textual change to match this statement?

Eliot

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 16 Oct 2008 14:56:11 -0400

Here are textual changes that I believe match Reinhold's statement.

In section 3.6.1 Event Component, change:

    ; the following are REQUIRED,
    ; but MUST NOT occur more than once

    dtstamp / dtstart / uid /

to:

    ; the following are REQUIRED,
    ; but MUST NOT occur more than once

    dtstamp / uid /

    ; the following is REQUIRED if the component
    ; appears in an iCalendar object that doesn't
    ; specify the "METHOD" property, otherwise it
    ; is OPTIONAL, in any case it MUST NOT occur
    ; more than once

    dtstart /

In section 3.8.2.4 Date/Time Start, change:

    This property is REQUIRED in "VEVENT" calendar components
    and in all types of recurring calendar components.

to:

    This property is REQUIRED in "VEVENT" calendar components
    and in all types of recurring calendar components contained
    in iCalendar objects that don't specify the "METHOD" property,
    otherwise it is OPTIONAL.

Cheers,
Bernard

---

From: "Tim Hare" <[email-masked]>
Date: Thu, 16 Oct 2008 18:04:49 -0400

In what use case during scheduling is the start of the event being scheduled
not relevant and not necessary?

I am opposed to allowing "waivers" on the general principle that we will end
right back where we started with multiple incompatible implementations.

As an end user I'd be opposed, because I could never tell which of my
colleagues' many possible systems would waive some requirements.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard
Desruisseaux
Sent: Thursday, October 16, 2008 10:34 AM
To: Reinhold Kainhofer
Cc: Calsify WG
Subject: [ietf-calsify] Issue RK-1 in rfc2445bis-08 (related to issue 37)
[Was: IETF Review of the RFC 2446bis-07 (iTIP) draft]

Hi Reinhold,

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

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:

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.

Thanks,
Bernard

---

From: Reinhold Kainhofer <[email-masked]>
Date: Fri, 17 Oct 2008 14:14:13 +0200

BTW, I realized that i didn't mention the rfc2446bis issue #100 in my issues 
list for rfc2445bis: 

RFC2446bis Sec. 4.5.7.2 (p.105): This section talks about how recurrence works 
in general for to-dos, which would much better belong in rfc2445bis rather 
than rfc2446bis. So I think this whole section should be moved to rfc2445bis. 
Also, this section speaks of the due date specified in a "REQUEST", while of 
course the same holds true for PUBLISH, ADD, COUNTER, etc., too. It is not 
even specific to iTIP, but rather a general issue in iCalendar. 

Cheers,
Reinhold

- --

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 17 Oct 2008 10:04:55 -0400

Hi Reinhold,

Section 4.5.7.2 Calculating due dates in recurring VTODOs should be 
removed from rfc2446bis (iTIP). The first sentence is actually wrong. 
The due date is NOT ``specified using the "RECURRENCE-ID" property''. 
You are correct in saying that this information belongs in rfc2445bis.

That being said, I don't believe any text change is required in 
rfc2445bis (iCalendar). I think the modification that was done to the 
last paragraph of the Description field of the RRULE property in section 
3.8.5.3 Recurrence Rule (issue 27) is sufficient.  See:

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#page-126

Thanks,
Bernard

Reinhold Kainhofer wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFI+IGYTqjEwhXvPN0RAvYOAJ4qZ+8ZTHm1OFGgP6MZus5K0sYl7ACgmDDC
> s7C4EuLB7XoVb2LPxAbkl/c=
> =Y92w
> -----END PGP SIGNATURE-----
>

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 17 Oct 2008 10:21:46 -0400

Hi Bernard,

> http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#page-126

I agree that 4.5.7.2 in 2446bis is redundant and I have removed it from my 
working copy of the draft.

-- 
Cyrus Daboo