vCard 4.0 Issues

(from http://microformats.org/wiki/vcard-suggestions)

    *  The "type" for "TEL" lacks a "textphone" option (for the devices used
by, e.g., people who are deaf or have speech difficulties. Example: Birmingham
City Council (303 1119) (http://www.birmingham.gov.uk/contact). It may be good
to consider adding a "textphone" value to the "type" for "TEL".
          o +0 Tantek: I think a rethinking of the taxonomy of TEL types is
merited, but I am uncertain whether it is worth growing the existing limited
taxonomy or instead permitting user defined TEL types and thus allowing for
natural evolution of a folksonomy of TEL types.
          o +1 Andy Mabbett: There are a limited number of types. Note also the
cell vs. mobile issue. 
    * The "type" for "TEL" lacks a "freephone" option. It may be good to
consider adding a "freephone" value to the "type" for "TEL". Usually freephone
numbers are not accessible from outside the country so it could help parsers
with something?
    * The "type" for "TEL" lacks an "SMS short code" option. (Raised in e-mail,
2008-01-08 by Michael Smethurst
(http://microformats.org/discuss/mail/microformats-discuss/2008-January/011292.html))
          o Seems like 'sms' TEL TYPE is a viable implementation option
--Guillaume 12:17, 8 Jan 2008 (PST). 
    * FYI. Some existing Personal Information Manager software practices:
          o Mac OS X address book allows custom labels for TEL but not custom
TEL TYPE per se, although for the user a custom TEL label just looks like a TEL
TYPE
          o Microsoft Outlook does not allow custom TEL TYPE values. Also,
Microsoft Outlook has a "Company" telephone type, but unfortunately it isn't
mapped to anything in vCard i.e. if you export a contact with a company tel, it
is lost.
          o Windows Mobile 6 displays SMS as a service that is only available
if the telephone type is 'mobile'.
          o Thunderbird 2 (Mac) does not allow custom TEL TYPE values. 

Note: it might be a good idea to look at the proposed registry for "tel:" URI
parameters (http://tools.ietf.org/html/draft-ietf-iptel-tel-reg-04); especially
the "phone-context" URI parameter (http://tools.ietf.org/html/rfc3966), since
it tries to solve a similar problem. (per e-mail, 2008-01-08
(http://microformats.org/discuss/mail/microformats-discuss/2008-January/011295.html)).

(from IETF Chicago presentation by Cyrus Daboo)

There are too many combinations of parameters for TEL.

We've been discussing two alternatives:

- Use E.123 syntax.
- Use a tel URI as defined in RFC 3966.

See mailing list archives for details.

The TEL value is now a URI. See RFC 3966.

Actually the OMA folks have brought up this issue before. In particular 
they wanted to limit the possible combinations of TYPE values to a strict 
subset. e.g.:

tel-param    = "TYPE" "=" tel-type *2["," tel-type]
            ; a type-tel, type-location or type-pref MUST only appear
            ; once.

tel-type      =  type-tel / type-location / type-pref

type-tel      = "VOICE" / "FAX" / "VIDEO" / "CELL" / iana-token / x-token

type-location = "HOME" / "WORK" / "MOBILE" / "OTHER" / iana-token / x-token

type-pref     = "PREF" / iana-token / x-token

Note I split out type-location and type-pref because those should also be 
used for ADR, IM and EMAIL types.

There has been some discussion (still unresolved) about whether we should
impose additional constraints on the tel: URI or not. Some think that only
absolute numbers (e.g. tel:+14185555555) should be allowed.

Current proposal:

1. Drop PREF. (Mark Paterson)
2. Reuse group syntax instead of WORK/HOME. (Peter K. Sheerin)
3. Restrict TYPE to this set:
   "VOICE" / "VIDEO" / "TEXT" / "FAX" / "CELL" / "PAGER" / iana-token / x-token

*** Bug 235 has been marked as a duplicate of this bug. ***

(from http://microformats.org/wiki/vcard-suggestions)

"N" (See RFC2426 section 3.1.2) sub-property; for people, whose given-name is
not stated (e.g. "A. N. Other", whose given name might be, say, "Adrian" or
"Nigel"); to allow values like:

   initials:    A. N.
   family-name: Other

instead of the more contrived:

   given-name:  A. N.
   family-name: Other

Also, for people whose given-name and initials are given:

   given-name:      Theophilus
   middle-initials: P.
   family-name:     Wildebeest

and:

   initials:       J.
   given-name:     Paul
   family-name:    Getty

It looks like all these cases could be expressed with the current spec.

>    initials:    A. N.
>    family-name: Other
> 
> instead of the more contrived:
> 
>    given-name:  A. N.
>    family-name: Other

N:Other;A.;N.;;

> Also, for people whose given-name and initials are given:
> 
>    given-name:      Theophilus
>    middle-initials: P.
>    family-name:     Wildebeest

N:Wildebeest;Theophilus;P.;;

> and:
> 
>    initials:       J.
>    given-name:     Paul
>    family-name:    Getty

N:Getty;Paul;J.;;


Therefore, the current proposal is to close this issue without action.

(from http://microformats.org/wiki/vcard-suggestions)

Body

"ADR" (See RFC2426 section 3.2.1) sub-property; for people (e.g. in proposed
moon base, Mars expedition) or places (e.g. lunar crater, Martian mountain)
off-planet.

    * See also geo-extension-nonWGS84 

Continent

"ADR" (See RFC2426 section 3.2.1) sub-property; self-explanatory.

Vessel

"ADR" (See RFC2426 section 3.2.1) sub-property; for people on, say, ships,
live-aboard boats, oil rigs, and even space vehicles (e.g. the ISS)

Elevation

"GEO" (See RFC2426 section 3.4.2) sub-property; aka "altitude" or "depth".

    * See geo-extension-elevation 

Schema

"GEO" (See RFC2426 section 3.4.2) sub-property; for coordinates using non-WGS84
schema (terrestrial and for other bodies)

    * See also geo-extension-nonWGS84

(from IETF Chicago presentation by Cyrus Daboo)

Geographic properties should be parameters on ADR and we should add a MAP
parameter.

[VCARDDAV] proper datum/reference system for GEO property
 From: Alexander Mayrhofer
 To: vcarddav@ietf.org

Hi,

I've been looking at the definition of the "GEO" property in
draft-resnick-vcarddav-vcardrev-01. The current specification does not
clarify which datum and reference system is to be used for data in the
GEO property, which is really bad, and can lead to errors up to several
hundred meters (depending on which reference system is used).

I'd suggest clarifying that by adding something like "Coordinates used
in the GEO property MUST use the WGS 84 datum and reference system".
(WGS84 is the most common one, and also used in GPS devices).

cheers

Alex

The reference to WGS 84 is now explicit. Other enhancements would probably best
be served by extensions to the core vCard format.

Current proposal: close without action.

(from http://microformats.org/wiki/vcard-suggestions)

For historic figures, where no birth and/ or death dates are known a
"flourished" date, or "flourished from"+"flourished to" pair, would be useful.

In genealogy, some people have no recorded birth date, but their "baptised"
date is known.

In my opinion this is overkill. vCard is not designed for genealogy.

Current proposal: close it with no action.

Global Location Number (GLN) - generally used in electronic commerce
transactions [1] (http://en.wikipedia.org/wiki/Global_Location_Number). Andy
Mabbett 06:43, 31 Aug 2007 (PDT)

(from http://microformats.org/wiki/vcard-suggestions)

Personnally I think this is too domain-specific to be included in vCard.

Current proposal: close it with no action.

(from http://microformats.org/wiki/vcard-suggestions)

Telephone, cellphone, fax, post , e-mail, IM, SMS, IRC, Twitter, etc.

(In reply to comment #0)
> Telephone, cellphone, fax, post , e-mail, IM, SMS, IRC, Twitter, etc.

In that list, there is no way in vCard to specify contact info for IM, SMS,
IRC, and Twitter. So what do we do? Create a new property with free-form text
value? Would that even be useful?

Another issue: It is already possible to distinguish between telephone,
cellphone and fax with the "pref" TEL parameter. So these three are actually
redundant.

So would it be good to create a new property whose value is one of tel, post,
and email? Would that even be useful? I think not given that you will use of of
those three depending on your particular communication needs, not on the
recipient's preference. At least, in the general context of vCard. Maybe not in
the domain-specific context of marketing or I don't know what else.

Any proposal for this issue will need to take into account the resolution of
issue #152.

(from IETF Chicago presentation by Cyrus Daboo)

Provide UID on each multi-occurring property to aid synchronization.

Let's expand on this problem a bit.

Now synchronization is done at the vCard level. Each vCard has its own UID, so
even if you change every single property, as long as you keep the same UID you
will be able to propagate changes.

But try as I might, I can't conceive a use case for per-property UIDs. Care to
provide one?

(from Javier Godoy)

I like the idea. I think an UID parameter would be fine. It would be 
OPTIONAL for each repeatable property.

The value of such
parameter MUST be a globally unique identifier (this allows distributed
edition of a vCard identifying someone else). I'm not sure if we have to be
too lax about this identifiers...

What identifier should be used? I can think about three alternatives:
 - a UUID literal.
 - a UUID URN
 - any URI

(from Cyrus Daboo)

I guess my big concern with this is that the UUID values will more often 
than not end up be more characters than the actual properties being 
"tagged". For limited bandwidth situations that is not ideal.

In reality a full-blown UUID is not needed. All that is needed is a token 
unique within the context of the enclosing vCard.

Another option is to also look into the property name prefix syntax allowed 
in vCard as a means of tagging items, e.g.:

TAG1.ADR:...
TAG2.ADR:...
TAG1.TEL:...
TAG2.TEL:...

(from Mark Paterson)

I prefer the idea of using UID. Using the example from the draft....

BEGIN:VCARD
VERSION:4.0
UID:<This is a globally unique ID>
FN:Simon Perreault
N:Perreault;Simon;;;ing. jr.,M.Sc.
BDAY:1983-02-03
GENDER:M
ORG:Viagenie
ADR;UID=1;TYPE=work:;;2600 boul. Laurier\, suite 625;
       Quebec;QC;G1V 4W1;Canada
TEL;UID=1;TYPE=voice,work:+1-418-656-9254
TEL;UID=2;TYPE=fax,work:+1-418-656-9257
EMAIL;UID=1;TYPE=internet,work:simon.perreault@viagenie.ca
GEO:46.772673,-71.282945
CLASS:PUBLIC
KEY;VALUE=uri:http://www.viagenie.ca/simon.perreault/simon.asc
END:VCARD

(from Cyrus Daboo)

I would actually prefer to use another name for the parameter, how about 
"PID" (property ID) - just to avoid any confusion with the UID property.

So if we use this scheme is there any need to track the old PIDs. e.g., in 
the example above, lets say one client deletes the TEL property with 
UID/PID=2. Then another client comes along and creates a new TEL property. 
Should the new one have PID=2 or PID=3? i.e. does it matter that PID=2 gets 
re-used for a "different" property? If there is a need to track old PIDs 
for deleted properties, then that would complicate things a lot.

(from Javier Godoy)

I think it matters. Otherwise, what are PID for? I have understood they were 
for distinguishing whether a property was modified, or it was deleted and a 
new (unrelated) property was inserted at a later time (I'm not sure if my 
reasoning is correct?).

In any case, there is no need for tracking all removed PIDs. If PIDs are 
increasing integers, then knowledge of the "last used PID" would be enough. 
If no "last used PID" is given, it would be assumed to be the greater PID 
present in the vCard.

Had PIDs been globally unique they would have been only reused on purpose, 
and this problem would have been avoided (at the expense of several bytes, 
as Cyrus said).

Per-property UIDs have been added in r66. The synchronization mechanisms have
been described in a new Synchronization section.

This bug is closed until someone says that what was written doesn't work.

It has been shown that it doesn't work at all. The values are much too large to
be useful.

By UID I really meant UUID. And by "too large to be useful", I mean that the
UUID string, including the "urn:uuid:" prefix, consumes too many bytes compared
to the property data. The OMA folks who have been pushing for PIDs need them to
be small because their devices have low resources and bandwidth.

Current proposal:

1. Rename UID parameter to PID.
2. Change PID value type to "a small integer."
3. Adapt examples so that they match the above.

(from IETF Chicago presentation by Cyrus Daboo)

XML-based variant of vCard syntax, e.g.:

http://www.xmpp.org/extensions/xep-0054.html

They are used in similar ways, i.e. a given implementation will write

FN:Simon Perreault
NAME:Simon Perreault

in a produced vCard file. I've seen this with KAddressBook.

What we should do is give to NAME the actual description of FN and make FN an
alias for NAME.

It looks like there is absolutely no need to touch this.

Proposal: close it with no action.

The language of a text value is known by inspecting these places, in order:

1. The "language" property parameter.
2. The Content-Language MIME header.
3. Default: undefined

The character set of a text value is know by inspecting these places, in order:

1. The "charset" MIME Content-Type parameter.
2. Default: UTF-8

The problem is that if you save the vCard data to a file, then you lose the
MIME headers. We should add LANGUAGE and CHARSET properties that specify the
language and character set for the whole file. I also propose that the default
language be 'en', English.

CHARSET was present in -00. As for LANGUAGE,

1) It conflicts with the already-present LANG.
2) Many (most?) properties are language-agnostic. Therefore specifying language
on a per-property basis is good enough.

CHARSET is a broken idea. Pete will draft rationale paragraph to be put in the
text.

As raised a few times, one of which is during the calconnect conf call about a
use case scenario in the OMA world, the vcard format may be used as an
interchange format between two proprietary/other formats. Therefore, vcard
should have a capability to include extra stuff in an opaque way and not loose
it.

A few thoughts on this:

A vendor may define an X- property and put anything he wants there. But you
cannot really put anything in a vCard value. For example, control characters
are explicitly forbidden in a property value. The bulletproof way is to
base64-encode it and put the resulting string there, as is done for the IMAGE
and SOUND properties.

Current proposal:

Close it with no action.

This should be done later, when other changes have settled.

As suggested by Mark Paterson on vcarddav@ietf.org.

(from Mark Paterson)

CalConnect published recommendations on a time zone registry which is 
what we'd need here but nothing has really happened as far as I know.

http://www.calconnect.org/publications/timezoneregistryandservicerecommendationsv1.0.pdf

might be just a time to suggest an IANA registry for timezones that would be
available for all. In this case, it could be another RFC for establishing the
registry. I'll write a first version of it, unless a published standard for
timezones already exists and is referencable and easily available.

(from Cyrus Daboo)

CalConnect has a technical committee currently working on formalizing the 
timezone registry and service protocols. The current thinking is that we 
would define a registry of timezone source names, e.g 'Olson', 'EU', 'NATO' 
etc. Those names would be the top-level namespace of iCalendar's TZID 
property, and the actual timezone name would follow: 
'/Olson/America/New_York'. That fits with definition of TZIDs in iCalendar.

My personal feeling is that TZ isn't needed in vCard. But if it is kept in, 
I think stating that it can be any valid iCalendar TZID value would be all 
we need to do.

might want to look at: draft-lear-dhc-timezone-option-xx.txt
why would POSIX TZ not be a good candidate?

draft-lear is now RFC4833

Did we decide on whether UID should be mandatory in a vCard? If so, we 
need to include that in the vcard definition comment in Section 6.

The UID property has been made mandatory when synchronization is to be used in
r66.

Reopening because it needs more discussion.

From: Peter K. Sheerin  [vCard]
 To: vcarddav@ietf.org

In the past, I've tried to enter birthdays for friends in my contact 
databases, and have often found it as difficult to enter a date for the 
birthday field without the year as it is to get that year from women 
over 30 <g,d,&r>.

So, although ISO 8601:2000 has now been superseded by ISO 8601:2004 and 
deletes the ability to truncate the left side of a date, I propose that 
this specific feature from the older standard be specifically allowed as 
a means of indicating a recurring birthday when no year is known.

According to the older spec, this would allow the following 
representation of my birthday while not revealing how old I am:

--06-16

For reference, please see:

ISO 8601:2000
    http://lists.ebxml.org/archives/ebxml-core/200104/pdf00005.pdf
ISO 8601:2004

http://isotc.iso.org/livelink/livelink/4021199/ISO_8601_2004_E.zip?func=doc.Fetch&nodeid=4021199

From Chris Newmann:

There is also a security consideration here as the birth year-month-day of 
a person is one of the key pieces of information necessary for identity 
theft.  Given how poorly most systems treat the security of 
vCard/address-book storage, I'd prefer to store the birth year offline and 
consider UIs that mandate a birth year to be broken.  The year is 
superfluous for the most common use of the BDAY field (birthday reminder).

The current proposal is to specify ISO 8601:2000.

[VCARDDAV] Do we need type for EMAIL or IMPP?
 From: Mark Paterson
 To: vcarddav@ietf.org

We recently discussed the use of TYPE for telephone numbers. As part of 
that discussion we've proposed dropping pref and making use of labels to 
indicate something is a home number or a work number. If we apply this 
same idea to EMAIL and IM we are left with the only values for email; 
being "internet", "x.400" or "uri" and the only values for IMPP being 
"mobile". It's not clear we really need these at all. Perhaps we should 
drop the special notes in theses section (see below) and rework the 
examples not to use type.

Re: [VCARDDAV] PIDs proposal
 From: Javier Godoy
 To: "Darryl Champagne" <dgc@funambol.com>, vcarddav@ietf.org

On Tue, 24 Jun 2008 09:35:35 -0400 Darryl Champagne wrote:

> If you would look at the text I wrote (has anyone?) - I specifically said
> that:  "It MUST NOT appear on properties that only may have one instance
> per vCard.".

I did, but the only property which cannot be repeated are UID (a fix in this
revision, as this was not explicit in vCard 3.0), and obviously BEGIN and
END. There are other properties about which we can reasonably assume they
can only occur once (such as N, FN, BDAY...) but it should be stated
somewhere.

Proposal: define the cardinality of each property (it may be done by
including a separate slot on each definition). Just a few properties are 
(1,1), most of them are either (0,1) or (0,n); and
I think there are no (1,n) cases.


Best Regards

Javier

[VCARDDAV] Issue #306 (Define the cardinality of each property)
 From: Javier Godoy
 To: vcarddav@ietf.org

> Proposal: define the cardinality of each property (it may be done by
> including a separate slot on each definition).

Note: The cardinality should also be required when registering a new 
property per 12.1.3. Registration Template for Properties.


Best Regards

Javier

PID ABNF (was: I-D Action:draft-ietf-vcarddav-vcardrev-02.txt)
 From: Javier Godoy
 To: "Simon Perreault" <simon.perreault@viagenie.ca>, vcarddav@ietf.org

Simon Perreault wrote:

>> 8)
>> Section 9: ABNF
>>
>> The ABNF does not include PID as a common parameter.
>
> I created
>
>   pid-param    = ("PID" "=" 1*DIGIT)
>
> and added pid-param to NICKNAME, PHOTO, ADR, LABEL, TEL, EMAIL, TITLE, 
> ROLE,
> LOGO, AGENT, ORG, MEMBER, RELATED, CATEGORIES, NOTE, SOUND, URL, and KEY.

If PID "MUST NOT appear on properties that only may have one instance per 
vCard" it follows that it MAY be specified for the other properties. Then, 
the following should also allow PID, because there may be more than one 
instance of each property type: SOURCE, IMPP, FBURL, CALADURI, CALURI and 
X-*.


Best Regards

Javier

Re: [VCARDDAV] I-D Action:draft-ietf-vcarddav-vcardrev-02.txt
 From: Javier Godoy
 To: "Simon Perreault" <simon.perreault@viagenie.ca>, vcarddav@ietf.org

Simon Perreault wrote:

> Here's the log of changes:

>   Added the RELATED (Section 7.6.7) property.

I would suggest replacing the AGENT property by a type of RELATED, since 
"agent" is a particular kind of relation, which may be described by the 
RELATED property.

The only difference with this approach (RELATED;type=agent) is that it will 
not be possible to "reset the value to single text". Do we really need this 
feature? (currently, RELATED only allows URI). If text values are required 
for AGENT, I think it will also be required for RELATED.


> Allow for dates such as 2008 and 2008-05 and times such as 07 and 07:54.

Which is the status of issue #236 (Suggestion for allowance of truncated 
date format in BDAY) ?


Best Regards

Javier

URL in 7.7.8 (vcardrev)
 From: Javier Godoy
 To: "Simon Perreault" <simon.perreault@viagenie.ca>

Simon, I have just noticed that the example in the definition of the URL 
property reads

URL:http://www.swbyps.restaurant.french/~chezchic.html

Per issue #220 it should use an example.org or example.com domain, e.g.:

URL:http://example.org/restaurant.french/~chezchic.html


Best Regards

Javier

BTW, I think there should be an initialization table for the IANA mantained
registry of values (Section 12.1 defines registration templates for properties,
parameters, data types and values, but Section 12.2 only gives initialization
tables for properties, parameters and data types).


Best Regards

Javier

Cyrus Daboo:

We should probably make a better stipulation in the spec as to what is expected
with each type of CLASS (e.g. clients MUST NOT "export" PRIVATE vCards). CLASS
in iCalendar is very poorly specified in terms of what should really happen. It
would be good to be more specific about the different CLASS values in vCard 4.0
if we can.

Javier Godoy:

IMHO, the meaning of the CLASS values is:

PRIVATE == MUST NOT be shared (they are only readable by its creator). MAY be
exported if explictly authorized and requested by the creator.
CONFIDENTIAL == may be shared with allowed users/systems (e.g. CardDAV + RFC
3744). The exact confidentiality level is out of scope for the vCard
specification.
PUBLIC == may be shared with anyone (*).

I think this definitions (or similar definitions with the same intent) are
general enough. Emphasis should be added in that further restrictions may be
imposed by the system where the vCards are stored.

(*) There is an scenario which I'm not sure if it is CONFIDENTIAL or PUBLIC: a
vCard instance may be only readable by authenticated users, (excluding "guest"
users). This scenario specifies a broad audience for the vCard instance,
despite of denying read privileges to some agents (e.g: mail harvesters which
would be unauthenticated). 

testing

(from http://microformats.org/wiki/vcard-suggestions)

    *  The "type" for "EMAIL" lacks distinction for various types of email,
e.g. work or home.
    * The "type" for "EMAIL" lacks distinction for give an alternative to the
e-mail like a contact form.

(In reply to comment #0)
>     *  The "type" for "EMAIL" lacks distinction for various types of email,
> e.g. work or home.

Added in r4.

(In reply to comment #0)
>     * The "type" for "EMAIL" lacks distinction for give an alternative to the
> e-mail like a contact form.

Added in r5. This is the current definition:

              The type can include the type
              parameter "TYPE" to specify the format or preference of the
              electronic mail address. The TYPE parameter values can include:
              "internet" to indicate an Internet addressing type, "x400" to
              indicate a X.400 addressing type, "uri" to indicate a URI useable
              for electronic communication, "home" to indicate an address
              associated with a residence, "work" to indicate an address
              associated with a place of work, or "pref" to indicate a
              preferred-use email address when more than one is specified.
              Another IANA registered address type can also be specified. The
              default email type is "internet". A non-standard value can also
be
              specified.

        Type example:

        EMAIL;TYPE=internet:jqpublic@xyz.dom1.com

        EMAIL;TYPE=internet,pref:jane_doe@abc.com

        EMAIL;TYPE=uri,work:http://example.com/contact.php

aka "date of death"

    * See hcard-date-of-death

Cyrus Daboo mentioned this new property at IETF Chicago. He also suggested
place of birth/death.

Fixed in r17. I added the DDAY, BIRTH, and DEATH properties.

(from http://microformats.org/wiki/vcard-suggestions)

    * There is no vCard property for gender.
          o A workaround in hCard: add the tag/category "male", "female", etc.
See also earlier discussion and genealogy-brainstorming#Gender.
                + -1 Tantek: I think tags/categories are good enough for now.
                + +1 Andy Mabbett:Tags are often not appropriate, as per the
cited discussion. 

See gender-examples and genealogy-brainstorming.

Cyrus Daboo mentioned this new property at IETF Chicago.

Added the following in r6:

5.1.6.  GENDER Type Definition

   To:  ietf-mime-directory@imc.org

   Subject:  Registration of text/directory MIME type GENDER

   Type name:  GENDER

   Type purpose:  To specify the gender of the object the vCard
      represents.

   Type encoding:  8bit

   Type value:  A single text value.

   Type special notes:  The value "M" stands for male while "F" stands
      for female.

   Type examples:

             GENDER:F

(from http://microformats.org/wiki/vcard-suggestions)

    *  ISO codes ?
    * Also ability to indicate preferred contact language(s) 

    Per FajRo

Fixed in r18. The following was added:

5.4.4.  LANG

   Purpose:  To specify the language(s) that may be used for contacting
      the individual associated with the vCard.

   Value type:  A list of text values.

   Special notes:  The list is to be interpreted as defined in
      [RFC2616], Section 14.4, i.e. as the value of an Accept-Language
      HTTP header.  This lets one specify preference among languages.
      Note that any SEMI-COLON character (ASCII decimal 59) must be
      escaped.

   Example:

       LANG:fr,en\;q=0.9

(from http://microformats.org/wiki/vcard-suggestions)

The use of "fn" and "fn org" differentiate between hCards for people and for
other entities, but we perhaps need some further differentiator, between, say,
organisations and venues (including buildings, governmental divisions,
waypoints, etc.) at a level of granularity to be determined. Andy Mabbett
14:30, 11 Jul 2007 (PDT)

    * This may no longer be necessary; as the use of "fn [child-of-adr]", for
venues and other places, has been proposed and is being debated (see email of
2007-12-30
(http://microformats.org/discuss/mail/microformats-discuss/2007-December/011169.html).
Andy Mabbett 14:04, 8 Jan 2008 (PST)

Well, LABEL is to ADR what FN is to N. So just put whatever human-readable text
that doesn't fit the ADR structure in LABEL. Or did I miss something?

(from http://microformats.org/wiki/vcard-suggestions)

The vCard standard specifies that US-ASCII is assumed to be the encoding in the
absence of a MIME content type header or a CHARSET parameter that indicates
otherwise. This was an unfortunate choice. vCard .vcf files stored on a local
filesystem do not contain a MIME header and the only way to reliably use an
encoding other than ASCII is to tag each field with the "CHARSET=" label. This
makes the vCard stream more complicated than necessary. This could be
simplified by a revision of the standard that specifies UTF-8 as the default
encoding. This could work safely with existing vCard .vcf files, which do not
contain a MIME content header. The first vCard VERSION field would be the same
encoded as either ASCII or UTF-8, so readers could easily determine which
encoding to default to.

Furthermore, those creating vCard readers should be encouraged to support vCard
.vcf files that begin with a UTF-8 BOM sequence. If the first three bytes of
the file are 0xEF 0xBB 0xBF, the text file is UTF-8 encoded, and the vCard
reader should assume UTF-8 is the default. Unfortunately many readers today
fail to recognize the UTF-8 BOM and view the file as a corrupt vCard.

(from CalConnect workshop)

- Follow iCalendar's lead and require vCard data to be utf-8.
- charset=utf-8 will be the default for text/vcard.

Fixed in r19. The following was added:

5.1.5.  CHARSET

   Purpose:  To specify the character set of a vCard.

   Value type:  A single text value.

   Special notes:  The value must be a character set tag registered from
      IANA as defined in [RFC2978].

      If this property is absent, the value of the MIME "charset"
      parameter is used instead.  If that is absent, the default
      character set is UTF-8 as defined in [RFC3629].  Note that there
      is no way to specify per-property character sets.

      This property may appear by itself (i.e. not between BEGIN and END
      properties).  In that case, it applies to the whole MIME stream
      (or file).  Otherwise, it only appears to the enclosing vCard.

   Example:  In this example, the first and second vCards are expressed
      in the ISO-8859-1 character set while the third one is expressed
      in the UTF-8 character set.

       CHARSET:ISO-8859-1
       BEGIN:VCARD
       ...
       END:VCARD
       BEGIN:VCARD
       ...
       END:VCARD
       BEGIN:VCARD
       CHARSET:UTF-8
       ...
       END:VCARD

Now we are independent of the MIME headers, which is good when e.g. you want to
save the vCard to a file, which usually doesn't preserve the MIME metadata. I
also specified a way to have per-vCard charsets which is important when you
want to aggregate vCards from multiple locations into a single file.

I made CHARSET take priority over the MIME charset parameter because of
experience with HTML's <meta http-equiv=...> tags. If a web server is
configured for always sending UTF-8, it must be possible to override that
setting per-resource in the resource content itself.

What should we do about it?

Integrated in r20. The following was added:

5.4.3.  IMPP

   Purpose:  To specify the URI for instant messaging and presence
      protocol communications with the object the vCard represents.

   Value type:  A single URI.  The type of the URI indicates the
      protocol that can be used for this contact.

   Special notes:  The property may include the type parameter "TYPE" to
      specify an intended use for the URI.  The TYPE parameter values
      include one or more of the following:

      *  An indication of the type of communication for which this URI
         is appropriate.  This can be a value of "personal" or
         "business".

      *  An indication of the location of a device associated with this
         URI.  Values can be "home", "work", or "mobile".

      *  The value "pref" indicates this is a preferred address and has
         the same semantics as the "pref" value in a TEL property.

   Example:

       IMPP;TYPE=personal,pref:xmpp:alice@example.com

(from IETF Chicago presentation by Cyrus Daboo)

How to indicate localization for address formats?

This is the state of things:

- ADR is based on semantics of the X.520 geographical and postal addressing
attributes.
- LABEL is to ADR what FN is to N. Free-form, everything that doesn't fit in
ADR.

The question is: do we want to explicitly support schemes other than X.520? If
so, which ones, and how do we specify it?

Until we have a more precise suggestion, this is WONTFIX.

(from IETF Chicago presentation by Cyrus Daboo)

Create X-<vendor-id> namespace for private extensions.

Is there really a need to go beyond what we already provide? Properties and
parameters whose names starts with X- already are private. Do vendors really
need their own namespace?

there should be a way for vendors to add their own stuff and still have
interoperability. Therefore, an extension mechanism of some sort need to be
defined clearly. Maybe an IANA registry with expert review is the right way to
do this.

It's defined in Secion 12.1.2 (Vendor Namespace).

Currently 2426 has been translated to XML. We should merge 2425 into that.

Here's how I intend to proceed with the merge:

- Sections 1-4 will be discarded and something similar will need to be written
from scratch.

- Section 5 will be renamed "Basic Grammar and Conventions" and the content of
section 5.8 will be reused and adapted. Other subsections will have to be
rewritten so as to register the text/vcard MIME type.

- Section 6 will be reused and adapted. Instead of "types" we'll be talking
about "properties". Subsection 6.3 will be dropped, as will all references to
"directory profiles".

- Sections 7-20 will be dropped.

Done in r11.

Should be text/vcard.

Done in r9. I complete the registration template found in RFC 4288 and added it
as a section.

(from IETF Chicago presentation by Cyrus Daboo)

Merge existing extensions into new document.

RFC 4770 was just merged in (r20). What else is there?

I merged RFC 2739 in r51. The charter only mentions RFC 2739 and RFC 4770 as
merge candidates, so I guess we're done merging stuff.

(from IETF Chicago presentation by Cyrus Daboo)

Clarify allowed parameter combinations.

(In reply to comment #0)
> Clarify allowed parameter combinations.

Clarify this.

(from IETF Chicago presentation by Cyrus Daboo)

Define "formal" IANA process rather than ietf-mime-direct@imc.org mechanism.

(from CalConnect workshop)

- Define formal IANA registry.
- Use template format now used in iCalendar 2445bis.
- X-<Vendor-ID> mechanism for non-standard extensions.

Much of 2445bis's IANA process text has been adapted to vCard. A vendor
namespace has also been created. The text has been adapted from RFC 4288.
Closed as of r69.

From RFC 2425 section 5.8.2:

   The group construct is used to group related attributes together.
   The group name is a syntactic convention used to indicate that all
   type names prefaced with the same group name SHOULD be grouped
   together when displayed by an application. It has no other
   significance.  Implementations that do not understand or support
   grouping MAY simply strip off any text before a "." to the left of
   the type name and present the types and values as normal.

Is this used at all? Maybe it should be removed...

(from Cyrus Daboo)

The one incompatibility between the iCalendar and vCard syntaxes 
is that construct - iCalendar does not have anything similar, which means 
it is not possible to embed an arbitrary vCard in an iCalendar object 
without doing some manipulations to remove the property name prefix. There 
are those that would like to embed vCard in iCalendar.

(from Cyrus Daboo)

Last I checked Apple's AddressBook does use this construct for tying 
together ADR locale information to the ADR value i.e. the UI allows the 
user to associate a locale with each mailing address so that the address is 
formatted for that locale - they put the locale in a property and need to 
make sure that property relates to a specific ADR. Of course a parameter on 
ADR could be used instead.

Groups were removed in r31.

Its meaning is vague an the parameter seems to be of no use.

*** Bug 190 has been marked as a duplicate of this bug. ***

The CONTEXT parameter has been removed in r36.

(email from Javier Godoy on vcarddav@ietf.org)

2. PRODID

It says:
>   Special notes:  Implementations SHOULD use a method such as that
>      specified for Formal Public Identifiers in ISO 9070 to assure that
>      the text value is unique.

This requirement stands for recommending identifier uniqueness, and
Formal Public Identifiers are only refered as an example (but any other unique
identifier meets the requirement). 

Since there is a good discussion about global uniqueness in the RFC series (RFC
3406 "Uniform Resource Names Namespace Definition Mechanisms"), i think it
could be used instead of ISO 9070. Besides, per RFC 3967, page 2, 3rd paragraph
I understand the reference to ISO 9070 (or RFC 3406) should be informative
instead of normative.

The reference to ISO 9070 was made informative in r38.

This issue should have been closed long ago. Either ISO 9070 or RFC 3406 is
suggested. Implementations are free to choose any method to generate this
opaque string.

(email from Javier Godoy on vcarddav@ietf.org)

Even though vCards are intended for information about individual subjects, in
some use-cases the "contact" is a corporation as a whole (instead of a single
individual).

What is the correct way for creating a valid vCard for a corporate entity?
(this is not a pathological question, it was raised while discussing the
corrigenda for
IEEE standard 1484.12.1, which includes vCard content).

In my opinion, vCards about corporate entities should have empty Given Name,
Additional Names and Honorific Prefixes. The Family Name and Honorific Suffixes
components may be used, for instance N:Corporate Entities,,,,Inc.. If no suffix
is used, it falls to N:Corporate Entities (trailing commas ommited). 

But RFC 2426 does not specify how to encode corporation names in the N
property, therefore my rationale is no more than a guess. 

If there is a widely accepted solution, I would suggest including some
paragraph in the new draft (maybe a "SHOULD", since it does not forbid any
non-conforming practice).

(email from Cyrus Daboo on vcarddav@ietf.org)

Yes, I want to emphasize this point. The current spec does imply that 
vcards are meant for individuals only but they are increasing being used 
for corporations, and there is interest in also using them for general 
location/venue information (c.f the VVENUE spec for iCalendar which is an 
attempt to introduce a new component type for giving richer information 
about calendar event locations - there is a general feeling now that it 
might be better to simply embed vcard objects in iCalendar to do the same - 
plus that allows for richer information about attendees too).

So I would certainly like to see Javier's point above addressed in addition 
to any others that restrict use to "individuals". I'll see if I can come up 
with a list of what I think those are.

Javier Godoy proposed adding a KIND property that would take either
"individual" or "org" as value.

(from Cyrus Daboo)

iCalendar has a CUTYPE parameter for ATTENDEE's defined as:

     cutypeparam        = "CUTYPE" "="
                         ("INDIVIDUAL"          ; An individual
                        / "GROUP"               ; A group of individuals
                        / "RESOURCE"            ; A physical resource
                        / "ROOM"                ; A room resource
                        / "UNKNOWN"             ; Otherwise not known
                        / x-name                ; Experimental type
                        / iana-token)           ; Other IANA registered


I think we need to include some of those values in the vCard equivalent. 
Certainly 'GROUP' - we have discussed a little befiore about how 
groups/distribution lists should be represented in vCard and having a KIND 
property that identifies vCards as groups would be useful.

Fixed in r34. Added the following text:

5.1.5.  KIND

   Purpose:  To specify the kind of object the vCard represents.

   Value type:  A single text value.

   Special notes:  The value may be one of: "individual" for a single
      person, "group" for a group of people, "org" for an organization,
      an x-name or an iana-token.  If this property is absent,
      "individual" MUST be assumed as default.

   Example:

      This represents someone named Jane Doe working in the marketing
      department of the North American division of ABC Inc.

         BEGIN:VCARD
         VERSION:4.0
         KIND:individual
         FN:Jane Doe
         ORG:ABC\, Inc.;North American Division;Marketing
         END:VCARD

      This represents the department itself, commonly known as ABC
      Marketing.

         BEGIN:VCARD
         VERSION:4.0
         KIND:org
         FN:ABC Marketing
         ORG:ABC\, Inc.;North American Division;Marketing
         END:VCARD

As suggested by Mark Paterson on vcarddav@ietf.org.

The MAILER property has been removed in r37.

(email from Javier Godoy on vcarddav@ietf.org)

(From Section 5.1.3)

The interpretation of the value for a SOURCE property can depend on the 
setting of the CONTEXT type parameter. The value of the CONTEXT type 
parameter MUST be compatible with the value of the uri prefix.

Examples:

SOURCE;CONTEXT=LDAP:ldap://ldap.host/cn=Babs%20Jensen,
 %20o=Babsco,%20c=US

it seems as if the CONTEXT parameter were to name the URI scheme used as 
value. If that is true, then it is redundant. What other values may be used?

*** This bug has been marked as a duplicate of bug 179 ***

(email from Mark Paterson on vcarddav@ietf.org)

>> - Section 5.3 might be more clear if it were labeled "Postal Addressing
>> Properties". I think the word "Delivery" is a little confusing since I
>> can deliver something as an email
>>     
>
> Maybe, but then how would you rephrase this?
>
> ""postal" to indicate a postal delivery address"
>
> That's from the description of the TYPE parameter for the ADR property.
>   
I honestly think the entire Special Notes section needs to be rewritten. 
How is a postal address different from a parcel address? What does dom 
and intl mean?? I woudl assume an address in Japan is domestic to 
someome in Japan but intl to someone in Canada. A good look at other 
standards which define how to specify an address should be examined for 
inspiration.

Fixed in r41.

- Removed "intl", "dom", "postal", and "parcel" TYPE parameter values for the
  ADR and LABEL properties.
- Clarified meaning of "extended address" ADR field.

(email by Mark Paterson on vcarddav@iet