RCF2426 <http://www.imc.org/rfc2426> defines types and structure of vCard fields. The address book should support all these types as much as possible. For instance: - BDAY field: bug 13595. - N type allows for first, last, additional names, prefixes, suffixes. Address book only has first and last name. (In some countries, honorific titles are very important in business communication. Not being able to keep track of the "Prof. Dr. Dr." in fornt of names may seriously deter, say, Austrians from using AB). - Duplicate type of TEL field, and more parameter values than work, home, fax, pager, cell. Make the telephone type a select field, like on the Palm. - CATEGORIES for interoperability with Palm - Other types, like, TZ, GEO, PHOTO.

Phil, I am sending to you for comment. Birthday missing is already a bug. What about the rest?

I'd prefer not to add more features to the address book until we have a chance to look at our remaining Seamonkey features as a whole after beta1. In the meantime, I think we should put this out on the helpwanted list. We can pull some or all of these items onto a Netscape engineer's schedule later if that seems like the right thing to do.

moving way out there...nobody is a busy person.

VCard (RFC2426) support is definitely needed for businesses to make use of the address book in Mozilla. Since it is missing in Netscape 6.2.2 we are not able to use that browser either. We have to stay with Netscape 7.9 or IE 5.5 or better. George.Metz@oracle.com

Drag and Drop would be nice too: I want to be able to drag an address book entry to my desktop and would get a vcard file. I want to be able to drag a vcard file to the address book and the contact would be added.

> Drag and Drop would be nice too: > I want to be able to drag an address book entry to my desktop and would get a > vcard file. Yes! I would like this feature, too. But IMHO this belongs to bug 20304

re-assign to sspitzer

Do you want Addressbook to be based on the vCard standard, or do you just want import/export functions?

As long as we can still import items from LDAP.

Does this bug cover also bug# 119459? AFAIK the vCard standard includes a photo field. Although I don't like much vCard's they are pretty standard in corporate enviroment and it should be supported, especially now that Thunderbird has an end-user focus.

At least add UID support: 3.6.7 UID Type Definition To: ietf-mime-directory@imc.org Subject: Registration of text/directory MIME type UID Type name: UID Type purpose: To specify a value that represents a globally unique identifier corresponding to the individual or resource associated with the vCard. Type encoding: 8bit Type value: A single text value. Type special notes: The type is used to uniquely identify the object that the vCard represents. The type can include the type parameter "TYPE" to specify the format of the identifier. The TYPE parameter value should be an IANA registered identifier format. The value can also be a non-standard format. Type example: UID:19950401-080045-40000F192713-0052

related Bug 60936 - vCard Mime type RFC2425

HiAll, Like every one i would love to use vCard , but ver 3.0. recent case usage. I am using Thunderbird 1.5rc1 on PC with XP pro SP2. I emailed a message with vcard attached , thinking he would be able to import all content staight into whichever package , PIM , outlook 2000 , outlook express he had. He emailed me back saying that no software will import file, he has outlook 2003. If this is generally the case does that meen that vCard will only work if all parties use Mozilla Thunderbird software. I tried creating a sandbox vCard with dummy details , export from thinderbird by emailing myself and then import into outlook 2000 , didnt work. Thunderbird is great , but not all the time. I thought is we need a extention or patch .

This bug should also depends on https://bugzilla.mozilla.org/show_bug.cgi?id=119459

wanted‑thunderbird3-; patches welcome though.

i do agree that TB should be able to interface so that businesses can utilize its multifaceted implications.

Note to potential implementers: any implementation should have potential to cover the newer vcard specs currently being discussed.

I guess in order to further increase the market impact with TB, one really have to work on the address book. Like many other commenters, I feel this is the Achilles heel.

Hi! I'm a fourth-year CS student from Waterloo who will be working on Thunderbird this term as part of an open-source projects course, and I would be happy to help take on this feature request. To that effect: the vCard spec is rather large. What should be prioritized?

Further to my previous comment - it seems that TB doesn't support vCard imports for currently existing address book fields. This seems like a good way to gain some familiarity with both the vCard spec and the Mozilla codebase - any thoughts?

Evan, glad to hear that! Import is bug 79709, i guess that could be an interesting start.

To summarize some stuff said on IRC: 1. It would probably be better to rewrite the current vCard implementation than to try to change some of the stuff, especially on the parser end (it's a yacc-generated file, and the original yacc code was lost [1]). 2. Should the new stuff be in C++ or JS? There is concern for the impact on performance if written in JS. 3. There may exist a suitable JS library for vCard read/write that we could adapt for Mozilla. 4. In terms of import, https://wiki.mozilla.org/User:Jcranmer/Writing_an_Importer has a basic, if sparse, introduction to writing address book importers. Other personal notes: 5. The nsIMsgVCardService interface is presently unusable from JS, and arguably hard-to-use from C++ as well; if the vCard implementation is changed, then the interface would probably need to be changed as well. 6. There are exactly two tests that mention vcards in the true, and they're not exactly testing the vcard engine to any degree. 7. nsAbCardProperty::ConvertToEscapedVCard currently uses a hard-coded list of properties for the vcard export. It would probably be a good idea to use a property map, à la nsIAbLDAPPropertyMap. Actually, that interface is probably sufficiently generic to be used for a vcard property map as well. This may just be the inner rewriter in me jumping at the possibility of seeing the vcard code get a hefty rewrite, though. [1] I've reverse engineered what I think was at least the original rules for the yacc file (the file has all of the rules listed out verbatim in one of the yy properties), but I don't trust myself to test to see if the generated code would work the same.

This patch makes a very tentative step towards supporting the MIME Content-Type for directory information described in RFC 2425. In particular: - it's implemented as an XPCOM component. - it pulls out types (with their parameters) and values, storing them in an array of (type, value) pairs. - it supports searching for types, both with and without parameters (see tests for examples); the value(s) are returned in an array, as each type may have several values. Parameter-based searches means that we can pull out specific types of addresses, telephone numbers, etc. by simple queries. - it does not attempt to interpret values (e.g. as datetime strings, lists, etc. as described in Section 5.8.4) - Quoted-Printable encoding is not supported yet - I'm assuming this would need some kind of content handler under /mailnews/mime/cthandlers? The idea is that, having supported this, vCard is just a specific subformat - so, with more polish, proper handling of MIME headers, a bit of extra checking for various vCard-specific stuff, and some work into switching existing code over, this could hopefully replace the current yacc-based VObject stuff. Nevertheless, it's admittedly incomplete; I'm hoping review will surface anything I've missed. Thoughts?

(In reply to comment #23) > Created an attachment (id=436422) [details] > Nevertheless, it's admittedly incomplete; I'm hoping review will surface > anything I've missed. Thoughts? Evan, can you describe a bit more about how your patch will work and interact with the rest of the code and other potential options? It might be useful to whip up some ascii art or a quick picture to help us understand. Thanks

The patch adds an interface definition and C++ implementation of nsIMIMEDirectoryEntry, a first crack at a simple parser and associated data structure for the directory format in RFC 2425. As a parser, it would replace the yacc-based VObject stuff with something infinitely more readable; it also provides serialization for outputting data to RFC 2425 format. As a data structure, it permits type/property lookups that could, e.g., be used to map vCards onto nsIAbCards. I think that covers most of our existing vCard-related use cases :) More specifically: I wrote this as a potential replacement for mailnews/addrbook/src/nsVCard{,Obj}.{h,cpp}, with the following plan for integration: - Add nsIMIMEDirectoryEntry alongside the existing code; - Write a simple wrapper around this for parsing vCards (i.e. check for BEGIN:VCARD, END:VCARD markers, pass string between them into a nsIMIMEDirectoryEntry member and read() type-value pairs - this could possibly be written to accept arbitrary BEGIN/END values, so as to support other RFC 2425-based formats like iCalendar); - Rewrite existing functions (nsAbManager::EscapedVCardToAbCard(), nsAbManager::convertFromVObject()) to use this wrapper.

Comment on attachment 436422 [details] [diff] [review] First experimental stab at implementing RFC 2425 I think this is potentially a good start, though I'd like to see more information on how multi-valued attributes would be handled and a bit more about the spec adherence, and I also think a javascript implementation may be better in terms of being more easily maintainable and potentially more flexible.

Hi All! I am using TB 10 the first time and wanted to import my addressbook from the vCard format which has set at least a widespread standard, regarding the content of the data fields. Now I have to realize that a complete takeover of the address book from vCard to TB 10 via the import function does not work. Only one single data set can then be imported per step. With the help of the csv-import and after much experimentation I managed to take my extensive contacts in the TB 10. This lack devalues the Thunderbird program, unfortunately. Much worse however is that the data fields in TB 10 are not congruent with the data collected in the vCard. There is, for example in the "private", as in "officially" not a field for the fax number. Other essential data which I will not give up cannot be keyed in or dedicated to the TB fields. Therefore a Thunderbird-based address management fails, and I must continue to maintain my contacts management with vCard. I read about your technical discussions but i am not able to relate these. So I want to initiate an adjustment and completion of data fields first of all. With the programming effort at low it will increase the "user friendliness" significant. Thanks

updating the bug's name in order to make it easier to find when looking for vCard 3.0 support...

The thing that really is outdated in mozilla mail-solutions is the address-book: missing full support for vcf: if for example an mail has been put under mail at work it won't be imported. vCard 3.0 is a must mozilla is really way back at this!!!!!

For an address book bug, Thunderbird and/or SeaMonkey tracking flags may or may not be relevant, but Firefox ones certainly aren't. kertase: see also https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Clearing all the tracking flags; as this is an enhancement request, not a regression, there is no need to track it for so many releases. Also, given that there is no patch close to landing on trunk, and given that there is a request for tracking a dead branch, it's clear that the requests are not legitimate requests, and were made in willful violation of the second bullet point on the etiquette page. kertase: please do not request them again.

Dear Mozilla Leadership, Thunderbird is a great application, however, it is still missing it in regards to addressbook / contact integration with LDAP and vCard. Really, I must emphasize how much this is needed in order to bring Thunderbird up to par with Outlook, or other clients with full address book sync support. Somewhere on the Mozilla site I read something to the effect that "maybe Thundebird is perfect already!" Sure, if you're not targeting non-profit (or even for-profit) organizations with real IT management needs. TB works great for a single user, but it's still in need of effort to get it working for medium to larger organizations. I can't see how a university would be able to fully integrate Thunderbird without proper LDAP directory syncing at least. In my opinion, you guys are ignoring a huge potential market, one in which you could get donations and funding for your non-profit work if you would put the time into it. Thunderbird is a great client, and it's value lies in it's great IMAP support. What that means for a non-profit is that we don't have to go the Microsoft route with our email servers. We can use Postfix and Dovecot, and save tons of not only money, but time and effort by using these excellent open source email servers, and not have to give MS even more money on top of what we're already paying for Office, etc. Lightning is starting to be a decent calendar client, all TB really needs is that address book sync and it's a serious competitor. Hope this reaches somebody in leadership. Thanks for reading.

https://github.com/mikeconley/thunderbird-ensemble It's a new a<dress book under development they are working on carddav integration at the moment.

And the bug for it is bug 841598.

As seen in bug 1450638 the current vcards are no longer supported by most email clients these days. So it's no longer about supporting a new standard, but about a broken functionality. Having vcards allows to exchange contacts instantly, without vcards we are forced to type contacts by hand. Furthermore the people that contact you are the most likely to turn into clients. If they have your contact and web page right away, email turns to be highly effective advertising. As result 89 people voted for this bug, and 59 are following it. Meanwhile the issue stayed unfixed for 18 years. So the question I'm asking myself is "would this ever get fixed?". I would raise this report importance. From all the features you could implement right now this is likely the most relevant one.

You can work around this issue by manually creating a .vcf file, and pasting it somewhere online. The file format is this: BEGIN:VCARD VERSION:4.0 N:[SURNAME];[NAME];;; FN:[FULL NAME] EMAIL:[EMAIL] TEL;TYPE=HOME:[HOME PHONE] TEL;TYPE=WORK:[WORK PHONE] TEL;TYPE=CELL:[CELL PHONE] URL:[WEBSITE] NOTE:[NOTE] END:VCARD Nevertheless Thunderbird will still be useless for managing vcards. You can install the add-on "Cardbook" for that, but it still would be more confortable adding the contacts through Gmail.

That said the title of this report says vCard 3.0, where vCard 4.0 is out.