Re: [VCARDDAV] PIDs proposal

[Aki Niemi <aki.niemi at nokia.com>]

ti, 2008-06-24 kello 07:08 -0400, ext Darryl Champagne kirjoitti:
> > First of all, you insist on a per-property ID, yet most of the
> > discussion is about changes in TEL properties. Surely the PID is
> > completely superfluous on singleton properties like N or FN, no? 
> 
> If you would look at the text I wrote (has anyone?) - I specifically said
> that:  "It MUST NOT appear on properties that only may have one instance per
> vCard.".  This is a total non-issue.

I had missed that, sorry.

> > Secondly, the only way to detect deletions with the PID scheme reliably
> > is to store the entire history in the object, with something like NULL
> > property values. That's just wrong. I don't want to clutter the data
> > format with an edit history information.
> 
> Sync Engines can already detect deletions successfully.  That is a total
> non-issue.  The primary thing they cannot do well with the vCard format is
> to know which item of multiples was deleted.

They can detect deletions, but not additions or modifications? How is
that possible?

<snip />

> If people do not understand the implications of sync - mapping between
> different formats, the loss of data, the recovery issues, the issues that
> the vast majority of real world contact books do not store vCards, yet can
> be synchronized with vCard, and what sync engines can do easily (like detect
> deletions), and what they cannot, then it is not very useful discussion.

And this is exactly what bothers me. It's clear there are sync solutions
deployed today using vCard that arguably work without any per property
identifiers.

How is it that this fundamental change is required at this point?
Assuming clients worked as they should, i.e., didn't lose information
when converting vCard into their internal data format and back, what
exactly is the problem with vCard?

I think there needs to be some fundamental flaw in the data format to
justify PIDs. Bugs in client implementations are not such a flaw for
mainly two reasons: 

      * We've got no guarantees that they will ever implement PIDs in
        the correct way either. In fact, you've said changes generally
        propagate to phones slowly (which might or might not be true ;),
        which actually seems contradictory to proposing extensive
        changes to the data format.
      * The devices on which this new version ends up being implemented
        are a few years away anyway, which makes it futile to optimize
        on current hardware limitations.

> > And usually, writing an internet-draft is the best way to communicate
> > ideas that are too complex to represent efficiently over email. It also
> > allows having a single proposal on the table, on which everyone can then
> > focus their discussion.
> > 
> > > Otherwise it seems like we are at the point that it has been a couple of
> > > months since everything was discussed, and people have forgotten about
> > it,
> > > and we are starting everything over, which is incredibly frustrating and
> > > wasteful.  If people did not agree to the last round of emails about
> > PIDs,
> > > why wait until now?
> > 
> > Well, the only changes I've seen since then are that the parameter name
> > was changed and the type size decreased from UUID to int. Those are
> > purely cosmetic changes, and have done nothing to address the
> > fundamentals.
> 
> Define the fundamentals.  I have already done threads on the actual issues
> with collisions, and the real world odds of collisions, and people keep
> forgetting that the way it works today is that every change is the
> equivalent of a PID collision.  If people need yet another thread on the
> chance of a collision, and the impact, then so be it, but it still seems a
> waste.

Fundamentals, as in why the heck this new parameter when sync today
seems to be working quite well without it, modulo the client bugs? 

And assuming there was a good justification, the ordered list approach
seems much cleaner than the PID proposal, but it's hard to evaluate
their merits when the problem isn't clear.

> It especially seems a waste to write stuff, and have no sign of anyone
> actually reading it.

Don't assume I don't read your posts. I've read them, and still don't
understand your point. There's a big difference, and apparently the
situation won't improve by me re-reading your posts (which I also did).

Cheers,
Aki



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