Re: [VCARDDAV] vcardrev nits

Peter Saint-Andre <stpeter@stpeter.im> Wed, 16 September 2009 20:27 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: vcarddav@core3.amsl.com
Delivered-To: vcarddav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2B03A6804 for <vcarddav@core3.amsl.com>; Wed, 16 Sep 2009 13:27:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=-1.241, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_13=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_64=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbLHsXQYX-eS for <vcarddav@core3.amsl.com>; Wed, 16 Sep 2009 13:27:13 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8FFAB3A6942 for <vcarddav@ietf.org>; Wed, 16 Sep 2009 13:27:13 -0700 (PDT)
Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 09D9D40D12; Wed, 16 Sep 2009 14:27:58 -0600 (MDT)
Message-ID: <4AB100C4.4030601@stpeter.im>
Date: Wed, 16 Sep 2009 09:14:12 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Javier Godoy <rjgodoy@fich.unl.edu.ar>
References: <4AB00791.4040005@stpeter.im> <4A6CDE38802D481BAF82CDF30E08B75E@Javier2>
In-Reply-To: <4A6CDE38802D481BAF82CDF30E08B75E@Javier2>
X-Enigmail-Version: 0.96.0
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: vcarddav@ietf.org
Subject: Re: [VCARDDAV] vcardrev nits
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2009 20:27:14 -0000

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