Subject: [VCARDDAV] Some remarks bout the vCard 4.0/0.3

From: Jean-Luc Schellens <[email-masked]>
Date: Mon, 4 Aug 2008 12:36:29 +0200

Hello,
Please find below some remarks and comments about the last vCard 4.0  
specs

Introduction
Basically, I am a CRM expert (Siebel, SAP, Salesforce, Microsoft...)  
so I’m expecting a more relational approach with N:N relations between  
cards and a clear difference between a “physical person” (a contact in  
a CRM application) and a “legal person” (an account in a CRM  
solution). Data quality and synchronization are also key in the CRM  
business, Microsoft Outlook being the by default integrated address  
book with all the well-known limits...
I am also defining an iPhone application, so compatibility with the  
iPhone and Mac address book is also important!

Issues:
For me

1 NAME vs. FN: excellent but the specific characteristics and purposes  
have to be clarified
2 KIND: really key and very useful but if KIND replaces GROUP (see  
14), would it still be possible to have a hierarchy like PARENT GROUP  
in the Mac Address Book?
3 N would have a “Family Name Prefix” for the small caps part of an  
“aristocratic” name (see 11)
4 NICKNAME could be a value of N
5 BDAY/DDAY seem to be limited. I would like to define Start/End  
dates, Move In/Out...
6 LANG would be an identification property with parameters to define  
the level (e.g; Mother, Fluent, Business practice...well known issue  
for Canadian and Belgian ;o)
7 LOGO and PHOTO are maybe redundant!
8 MEMBER & RELATED would be clarified. For me RELATED is more a MEMBER  
value!
9 CATEGORIES has to be clarified. As described, it looks like a mean  
to define the activities of an organization and that is fine. But the  
Mac Address Book uses CATEGORIES to export the “GROUPS” in vCard 3.0!  
(see my question about GROUP) --> rather ACTIVITIES or SECTOR as  
property name
10 REV would be a multi-value property including the PID for data  
quality and synchronization purposes
11 SORT-STRING would be based on the “last name prefix” type for the  
“aristocratic” sorting like in the “van der Harten” example.
12 SOUND would be a multi-value property e.g. to store the  
pronunciations and ringtones related to a card.
13 URL would be multi-value property with types like “extranet”,  
blog”...
14 Why “GROUP” is removed? No more hierarchy with “PARENT GROUP” like  
the Mac AB!

Details:
For me,

1 GEO and TZ would be Delivery Addressing properties related to a  
street address
2 UID would be a general property
3 CLASS would be a general property for “privacy” purposes --> rather  
PRIVACY as property name
4 KEY would be a communications property associated with an email  
address

Regards,
Jean-Luc
PS Marc et Simon, est-ce la bonne manière de procéder ?

_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Mon, 04 Aug 2008 17:14:24 -0500

Jean-Luc Schellens wrote:
> Please find below some remarks and comments about the last vCard 4.0 specs

I agree with Javier's comments. Here are some of my own.

> 1 NAME vs. FN: excellent but the specific characteristics and purposes 

Do you have text to propose?

> 4 NICKNAME could be a value of N

What would be the advantage of that?

> 5 BDAY/DDAY seem to be limited. I would like to define Start/End dates, 
> Move In/Out...

You mean like a birth that spans several days? Please explain.

> 9 CATEGORIES has to be clarified. As described, it looks like a mean to 
> define the activities of an organization and that is fine. But the Mac 
> Address Book uses CATEGORIES to export the “GROUPS” in vCard 3.0! (see 
> my question about GROUP) --> rather ACTIVITIES or SECTOR as property name

Do you have text to propose?

Note that CATEGORIES really is a way to specify the categories, or 
groups, that a given vCard belongs to.

> “aristocratic” sorting like in the “van der Harten” example.

What if you want to sort on something else?

> 1 GEO and TZ would be Delivery Addressing properties related to a street 
> address

Could you be more specific? I don't understand what you're suggesting.

> 3 CLASS would be a general property for “privacy” purposes --> rather 

Let's not change property names and preserve backward compatibility.

> 4 KEY would be a communications property associated with an email address

I don't quite understand what you mean.

> PS Marc et Simon, est-ce la bonne manière de procéder ?

Oui, c'est parfait! Mais avec des exemples concrets de texte à modifier 
dans le spec, c'est encore mieux. ;)

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 5 Aug 2008 08:30:44 +0100

In message <[email-masked]>, Simon Perreault 
<[email-masked]> writes

>Could you be more specific? I don't understand what you're suggesting.

I would like it to be possible to record the tine-zone and coordinates 
of all of my addresses: my home in Birmingham, England, my summer home 
in the south of France [*], and my cottage in the Bahamas [*]. I think 
this refers to that capability.

[*] I can dream...

-- 
Andy Mabbett