Subject: Question regarding VCOMMAND, VQUERY

From: [email-masked] (Greg Scallan)
Date: Tue, 02 Nov 1999 08:39:17 -0800

Hey All,

    I have a question regarding the VQUERY and VCOMMAND components as
specified in the CAP Internet Draft (draft-ietf-calsch-cap-01.txt). In
particular, the proposal seems to infer that VCOMMAND and VQUERY are not
part of the calendar store (atleast, they are not depicted in the
Calendar Store Object Model diagram in section 2.2).  However, the
examples show 'BEGIN: VCOOMAND' and 'BEGIN: VQUERY' statements within a
'BEGIN: VCALENDAR'.  This seems somewhat confusing to allow these
components within the VCALENDAR statement in iCalendar, inferring that
they are somehow related (properties of?).

    Shouldn't the VCOMMAND and VQUERY be *outside* the 'BEGIN:
VCALENDAR'?

Thanks for any enlightenment :-)
Greg

---

From: Doug Royer <[email-masked]>
Date: Tue, 02 Nov 1999 10:12:43 -0800

It is still an iCalendar object (VCALENDAR). Do you store VERSION
in the STORE? No - commands are at the same level.

Our idea was that if we put VCOMMAND and VQUERY inside of VCALENDAR
then the entire object is intact. You can email it, ftp, ...
and not worry about signatures or any other text that may
be around the object while in transit.

They are properties if the object in transit. That does not mean
you need to store them.

-Doug

---

From: [email-masked] (Greg Scallan)
Date: Tue, 02 Nov 1999 15:04:15 -0800

> in the STORE? No - commands are at the same level.

Actually, I also think Version should be at a higher level. It almost seems
that iCalendar was originally created to represent just 1 calendar, and now
additional properties are kinda being wedged in. VERSION seems like a property
of, say, a VICAL object, which should be able to contain multiple VCALENDAR
objects.

(I honestly have no clue on the historical aspects as I'm relatively new to
this work, which I think is great stuff, BTW).

> be around the object while in transit.

It seems to me that what you really need is a higher level object (VICAL) that
can contain multiple VCALENDARS and support other iCalendar Objects which are
not strictly properties of VCALENDAR.

Thus you would see something like:

     BEGIN: VICAL
       ...
     BEGIN: VCOMMAND
     END: VCOMMAND

     BEGIN: VCALENDAR
     ... # vcalendar properties and children go here...
     END: VCALENDAR

     BEGIN: VCALENDAR
     ... # vcalendar properties and children go here...
     END: VCALENDAR

     END: VICAL

This will maintain your desire for an intact iCalendar object and will enforce
that only properties or children objects of a vcalendar can belong within the
iCalendar for that calendar.

> They are properties if the object in transit. That does not mean

They are properties, but not of the calendar they are contained in (because
VCOMMAND has a TARGET which points to any number of calendars).

It sounds like what I'm hearing is that arbitrary iCalendar Properties can
exist within a VCALENDAR even if they are not properties and have no
relationship with that VCALENDAR. (ie VCOMMAND).  If that is the case, I find
the structure of the iCalendar format somewhat confusing, especially since
some objects (like VALARM) cannot be arbitratily placed within the iCalendar
Object, but are tied to their component (VEVENT, VTODO).  Why not have VALARMS
have a TARGET property for the target event to be consistent with the VCOMMAND
object.

I guess the iCalendar objects seem inconsistent to me.

Maybe part of my confustion is that I do not understand how to have multiple
calendars included in an iCalendar object.  It seems that you can only have
one calendar (VCALENDAR), but properties can reference multiple calendars (ie
VCOMMAND.TARGET property).

Just some thoughts,
Greg

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Wed, 3 Nov 1999 16:53:03 +0100

Greg Scallan wrote:

> Maybe part of my confusion is that I do not understand how to
> have multiple
> calendars included in an iCalendar object.

Since some (perhaps many) others might have had problems with understanding
the iCalendar structure.  I am posting a graphical description here.

http://www.skical.org/powerpoint/monopoly/monopoly.ppt

It might (and might not:-) make the relationship between multiple instances
in a calendar clearer.  Criticisms, as always, are appreciated.

Greg (FitzPatrick)
SKiCal WG

---

From: Doug Royer <[email-masked]>
Date: Wed, 03 Nov 1999 07:59:59 -0800

> of, say, a VICAL object, which should be able to contain multiple VCALENDAR

The ABNF in RFC2445 allows for more that one per object.

> not strictly properties of VCALENDAR.

I do not see anything gained. And some minor bandwidth lost.

> iCalendar for that calendar.

I do not see any difference. As to 'children objects', I have not
seen any discussion of being able to send a hierarchy of calendars
down.

> VCOMMAND has a TARGET which points to any number of calendars).

True - so what? 

> relationship with that VCALENDAR.  (ie VCOMMAND). 

RFC's 2445, 2446, and 2447 are representation of objects in transient
and the information needed to interoperate between vendors.
They are not descriptions of calendars in a store.

I do not (yet?) see your point.

> If that is the case, I find
> Object, but are tied to their component (VEVENT, VTODO). 

Objects are only tied to their component in 'iTIP' scheduling so that
we have a standard way to interchange the objects.

In CAP however - you can get or put parts of an entire VEVENT. One
thing that is a 'dodo' for CAP are the CAP restriction tables. (You must
have at least an X and Y in this object for CAP). These restriction
tables will have MUCH less in them that iTIP because the CUA will
know the context in which the CUA made the request.

> Why not have VALARMS

If that is what you want, then that is what you query for in CAP when
you ask for VALARMs. Get all VALARMs and the UID associated with them?

> calendars included in an iCalendar object.

They are not multiple calendars, they are multiple calendar objects.
One of which which might be an entire calendar, or just parts of one.

We could wrap them in another layer - I do not see any gain from that.

-Doug