Reinhold Kainhofer | 8 Sep 01:44 2008

Re: 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 
(Continue reading)

Cyrus Daboo | 8 Sep 04:38 2008

Re: 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 
<lisa <at> osafoundation.org> 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
(Continue reading)

Cyrus Daboo | 8 Sep 04:57 2008

Re: [APPS-REVIEW] IETF Review of rfc2446bis-07

Hi Reinhold,

--On September 8, 2008 3:14:35 AM +0200 Reinhold Kainhofer 
<reinhold <at> kainhofer.com> 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
Reinhold Kainhofer | 8 Sep 05:45 2008

Re: AD review issue #5: Meaning of Contact, Organizer and Recurrence ID in VJOURNAL (was: Re: Re: AD review on 2445bis)


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: 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/
Reinhold Kainhofer | 8 Sep 05:47 2008

Re: AD review issue #4: Supporting both VTODO and VEVENT in thesame iCalendar stream (was: Re: 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: 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/
Reinhold Kainhofer | 8 Sep 12:43 2008

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 
(Continue reading)

Eliot Lear | 8 Sep 13:52 2008
Picon

Re: IETF Review of rfc2446bis-07

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
(Continue reading)

Cyrus Daboo | 8 Sep 17:23 2008

Re: IETF Review of rfc2446bis-07

Hi Eliot,

--On September 8, 2008 1:52:59 PM +0200 Eliot Lear <lear <at> cisco.com> 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
Tim Hare | 9 Sep 00:11 2008
Picon
Picon

RE: AD review issue #4: Supporting both VTODO and VEVENT in thesame iCalendar stream (was: Re: Re: AD review on2445bis)

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:reinhold <at> kainhofer.com] 
Sent: Sunday, September 07, 2008 11:48 PM
To: ietf-calsify <at> osafoundation.org
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)

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

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.

(Continue reading)

Reinhold Kainhofer | 9 Sep 00:46 2008

Re: AD review issue #4: Supporting both VTODO and VEVENT in thesame iCalendar stream (was: Re: Re: AD review on2445bis)


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: 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/

Gmane