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