----------------------------------------------------------------------
Message: 1
Date: Tue, 20 Oct 2009 09:44:19 -0400
From: Simon Perreault <simon.perreault at viagenie.ca>
Subject: Re: [VCARDDAV] vcardrev nits
To: vcarddav at ietf.org
Message-ID: <4ADDBEB3.9090604 at viagenie.ca>
Content-Type: text/plain; charset=ISO-8859-1
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.)"
In Calconnect, we have been working on a draft, defining resources, in
the calendaring and scheduling context. VCARD is one form of
representation we are defining and we are trying to reuse as many
attribute definitions as possible from this draft. Would it be
possible to have a value of 'resource', for KIND. In scheduling
context, that would cover a room, an equipment, or even a role (person
with specific skill set).
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