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