Re: [VCARDDAV] vcardrev nits

[Peter Saint-Andre <stpeter at stpeter.im>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/15/09 10:24 PM, Javier Godoy wrote:
> 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"?

Works for me.

>> 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.

A value for "thing" sounds good.

> 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).

I agree that it's desirable to avoid x- tokens.

>> 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.

OK. I think this could be worded more clearly, but I'm yet sure exactly how.

>> 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".

Well all of these definitions are close to tautological ("parent" means
parent, etc.), so I don't know how much it really matters.

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

It might be good to make that clear, since many people are familiar with
the concept of "tagging" these days.

>> 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."

That's better, yes.

> 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.

Correct. But that would be stupid. :) We can't save implementers from
their own stupidity, but I suppose we can help them understand that the
SORT-STRING is used for alphabetical sorting of family names containing
multiple words.

> 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.

OK.

>> 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 ..."

Right, it's a hypothetical imperative, not a categorical imperative.

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqxAMQACgkQNL8k5A2w/vwb6wCg8abvOAlkmVx1g9HtpQz3wPgu
mMIAn2pIvN/lueSVH2d2DLgZx33+6QQL
=SCXm
-----END PGP SIGNATURE-----