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

From: Jean-Luc Schellens <[email-masked]>
Date: Wed, 6 Aug 2008 23:28:04 +0200

>   1. Re:  VCARDDAV Digest, Vol 12, Issue 39 (Darryl Champagne)
>
>>
>>>>>>> - 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
>
> 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.

I understand your reactions but let's take into account:
1 - Which vCards are frequently updated (add/edit/delete).
- Your own cards - how many do you have? I have more than 10 personal/ 
professional cards because I'm a consultant working for different  
companies as a self-employed collaborator, but I think I'm quite an  
exception! Anyway, I'm not updating frequently my own cards!
- The cards of your contacts - how many do you have? I have currently  
more than 250 (family, friends, colleagues...). But I rarely update  
these cards! In fact, I'm expecting updates from my contacts. That's  
why the Plaxo concept of "update requests" was great (but poorly  
implemented/marketed)!
And if you look to Facebook, having more than 500 "friends" is quite a  
"non-sense record" ;o))
So for me size it's no a real concern, even if all the properties will  
have a PID.
When you create a vCard, you'll have REV:PID=ALL;TYPE=created;2008-08-08
When you update a vCard, you'll have REV:PID=2;TYPE=deleted;2008-10-10
When you delete, you'll have REV:PID=ALL;TYPE=deleted;2008-10-12.
+/- 100k to compare with a KEY (+/- 2800k) or a PHOTO/LOGO
2 - It's not because vCard 2.1 and mobile platforms are limited today  
that we have to restrict vCard 4.0. We have to target the  
"smartphones" which will becomes commodities in the next 5 years.  
(With guys from Apple, Cisco, Nokia, Oracle, Qualcom, Samsung, Sun...  
in the vcarddav group ;o))
3 - For me vCard 4.0 is a great opportunity to relaunch the electronic  
exchange of personal data and to be definitely rid of the paper  
business cards. (For me the business card reader is one of the most  
stupid product but its success is probably due to the limits of vCard.  
And I also hate the email's automatic signature with all the sender  
data at the bottom when you know how simple it's to attached a vCard  
to the signature!)
4 - So to conclude, such a rich REV property will be a great solution  
for all the data quality and synchronization issues which are today  
real nightmares as you probably know
Regards
Jean-Luc

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

---

From: "Darryl Champagne" <[email-masked]>
Date: Thu, 7 Aug 2008 22:19:20 -0400

_____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jean-Luc Schellens
Sent: Wednesday, August 06, 2008 5:28 PM
To: [email-masked]
Subject: Re: [VCARDDAV] VCARDDAV Digest, Vol 12, Issue 45

.

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.  

.
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.

- Your own cards - how many do you have? I have more than 10
personal/professional cards because I'm a consultant working for different
companies as a self-employed collaborator, but I think I'm quite an
exception! Anyway, I'm not updating frequently my own cards!

- The cards of your contacts - how many do you have? I have currently more
than 250 (family, friends, colleagues...). 

For me, 1 - I create custom ones when I need to.  However, I have gone
through 9 companies, several with more than one address, each with different
email addresses and office and mobile phone numbers, at least 4 ISPs with
their addresses (although I keep just one email forwarder), and so on.  It
does start to add up, which leads to wanting to truncate it at some point,
which allows people to truncate it really short and then its no longer
useful.

955, but I have been getting lazy and not entering lots of them in the last
couple of years - just searching for people's emails when I need to -
basically using search instead of the address book most of the time.  Most
only get updated every couple of years, when I hear that someone has
switched companies, has a new email address, birth/marriage/child, phone
number, etc.  

You especially have to watch out for the CEO or Sales executive with 10K+
contacts, when they go to demo the product.

But I rarely update these cards! In fact, I'm expecting updates from my
contacts. That's why the Plaxo concept of "update requests" was great (but
poorly implemented/marketed)!

So for me size it's no a real concern, even if all the properties will have
a PID.

2 - It's not because vCard 2.1 and mobile platforms are limited today that
we have to restrict vCard 4.0. We have to target the "smartphones" which
will becomes commodities in the next 5 years. (With guys from Apple, Cisco,
Nokia, Oracle, Qualcom, Samsung, Sun... in the vcarddav group ;o))

I think you miss the point I am trying to make - I was referencing what
Smartphone's and PC's do, not just low end devices.  It's not just something
that goes away when they have more than X Kb/Mb/Gb.  Microsoft Outlook (at
least through 2003 - I can't bring myself to try a newer version) can only
export vCard 2.1, for example - a PC application.  It isn't because of
limited memory - it's on a Windows platform, and uses huge amounts of
memory.  

Anyway, nearly all devices and environments end up with the Sync Application
separate from the Address Book Application.  Nearly all Address Book
Applications end up storing the data in their own internal format (usually
some kind of relatively static structure), not as a vCard.  All the data
that does not exactly fit into that static format ends up having to be
stored in the Sync Application, separate from the address book.  When the
vCard is a good fit with the address book, then most of the data can go in
the address book, with just a little bit in the Sync Application.  Things
that aren't a good fit have to have special processing by the sync app, and
the path of least resistance for a lot of developers is to throw away data
they don't need for anything..

In that case, a 100K photo that has a home in the parent application has
almost no cost if you aren't bandwidth limited, while PIDs and REVs and UIDs
and so on do have costs.

If you are bandwidth limited (including due to cost while roaming), then
large photos (etc) shouldn't be transferred - only the things actually
usable on that device.   Because the developer of the handset app works for
the company that gets screamed at when it takes several hours to do the
initial sync of their address book, or causes the infamous multi-thousand
dollar roaming bills, it is an environment where it is highly desirable to
be as conservative as possible.  Essentially, if there isn't an obvious
immediate advantage to them storing or transferring the data, they probably
won't.  I'm just rather pessimistic about storing extra data, or making
extra changes, because I have been banging my head against that brick wall
for over 11 years now.  We have a lot more memory now, and a lot more data,
but there still is the desire to keep it to only what is critically needed.
Maybe when 4G, or 5G, etc. comes out, or when all plans have free data
roaming over entire continents, but we are many years past what I first
thought the limits were.  

Anyway, it all comes down to what opinions people hold about what is a
"reasonable" amount of extra data, which is going to vary.

3 - For me vCard 4.0 is a great opportunity to relaunch the electronic
exchange of personal data and to be definitely rid of the paper business
cards. (For me the business card reader is one of the most stupid product
but its success is probably due to the limits of vCard. And I also hate the
email's automatic signature with all the sender data at the bottom when you
know how simple it's to attached a vCard to the signature!)

I agree about paper cards, but don't forget how many people in the IETF
still prefer to stick with only plain-text email - any attachments,
especially repeated on each email ones, are seen as evil and annoying by
some people.

4 - So to conclude, such a rich REV property will be a great solution for
all the data quality and synchronization issues which are today real
nightmares as you probably know

Regards

Jean-Luc

---

From: Andy Mabbett <[email-masked]>
Date: Sat, 9 Aug 2008 11:07:01 +0100

In message <001601c8f8fd$2c2e5f30$6f02a8c0@DGCSonyFS>, Darryl Champagne 
<[email-masked]> writes

> don?t forget how many people in the IETF still prefer to stick with 
>only plain-text email

Not just them- there are many other people (including me!) who prefer 
plain-text e-mail; and many who have it forded on them by their device, 
their software, or their employer's IT policies.

Bearing that in mind, please use a more standard quoting convention, 
like the chevrons I use above. I found it very difficult to tell what in 
your e-mail was written by you, and what was quoted. Thank you.

-- 
Andy Mabbett