Subject: [VCARDDAV] use case for multiple affiliations

From: Marc Blanchet <[email-masked]>
Date: Mon, 27 Jul 2009 10:49:52 +0200

Hi,
 how do we take into account the following use case in vcard4?

One individual has a professional vcard which contains multiple
affiliations: i.e. one have a day job (title, company, phone number,
email, ...) and also have a board membership in another company (title,
company, phone number, email) and etc...

The specific data should be related to the identity. That person wants
you to call him on the specific number related to the specific
identity/affiliation.

having multiple vcards is less than optimal since you don't want to send
multiple vcards to your contacts, but only one that contains all the data.

how do we bind the specific data to the appropriate identity in a single
vcard?

Marc.
-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

---

From: Markus Lorenz <[email-masked]>
Date: Mon, 27 Jul 2009 11:13:31 +0200

In vCard 3 I would have said: use grouping. Something like

   abccompany.TEL;TYPE=work,voice:+1-213-123-4567
   abccompany.ADR;TYPE=WORK,PARCEL:;;2nd Street;My
    Town;CA;91921-5678
   xyzboard.TEL;TYPE=work,voice:+1-213-555-1234
   xyzboard.ADR;TYPE=WORK,PARCEL:;;123 Main Street;Any
    Town;CA;91921-1234

But as the function of grouping has changed in vCard 4 to distinguish
between work and home information I also don't know how to build a
connection between information which belongs together. You have to use
the group "work" to indicate a work address, because the TYPE "work" has
been removed from ADR, TEL. etc. Multiple groups are not allowed.

Same problem appears with multiple private contact locations, e.g.
summer residence, semester address.

Markus

---

From: Kepeng Li <[email-masked]>
Date: Mon, 27 Jul 2009 17:14:14 +0800

Hi Marc,

Can we group all the data related to each identity together within one
group? 

Thanks,

BR,
Kepeng Li
Huawei
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marc Blanchet
Sent: Monday, July 27, 2009 4:50 PM
To: [email-masked]
Subject: [VCARDDAV] use case for multiple affiliations

Hi,

One individual has a professional vcard which contains multiple
affiliations: i.e. one have a day job (title, company, phone number, email,
...) and also have a board membership in another company (title, company,
phone number, email) and etc...

The specific data should be related to the identity. That person wants you
to call him on the specific number related to the specific
identity/affiliation.

Marc.
--
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server
for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service:
http://reeves.viagenie.ca

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

---

From: Simon Perreault <[email-masked]>
Date: Mon, 27 Jul 2009 13:24:38 +0200

>    xyzboard.ADR;TYPE=WORK,PARCEL:;;123 Main Street;Any

Marc had mentioned this problem to me privately and I couldn't think of
a solution at the time. Now I think this would be right:

Adapted for vCard 4:

   X-abccompany.TEL;TYPE=work,voice:+1-213-123-4567
   X-abccompany.ADR;TYPE=WORK,PARCEL:;;2nd Street;My
    Town;CA;91921-5678
   X-xyzboard.TEL;TYPE=work,voice:+1-213-555-1234
   X-xyzboard.ADR;TYPE=WORK,PARCEL:;;123 Main Street;Any
    Town;CA;91921-1234

> been removed from ADR, TEL. etc. Multiple groups are not allowed.

You can replace X-abccompany or X-xyzboard with work if you want to use
its semantics (i.e. "properties related to an individual's work place").

Otherwise, the X- groups have no special meaning that could be
interpreted by a computer. But you can use the X-group.ORG property to
describe the group to a human.

So the example becomes:

   work.TEL;TYPE=voice:+1-213-123-4567
   work.ADR;TYPE=PARCEL:;;2nd Street;My
    Town;CA;91921-5678
   work.ORG=ABC Company
   X-xyzboard.TEL;TYPE=voice:+1-213-555-1234
   X-xyzboard.ADR;TYPE=PARCEL:;;123 Main Street;Any
    Town;CA;91921-1234
   X-xyzboard.ORG=XYZ;Board

> summer residence, semester address.

Same problem has same solution, e.g.

   X-summer-residence.ADR:...
   X-summer-residence.TEL:...
   X-summer-residence.ORG:Summer residence

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 27 Jul 2009 13:44:11 -0400

Hi Simon,

>    X-summer-residence.ORG:Summer residence

I really don't like the idea of encoding information like that into the 
group name. If we want to have special meaning for groups, then we need 
additional properties to describe those groups. e.g.:

   X-1234.ADR:...
   X-1234.TEL:...
   X-1234.ORG:Summer residence
   X-1234.GROUP-DESCRIPTION:My summer residence from May - September

One could also imagine a type property for the group description for 
various cases, e.g. TYPE=HISTORIC for a set of information that is no 
longer valid but included for completeness, or TYPE=FUTURE;START=20090921 
for contact information that will be active from the specified data onwards 
only.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Mon, 27 Jul 2009 13:46:50 +0200

Cyrus Daboo wrote:
> group name.

What information? I could have used X-asdf and it would have had the
exact same meaning.

> If we want to have special meaning for groups, then we need

That's what ORG is for.

> longer valid but included for completeness, or
> TYPE=FUTURE;START=20090921 for contact information that will be active
> from the specified data onwards only.

Is this usage common enough to warrant new properties? Why not leave it
in plain text? Do computers really need to parse this?

Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 27 Jul 2009 14:06:00 +0200

Hi Simon,

>>   X-1234.GROUP-DESCRIPTION:My summer residence from May - September

Ah - missed that. OK, so ORG and NOTE etc with a group prefix can be used 
for this kind of thing. Maybe that could be clearer by some tweaks to the 
text.

> in plain text? Do computers really need to parse this?

It would be useful to be able to specify when a new address is going to be 
active so that a new vcard can be sent out ahead of time and a switch to 
the new address seamlessly achieved. There was also discussion in the past 
about capturing "historic" information in the vcard - but I don't think 
that is as important as the "update ahead of time" use case.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Mon, 27 Jul 2009 14:15:07 +0200

Cyrus Daboo wrote:
> Ah - missed that. OK, so ORG and NOTE etc with a group prefix can be
> used for this kind of thing. Maybe that could be clearer by some tweaks
> to the text.

Sure, will do.

> It would be useful to be able to specify when a new address is going to
> be active so that a new vcard can be sent out ahead of time and a switch
> to the new address seamlessly achieved. There was also discussion in the
> past about capturing "historic" information in the vcard - but I don't
> think that is as important as the "update ahead of time" use case. 

Hmmm... I'm really not sure that the use case is common enough for this
to be included in vCard core.

Moreover, I can easily see this being extended to all properties and
becoming "big" enough to warrant an RFC of its own.

Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 27 Jul 2009 14:18:30 +0200

Hi Simon,

> becoming "big" enough to warrant an RFC of its own.

Sure, this can be an extension.

-- 
Cyrus Daboo

---

From: Markus Lorenz <[email-masked]>
Date: Mon, 27 Jul 2009 14:31:33 +0200

>    X-xyzboard.ADR;TYPE=WORK,PARCEL:;;123 Main Street;Any

I can not see any values like "work", "voice", "parcel", or others
defined for "TYPE" in vCard 4 draft 08. "TYPE=home" and "TYPE=work" have
been removed in draft 04 and "parcel", "dom", etc. in draft 08.

>    X-xyzboard.ADR;TYPE=PARCEL:;;123 Main Street;Any

Yes, I could use X-groups to group these information together. But I
have no chance to determine automatically, if this group of information
belongs to home or work. The user has to guess it from the context. If I
had an application showing different icons for work and home, it would
not be able to decide which icon would be the right one for X-xyzboard.
For the application this could also be a summer residence.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 27 Jul 2009 14:47:54 +0200

> been removed in draft 04 and "parcel", "dom", etc. in draft 08.

Yeah, OK, I forgot those. My attention was focused on group names.

> For the application this could also be a summer residence.

So work and home should be tags, not groups, right?

Please send text... ;)

Simon

---

From: Markus Lorenz <[email-masked]>
Date: Wed, 29 Jul 2009 14:27:37 +0200

Simon Perreault schrieb:
>> have no chance to determine automatically, if this group of
>> information belongs to home or work. The user has to guess it from
>> the context. If I had an application showing different icons for work
>> and home, it would not be able to decide which icon would be the
>> right one for X-xyzboard. For the application this could also be a
>> summer residence.
>

What's important for me is this:

I think it's reasonable to have the possibility to group information
together. There is much data in a vcard that belongs together, because
it belongs to the same place. In our previous examples we had different
work places, summer residence, and semester address. There can be one
(or more) property value to each of these place for ADR, LABEL, TEL,
EMAIL, IMPP, TZ, GEO, TITLE, ROLE, LOGO, ORG, RELATED, NOTE, SOUND, URL,
KEY. Maybe others.

We can indicate that these values belong together by using groups. But I
can see no possibility to indicate the type of a group. If I want to
contact a person I'm working with to talk about some work stuff, I
probably won't want to call this person at home or on vacation. I think
this is a common use case! But I would have to guess from the given
values of a group what kind of address or phone number it is.

I would like to indicate the type of information. We had this feature in
vcard 3 with "TYPE=work" for ADR, LABEL, and TEL. I'm not yet sure how
to do this. But just now I had the idea, to associate the type of
information not to a property but to a group. I don't know how to do
this by now, because I see no way to associate information to a group
with the current specification. Creating a new property seems ugly,
because all current properties can be used without any group and don't
by force loose their meaning. If we created a new property to show the
type of a group, (e.g. "x-my-group.GROUPTYPE:work") this property would
be meaningless without the group. So this wouldn't suit the current
specification.

Anyhow, I would love to associate the type of data with a group. I think
it's useful, because if you have grouped information then it can only be
of one type. This type is the reason why you created the group in the
first place.

If you agree with this idea:

   - We would have to find a way to add it to the vcard specification
     without messing it up.

   - We would also have to think about if indicating the type of
     information (home/work) should force someone to use a group even if
     this group would then contain only one property.

   - Maybe "home" and "work" aren't the only types a group of
     information can have. So maybe we should think of some more
     predefined types.

   - For extensibility we should allow "x-"-types.

   - And if we already indicate the type of information, maybe we can
     also allow a descriptive text. Multiple private addresses don't
     have a ORG-property which describes the address. This could be
     helpful distinguish between summer residence and home, which are
     both private addresses.

I would like to hear other opinions on this.

Regards,

Markus

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 29 Jul 2009 14:55:52 +0200

might want to think about doing this construct in XML.

Marc.