[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [VCARDDAV] vcardrev nits
-----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-----