canmove, Confirmed users
2,675
edits
(started draft 15 section by section review, incorporated carryovers from draft 13 review through section 5.) |
(→draft 15 section by section review: add 6.1.4 KIND feedback update) |
||
Line 132: | Line 132: | ||
Same issue(s) as draft 13 section 5.7. No specific comments. General comment - type seems like a catch-all of sorts - not very well designed. Some of the uses are quite flawed. E.g. the notions of "work" and "home" have not worked well in practice. In particular "work" doesn't make much sense given that there is an "ORG" property with which any work email/phone/address should be associated, rather than just implied. | Same issue(s) as draft 13 section 5.7. No specific comments. General comment - type seems like a catch-all of sorts - not very well designed. Some of the uses are quite flawed. E.g. the notions of "work" and "home" have not worked well in practice. In particular "work" doesn't make much sense given that there is an "ORG" property with which any work email/phone/address should be associated, rather than just implied. | ||
=== section 6.1.4. KIND === | |||
6.1.4. KIND | |||
While not the best of ideas, the introduction of this somewhat meta-property may be inevitable to at least distinguish between the existing real world uses and implementations of vCards for organizations, people, and places. | |||
I still object to: GROUP | |||
GROUP should be dropped from 6.1.4 KIND. It may make sense as an extension (similar to LIST and ROBOT suggested by Kevin Marks). | |||
2010-12-20 email sent to vcarddav list accordingly. | |||
== related == | == related == | ||
* [[Standards]] | * [[Standards]] |