Re: [VCARDDAV] Core vCard requirement for Synchronization

["Darryl Champagne" <dgc at funambol.com>]

I really don't appreciate this quoting out of context nonsense.  Say what
you want as your opinion, but *do* *not* *misrepresent* *mine*.

I was very explicit about the size burden being the issue of a UUID being
attached to every property - "In this environment the requirements to store
additional data need to be minimized" and "Imposing a requirement for a UID
adds additional data of comparable size to the data being stored, which is
not practical for limited devices" - when I started the thread "[VCARDDAV]
UID/PID problems" on 5/29, because of lack of action.  Saying that I only
claimed that it was because clients could not store the vCard is completely
misleading, since that was just the start of an explanation as to WHY the
space mattered.  Saying that you are right and I am wrong because they are
too big - when that is what I said long before you, the person who put them
in - is flat out deceptive.  And in actual fact, the first person to
actually say that was Cyrus, on 1/22, unless you count the OMA-DS
contribution which suggested small numbers, which was from well before that.

The current wording is at least reasonable, although not ideal.  Clearly the
suggestions I make will not be incorporated without pages of text providing
absolute proof, so I need not bother to try and refine anything.  Stop the
rest of the nonsense unless there is a real issue.  If the point doesn't
involve a change to the spec, why is it on the mailing list?

I don't really care if you agree or not, or if you think you are the
ultimate guru of sync, vCard, or programming in general, or can't finish a
thread unless you are the only one right or whatever.  I care when it wastes
my time having to explain the absolute basics of sync, over and over, which
I am very tired of (and in general, I don't mind questions made in
ignorance, it's claiming expertise that isn't there that really bugs me).

I care if vCard 4.0 is going to be something that stands a chance of being
adopted, and I care about trying to get enough improvements that I can
justify to my boss the time spent on this, which is currently considered
mostly a waste (and frankly, anyone looking at the last 8 or 9 emails would
probably agree).

I have also worked with Mark for enough years to respect his opinions
(whether I agree or not :-; ).  I completely agree with him in that device
manufacturers have seen no reason to bother to change away from vCard 2.1.
Clearly the availability of UID (the property) was not a compelling reason
for them to switch to vCard 3.0, which makes me doubtful that it would help
push vCard 4.0 very much (sorry to disagree slightly with Cyrus).  The
availability of a PID might help, but I considered having every single PID
be a full uuid value as a strong dis-incentive to adoption, and that is what
I stated, which I think is pretty close to Mark's statement "prefer not to
see big huge UUIDs every where in vCARD " - with his context below (and
Cyrus had a similar statement back in January).

I also fully agree with Cyrus that "4.0 really does need to show some clear
benefits to be adopted".  I wish PIDs and UIDs would be considered part of
strong arguments, but I have been disappointed before - right now I am just
hoping that we can show a moderate benefit with little cost, to perhaps get
some adoption.

If my views are misrepresented, or further untruths stated I will respond,
or if there are actual issues with the spec, but right now this whole thing
has just been a total waste of time, and I hope to be done with it.  Anyone
who wants to know who understands what about sync need only review these
threads from the beginning, rather than looking at the final
misrepresentations.  And if this means I look mean, well, better that than
having to re-explain every little thing in pages of text from the most basic
point month after month to get simple little text changes in, like getting
rid of a totally inappropriate MUST NOT (which of course, still isn't out of
a posted draft).  If there is some point to be made that impacts the spec,
then make it, otherwise just stop.

dgc

> -----Original Message-----
> From: vcarddav-bounces at ietf.org [mailto:vcarddav-bounces at ietf.org] On
> Behalf Of Simon Perreault
> Sent: Friday, June 27, 2008 4:27 PM
> To: vcarddav at ietf.org
> Subject: Re: [VCARDDAV] Core vCard requirement for Synchronization
> 
> On Friday 27 June 2008 16:08:12 you wrote:
> > Device Manufacturers will move to vCard 4.0 if they see a compelling
> > market reason to do so. If they are pushed by operators such as Orange
> > Vodafone, etc.. to provide a better sync client that doesn't end up in
> > duplicated phone numbers and a vCard 4.0 solution (whether it be OMA DS
> > or CardDAV based) provides a way to solve this issue they will do it.
> > The size of a UUID vs a PID isn't really going to be what makes them
> > decide I suspect. Having said that I prefer not to see big huge UUIDs
> > every where in vCARD. I'd like to see implementors using UIDs (although
> > making them a MUST is not reasonable I suspect)  and smart use of PIDs
> > but let's be careful about presuming we know why device manufacturers
> > may or may not do something.
> 
> This is absolutely *not* what I was talking about. Let me try again:
> 
> - We have been examining 3 value types for the PID parameter: UUIDs, small
> integers, and opaque strings.
> 
> - Darryl states that UUIDs are (-1) because many devices cannot reproduce
> the
> original vCard as it was given to them.
> 
> - I say that's not the real reason, since even PCs cannot reproduce the
> original vCard as it was given to them. The real reason is that UUIDs are
> too
> big for the devices in question and won't be implemented.
> 
> - My point: the fact that many devices cannot reproduce the original vCard
> as
> it was given to them *has no impact whatsoever* because it has never been
> a
> prerequisite.

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