Subject: [VCARDDAV] draft minutes for IETF 72 Dublin vcarddav meeting

From: Chris Newman <[email-masked]>
Date: Thu, 31 Jul 2008 10:43:05 +0100

Minutes for vcarddav meeting IETF 72 Dublin

Intro Slides presented -- Marc

vCard revision slides presented -- Simon

 Discussion of group syntax for "work" vs. "home" in TEL type definition
 vs. using a parameter.  What if two work addresses each with it's own
 phone?  How is that phone grouped with that work address?
 => Room consensus this is useful feature, but not consensus to use groups.

 #236 Discussion of truncated dates and BDAY
 => Room consensus to use 3339 appendix (8601 full ABNF) as a starting point
 and boil it down.  Additional discussion on details is needed.

 ...

 #225 Mandatory UID property
 Suggestion: MUST create UID when creating a new card, MUST preserve UID,
 MUST NOT create UID in existing card (latter needs some wordsmithing).
 Postpone this to sync discussion.

 ...

vCard Sync presentation -- Pete

 PIDs, LASTPID?, Triangle Sync
 long discussion
 idea: device id and tag attribute
 How much of sync problem should be in vCard vs. out-of-band?
 Where is the line for that?
 Perhaps not allow Triangle Sync.
 For two party sync, think we can provide enough data in card to always 
detect
 a conflict.  For triangle sync, may be too complex.
 Additional discussion needed.

Discussion of possible interim meeting near October CalConnect meeting
(1st week in October)

Status of CardDAV presentation -- Cyrus

Status of MKCOL extended -- Cyrus

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

---

From: "Darryl Champagne" <[email-masked]>
Date: Thu, 31 Jul 2008 14:41:05 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Chris Newman
> Sent: Thursday, July 31, 2008 5:43 AM
> To: [email-masked]
> Subject: [VCARDDAV] draft minutes for IETF 72 Dublin vcarddav meeting
> 

>  Perhaps not allow Triangle Sync.

Do people realize that no-one advocates actually doing triangle sync?  That
every sync vender out there already tells people not to do it?  The SyncML /
OMA-DS / Funambol / My goal is to stop catastrophic failures from occurring
when people actually do it - which someone always does.  All that is
required is for someone to install a new sync solution with at least 3
parties - to test it, or whatever, and then switch back, and then you get
problems.  It doesn't matter if they started with ActiveSync, and then tried
something else, or whatever, someone always hits it, unless you belong to a
very authoritarian company that does not allow users to install or configure
any software on their own.  What is needed is to ensure that at a minimum,
it does not get any worse (unlike LASTPIDs, compared to alternatives).  "Not
allow" is also not realistic.

> Discussion of possible interim meeting near October CalConnect meeting

I think I would like to make sure that we even have vaguely overlapping
goals, before I try to persuade my management to go for anything like
that....

If the focus is on the implementations that store vCard natively (or close),
then based on non-replies and various comments (such as 
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00503.html and
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00441.html, and
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00354.html, which
drove this attempt at clarifying goals: 
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00378.html), it
seems like some people have already discarded caring about all low-end
devices (except (1), below), all mid-level devices (2), virtually all
high-end devices (3), the large majority of PCs (running Outlook/Notes) (4),
and most high-end scalable servers (internet/phone carrier/ISP portals) (5).

Are any of the discussions, such as for LASTPID, actually relevant not just
for "some" apps, but for something with a market presence (now or next
couple of years)?

As far as I can tell, this only works (meaning both sides store the
vCard-like data) for an insignificant fraction of what syncs currently occur
(or likely in the next couple of years).  Perhaps from the Mac to a PC
running Thunderbird, or from Thunderbird to some custom prototype, or from
Thunderbird to Eudora.  Nothing to or from any phone/pda/smart-phone/music
type device.  All the rest store the sync meta-data separate from the
address book data, and thus have to worry about switching sync clients,
upgrades, and so on, where the sync meta-information is out of sync with the
address book data.

Do we even care about the same situations?  If improving one hurts the
other, then we get nowhere if we have different goals.  At this point, we
seem to be trying to support completely different subsets of
implementations.

dgc

1) There once was a device that stored sync info with the address book data
- but the only way to modify any of it was to read the entire volatile
memory contents, and write the modified values back (long since off the
market).  All the rest that I know of can only store a specific set of
fields into the native address book.

2) That I know of anyway - does anyone have a counter-example?

3) Does anyone actually have a real, market deployed (or close) example of a
device that stores vCard-like data with the address book data - as opposed
to separately with the sync client - e.g. where if you upgrade or use a
different sync client you would get the vCard info back?  I expect there
might be some (although if the device supports downloading clients, it seems
unlikely), but I don't know of any - the iPhone has separately downloadable
sync clients, which I don't think can see any of this info (I might be
wrong, this is indirect info), Windows Mobile devices are not able to see
any vCard like data from the address book, J2ME devices do not, I don't
think any of the standard Symbian devices do... What's left?  I certainly do
not see any with significant market presence.

4) While Thunderbird is doing OK, the market numbers still show Outlook and
Notes as holding an overwhelming majority.  Both of those require all sync
data (including any direct vCard info) be stored independent of the address
book application (or encoded in a non-portable fashion - not visible to
other sync clients).

5) Many large scale servers have to deal with aging inactive data out.  Thus
while many of them do store enough information to recover the actual vCard,
and the address book information and sync meta-information specific to
active devices will be kept, but after a period of inactivity, they will
flush out all information that is only specific to an inactive device, and
thus we end up with the sync meta-information being lost relative to the
address book data.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 31 Jul 2008 23:55:34 +0100

Le 08-07-31 à 19:41, Darryl Champagne a écrit :
...

>  it

I'm sorry Darryl but I do firmly believe that all parties in this wg,  
at least the ones who are participating in the mailing list and in the  
meetings, have good will and desire to make progress and have no  
intent to discard any kind of device or applications. We all have in  
our pockets these devices that we, as users, want to have synced with  
the computers. We might want, as a working group, to build concensus  
on some set of use cases so that we are not winding up forever without  
results.

I do see that you are making very good contributions and take  
significant time for this working group and that is fantastic and  
appreciated. We should all try to contribute especially by providing  
text or modification to current text, so that we are making progress  
towards the goal that I think all of us want to achieve: a much better  
updated vcard spec, interoperable and deployable.

I would suggest that you try to provide text of modification of  
current text for the points you are making.

Again, thanks a lot for your contribution.

Marc.
-----
IPv6 book: Migrating to IPv6, Wiley, http://www.ipv6book.ca

---

From: Simon Perreault <[email-masked]>
Date: Fri, 01 Aug 2008 09:58:34 +0100

Darryl Champagne wrote:
> every sync vender out there already tells people not to do it?

Two-party sync is easy: just record diffs as metadata and exchange that 
in the sync protocol. PID/LASTPID are simply a way to put that metadata 
into the vCard.

What is the metadata that should go into the vCard (and thus become 
data)? I'm still not convinced that there should be *any*, especially if 
a sync engine still cannot do a reasonable sync job without metadata.

If we just don't want to address three-party sync, I would argue against 
having any PID stuff in vCard and instead just exchange diffs.

If we do want to address three-party sync, I fear PID/LASTPID won't be 
enough to do a reasonable sync job, and in that case I would also argue 
against having any PID stuff in vCard.

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav