[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [VCARDDAV] vcardrev nits

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