Subject: [Ietf-calsify] Just for the record. Notes has a full implementationof VTODOs

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Tue Aug 17 12:27:47 2004

Skipped content of type multipart/alternative

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Tue Aug 17 12:39:30 2004

I disagree.  There is very little diffence between the VTODO and the 
VCALENDAR.  Both have the same repeat behavior and attendee information. 
The only difference is that the VTODO has a few additional response 
states.

I have no problem with removing journal entries, since these are basically 
different than a Calendar or group todo.  Also I do not know of any 
implimentors.

Has anybody implimented iTip VFREEBUSY requests?

"Cameron Stillion" <[email-masked]> 
Sent by: [email-masked]
08/17/2004 03:27 PM

To
<[email-masked]>, <[email-masked]>
cc

Subject
RE: [Ietf-calsify] Just for the record. Notes has a full implementationof 
VTODOs

I realize there are actually a few vendors out there who have actually
put the time and effort into implementing VTODO from the previously
proposed standard.  I question whether this investment was made in
response to users clamoring for more task-management features from
calendaring systems, or if it was done simply because it happens to be
in the spec.  I know of no web sites that publish task lists using this
mechanism, no clients that even propose to interoperate in this way.
 
Also, I think it is clearly outside the scope of this standard (and
indeed this working group) to attempt to define a standard schema for
ALL OTHER PIM DATA TYPES.  I suggest that one of the mistakes made by
previous attempts to bring iCal to standard is that they tried to extend
the notion of a calendar data type to include task items and journal
items, which are different beasts, and should be treated differently.
They have different schemas, different semantics, and applications who
want to communicate using such data types will have very different
requirements for those data types.
 
I suggest that we stick to calendaring exclusively.  Removing support
for VTODO and VJOURNAL will hurt very few if any clients.  Systems that
have implemented a means of parsing or generating these datatypes, I
would argue, have no compelling interoperability scenario or clear user
features compelling in the space we are working in.  If there is
sufficient interest in specifying such data structures, I suggest that
separate working groups and separate documents be created to bring these
Task and Journal schemas into the standards process.
 
If we try to take on the whole PIM data enchilada, I believe we will
fail as have previous attempts to make calendaring and scheduling
schemas and systems speak a standard language. 
 
camerost 

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, August 17, 2004 7:50 AM
To: [email-masked]
Subject: [Ietf-calsify] Just for the record. Notes has a full
implementationof VTODOs

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Tue Aug 17 12:45:53 2004

I think Cameron may be right, even though I'd like to see a standard 
for Todo item schema.  Therefore, I'd be willing to work on it 
separately.  It might be an extremely simple separate spec if a todo is 
actually nearly a subset of a VEVENT -- the separate spec could reuse 
almost everything from VEVENT and define almost nothing new.

Lisa

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Aug 17 13:26:22 2004

Lisa Dusseault wrote:

> separately.  It might be an extremely simple separate spec if a todo 
> is actually nearly a subset of a VEVENT -- the separate spec could 
> reuse almost everything from VEVENT and define almost nothing new. 

I think that is an excellent idea. We all agree that VEVENT is necessary.

A VEVENT + VCALENDAR draft, a VTODO draft and a VJOURNAL draft (if 
anyone wants it).

iCal was designed to be extendable. By breaking these apart each one can 
make
standard status or fade out.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040817/40114eac/smime.bin

---

From: danw at novell.com (Dan Winship)
Date: Tue Aug 17 14:02:54 2004

> mechanism, no clients that even propose to interoperate in this way.

Lots of clients and servers that were written post-2445 use VTODO as
their native task data format (eg Evolution, Apple's iCal) and some
actually even do VTODO-over-iMIP and such. I think we should probably
keep VTODO, though maybe in a separate document as Doug suggested. (And
I also agree with your later post, that it really seems like some of the
existing VTODO features were just copied over from VEVENT "because we
can", and should be rethought.)

-- Dan

---

From: schumacher at kde.org (Cornelius Schumacher)
Date: Tue Aug 17 14:22:13 2004

On Tuesday 17 August 2004 21:39, [email-masked] wrote:
> VCALENDAR.  Both have the same repeat behavior and attendee
> information. The only difference is that the VTODO has a few
> additional response states.
>
> I have no problem with removing journal entries, since these are
> basically different than a Calendar or group todo.  Also I do not
> know of any implimentors.

KDE has an implementation of iCalendar journal entries. 

> Has anybody implimented iTip VFREEBUSY requests?

KDE also implements this.

In general I would like to see at least the todos but preferably also 
the journal entries stay in the standard to avoid any further 
fragmentation. Most organizer applications handle these kind of objects 
anyway, so why have another standard for them?

-- 
Cornelius Schumacher <[email-masked]>