Subject: [VCARDDAV] Dynamic data field support?

From: "Darryl Champagne" <[email-masked]>
Date: Thu, 8 May 2008 21:58:25 -0400

Hi all,

Inside OMA there is an effort called the "Converged Address Book", or CAB.
A description of the work program is available at
http://www.openmobilealliance.org/ftp/Public_documents/TP/Permanent_document
s/OMA-WID_0155-CAB-V1_0-20071009-A.zip.

Their scope includes "Define an extensible CAB data structure ensuring that
it shall be able to incorporate data fields from existing formats (e.g.,
vCard specifications supported in today's devices)." - Which appears to be
requiring a superset of vCard.

The primary data difference between it and existing vCards, outside of
requiring service support (similar to vCardDAV) and permissions issues
(publishing one's contact information to others), is that it expects to
include relatively dynamic information, such as one's presence information
(online, busy, Be Right Back, current best contact point, and so on).  It
also might link to other information, such as a user's list of bookmarks.

To me, since I dislike overlapping standards and effort, this raises the
question:

Should a revised vCard standard support information that is likely to be
dynamic - such as presence, current location, and current preferred contact
(E.g. a PREF that floats based upon time of day)?  This is not a ruleset for
PREF, it is a PREF that may be different for each read.

vCard already supports PREF, to indicate a preferred phone number or email
address.  The main difference between this and some of CAB requirements is
to allow PREF to change over the course of a day - when fetching the data
during business hours the preferred contact point might be the business
phone, outside of normal hours (but not during sleeping hours) it might be a
mobile number, and during sleeping hours it might only be an email address.

Obviously this complicates revision tracking (and one might want to exclude
all dynamic data from REV entirely).

Is this within the scope of vCard?  Should PREF be removed from individual
properties, and made its own property? Or why should this not be part of
vCard, since vCard is a "data format for representing and exchanging a
variety of information about an individual ", which this is...

This is not an attempt to be difficult, but rather being concerned about the
IETF updating vCard at the same time that OMA is talking about creating a
vCard superset (and NOT by using X- fields in a vCard).

Thanks,
dgc
--
Darryl G. Champagne
Technology Evangelist
Funambol
[email-masked]          http://www.funambol.com 

_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 May 2008 20:11:53 -0600

> dynamic - such as presence, current location, and current preferred contact

I think not. We already have infrastructure for presence, as well as
"rich" or "extended" presence data such as geolocation. IMHO a vCard
contains relatively stable information about an entity. If we put
dynamic data into vCards, then we'll need a technology for obtaining
dynamic updates about that data (push or poll -- pick your poison). And
then we'd need to define a way to categorize static vs. dynamic so that
we don't poll for the static data only to be told that, no, the person's
name still hasn't changed. Etc. Sounds pretty messy to me.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Darryl Champagne" <[email-masked]>
Date: Fri, 9 May 2008 10:15:15 -0400

> -----Original Message-----
> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Thursday, May 08, 2008 10:12 PM
> To: Darryl Champagne
> Cc: [email-masked]
> Subject: Re: [VCARDDAV] Dynamic data field support?
> 
> "rich" or "extended" presence data such as geolocation. 

Agreed, and perhaps a better integration is eventually just adding a
vcarddav url there...

> IMHO a vCard
> dynamic updates about that data (push or poll -- pick your poison). 

Note that OMA-DS/SyncML 1.1 and up (and ActiveSync, if I remember correctly)
already does this (both push and pull)...

> And
> name still hasn't changed. Etc. 

OMA-DS/SyncML 1.2 and up supports sending just the fields that have changed,
although you still are doing this on a set of records, not polling or
receiving notifications based on a subset of fields.

> Sounds pretty messy to me.

Yes.  The one part I am seriously wondering about if there is some way to
update PREF to better fit the real world.  Unfortunately dealing with all
the issues is unreasonably complex - send work related emails to this
address, send personal messages to this one, use this phone for work related
stuff during these hours, for personal calls use these numbers during these
times, for emergencies use this...