Subject: [Ietf-calsify] PIM Data Types

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Wed Aug 18 05:27:27 2004

Well said.  I think that in reality, we have this situation today
already. Contact information is (somewhat) commonly transported through
a completely different standard - vCard (RFC 2426).  This standard is
remarkably similar to iCal, but that is not surprising given the common
beginnings (vCal, et.al. from versit technologies...)

I don't actually know what the status of vCard proposed standard is, but
obviously there is interest enough for a proposed standard to exist for
that PIM data type. Unfortunately, vCard uses slightly different
schematization for dates, time zones, etc. <aside: I would welcome an
effort similar to CALCIFY for contact data once we've brought
calendaring to a standard that we all feel pretty good about.../>

These separate standards should be brought into harmony so that separate
parsing engines do not have to be built for each one, but many basic
elements can be reused.  There also needs to be specification for
interoperability between these formats.  

For example, I need to be able to specify that a particular calendar
that I have published to my website is My Personal free/busy
information, or My Personal Schedule, and not just an IETF 60 calendar
that I put together for everyone's use. This implies that the calendar
have a property that links it to a contact (me) - and I would argue
vCard is the right general direction for that.  Likewise, I might want a
link from inside the vCard to my personal free/busy .ics so that when I
share my contact with someone, they can also schedule me for meetings. 

Similar situations exist with tasks, and other PIM data types.  We
should specify each of these data types in separate documents, using the
same basic underlying property types and schematization.  If there is
sufficient interest in publishing these data types and interoperating
between applications with them, then those documents will naturally move
along the standards track.  Adding links and interoperability of
multiple PIM data types should be built upon the standards.

Regards,
cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, August 17, 2004 8:37 PM
To: [email-masked]
Subject: [Ietf-calsify] Thoughts on some of the simplification thoughts
sofar

If you start breaking out VTODOs, VJOURNALs, or whatever, then perhaps
you're on a path where you have a multi-layered standard:

         Layer 0 would be representation of the "generic" parts of the
object (DTSTAMP, UID, DTSTART(?) etc.)
         Layer 1 would be representation of specific items, perhaps one
standard per VEVENT/VTODO/VJOURNAL, etc.

Endpoints of a calendaring conversation would have to either identify
what objects they could deal with, or issue errors when passed an object
they couldn't, or both.

Elimination of recurrence rules by passing lists of date/time values
back and forth overlooks the advantage of using the "shorthand" of
recurrence rules, which allow a large list of dates and times with a
short rule. I'm not arguing for or against, just making a point that I
hadn't heard expressed.  If you end wanting both possibilities, you have
to have a discovery mechanism to see what the other end handles. This, I
think, is at least partly handled by the "expand recurrence" property
which is returned in the GET-CAPABILITY response (I think).

Elimination of GEO values - I would rather see GEO be used as an index
into timezone data, rather than passing the timezone data along with the
objects, since a geographic location rather efficiently can get you the
timezone information. If eliminated, then I would like to see another
document for standardization of time zone identifiers, and only pass the
identifiers, not all of the time zone rules themselves.

Tim Hare
Interested Bystander, Non-Inc. 

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

---

From: Doug at Royer.com (Doug Royer)
Date: Wed Aug 18 09:38:30 2004

>share my contact with someone, they can also schedule me for meetings. 
I submitted such a draft severl months ago (now expired).   I agree. And 
there
is an RFC that describes how to link a VCARD to an iCAL objects
and that RFC also included LDAP links. RFC-2739

-- 

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/20040818/d198a5b0/smime.bin

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Mon Aug 23 09:07:48 2004

Hi Cameron,

--On Wednesday, August 18, 2004 5:27 AM +0000 Cameron Stillion 
<[email-masked]> wrote:

> <aside: I would welcome an

As a further aside I would also welcome a similar effort to caldav for 
vCard. i.e. being able to support personal address books (and shared 
address books) stored in webdav. This would be a replacement for IMSP and 
the (failed) ACAP protocols that we currently use for this.

-- 
Cyrus Daboo