Subject: [Ietf-calsify] Re: status of RFC 2445bis: AD Issue 1: Use of ALTREP

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 25 Sep 2008 16:23:04 -0400

Eliot Lear wrote:
> 
> AD Issue 1:
> 
> A disagreement between Bernard and everyone else.

:-)

 > Bernard, rough
> consensus says that you should change the text accordingly.

I propose to add the following text to section 3.2.1. Alternate Text 
Representation:

   Note: While there is no restriction imposed on the URI schemes
   allowed for this parameter, HTTP [RFC2616] and CID [RFC2392] are
   the URI schemes most commonly used by current implementations.

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

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 26 Sep 2008 14:19:25 -0400

Hi Bernard,

>    the URI schemes most commonly used by current implementations.

I think this is sufficient.

-- 
Cyrus Daboo

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 26 Sep 2008 19:24:28 +0100

> I think this is sufficient.

I like this text as well.

Date: Fri, 26 Sep 2008 19:24:28 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: status of RFC 2445bis: AD Issue 1: Use of ALTREP
Cc: Lisa Dusseault <[email-masked]>

> I think this is sufficient.

I like this text as well.

Date: Fri, 26 Sep 2008 14:19:25 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Re: status of RFC 2445bis: AD Issue 1: Use of ALTREP
Cc: [email-masked], Lisa Dusseault <[email-masked]>

Hi Bernard,

-- 
Cyrus Daboo

Date: Thu, 25 Sep 2008 16:23:04 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Lisa Dusseault <[email-masked]>
Subject: [Ietf-calsify] Re: status of RFC 2445bis: AD Issue 1: Use of ALTREP

:-)

Cheers,
Bernard

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] Why no empty calendar?
Date: Fri, 12 Sep 2008 18:27:53 -0400

I believe, but haven't tested yet, that an iCalendar object could have only
timezone components, which would be an effective empty calendar.

A CUA  would still need to notify the user when handling such an object.

On the other issue posted under this topic where it was mentioned that
Outlook will not allow a METHOD:PUBLISH object to contain ATTENDEES,  I
think that may be non-compliant behavior and I'd rather see the CUA fixed,
but I can see a use case for METHOD:ARCHIVE (or some such name) which would
mean "iCalendar stream created verbatim as an intended backup"..

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: Reinhold Kainhofer [mailto:[email-masked]] 
Sent: Sunday, September 07, 2008 7:45 PM
To: Lisa Dusseault
Cc: Tim Hare; [email-masked]
Subject: Re: [Ietf-calsify] Why no empty calendar?

Am Dienstag, 15. Juli 2008 schrieb Lisa Dusseault:
> On Jul 8, 2008, at 6:12 PM, Tim Hare wrote:
> > When you're discussing polling, you're in the realm of Atom or RSS 
> > and subscriptions, where eliminating the error message is "natural" 
> > - my RSS reader doesn't tell me when the feed has not been updated. 
> > If, however we allow VCALENDARs to be empty, a UA which imports a 
> > calendar through mechanisms other than a subscription definitely 
> > needs to warn the user.
> >
> > I'll have to think more deeply on this; perhaps there needs to be an
> > iTIP- /
> > iMIP- document to describe behaviors when iCalendar objects are 
> > consumed in ways other than mail, CalDAV, or subscriptions?
>
> +1.  Actually I think the subscription case needs to be fleshed out too.

Thinking of this a bit more: I really think that an empty calendar should be
allowed. In particular take the case of e.g. a sports team publishing their
upcoming competitions (or a choir/band/orchestra publishing their upcoming
concerts, or another organization their upcoming public events) as an .ics
file on a web page. If they have no upcoming competitions, they cannot
simply publish an empty .ics file, but have to change their homepage to
remove the link to the then-non-existing .ics file. 

Shouldn't that be made easier to allow an empty calendar, so that these
cases can be handled without much hassle? An empty calendar would be placed
on the homepage and a CUA or any other application able to handle .ics files
might (but doesn't have to) display a warning.

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.6 (GNU/Linux)

iD8DBQFIxGdkTqjEwhXvPN0RAhlFAJ4qPYOBNyl0dp56I5ZhaENBz2cCWwCeKuld
LcQ47lciN6sYlytA9/BIVGM=
=q6bn
-----END PGP SIGNATURE-----

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Why no empty calendar?
Date: Fri, 12 Sep 2008 14:31:06 +0200
Cc: [email-masked]

Am Dienstag, 15. Juli 2008 schrieb Lisa Dusseault:
> I drafted some text a little while back, that might have been a 2445
> appendix, but could instead get used in a separate doc.  This starts
> out as drafty text but then turns into somewhat of an outline.
>
> Lisa
>
> ----
>
> X.  Importing and exporting iCalendar Data
>
> The iCalendar specification is commonly used as the basis for
> exporting calendar files that can be imported into different software
> when users need to move their calendars around. This document
> describes that practice.  It is intended to be descriptive rather than
> normative.
>
> The file type and extension are as specified in RFC2445bis.
>
> When a user has several calendars for different categories or contexts
> (such as "home", "work" and "local events"), user agents most commonly
> export these as separate files rather than using categories within one
> big file.  This works well with user agents that import each ICS file
> as a new calendar.  Another common practice is to name the export file
> after the calendar, e.g. "work.ics".
[...]
> The METHOD property should not appear

I completely agree with this. In particular, MS Outlook refuses to import an 
iCalendar file unless it contains METHOD:PUBLISH. This however has the 
drawback that no ATTENDEEs are allowed on any component, which runs counter 
the idea of full data im-/export.

Maybe we should explicitly hint at such situations?

> How often is RELATED-TO really used and what for?  Can a user agent
> drop this on import?

In KOrganizer we use RELATED-TO to build a tree structure for to-dos (i.e. a 
to-do can have sub-todo, which are RELATED-TO the parent to-do). In many 
cases the summary of a sub-to-do only makes sense in the context of the 
parent to-do.

The other situtation where we use RELATED-TO is connected to the fact that 
likbcal does not support multiple components with the same UID. So, when one 
wants to modify one specific recurrence instance we don't use RECURRENCE-ID, 
but add that date as an EXDATE and a new event with a new UID is generated 
for the exception. However, to preserve at least some indication where that 
event came from, we set RELATED-TO to the original UID (although we don't use 
that setting anywhere).

Of course, that's just a workaround for some missing functionality, but that's 
the best we could think of without having to reimplement/restructure large 
parts of our code (which relies on the fact that the UID uniquely determines 
one event).

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: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Proposed new text for 3.4.6
Date: Wed, 10 Sep 2008 17:53:07 +0200

I like that new text in general. A few points:

Am Dienstag, 26. August 2008 schrieb Lisa Dusseault:
>   - If an attendee sends the "REFRESH" method with a UID but not a  
> RECURRENCE-ID, the "Organizer" responds with a "REQUEST" method and  
> the entire "VTODO" to bring the attendee up to date.
>   - If an attendee sends the "REFRESH" method and it identifies a  
> RECURRENCE-ID, the "Organizer" responds with a "REQUEST" method and  
> the "VTODO"  instance.

This leaves out the case of (1) a cancelled VTODO and (2) the attendee having 
been de-assigned the VTODO meanwhile. In both cases, the "Organizer" does not 
send out a "REQUEST" method, but rather a "CANCEL" method (setting STATUS 
appropriately to distinguish the two cases).

>   - If an "Organizer" sends the "REFRESH" method with a UID but not a  
> RECURRENCE-ID, each recipient attempts to identify themselves in the  
> "Attendee" list (possibly in several "Attendee" lists if there are  
> exception instances), 

"exception instances" is confusing, because we are not talking about EXDATE 
but rather about individual recurrence instances that have been modified 
separately. I can't provide a better formulation, though.

>   - If an "Organizer" sends the "REFRESH" method and it identifies a  
> RECURRENCE-ID, then the recipient attempts to identify itself in the  
> "Attendee" list for that instance, and if their PARTSTAT needs  
> refreshing,

Using "refreshing" in a section on REFRESH, where "refreshing" does not mean 
sending a REFRESH, is probably not a good idea ;-)  How about "needs an 
update"? or "has changed"? or "is not up-to-date"?

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: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT =?iso-8859-1?q?in=09thesame_iCalendar_stream?= (was: Re: [Ietf-calsify] Re: AD =?iso-8859-1?q?review=09on2445bis?=)
Date: Tue, 9 Sep 2008 00:46:27 +0200

Am Dienstag, 9. September 2008 schrieb Tim Hare:
> I thought the very definiton of x-properties was that they were
> 'experimental' and as such not "properly" part of the specification which
> needed to be handled by all conforming pieces of software.  I think that
> they should be ignored, but not necessarily discarded - if a CUA creates an
> iCalendar object with x- properties and asks a CS to store it, AND the CS
> does not recognize those x-properties it should still, in opinion, store
> them but take no action on them or because of them.

I completely agree, that's why I find the word "ignore" not ideal.
I just wanted to point out that "ignore" might possibly be misunderstood 
as "feel free to discard them". It makes a difference if you ignore a 
property/parameter on reading (i.e. don't parse it at all and thus also not 
save it) or ignore it on processing (i.e. it's there but you don't do 
anything with it).
This also applies to the issues #79 of my review of rfc2446bis-07.

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: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Subject: RE: AD review issue #4: Supporting both VTODO and VEVENT in	thesame iCalendar stream (was: Re: [Ietf-calsify] Re: AD review	on2445bis)
Date: Mon, 8 Sep 2008 18:11:00 -0400

I thought the very definiton of x-properties was that they were
'experimental' and as such not "properly" part of the specification which
needed to be handled by all conforming pieces of software.  I think that
they should be ignored, but not necessarily discarded - if a CUA creates an
iCalendar object with x- properties and asks a CS to store it, AND the CS
does not recognize those x-properties it should still, in opinion, store
them but take no action on them or because of them.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: Reinhold Kainhofer [mailto:[email-masked]] 
Sent: Sunday, September 07, 2008 11:48 PM
To: [email-masked]
Cc: Lisa Dusseault; Tim Hare
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in thesame
iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on2445bis)

Am Dienstag, 15. Juli 2008 schrieb Lisa Dusseault:
> NEW:
>
>     An iCalendar object MUST include the "PRODID" and "VERSION" calendar
>     properties.  In addition, it MUST include at least one calendar
>     component.   Applications MUST ignore
>     x-comp and iana-comp they don't recognized.

Ignoring means that they can savely discard all X-properties, which is a bad
idea in my view.

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.6 (GNU/Linux)

iD8DBQFIxKBlTqjEwhXvPN0RAheFAKCu06TILFay0p0exrMZfmKMSJvnoQCgtdAJ
T0CpEzSZS/0d02VFvN8bgoM=
=A6Ez
-----END PGP SIGNATURE-----

Date: Mon, 08 Sep 2008 11:23:52 -0400
From: Cyrus Daboo <[email-masked]>
To: Eliot Lear <[email-masked]>, Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] IETF Review of rfc2446bis-07
Cc: ietf-calsify list <[email-masked]>

Hi Eliot,

--On September 8, 2008 1:52:59 PM +0200 Eliot Lear <[email-masked]> wrote:

> Thanks for all of this.  I've begun to split issues into categories, but
> given the size of it I'll need a day or so just to do that.
>
> All, please review Reinhold's comments and comment.

I posted to the apps list that what I would like to do is convert the 123 
iTIP points into a spreadsheet so that I can track the issues as I work 
through them. I am not sure that all of them need to be raised as formal 
issues on the issue tracker just now. I can post the spreadsheet to the 
calsify wiki and we can use that to track the initial pass over these 
comments.

-- 
Cyrus Daboo

Date: Mon, 08 Sep 2008 13:52:59 +0200
From: Eliot Lear <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] IETF Review of rfc2446bis-07
Cc: ietf-calsify list <[email-masked]>

Reinhold,

Thanks for all of this.  I've begun to split issues into categories, but 
given the size of it I'll need a day or so just to do that.

All, please review Reinhold's comments and comment.

Eliot

Reinhold Kainhofer wrote:
> Dear Calsify group,
>
> Eric Burger asked me if I could review the latest draft of rfc2446bis, which I
> agreed to. I tried to read the draft very carefully and with utmost
> diligence, trying to be extremely picky. I found lots of issues, obvious
> typos and contradictions, or simply things that should/might be explained a
> little better. There are also some things that I've not completely understood
> from the draft.
>
> Here is my review, where I mention all issues / questions sequentially,
> ordered as they appear in the draft (thus mixing errors with open questions
> and suggestings).
> I wrote it in LaTeX, mainly because of its size and to make cross-references
> and automatic numbering easier. I'm attaching the PDF file, the LaTeX source
> document and a HTML-representation produced by hyperlatex (with some tweaks
> to achieve the consecutive item numbering for the lists).
> Apparently, the message size of the calsify list is set too low to be able to
> attach the review, so I uploaded it to my homepage:
> http://reinhold.kainhofer.com/Computing/Review_RFC2446bis_2008-09.pdf
> http://reinhold.kainhofer.com/Computing/Review_RFC2446bis_2008-09.html
> http://reinhold.kainhofer.com/Computing/Review_RFC2446bis_2008-09.tex
>
> I know that some of the things might sound like nitpicking. However, from my
> experience with RFC 2445, if there is anything that can possibly be
> misunderstood, it will probably be misunderstood by some implementor.
> Thus, I strived to find also all the spots where things could be spelled out a
> little more detailled. In my eyes, a standards document should be unambiguous
> and still easy to understand. Please view my comments in this light.
>
> On the other hand, I really wonder how things like the following could have
> survived in a public RFC for more than a decade:
>     DTSTART:19980101T100000-0700
> or
>     STATUS:IN-PROGRESS
> for a todo or
>     RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU
> for an event that should recur every week for 20 weeks or
>     DTSTART:19970701T200000Z
>     DTEND:19970701T2000000Z
> for an event or completely messed-up timezone conversions (Sec. 4.4.1).
>
> Most of my points do not change the meaning of the RFC draft at all and can
> probably be included with only very little discussion / controversy.
>
> While cross-checking some issues, I also came across some things in
> rfc2445bis-08, which might be changed there. These are listed at the end of
> my review.
>
> Cheers,
> Reinhold
>
> PS: Sorry (well, not really...) for all the work that my review will bring to
> the ietf calsify team, but well, you asked for it ;-)
>
>    

To: "ietf-calsify list" <[email-masked]>
From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
Date: Mon, 8 Sep 2008 12:43:07 +0200
Subject: [Ietf-calsify] IETF Review of rfc2446bis-07

Dear Calsify group, 

Eric Burger asked me if I could review the latest draft of rfc2446bis, which I 
agreed to. I tried to read the draft very carefully and with utmost 
diligence, trying to be extremely picky. I found lots of issues, obvious 
typos and contradictions, or simply things that should/might be explained a 
little better. There are also some things that I've not completely understood 
from the draft. 

Here is my review, where I mention all issues / questions sequentially, 
ordered as they appear in the draft (thus mixing errors with open questions 
and suggestings). 
I wrote it in LaTeX, mainly because of its size and to make cross-references 
and automatic numbering easier. I'm attaching the PDF file, the LaTeX source 
document and a HTML-representation produced by hyperlatex (with some tweaks 
to achieve the consecutive item numbering for the lists).
Apparently, the message size of the calsify list is set too low to be able to 
attach the review, so I uploaded it to my homepage:
http://reinhold.kainhofer.com/Computing/Review_RFC2446bis_2008-09.pdf
http://reinhold.kainhofer.com/Computing/Review_RFC2446bis_2008-09.html
http://reinhold.kainhofer.com/Computing/Review_RFC2446bis_2008-09.tex

I know that some of the things might sound like nitpicking. However, from my 
experience with RFC 2445, if there is anything that can possibly be 
misunderstood, it will probably be misunderstood by some implementor.
Thus, I strived to find also all the spots where things could be spelled out a 
little more detailled. In my eyes, a standards document should be unambiguous 
and still easy to understand. Please view my comments in this light.

On the other hand, I really wonder how things like the following could have 
survived in a public RFC for more than a decade:
   DTSTART:19980101T100000-0700
or
   STATUS:IN-PROGRESS
for a todo or
   RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU
for an event that should recur every week for 20 weeks or
   DTSTART:19970701T200000Z
   DTEND:19970701T2000000Z
for an event or completely messed-up timezone conversions (Sec. 4.4.1).

Most of my points do not change the meaning of the RFC draft at all and can 
probably be included with only very little discussion / controversy.

While cross-checking some issues, I also came across some things in 
rfc2445bis-08, which might be changed there. These are listed at the end of 
my review.

Cheers,
Reinhold

PS: Sorry (well, not really...) for all the work that my review will bring to 
the ietf calsify team, but well, you asked for it ;-)

-- 
------------------------------------------------------------------
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: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT =?iso-8859-1?q?in=09thesame_iCalendar_stream?= (was: Re: [Ietf-calsify] Re: AD =?iso-8859-1?q?review=09on2445bis?=)
Date: Mon, 8 Sep 2008 05:47:49 +0200

Am Dienstag, 15. Juli 2008 schrieb Lisa Dusseault:
> NEW:
>
>     An iCalendar object MUST include the "PRODID" and "VERSION" calendar
>     properties.  In addition, it MUST include at least one calendar
>     component.   Applications MUST ignore
>     x-comp and iana-comp they don't recognized.

Ignoring means that they can savely discard all X-properties, which is a bad 
idea in my view.

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: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: AD review issue #5: Meaning of Contact, Organizer and Recurrence ID in VJOURNAL (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
Date: Mon, 8 Sep 2008 05:45:48 +0200

Am Montag, 23. Juni 2008 schrieb Aki Niemi:
> Continuing with the second batch of the AD review comments...
>
> ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
> > > Section 3.8.4.3, 3.8.4.4:   CONTACT and ORGANIZER and RECURRENCE-ID
> > > are defined on VJOURNAL items.  I have no idea what they *mean* on
> > > VJOURNAL.
>
> Can we safely remove VJOURNAL from the list of components for each of
> these properties?

No, we can't since they are needed for iTIP (RFC 2446bis).
Organizer is the person who wrote the VJOURNAL and sends it out, RECURRENCE-ID 
is needed to change single instances of recurring VJOURNALs.

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/

Date: Sun, 07 Sep 2008 22:57:22 -0400
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, Eric Burger <[email-masked]>, ietf-calsify list <[email-masked]>, [email-masked], Lisa Dusseault <[email-masked]>
Subject: [Ietf-calsify] Re: [APPS-REVIEW] IETF Review of rfc2446bis-07

Hi Reinhold,

--On September 8, 2008 3:14:35 AM +0200 Reinhold Kainhofer 
<[email-masked]> wrote:

> Attached is my review, where I mention all issues / questions
> sequentially,  ordered as they appear in the draft (thus mixing errors
> with open questions  and suggestings).

Thank you for this extremely thorough review of this specification.

There are 123 points made about 2446bis. What I will need to do is import 
these into a spreadsheet so that I can track responses and changes to 
these. Anything that requires more than a simple fix will probably need to 
be raised as an issue on the issue tracker, assuming the chairs are 
willingly to re-open that to address this review.

> PS: Sorry (well, not really...) for all the work that my review will
> bring to  the ietf calsify team, but well, you asked for it ;-)

Well you did such a good job that it might backfire on you as I am sure 
Eric and the Apps Review team will be targeting you to do lots more :-)

-- 
Cyrus Daboo

Date: Sun, 07 Sep 2008 22:38:40 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, ietf-calsify list <[email-masked]>
Subject: Re: [Ietf-calsify] AD Review of RFC2446bis

Hi Lisa,
Thanks for the review. Comments in line. Most of your issues I have 
addressed by fixes to my working copy.

--On August 26, 2008 9:15:46 AM -0700 Lisa Dusseault 
<[email-masked]> wrote:

>
> Here's my review of version -07.  I have no high-level problems except a
> suggestion for formatting the constraints tables throughout the document
> if Cyrus is willing.
>
>
> ----
>
> Section 1.4
> Says that ADD can be used to add one or more new instances to an existing
> VEVENT, VTODO or VJOURNAL.  However, I'm not entirely clear how an iTIP
> recipient would get the VTODO or VJOURNAL in the first place.  PUBLISH
> includes any type of calendar entry -- what does "calendar entry" define
> and include (It's mentioned only once that I can find in 2445bis)?  Any
> iCalendar component?

OK - the term "calendar entry" is specific to this spec. It is not formally 
defined and frankly it is not clear precisely what it means, though section 
2.1 kind of introduces it. I have replaces it with "iCalendar object" with 
some suitable re-wording in places where it is used.

> Section 3
> First table says that PUBLISH can be used for VEVENT, VTODO, VJOURNAL and
> VFREEBUSY, but that REQUEST can be used for all except VJOURNAL.  This
> doesn't appear consistent with the text in Section 1.4 which implies that
> REQUEST can schedule any calendar entry.  Maybe we're back to the missing
> definition of "calendar entry".

So section 1.4 now just describes "generic" iCalendar objects, and the 
existing table in section 3 now gives the specific restrictions for the 
components defined in 2445. So I think no change is needed here.

> Section 3.2
> Main table says that the PUBLISH method constraints include 0 VTODO or
> VJOURNAL components.  In section 3.2.2,  REQUEST also has 0 , and in
> section 3.2.4, ADD has 0 VTODOs or VJOURNALs.  Isn't this in
> contradiction to section 1.4's description of ADD?  Doesn't this mean you
> can't send a VTODO or VJOURNAL out in iTIP at all?  ... It turns out I
> need to interpret the tables of constraints in a narrower context.  I
> suggest that the context be part of the title or first row of the table.

It needs to be clear that there is only one primary component type allowed 
per iTIP message. Hence when a VEVENT is present in an iTIP message, VTODO, 
VJOURNAL can't be. I have added some text to the end of 1.4 to indicate 
that.

In addition I will add an extra caption above each restriction table to 
make it clear what is being described.

> Section 3.2.2.6
> The event flow seems incomplete.  It describes how a request can be
> forwarded to a new CU that wasn't invited, and then the organizer decides
> whether or not to add the uninvited CU to the attendee list.  We're
> missing the step in between where the organizer learns that the new CU
> was invited. Is this by receiving a response from the uninvited CU, being
> cc'ed on the forwarded REQUEST, or receiving a separate copy of the
> REQUEST or a COUNTER, or any of the above?

OK, that piece is missing. I've added the missing step of the uninvited CU 
replying to the organizer.

> Same section: phrases like "a new ATTENDEE property is added" are in
> passive voice, aren't very clear about who is responsible.  In this case
> it should be something like
> If the "Organizer" decides to add an uninvited CU, the CU
> of the "Organizer" adds a new "ATTENDEE" property with
> the uninvited CU with its property parameters set as the
> "Organizer" deems appropriate.

...

> Section 3.2.3:
>
>    The "REPLY" method may also be used to respond to an unsuccessful
>    "REQUEST" method.
>
> Is there something missing here?  I read "unsuccessful" as a request that
> was not received.  Hard to know how to reply to a request that was not
> received.

"Unsuccessful" in this case means received but processing failed for some 
reason. I'll change the text to:

The "REPLY" method is also used when processing of a "REQUEST" fails.

> Section 3.3
>
>   "FREEBUSY" properties should be sorted such that their values are in
>    ascending order, based on the start time, and then the end time, with
>    the earliest periods first.
>
>
> Is there a reason why the SHOULD isn't capitalized?  Is there a reason
> why it's not a MUST?

Frankly it shouldn't matter. The client processing the data is going to 
have to do its own sorting anyway as part of its processing. Really the 
only benefit of sorting here is for humans reading the raw iCalendar data.

>    The busy time information within the iCalendar object MAY be grouped
>    into more than one "VFREEBUSY" calendar component.
>
>
> This requirement does not seem consistent with the tables in 3.3.2 or
> 3.3.3, where the "Presence" column says that only one VFREEBUSY component
> is allowed.  If it's only true for PUBLISH, then this statement quoted
> above should be moved into the section on PUBLISH (3.3.1) or even called
> out.

I will move that statement into the PUBLISH section. The third sentence 
will be removed because that refers to REPLY behavior which is not allowed 
to return multiple VFREEBUSY's.

>
> Section 3.4.2:
>
>    The originator of a "REQUEST" is the "Organizer" of the to-do.  The
>    recipient of a "REQUEST" is the "Calendar User" assigned the to-do.
>
>
> The REQUEST method is also used by the delegator as explained in 3.4.2.3.
> Maybe we should just add a prefix:  "In the most typical case, the
> originator of a REQUEST is..."

Changed.

> Next question in this same text:  How do user agents check that they are
> in fact the Calendar User assigned the to-do, and not just being cc'ed?

Well the calendar user using the CUA would be listed as an ATTENDEE if that 
user is being assigned the to-do. If it is a cc that calendar user's 
address would not appear in any ATTENDEE property.

Actually there is a weakness overall here in that it is not possible to 
include details about who might have been cc'd or bcc'd on an invite in the 
calendar data itself. It can be done by the transport (e.g. email headers). 
But not all transports have that capability by default. Plus that 
information is lost when the calendar data is extracted from the transport 
"wrapper". I don't propose we do anything about that in 2446bis, but I 
expect that we will need some new properties for this in the near future.

> Section 3.4.4
>
>
>
> If an "Attendee" implementation does not support the "ADD"
>    method it should respond with a "REQUEST-STATUS" value of 5.3 and ask
>    for a "REFRESH".
>
>
> Shouldn't this be 3.14 error instead of 5.3?  Section 3.2.4 for ADD uses
> a REQUEST-STATUS of 3.14 for the same case.

Changed to 3.14.

> Section 3.4.6
>
>
> I'm going to suggest a rewrite of these paragraphs -- sent separate mail.

Have not seen the separate email...

> Section 3.6, table, row for code 5.0 says:
>
>
> "Request MAY supported"
>
>
>
> Something must be missing here?

I think that should be "Request not supported". I have changed the text to 
reflect that.

> Section 3.7.3:
>
> Clients are not required to save X-Tokens or use them
>    in replies.
>
>
> It seems curious to have this anti-requirement, where there is no
> requirement of this sort for ordinary properties.  I couldn't find any
> requirement that standard properties in iCalendar methods must be saved
> or used in replies.

Actually this brings up an important point. Not only do we have X- tokens, 
but we also have IANA registered tokens that may extend the base set. Since 
2445bis calls out "iana-prop" as a separate item in its formal syntax, we 
should use IANA-PROPERTY etc in 2446bis to correspond to those. But we need 
to make some kind of statement about how the IANA- items should be treated 
as per 3.7.3. Really "IANA tokens SHOULD be saved and MAY be returned in 
replies".

> Section 4.2.4: The example in this section claims that the COUNTER
> requests a change to time and place of the meeting.  However, it looks
> like the LOCATION field has "Green Conference Room" in both the original
> REQUEST and in the COUNTER.

Fixed.

> Section 4.2.5 says:
>
>
>
>   It is not required that the "Delegate" include the "Delegator" in
>    their "REPLY" method.  However, it is strongly advised since this
>    will inform the "Delegator" whether the "Delegate" plans to attend
>    the meeting.
>
>
> However, Section 4.2.7 says:
>
>
>
>    In this example the "Delegate" declines the meeting request and sets
>    the "ATTENDEE" property "PARTSTAT" parameter to "DECLINED".  The
>    "Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT"
>    parameter of the "Delegate" set to "DECLINED".  This lets the
>    "Delegator" know that the "Delegate" has declined and provides an
>    opportunity to the "Delegator" to either accept the request or
>    delegate it to another CU.
>
>
>
>
> These are inconsistent because section 4.2.5 indicates that the Delegate
> is responsible for letting the "Delegator" know if they've accepted.
> Section 4.2.7, however, does not say that the Delegate does so (it is
> silent) but it does say that the "Organizer" sends an update  that lets
> the "Delegator" know if the delegate accepted.   Is it the Delegate, the
> Organizer or both that are responsible for letting the Delegator know the
> accept status?

In section 4.2.5 there is an "Editor's Note" left over from the original 
spec! The fact is there is no offical way for the delegate to include the 
delagator in their REPLY. Therefore I propose removing the text in 4.2.5 - 
the text in 4.2.7 is correct - the Organizer must push the notifications 
out.

> Section 4.5.5:
>
>
>
>    A reply indicating that "D" completed "D's" part of the assignment.
>
>
> Section 4.5.6 continues the example, however:
>
>
>
>      ATTENDEE;PARTSTAT=IN-PROCESS;CUTYPE=INDIVIDUAL:mailto:[email-masked]
>
>
> Shouldn't "D"'s PARTSTAT be COMPLETED rather than "IN-PROCESS"?

Fixed.

> Section 5.1.1:
>
>
>
>    +----------------+--------------------------------------------------+
>    | Method         | Fallback                                         |
>    +----------------+--------------------------------------------------+
>    | PUBLISH        | Required                                         |
>    | REQUEST        | PUBLISH                                          |
>    | REPLY          | Required                                         |
>    | ADD            | Required                                         |
>    | CANCEL         | Required                                         |
>    | REFRESH        | Required                                         |
>    | COUNTER        | Reply with Not Supported                         |
>    | DECLINECOUNTER | Required if EVENT-COUNTER is implemented;        |
>    |                | otherwise reply with Not Supported               |
>    +----------------+--------------------------------------------------+
>
>
> In this table, the "Fallback" context is inconsistent.  Saying that the
> fallback if you don't support REQUEST is to send a PUBLISH is an
> instruction to the sender.  However, saying that the fallback if you
> don't support COUNTER is to reply with Not Supported, is an instruction
> to the receiver.
>
>
> Isn't there a difference between "Required to be able to send" and
> "Required to be able to handle on receiving"?   Thus, all iTIP clients
> MUST be able to receive PUBLISH requests but obviously aren't required to
> send them.   COUNTER is not required to be sent or received.  REPLY is
> required to be both sent and handled on receiving.

OK, the whole fallback thing needs some major revisions. Looking at it now 
smethings are clearly wrong. e.g. ignoring the VERSION property is totally 
wrong, as is defaulting CALSCALE to GREGORIAN. That would make it all but 
impossible to do a significant revision to 2445 in the future. Your other 
point that the fallbacks need to be treated separately for send and 
receiver is also valid. Maybe we need to split the Fallback column into two 
for that?

> Section 7.  IANA Considerations
>
>
> I do not see any existing IANA registry for the iCalendar "METHOD"
> property values.  If there is a registry, please provide the URL to help
> IANA.  They will also need to be instructed to update the reference for
> these methods from 2446 to 2446bis.
>
>
> if, on the other hand there is no such registry and we are trying to
> create one, then IANA needs more clear instructions on creating the new
> registry and what fields it has and how entries are added (IETF
> consensus, expert assignment, First-come-first-served)

The "Methods Registry" is defined in Section 8.3.12 of 2445bis. I have 
added a reference to that in the IANA section to clarify where the METHOD 
registrations are supposed to go.

-- 
Cyrus Daboo

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Why no empty calendar?
Date: Mon, 8 Sep 2008 01:44:33 +0200
Cc: [email-masked]

Am Dienstag, 15. Juli 2008 schrieb Lisa Dusseault:
> On Jul 8, 2008, at 6:12 PM, Tim Hare wrote:
> > When you're discussing polling, you're in the realm of Atom or RSS and
> > subscriptions, where eliminating the error message is "natural" - my
> > RSS
> > reader doesn't tell me when the feed has not been updated. If,
> > however we
> > allow VCALENDARs to be empty, a UA which imports a calendar through
> > mechanisms other than a subscription definitely needs to warn the
> > user.
> >
> > I'll have to think more deeply on this; perhaps there needs to be an
> > iTIP- /
> > iMIP- document to describe behaviors when iCalendar objects are
> > consumed in
> > ways other than mail, CalDAV, or subscriptions?
>
> +1.  Actually I think the subscription case needs to be fleshed out too.

Thinking of this a bit more: I really think that an empty calendar should be 
allowed. In particular take the case of e.g. a sports team publishing their 
upcoming competitions (or a choir/band/orchestra publishing their upcoming 
concerts, or another organization their upcoming public events) as an .ics 
file on a web page. If they have no upcoming competitions, they cannot simply 
publish an empty .ics file, but have to change their homepage to remove the 
link to the then-non-existing .ics file. 

Shouldn't that be made easier to allow an empty calendar, so that these cases 
can be handled without much hassle? An empty calendar would be placed on the 
homepage and a CUA or any other application able to handle .ics files might 
(but doesn't have to) display a warning.

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/