AD review issue #4: Supporting both VTODO and VEVENT in the
same iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on
lisa at osafoundation.org
Mon Jun 16 09:25:14 PDT 2008
On Jun 16, 2008, at 9:11 AM, Cyrus Daboo wrote:
> Hi Lisa,
> --On June 16, 2008 9:01:07 AM -0700 Lisa Dusseault <lisa at osafoundation.org
> > wrote:
>>> Isn't this the implicit assumption already? Namely that if an
>>> implementation is conforming to the specification, it must supports
>>> of the defined components therein?
>> I should add that currently VTODO and VJOURNAL are treated exactly
>> same way as far as requirements are concerned, even though real-
>> world use
>> of VTODO is much greater than for VJOURNAL and I'm not even sure we
>> explain how people use VJOURNAL. So it seems odd that they're both
>> assumed to be required but one is really used and the other is
>> not. That
>> kind of thing may lead casual implementors to just ignore the
>> requirement, and lump VTODO in with VJOURNAL as something they don't
>> really want to figure out how to support.
>> Again, I can't think of any new requirement that would be a
>> definite good
>> thing, but we could easily write an implementation note that mentions
>> that VTODOs are increasingly seen in exported ICS files and even in
>> messages and that VEVENTS are ubiquitous.
> I don't think we can require support of all components. I think it
> is perfectly fine for a "task management" application to only
> support VTODOs and still claim to be iCalendar compliant.
> The suggestion of an implementation note that describes the "common
> use" of the components and explains that some may be supported and
> others not is fine. In fact telling implementors that they need to
> be prepared for another system to reject a component would be good.
I can get behind that. I'd also like to recommend that systems not
reject a component silently -- a user needs to know if they imported a
iCalendar file and lost 50 VJOURNAL components in the process.
More information about the Ietf-calsify