Re: [VCARDDAV] vcardrev nits

["Javier Godoy" <[e-mail]>]

Peter Saint-Andre wrote,

> 0. Abstract
>
> The reference to "individuals" might be taken to imply that vCards are
> only for humans, which I think they are not. Indeed, there is an old
> tradition in the Jabber community of assigning vCards to servers for
> geolocation purposes.

It is legacy text from RFC 2426 abstract.
Does it makes sense if we write "individuals or other entities"?

> 7.1.5. KIND
>
>   Special notes:  The value may be one of: "individual" for a single
>      person, "group" for a group of people, "org" for an organization,
>      "location" for a named geographical place, an x-name or an iana-
>      token.  If this property is absent, "individual" MUST be assumed
>      as default.
>
> What about devices, servers, and other entities?
>
> (Compare to 7.2.3 NICKNAME, which at least mentions the possibility that
> the entity could be a "thing".)

The idea behind KIND was to provide guidance about the semantics of other 
properties (for instance, the semantics of ORG when KIND:org is different from 
its semantics when KIND:individual), therefore the kind for "device" and 
"server" should be the same. We could define a new standard value "thing" for 
other cases which are not addressed by the current defined values.

Alternatively, KIND:x-Jabber-server may work, but I would prefer not 
encouraging x-* tokens when it can be managed with standards values (however, 
if distinguishing servers from other devices is important, this information 
should be conveyed in a different property).

> 7.4.3. IMPP
>
> Would a reference to RFC 4770 be appropriate?

I don't think so, RFC 4770 will be obsoleted by vcardrev.

>
> 7.5.1.  TZ
>
> I still think it would be nice to have a field for offset from UTC.

Me too.

Note that the cardinality of TZ is defined as (0,n). If several TZ properties 
are specified, are they supposed to be equivalent?, for instance:

TZ:-0500
TZ:EST
TZ:Raleigh/North America

If it were the case, we could require that text values of the form -hh, 
+hh, -hhmm, +hhmm and the literal value "Z" should be understood as 
differences from UTC, as defined in ISO 8601.2004

> 7.6.3. LOGO
>
>   Encoding:  The encoding MUST be reset to "b" using the ENCODING
>      parameter in order to specify inline, encoded binary data.  If the
>      value is referenced by a URI value, then the default encoding of
>      8bit is used and no explicit ENCODING parameter is needed.
>
>   Value type:  A single value.  The default is binary value.  It can
>      also be reset to uri value.  The uri value can be used to specify
>      a value outside of this MIME entity.
>
> This strikes me as contradictory -- the "default is binary value" yet
> "the encoding MUST be reset to "b" using the ENCODING parameter in order
> to specify inline, encoded binary data"?? Why is it necessary to reset
> the ENCODING parameter to "b" if the default is binary? (The same
> comment applies to 7.7.6 SOUND and 7.8.2 KEY.)

The default is binary value (i.e. VALUE=binary) and 8bit encoding (as for the 
every other property).
If a URI is specified, the value must be reset to "uri", but the default 
encoding is right.
If inline data is specified, the encoding must be reset to binary ("b"), but 
the default value is right.

> 7.6.6. RELATED
>
> represents has => has
>
>   "child" means the opposite of "parent"
>
> Hot is the opposite of cold, high is the opposite of low, but child is
> the opposite of parent? I recommend:
>
>   "child" means that the related individual is the child of the
>   individual this vCard represents.

It also may be
 "child" is the opposite relation of "parent".

> 7.7.1. CATEGORIES
>
> Is a category essentially the same as a "tag"?

I think so...

> 7.7.5. SORT-STRING
>
>   locale- or national-language- specific sorting
>
> This is hard to parse. I suggest:
>
>   The sort string is used to provide family name or
>   given name text that is to be used in sorting of
>   the formatted name and structured name types in the
>   context of a particular locale or national language.

I don't agree with the "context of a particular locale or national language" 
part, as it seems to suggest that the collation is well-known and defined 
somewhere else.
I would modify it by "an implied particular locale or national language."

Besides, the current special note "The sort string is used to provide family 
name or given name text..." is ambiguous. How could the sort-string be of use 
if one cannot tell whether it applies to the given name or the family name.

Example 1
FN:Rene van der Harten
N:van der Harten;Rene;J.;Sir;R.D.O.N.
SORT-STRING:Harten

Example 2
FN:Rene van der Harten
N:van der Harten;Rene;J.;Sir;R.D.O.N.
SORT-STRING:Rene

In example 2 were specified (which is valid according to the definition), I 
would collate "van der Harten" under R.

Note also that the N property was redefined as a four-component text value. 
Hence the example (copied from section 7.7.5 of vcardrev-08) should read
N:van der Harten;Rene,J.;Sir;R.D.O.N.


> 8.1.1.  Matching vCard Instances> >   vCard instances for which the UID 
> properties (Section 7.7.7) are>   equivalent MUST be matched.> > Is it not 
> an option to punt on matching?
The option should be not to synchronize.
 "If synchronization is performed vCard instances for which the UID properties 
..."


Best regards

Javier