Re: problem with kaddressbook

> On 2009.09.04 18:29, Peter Bloomfield wrote:
>> Hi Jack!
>>
>> On 09/03/2009 04:11:54 PM Thu, Jack wrote:
>>> I've pointed Balsa to my kaddressbook std.vcf file.  When I open the  
>>> file through one of the KDE apps, I see dozens of entries.  When I  
>>> open the address book in Balsa, I only see three names.  I finally  
>>> tracked it down that Balsa only shows those names with a  
>>> EMAIL;TYPE=PREF:name@host line.  Most of my entries have only an  
>>> EMAIL:name@host.  The PREF is only there for names that have two email  
>>> addresses.
>>>
>>> Should Balsa show names with only a single EMAIL entry, or was this a  
>>> problem when kaddressbook imported the original vcards, which were  
>>> originally exported from Outlook?
>>>
>>> Is my best fix just to manually add ";TYPE=PREF" to the other EMAIL  
>>> lines?
>>
>> It looks like a bug in Balsa's vCard address book code.  It looks for:
>>
>> EMAIL;.*:name@host
>>
>> evidently based on the assumption that all EMAIL lines have  
>> ";TYPE=...:" qualifiers.  I can't find any authority that requires  
>> them, and RFC-242[56] [1] makes it clear that they are optional, with  
>> TYPE=INTERNET as the default, so perhaps Balsa should be more  
>> permissive--patch attached.
>>
>> Best,
>>
>> Peter
>>
>> [1] <URL:http://www.faqs.org/rfcs/rfc2426.html> "defines the profile of  
>> the MIME Content-Type [MIME-DIR] for directory information for a  
>> white-pages person object, based on a vCard electronic business card.",  
>> which doesn't define what an address book should contain, but may be as  
>> close to a definition as we'll find...
>
> Success.  It works as advertised.  For the two who showed up before, it  
> (correctly?) shows both emails on the list.  (I prefer it shows both,  
> although one interpretation could be to chose the one with the PREF, but  
> I think that's overkill.)
>
> Thanks.
>
> Since this probably won't get rolled out until the next version, I'll  
> probably submit a Gentoo bug report with your patch, unless there is any  
> reason not to do so.