Subject: Re: Restore iTIP Functionality (fwd)

From: "G. Barnes" <[email-masked]>
Date: Wed, 15 Oct 2003 14:14:02 -0700 (PDT)

I meant to send this to the mailing list, not just Craig Johnson, but
screwed up.

---------- Forwarded message ----------
Date: Wed, 15 Oct 2003 11:00:22 -0700 (PDT)
From: G. Barnes <[email-masked]>
To: Craig Johnson <[email-masked]>
Subject: Re: Restore iTIP Functionality

On Wed, 15 Oct 2003, Craig Johnson wrote:

> Before CAP-12, it was possible for a CUA to obtain 'UNPROCESSED'
> VFREEBUSY components from the Calendar Store.  Now, however, a new
> section in CAP-12 explicitly prohibits this (Section 10.12.1, paragraph
> 4):
>    If a CUA searches for "VFREEBUSY" components with STATE() =
>    'UNPROCESSED', such a CS MUST return a "VREPLY" with no components.

Just to be clear:

Note the phrase 'such a CS'.  This paragraph refers to a CS described
in the first paragraph of 10.12.1, not all CS's.

When I rewrote this text, paragraphs 2 and 5 in this section were
indented to indicate that they were conclusions that follow from
the first paragraph.  This indenting has been eliminated, which
to my mind makes things less clear, but maybe there's some IETF
formatting rule I don't know about.

Knowing that, if you don't agree with the logic in the first 5 paragraphs
of this section, you can look at

  http://www.imc.org/ietf-calendar/mail-archive/msg08121.html

which contains a discussion of what was there before, and why I thought
it needing rewriting.  In my mind, this is only a clarification of what
was there before, so you'll have to search further back to figure out
why RECUR-EXPAND=TRUE implies VFREEBUSY objects are never stored.

                        Greg Barnes
                        Computing and Communications, University of Washington
                        [email-masked]
                        (206) 685-3295