Re: [VCARDDAV] vcardrev nits

[Simon Perreault <[e-mail]>]

Peter,

Many thanks for this very detailed review! I left out the minor grammatical
fixes in the reply below...

Peter Saint-Andre wrote, on 2009-09-15 17:30:
> 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.

I changed that to "individuals and other entities".

> 1. Introduction
> 
> This text is worrisome...
> 
>    Note: This draft contains much of the same text as 2425 and 2426
>    which may not be correct.

:)

It's outdated. I removed it completely. It feels good.

> 3. MIME Type Registration
> 
> Would it simplify things for IANA if this were in the IANA
> Considerations section?

Yes! I moved it.

> 4.1. Line Delimiting and Folding
> 
>    At least one character must be present on the
>    folded line.
> 
> I suggest:
> 
>    The folded line MUST contain at least one character.

Better. Changed.

> 4.2. ABNF Format Definition
> 
> The comment on the contentline field contains normative text:
> 
>        ; When parsing a content line, folded lines MUST first
>        ; be unfolded according to the unfolding procedure
>        ; described above.
> 
> This strikes me as an odd place to put normative text.

Since this is a repeat of what's already said above, I just lowercased the MUST.

> 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".)

I added the "thing" value which stands for "an inanimate object (e.g. a device,
a server, etc.)"

> 7.2.4. PHOTO
> 
>    The full
>    media type name, including the "image/" prefix, should be used.
> 
> Change "should" to "SHOULD"?
> 
> (Same for LOGO and SOUND.)

Agreed. Changed.

> 7.4.3. IMPP
> 
> Would a reference to RFC 4770 be appropriate?

There is already a reference to RFC4770 in the "New Properties and Parameters"
section. I added one in the IMPP section.

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

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

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

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

Wow, I'm laughing out loud! I don't know what kind of logic I was thinking when
I wrote that. Of course you're right. Changed.

> We might also mention that a child does not need to be a natural,
> biological child (adopted child, stepchild, etc.).

Sure.

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

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

Better. Changed.

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

> 8. Synchronization
> 
> As noted, I might have more substantive comments on this section.
> 
> 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.

> 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 again,
Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org