Subject: [ietf-calsify] iTIP open issues

From: Cyrus Daboo <[email-masked]>
Date: Sun, 18 Jan 2009 22:25:39 -0500

Hi folks,
Here are the list of currently open issues from Reinhold's review:

<http://trac.tools.ietf.org/wg/calsify/trac/attachment/wiki/RFC2446bis/Review_RFC2446bis_2008-09.pdf>

Issues: #25, #30, #33, #40, #59, #64, #67, #70, #95, #105, #106, #107, #109.

These issues need further discussion.

Other issues have been dealt with (either fixed or not) as per 
<http://trac.tools.ietf.org/wg/calsify/trac/attachment/wiki/RFC2446bis/Issues.pdf>. 
All of this needs review from other people to confirm that the changes made 
(or not made) are valid.

-- 
Cyrus Daboo

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 19 Jan 2009 15:35:43 +0100

Thanks for that, Cyrus.  What I would like to do is schedule a jabber 
meeting in about two week's time.  To do so, and so that it is 
convenient for as many people as possible, can everyone please take a 
moment and go to the following web page:

http://www.doodle.com/participation.html?pollId=e2uvzzf3per72ae9

I'll look at results in the next two days to schedule.

Eliot

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 19 Jan 2009 09:42:41 -0500

Hi Eliot,

This specific week conflicts with CalConnect XIV.

Cheers,
Bernard

---

From: "Tim Hare" <[email-masked]>
Date: Mon, 19 Jan 2009 11:58:25 -0500

Small comment on a small issue:  VALARM at the same level as other
components (really a 2445 issue?)

It might be useful to make VALARM a component at the same level as
VTIMEZONE, so that other entries in a calendar stream could refer to them.
This would be purely to shorten the serialized data.  Many CUAs have a
default for "reminder" (say, 15 minutes before the event, make a chime noise
and display something) - having VALARM at the component level would allow
defining it once and referring to it.

Another advantage would be elimination of a BEGIN:/END: sequence within
another BEGIN:/END: component sequence, which may or may not be a parsing
issue for some. I think VALARM is the only component (or perhaps we should
say component-like property) which currently can be contained within another
component.

Some proposed text/ideas for changes in 2445

-----------------------------------
In 3.6.6 

Add alarmid as a property of a VALARM component.  

Alarmid is REQUIRED, but MUST NOT occur more than once

Remove the requirement for TRIGGER and the paragraphs about TRIGGER

In 3.6.1 and 3.6.2

Remove *alarmc and add a property named alarm which is OPTIONAL and MAY
occur more than ocne

Add ALARM as a property to the text.

ALARM ALARMID=,RELATED=:  

Where the ALARMID is a reference to the VALARM component, RELATED and the
ALARM value work like TRIGGER worked in VALARM

--------------------------------------------

I will try to work out better text for this, but I wanted to put the idea
out there.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Sunday, January 18, 2009 10:26 PM
To: Calsify
Subject: [ietf-calsify] iTIP open issues

Hi folks,

<http://trac.tools.ietf.org/wg/calsify/trac/attachment/wiki/RFC2446bis/Revie
w_RFC2446bis_2008-09.pdf>

Other issues have been dealt with (either fixed or not) as per
<http://trac.tools.ietf.org/wg/calsify/trac/attachment/wiki/RFC2446bis/Issue
s.pdf>. 
All of this needs review from other people to confirm that the changes made
(or not made) are valid.

--
Cyrus Daboo

---

From: Reinhold Kainhofer <[email-masked]>
Date: Mon, 19 Jan 2009 19:32:32 +0100

> VTIMEZONE, so that other entries in a calendar stream could refer to them.

There are advantages and disadvantages to this:
- -) It is an incompatible change!
+) alarm components can be reused
+) One less occurrence of nested objects
- -) Like with VTIMEZONE, you can no longer sequentially write out one 
VEVENT/VTODO/VJOURNAL after the other, but first have to scan for used VALARM 
objects, which have to be printed out separately (first?). Alternatively, you 
need to build the whole output structure in memory before writing it to file.
- -) Possible ambiguities in the GUI: Several VEVENT components can have the 
same VALARM assigned. If you change the alarm of one of these events, shall 
the "other" alarms be automatically changed, too? From a user's perspective, 
this would be VERY confusing at best. 

> say component-like property) which currently can be contained within
> another component.

A VTIMEZONE component also contains DAYLIGHT and STANDARD components... So a 
parser must be able top handle them properly

> Some proposed text/ideas for changes in 2445

This is an incompatible change and would make all previous iCalendar files 
using VALARM invalid (and all new ones invalid with regard to the old 
definition), so in this case the VERSION property should also be increased to 
3.0, which I don't think we want to / should do...

Cheers,
Reinhold
- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, [email-masked], http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org
_______________________________________________
ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Adrian Crum <[email-masked]>
Date: Mon, 19 Jan 2009 11:01:49 -0800 (PST)

> 3.0, which I don't think we want to / should do...

There are many things in the draft that are incompatible with the existing standard. Why not add one more?

-Adrian

---

From: "Tim Hare" <[email-masked]>
Date: Mon, 19 Jan 2009 17:02:35 -0500

I do not want to make an incompatible change - and I overlooked that.  

I guess this should be filed under "proposals for how iCalendar should have
been designed better" and forgotten.

As for GUI issues - I would say if an alarm changes in someones CUA it would
become a different alarm with a different alarmid - the CUA SHOULD scan for
duplicates before creating a new one. In practice I believe the number of
alarms to be fairly small, and burden to select VALARMS used by VEVENTS or
VTODOs would of course depend upon the implementation of the calendar store.

Tim Hare

-----Original Message-----
From: Reinhold Kainhofer [mailto:[email-masked]] 
Sent: Monday, January 19, 2009 1:33 PM
To: [email-masked]
Cc: Tim Hare; 'Cyrus Daboo'
Subject: Re: [ietf-calsify] iTIP open issues

There are advantages and disadvantages to this:
- -) It is an incompatible change!
+) alarm components can be reused
+) One less occurrence of nested objects
- -) Like with VTIMEZONE, you can no longer sequentially write out one
VEVENT/VTODO/VJOURNAL after the other, but first have to scan for used
VALARM objects, which have to be printed out separately (first?).
Alternatively, you need to build the whole output structure in memory before
writing it to file.
- -) Possible ambiguities in the GUI: Several VEVENT components can have the
same VALARM assigned. If you change the alarm of one of these events, shall
the "other" alarms be automatically changed, too? From a user's perspective,
this would be VERY confusing at best. 

> Another advantage would be elimination of a BEGIN:/END: sequence 
> within another BEGIN:/END: component sequence, which may or may not be 
> a parsing issue for some. I think VALARM is the only component (or 
> perhaps we should say component-like property) which currently can be 
> contained within another component.

This is an incompatible change and would make all previous iCalendar files
using VALARM invalid (and all new ones invalid with regard to the old
definition), so in this case the VERSION property should also be increased
to 3.0, which I don't think we want to / should do...

Cheers,
Reinhold
- --
- ------------------------------------------------------------------
Reinhold Kainhofer, [email-masked], http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org -----BEGIN PGP
SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD4DBQFJdMdBTqjEwhXvPN0RAnzsAJ9hEv6az35SueTuuvmIrwF5cDnupACXUXq/
Uzxd8K8SGCsNNJALPfoEYw==
=vPei

---

From: Reinhold Kainhofer <[email-masked]>
Date: Tue, 20 Jan 2009 00:55:35 +0100

Am Montag, 19. Januar 2009 04:25:39 schrieb Cyrus Daboo:
> <http://trac.tools.ietf.org/wg/calsify/trac/attachment/wiki/RFC2446bis/Issu
>es.pdf>. All of this needs review from other people to confirm that the
> changes made (or not made) are valid.

I took a look at the issues you marked as fixed in your table. Mostly, the 
changes fix my issues. However:

#25: Maybe it should be mentioned that the uninvited CU replies to the 
"Organizer" adding himself as an ATTENDEE? (It might be clear from the 
definition of a REPLY, but in the table in section 3.2.3 we say "MUST be the 
address of the Attendee replying". The uninvited CU is not an attendee, 
though...)

#36: I would also add the usual "MUST be present if any date/time refers to a 
timezone" comment for VTIMEZONE, which is present in all other tables.

#60: You say that "unsuccessfull" is only meant for technical failures, not 
for requests that are declined and are unsuccessfull requests in that sense. 
The word "method" in "to an unsuccessfull VTODO calendar component REQUEST 
method" might be enough to indicate this, but it would still be be a good idea 
to make it clear that unsuccessfull is meant as a technical failure.

#65: DTSTART, DUE and RDATE can have different time zones attached, in which 
case "0 or 1" for VTIMEZONE is not sufficient. I would suggest "0+". The same 
goes for 3.4.7 COUNTER.

#78: The last sentence "is used as the value "RECURRENCE-ID" property" is 
missing an "of the".

#92: Some FREEBUSY properties are still outside the 1.1.-8.1. time frame 
specified by DTSTART and DTEND

Nitpicking: 
- -) I also noticed that section 4.2.3 is named "Update An Event", while other 
sections use "an" in lowercase.
- -) Similarly, sections 4.1.2, 4.1.3, 4.2.2, 4.2.9, 4.4.6, 4.4.7, 4.4.8, 4.4.9 
use "A" in uppercase (6.1.5 in lowercase).
- -) Sections 4.1.5, 6.2.1, A.2 do not use headline uppercasing at all.
- -) Sections 3.2, 4.5.3 use "for", Sections 3.3, 3.4, 3.5 use "For".

Cheers,
Reinhold
- --

---

From: Eliot Lear <[email-masked]>
Date: Fri, 23 Jan 2009 15:15:35 +0100

proposals, probably because of CalConnect.  We will push one week out.  
If we fail to doodle again, then the chairs are going to have to take 
more serious action in consideration of these drafts.  That may require 
a meeting in SF.  I would like to avoid that.

Eliot

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 23 Jan 2009 09:46:12 -0500

--On January 23, 2009 3:15:35 PM +0100 Eliot Lear <[email-masked]> wrote:

> Ok, let's try one more time.  Only two people doodled the schedule
> more serious action in consideration of these drafts.  That may require a
> meeting in SF.  I would like to avoid that.

My availability added.

-- 
Cyrus Daboo