[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[VCARDDAV] Dynamic data field support?



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
dgc at funambol.com          http://www.funambol.com 
 


_______________________________________________
VCARDDAV mailing list
VCARDDAV at ietf.org
https://www.ietf.org/mailman/listinfo/vcarddav