Subject: [VCARDDAV] vCard revision - DRINK attribute

From: Sly Gryphon <[email-masked]>
Date: Wed, 10 Jun 2009 22:25:27 +1000

Additional DRINK attribute for consideration of inclusion in vCard 4.0.

Rationale: Provide a value based on the semantics of the LDAP RFC4524
drink attribute. Technology should not be composed solely of boring
bits, name, telephone, fax, address ... so I think it would add a touch
of enjoyment by using this attribute from RFC4524 (and it can even be
included in the vCard-LDAP mapping standard as well).

DRINK

Purpose: Specifies the favorite drinks of an object (or person), for
instance, "cola" and "beer".

Value type: A single text value.

Cardinality: (0,n)

Special notes: This type is based on the semantics of the [RFC4524]
'drink' attribute.

ABNF:
    param = "VALUE=text" / language-param / pid-param / pref-param
           / any-param
     value = text

Example:
  DRINK: Cola

---

From: Simon Perreault <[email-masked]>
Date: Wed, 10 Jun 2009 09:59:00 -0400

> instance, "cola" and "beer".

This reply is valid also for the AN and CAR extension proposals.

Recently I posted my personal reasons for considering an extension for inclusion
in vCard 4. They were fairly well received. Here they are:

- The extension provides functionality that was present in vCard 3 or earlier.
- It provides functionality that is necessary for extensions to build upon.
- It is needed by a majority of vCard implementations.

As far as I can see, neither DRINK, AN, nor CAR fit any of these.

They can still become "official" extensions. See
<http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-07#section-11.2>.

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

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 10 Jun 2009 11:55:55 -0300

> As far as I can see, neither DRINK, AN, nor CAR fit any of these.

+1 for not including DRINK and CAR in the core spec.

About AN, I think it is a common use case. There are already different 
X-properties for representing this information (e.g. X-ANNIVERSARY, 
X-EVOLUTION-ANNIVERSARY). Besides, some contact management software, such as 
Outlook (whose vCard implementation is rather incomplete) allows an 
anniversary date.

Regards

Javier

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 10 Jun 2009 10:06:29 -0700

Hi Javier,

--On June 10, 2009 11:55:55 AM -0300 Javier Godoy <[email-masked]> 
wrote:

> X-EVOLUTION-ANNIVERSARY). Besides, some contact management software, such
> as Outlook (whose vCard implementation is rather incomplete) allows an
> anniversary date.

I don't really want to re-invent iCalendar in vCard (really) but perhaps we 
should generalize this a little bit more. How about a "DATES" property 
which can include a TYPE parameter which initially we define a single value 
for: "ANNIVERSARY", with the definition that the data supplied is 
implicitly a yearly recurring "event".

However, a question is whether data like this really belongs in an address 
book vs a calendar. Maybe the vCard should have a pointer to an iCalendar 
object containing "personal" dates like this. Ultimately the vcard data is 
likely to be "imported" into a calendar so that alarms and other 
annotations could be added.

-- 
Cyrus Daboo

---

From: Sly Gryphon <[email-masked]>
Date: Thu, 11 Jun 2009 20:57:41 +1000

The AN and RELATED;TYPE=partner fields are connected, so it is probably 
worth combining the dicussion on them.

Simon Perreault wrote:
Recently I posted my personal reasons for considering an extension for 
inclusion
in vCard 4. They were fairly well received. Here they are:
- The extension provides functionality that was present in vCard 3 or 
earlier.
- It provides functionality that is necessary for extensions to build upon.
- It is needed by a majority of vCard implementations.
<<<<<

* On AN:

Well, I think that anniversary better meets those criteria (and is more 
important than) than date of death (DDAY), particular as an existing 
field in applications, e.g. Outlook 2007 has Birthday and Anniversary 
fields, but not date of death (I think Evolution also has anniversary 
but not death).

In fact, once date of death is set, a lot of the other fields becomes 
redundant/useless (except maybe if you are John Edwards), e.g.

FN: Bob Smith
DDAY: 20080105
ADR: Rookwood Cemetary, Six feet under
TEL;TYPE=cell: We buried a cell phone with him, but the battery has 
probably run out by now

I would suggest dropping DDAY, but including AN.

* On RELATED;TYPE=partner:

It just seems kind of strange to have child (and parent), but not 
spouse/partner. e.g. "Hi Alice, how are the kids Jack and Jill, and your 
parents Carol & David (and your brother Fred)" ... and not mention their 
partner.

In fact, I would have thought partner/spouse was _more_ important than 
children (and definitely more important than parents).

In relation to the inclusion criteria, this is a used field, for 
instance Outlook 2007 has "Spouse/Partner" in the personal section, but 
not children (and certainly not parents). It also has Manager and 
Assistant in the business section, and these are probably what I see as 
the top three (Manager, Secretary/Assistant, and Partner/Spouse), with 
Children as maybe fourth -- at least these are the fields I would use.

I think Evolution has the same three (manager, assistant, spouse), and 
Rolodap has secretary, spouse, and children.

The main problem seems to be not the importance of the field, but that a 
consensus can't be reached on the naming: it is worried that partner 
might be confused with business partner, whilst spouse might be seen as 
too restrictive, and alternatives like domesticPartner or 
partnerOrSpouse seem too long (or corny). I think it is silly to leave a 
field out simply because you can't agree on the name (whilst putting in 
less important ones).

Presuming we want the field to cover more than just marriage, then the 
label just needs to be "partner", and a clear description as "spouse or 
partner" will have to suffice (if implementers don't read the 
descriptions of the fields then there are probably bigger problems than 
confusing "partner" with "business partner", and if they confuse it with 
"tennis partner" well I don't think there is any hope).

If "partner" still isn't sufficient, a thesaurus can provide a range of 
alternatives: "companion", "mate", "consort", "betterHalf", "steady", 
"significantOther", "spouseEquivalent", "domesticPartner".

(In fact, simliar to AN/DDAY, I would even suggest dropping TYPE=parent 
and including TYPE=partner).

These fields clearly do not fall under criteria 1 or 2, but can you 
really say that DDAY and RELATED;TYPE=parent are needed by more vCard 
implementations than AN and RELATED;TYPE=partner?

Sly

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 11 Jun 2009 10:25:42 -0300

Hi Cyrus,

On Wednesday, June 10, 2009 2:06 PM Cyrus Daboo wrote:

> should generalize this a little bit more. How about a "DATES" property which 
> can include a TYPE parameter which initially we define a single value for: 
> "ANNIVERSARY",

Moving in that direction, BDAY and DDAY become special cases of DATE (in the 
same way we dropped AGENT in favor of RELATED) . I like the approach, though 
I'm also fine with BDAY + DDAY + ANNIVERSARY.

>with the definition that the data supplied is implicitly a yearly recurring 
>"event".

Not sure. Actually ANNIVERSARY is an euphemism for WEDDING-DAY (or any similar 
event other than wedding). This makes sense because complete dates (yyyymmdd) 
are allowed.
On the other hand, --mmdd dates are (by definition) in the "implied year" (ISO 
8601:2000 5.2.1.3.d), which would be the year when the event happened.

This case is similar to BDAY, which specifies the "birth date" instead of 
"birthday".

> likely to be "imported" into a calendar so that alarms and other annotations 
> could be added.

In an ideal world, yes. But it is unlikely to expect systems implementing 
iCalendar only to record the anniversary date and some other information.
Of course, if you need iCalendar-specific features (such as additional 
information about the "event", or tracking mutable dates) you should be usign 
iCalendar, but as long as the information is (almost) inmutable, I think it 
can find its place within vCard as DATE types or date-valued properties

Regards

Javier

---

From: Sly Gryphon <[email-masked]>
Date: Fri, 12 Jun 2009 23:00:51 +1000

I had a think of different contact applications and had a look at what 
fields they use around relationships and dates. (list below)

The summary:

- Anniversary is very common (as common as Birthday in fact).
- I couldn't find anything that stored date of death (except custom fields).

- Spouse/Partner is quite common, about as common as Manager and - 
Assistant, with the term "Spouse" slightly more frequent (also the Mac 
addressbook had them as separate fields). I would accept "spouse" as the 
field name (people will probably use it for spouse-like relations 
anyway), but think "partner" is slightly better.
- Chidren occurs occasionally, with parent slightly less often.
- Sibling is reasonably rare.
- Agent and emergency non-existent.

If you have more to add to the list below, feel free, but it is 
certainly looking like both "Partner" and "Anniversary" meet the 
criteria of being relevant for a majority (> 50%) of relevant applications.

I would actually propose removing DDAY (and DEATH) from the RFC, unless 
there is actually a need for them I can't think of (maybe genealogy is 
popular?)  

In most cases DDAY is not a very useful field for a contact: once dead, 
they aren't very useful as a contact, and someone isn't ever going to 
actually send you a new vCard (for themselves) with the value updated.

Agent is not very useful for personal contacts, but I can see a benefit 
for company contacts (as the name of a person). Emergency was argued for 
recently, but doesn't really have any existing implementations.

Sly Gryphon

List of applications I could think of: (please don't reply and resend 
this to the list)

* Microsoft Outlook 2007 :-
Manager, Assistant, Spouse/Partner; advanced fields include Children
Birthday, Anniversary

* Windows Address Book (Vista) / Outlook Express:-
Spouse/Partner, Children
Birthday, Anniversary

* Mozilla Thunderbird :-
None relevant

* LDAP (inetOrgPerson) :-
manager, secretary

* Evolution :-
Anniversary, Birthday
Manager, Assistant, Spouse

* Rolodap :-
Spouse, Children, Secretary

* Portable Contacts :-
Birthday, Anniversary
Children
Relationship values from XFN: child, parent, sibling, spouse, kin

* Windows Live Contacts API
Birthdate, Anniversary
SpouseName, Manager, Assistant

* Yahoo Contacts API
Birthday, Anniversary

* Open Contacts
Anniversary, Birthday,
Manager, Assistant, Child, Parent, Spouse
(can add arbitrary named fields)

* Mac Addressbook
Parent, Child, Partner, Spouse (separate fields)
Manager, Assistant, Friend

* iPhone
Birthday, Anniversary

---

From: Simon Perreault <[email-masked]>
Date: Fri, 12 Jun 2009 09:15:00 -0400

> fields they use around relationships and dates. (list below)

Thanks a lot for this survey. It is very useful.

The proposal is to add the following:

- A "spouse" value for the RELATED property.
- A WEDDING property. (I find anniversary to be ambiguous.)

Unless a compelling argument is made, they will be added to the next
version of the draft.

Simon

---

From: "Javier Godoy" <[email-masked]>
Date: Fri, 12 Jun 2009 12:00:55 -0300

> Unless a compelling argument is made, they will be added to the next

+1, though it should be cautioned that semantics is actually broader than 
which is implied by the natural-language property names.

Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Fri, 12 Jun 2009 11:03:03 -0400

Javier Godoy wrote, on 2009-06-12 11:00:
> +1, though it should be cautioned that semantics is actually broader
> than which is implied by the natural-language property names.

Semantics for wedding or spouse? Could you provide sample text?

Thanks,
Simon

---

From: Andy Mabbett <[email-masked]>
Date: Fri, 12 Jun 2009 16:47:17 +0100

In message <[email-masked]>, Sly Gryphon 
<[email-masked]> writes

>actually send you a new vCard (for themselves) with the value updated.

The rationale and use-cases were posted to this list some time ago, and 
resulted in consensus for the wording in the current draft.

I shall be happy to dig out a reference for you, if you will confirm 
that you have tried and failed to do so.

Simply asserting that "they aren't very useful", without having reviewed 
rationale and use-cases is, in my view, not very helpful. Doing so under 
an unrelated subject heading, doubly so.

-- 
Andy Mabbett

---

From: "Javier Godoy" <[email-masked]>
Date: Fri, 12 Jun 2009 13:14:53 -0300

> Semantics for wedding or spouse? Could you provide sample text?

Both. I think you suggested "wedding" in order to avoid "anniversary" been
understood as other kind of anniversary, and "spouse" in order to exclude the
meaning of business/tennis partners. I'm fine with these names, because
"spouse" do not conveys additional meanings, and "wedding" is obviously
associated with spouses.

However, it is clear from previous discussion that marriage as "a legal union
between one man and one woman as husband and wife" is too restrictive. It
follows that "spouse" and "wedding" may be understood as implying this
definition. Informally, all we need is the "spouse" RELATED type in order to
know that one individual is marriage-like related to other (and wedding in
order to record when this relationship began). The actual kind of relation is
out of the scope of vCard unless we want to specify several variations (and it
is clear we don't).

The term wedding is normally associated with an act or ceremony taking place.
This is not always the case, as for if they are in consensual union (de facto
marriage) there have been no ceremony, even though they may be regarded as
spouses. Then I think the more consistent solution is to define wedding in
terms of spouse.

<![PROPOSAL[[

WEDDING -  Purpose:  To specify the date from when another individual is
considered "spouse" of the individual this vCard represents (as defined in
section 7.6.6) even if the other individual is not specified in the vCard.

]]>

About "spouse" I found hard to define it by my own, without implying the
strict meaning.
I found two definitions which may be similar to what we are talking about, but
both websites claim copyright.

<![PROPOSAL[[

"spouse" means that the related individual is married to the individual this
vCard represents, or they

    consider their relationship to be akin to marriage. [1]

--or--

   have pledged themselves to each other in the manner of a husband and wife,
even without legal sanction. [2]

]]>

Regards

Javier

[1]
http://www2.stats.govt.nz/domino/external/omni/omni.nsf/23f076d733ded7e74c256570001d92b4/212fd6abedd8f01dcc2570df000db5a9?OpenDocument

[2] http://dictionary.reference.com/browse/marriage

---

From: Andy Mabbett <[email-masked]>
Date: Fri, 12 Jun 2009 18:28:30 +0100

In message <E2B4E6A81F8B42CAA5EE4C2C9292F708@Javier2>, Javier Godoy
<[email-masked]> writes

>[1]
>http://www2.stats.govt.nz/domino/external/omni/omni.nsf/23f076d733ded7e
>74c256570001d92b4/212fd6abedd8f01dcc2570df000db5a9?OpenDocument
>

It is doubtful whether either can claim copyright on such simple
definitions; but to avoid doubt we could use:

        "spouse" means that the related individual is married to the
        individual this vCard represents, or that they consider
        themselves to have an equivalent relationship.

I would avoid the words "husband and wife", since same-sex couples may
self-define as being made up of two of either one of those.

-- 
Andy Mabbett

---

From: "Javier Godoy" <[email-masked]>
Date: Fri, 12 Jun 2009 15:52:20 -0300

>        themselves to have an equivalent relationship.

+1

> self-define as being made up of two of either one of those.

Agree. 

Regards

Javier

---

From: Sly Gryphon <[email-masked]>
Date: Sat, 13 Jun 2009 16:14:26 +1000

> - A WEDDING property. (I find anniversary to be ambiguous.)
+1 happy to agree with "spouse" -- it is what the majority of products
use, which is really I suppose what vCard is intended to support.

However for the date value, looking at what the products name their
fields, I actually think wedding would be the *more *confusing choice.
_Every_ relevant app listed uses the term anniversary (_none_ use
wedding), so it would be easier for them to map directly to anniversary
(or even "AN" if you want a short field name).

If vCard uses wedding then application developers will need to
guess/work out if their "anniversary" field is the same as the vCard
wedding property or not.

Possible wording (this is similar to what I previously posted):

ANNIVERSARY
  Purpose:  The date of marriage, or equivalent, of the contact
represented by the directory entry. [Rest of definition similar to BDAY]

RELATED
[add to list]
* "spouse" means that the related individual is recognised as the
spouse, domestic partner, or similar relation of the individual.

- Sly

---

From: Simon Perreault <[email-masked]>
Date: Sat, 13 Jun 2009 09:18:38 -0400

> (or even "AN" if you want a short field name).

Tell me, how is anniversary less confusing? From the Wikipedia page, an 
anniversary commemorates any kind of event, including birth, wedding, 
and death.

Is it common knowledge that anniversary == wedding? If I was using such 
an app I would be very confused, but maybe that's because my mother 
tongue is not English.

It doesn't matter what apps display to the user. The goal in this case 
is for vCard to be unambiguous.

Simon

---

From: Sly Gryphon <[email-masked]>
Date: Tue, 16 Jun 2009 22:32:28 +1000

Simon Perreault wrote:
> Tell me, how is anniversary less confusing? 
Less confusing for the developers writing software that uses vCard when
mapping from their existing fields to vCard, because there is already a
field called "anniversary" in all of the applications I could think of
(and none of them had a field called "wedding").

The actual definition provides the meaning, e.g. "FN" is not very
meaningful by itself, but the definition (as the person's name) is
fairly clear.

When a user enters a value in the Anniversary field in the Windows
Address Book, it doesn't actually matter what the date is, but they
would expect it to appear in the Anniversary field when important into
Evolution.

 From this point of view, the field might as well be called "X107", so
long as one application exports from anniversary to X107 and the other
imports from X107 to anniversary. (The actual definition of X107 is in
the RFC, so that both applications know it means their anniverary field).

My argument is that the easiest thing to call "the property that
anniversary is exported to and imported from" is "anniversary". The
property name is as a mnenonic aid that hints what the field is, like FN
provides a hint that it contains the "F"ull "N"ame.

For any field, there are many possible names that will provide the
needed hint; different terms may be more accurate depending on the
circumstances (or person), but I think ANNIVERSARY (or even just AN)
provides the *better hint* because _all_ applications I could think of
already call the field "anniversary" (in the English version).

Hopefully that better explains what I am trying to say, so I would like
to summarise and compare the proposed options:

I am glad at least that we are looking to include the field (so that
applications have something common to import/export -- which is the
important part), and think we have two main candidate names for the
field (presuming the actual definition of the field will be the same in
either case):

WEDDING - Argument is the name is a better mnemonic aid because the
meaning of "wedding" better reflects the definition of the property.
ANNIVERSARY - Argument is the name better matches what applications
already call the property, making mapping easier.

What is other people's preference between the two, or does anyone have
anything to add?

Sly

---

From: "Tantek Celik" <[email-masked]>
Date: Tue, 16 Jun 2009 16:34:33 +0000

+1 ANNIVERSARY. Reuse common term from existing tools rather than using/inventing new term.
 
-----Original Message-----
From: Sly Gryphon <[email-masked]>

Date: Tue, 16 Jun 2009 22:32:28 
To: <[email-masked]>
Subject: Re: [VCARDDAV] vCard revision - AN and RELATED;TYPE=partner

Sly

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

---

From: Simon Perreault <[email-masked]>
Date: Tue, 16 Jun 2009 13:55:01 -0400

> +1 ANNIVERSARY. Reuse common term from existing tools rather than using/inventing new term.

I haven't seen my concern about anniversary being ambiguous addressed.

Without context, anniversary can mean just about anything. At least in
Evolution, the anniversary is right next to the spouse name making it evident
that we are talking about *wedding* anniversary.

There is no such context in vCard.

The title of this property has to be clear enough that the hordes of people who
don't read RFCs have a good chance of getting it right the first time. Naming is
anniversary is asking for trouble. Wedding is unambiguous.

That's only my opinion. So far I haven't heard much from other people who care.

Simon

---

From: Sly Gryphon <[email-masked]>
Date: Wed, 17 Jun 2009 07:50:33 +1000

> I haven't seen my concern about anniversary being ambiguous addressed.
Another attempt to address this.

1. Meaning of the term.

In English (at least Australian English), the term "anniversary" by
itself would generally be interpreted as meaning wedding anniversary,
e.g. "On anniversary is on 31 October", means wedding anniversary.

For example, as used on cards -- see the Hallmark website (a large card
manufacturer):

http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/Occasions/OCC_ANNIVERSARY

Their category is called "Anniversary", and cards generally say
something like "Happy Anniversary" (these are references to wedding
anniversary).

2. Ambiguity when mapping to existing applications.

When Evolution, Outlook, Portable Contacts, Yahoo Contacts, etc are
developing export or import for vCards then need to map their fields to
vCard.

* To map their name field, they need to read the vCard spec to work out
"FN" is the name. Slightly ambiguous.
* To map birthday, they need to read the vCard spec to work out the
difference between "BDAY" and "BIRTH". Slightly ambiguous.
* To map anniversary, a property "ANNIVERSARY" would be an obvious
choice (compared to "WEDDING" being slightly ambiguous, similar to FN).

---

From: Simon Perreault <[email-masked]>
Date: Wed, 17 Jun 2009 08:21:41 -0400

> http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/Occasions/OCC_ANNIVERSARY

Thanks. I didn't know that it was that way in English.

Unless people object, we'll go with ANNIVERSARY.

Simon