Greg Scallan wrote: > > Doug Royer wrote: > > > It is still an iCalendar object (VCALENDAR). Do you store VERSION > > 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. The ABNF in RFC2445 allows for more that one per object. > (I honestly have no clue on the historical aspects as I'm relatively new to > this work, which I think is great stuff, BTW). > > > 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. > > 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. I do not see anything gained. And some minor bandwidth lost. > Thus you would see something like: > ... > 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. 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. > > They are properties if the object in transit. That does not mean > > you need to store them. > > They are properties, but not of the calendar they are contained in (because > VCOMMAND has a TARGET which points to any number of calendars). True - so what? > 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). 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 > 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). 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 > have a TARGET property for the target event to be consistent with the VCOMMAND > object. 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? > > 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. 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
begin:vcard n:Royer;Doug tel;pager:pager@royer.com or 650-274-8960 tel;cell:650-274-8960 tel;fax:805-957-1544 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:Software.com version:2.1 email;internet:Doug.Royer@Software.com title:Architect adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A fn:Doug Royer end:vcard
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature