Re: [VCARDDAV] vcardrev nits
Peter Saint-Andre <stpeter@stpeter.im> Tue, 20 October 2009 15:29 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 21FDA28C0F1 for <vcarddav@core3.amsl.com>; Tue, 20 Oct 2009 08:29:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_81=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 lZFUAj6CoFRD for <vcarddav@core3.amsl.com>; Tue, 20 Oct 2009 08:29:56 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 02A6328C11D for <vcarddav@ietf.org>; Tue, 20 Oct 2009 08:29:56 -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 7DECD40D0B; Tue, 20 Oct 2009 09:30:03 -0600 (MDT)
Message-ID: <4ADDD77B.7000801@stpeter.im>
Date: Tue, 20 Oct 2009 09:30:03 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Simon Perreault <simon.perreault@viagenie.ca>
References: <4AB00791.4040005@stpeter.im> <4ADDBEB3.9090604@viagenie.ca>
In-Reply-To: <4ADDBEB3.9090604@viagenie.ca>
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: Tue, 20 Oct 2009 15:29:57 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/20/09 7:44 AM, Simon Perreault wrote: Hi Simon, thanks for the edits. A few more minor comments inline... >> 7.5.1. TZ >> >> I still think it would be nice to have a field for offset from UTC. > > I added the possibility of a utc-offset value with the following note (thanks > Cyrus!): > > Note that utc-offset values SHOULD NOT be used because the UTC > offset varies with time - not just because of the usual DST shifts > that occur in may regions, but often entire regions will "re-base" > their offset entirely. The actual offset may be +/- 1 hour (or > perhaps a little more) than the one given. OK, that seems reasonable. >> 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.) > > Currently, a value of type binary needs the ENCODING=b parameter. That's the way > it is, no questions asked. > > The reason is both for backward compatibility (there were other encoding types > in previous versions of vCard) and for forward compatibility (we may choose to > add another encoding in the future). > > Just don't touch it, it's not broken. If you say so... ;-) >> 7.6.6. RELATED >> >> represents has => has > > Actually "represents has" is correct in this context. > > Purpose: To specify a relationship the individual this > vCard represents has with another. Oh, I see! The concatenation of two second-person singular verbs is confusing. I suggest: Purpose: To specify a relationship between another person and the individual represented by this vCard. >> 7.7.1. CATEGORIES >> >> Is a category essentially the same as a "tag"? > > Yes! > > Actually this is worth mentioning so that "kids these days" know what we're > talking about. You betcha! >> 7.9.1. FBURL >> >> last six weeks >> >> Is the definition of FBURL really that specific? > > This is copied from RFC 2739, which also says the following: > > The amount of busy time data pointed to by the FBURL will generally > be pre-determined; for example one month of busy time data. As a > guideline, it is recommended that the previous six weeks of busy time > data be published at the location associated with the FBURL. > > Seems contradictory... Either it is fixed or not. > > Is there existing usage of this property? Do people like it to be fixed or not? I don't have a strong preference here -- we can inherit from RFC 2739. >> 8. Synchronization >> >> As noted, I might have more substantive comments on this section. I got confused when I first read that section, but now I'm not confused. Or at least I'm less confused. Synchronization is thorny. >> 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? > > You mean not doing synchronization? Sure, implicitly. But if you do, and the > UIDs are equivalent, then the vCards are matched. Also: > > In all other cases, vCard instances MAY be matched at the discretion of > the synchronization engine. OK, that clarifies it for me. >> 10. Security Considerations >> >> The mention of Internet mail is jarring. Perhaps first mention that >> vCards are often used to transport vCards? > > Yes. > > Internet mail is often used to transport vCards and is subject to many > well known security attacks... Thanks, you understood what I meant and not what I wrote. :) 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/ iEYEARECAAYFAkrd13sACgkQNL8k5A2w/vzOsgCeOCAlMpmniBTwfYkins8cilZq xEEAoMuABbwPeyc6wltjiWFOmb39gz98 =2G7j -----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