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-----
- [VCARDDAV] vcardrev nits Peter Saint-Andre
- Re: [VCARDDAV] vcardrev nits Javier Godoy
- Re: [VCARDDAV] vcardrev nits Julian Reschke
- Re: [VCARDDAV] vcardrev nits Javier Godoy
- Re: [VCARDDAV] vcardrev nits Kurt Zeilenga
- Re: [VCARDDAV] vcardrev nits Julian Reschke
- Re: [VCARDDAV] vcardrev nits Julian Reschke
- Re: [VCARDDAV] vcardrev nits Kurt Zeilenga
- Re: [VCARDDAV] vcardrev nits Alexey Melnikov
- Re: [VCARDDAV] vcardrev nits Peter Saint-Andre
- Re: [VCARDDAV] vcardrev nits Cyrus Daboo
- Re: [VCARDDAV] vcardrev nits Peter Saint-Andre
- [VCARDDAV] SORT-STRING [was:vcardrev nits] Javier Godoy
- Re: [VCARDDAV] SORT-STRING [was:vcardrev nits] Peter Saint-Andre
- Re: [VCARDDAV] SORT-STRING [was:vcardrev nits] Javier Godoy
- Re: [VCARDDAV] vcardrev nits Simon Perreault
- Re: [VCARDDAV] vcardrev nits Peter Saint-Andre
- Re: [VCARDDAV] vcardrev nits Ciny Joy
- Re: [VCARDDAV] vcardrev nits Simon Perreault
- Re: [VCARDDAV] vcardrev nits Ciny Joy