Subject: Re: [VCARDDAV] VCARDDAV Digest, Vol 12, Issue 39

From: Jean-Luc Schellens <[email-masked]>
Date: Tue, 5 Aug 2008 18:50:15 +0200

>   1. Re:  VCARDDAV Digest, Vol 12, Issue 29 (Simon Perreault)
>
> Jean-Luc Schellens wrote:
>>> Jean-Luc Schellens wrote:
>>>>> Just understand that there is no "meaning" associated with  
>>>>> particular q
>>>>> values. It's just a way to order languages by preference.
>>>>
>>>> Does it mean that we are free to define the meanings?
>>>
>>> You mean in the spec or in your head?
>>
>> Indeed my head being my application!
>
> Well you're obviously free to think of q values any way you want.

I like to be free!

>>>>> - REV cannot have the PID parameter because it's a single- 
>>>>> instance-only
>>>>> property.
>>
>> For me, REV HAS to be a multi-instance property
>
> Can you say why?

Because a card can have more than one revision/change!

>>>>> - What does the TYPE mean?
>>
>> TYPE will have 3 values: created, updated, deleted
>
> What would they mean?
Just to say that PID=1 has been created, updated or deleted.

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

---

From: "Darryl Champagne" <[email-masked]>
Date: Tue, 5 Aug 2008 13:43:29 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jean-Luc Schellens
> Sent: Tuesday, August 05, 2008 12:50 PM
> To: [email-masked]
> Subject: Re: [VCARDDAV] VCARDDAV Digest, Vol 12, Issue 39
> 

> Just to say that PID=1 has been created, updated or deleted.

I believe I see what you are trying to do, but there are several problems.

1) If you really want to track when each change that has occurred to the
vCard was done, then you probably want to do it for all properties, not just
the multi-valued ones with PIDs (e.g. when was the UID created, or last
changed).

2) Size, Size, and more Size....  That can get pretty big, and how realistic
is it for that data to actually be kept?  The majority of portable devices
(other than laptops :-) ) still send vCard 2.1, instead of vCard 3.0, and
almost all of them only deal with vCal - almost none accept iCal.  They are
pretty slow to change, use extra memory, etc.. You really are talking more
about Journaling at this point, such as vJournal or something else.  If it
helped for a significant set of cases, that would be one thing, but
virtually all syncs today would have one side toss that data out, so the
data would never be used.

3) Sync Conflicts.  If I am merging two parallel sets of changes what
date/time matters?  If I use the original time that something changed
somewhere else, that will have sync problems, because it has changed in my
copy of the vCard since that time, so I need to send that change out to
everyone else I sync with.  But if I use the time of the merge, then either
I will be out of sync with the other side (I say it changed when I
incorporated the value into my vCard, while the other side still has the
original change time), or else I send my time of change back to the other
side, and it will have redundant changes being sent out - the date of change
is different, but the data isn't.

4) Details.  There would be a number of details to figure out - what if the
device truncates the value due to storage limits?  Is that a real change?
Do you really want it propagated to the other side?  What about values the
device doesn't store?  If it doesn't have room in its address book for the
data, how would it keep track of deleting something?  What about character
set changes, or capitalization changes?  Does reformatting (like adding
spaces to a telephone number) count?  Does adding a +1 in front of a North
American area code count?

Anyway, to me #2 is a killer - I just don't see where implementations would
actually be able to use it for anything in the real world.  It would be
great if the data was available, but it seems more just a good theory, not
actually practical.

dgc