Re: [VCARDDAV] Format of PID field

["Javier Godoy" <rjgodoy at fich.unl.edu.ar>]

Hi Aki,

> If I understood the problem statement correctly in the last meeting, the
> problem is mainly with information loss, i.e., syncing devices drop
> parameters they don't understand or use themselves. This ambiguates the
> changes made, which causes all sorts of problems in the reverse
> direction.

This remembers me of a requirement in Section 8.1: "A missing UID property 
MUST NOT be considered equivalent to any other. Hence, the UID parameter 
MUST be present if synchronization is to be used."

I think "SHOULD NOT ... SHOULD" would better describe the situation where 
"intelligent merges" treat two properties as equivalent, even though one of 
them has no PID, or if no PID is present at all.


> But IMHO, this behavior is a bug in the implementation, not in the
> specification. If all syncing parties retained all information so that
> deletions or additions are all explicit and unambiguous, then I don't
> see the problem.

I agree, but it is a bug that implementors actually want (because vCard 3.0 
fails to address their requirements).

IIRC, vCard 2.0 had defined MAY/MUST requirements for "vCard readers" and 
"vCard writers", about each property type (e.g. vCard readers MUST 
understand the XXX property, vCard writers MAY generate the XXX property). 
IMHO, some statements in that direction may help (at least you will know 
what will be preserved by a "good" implementation, and you will be aware of 
possible loss of information).

Best Regards

Javier 


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