Feature Request: RFC 6350: "LABEL" parameter for ADR

michaelof commented 4 years ago

Hi,

in docs for Text::vCard::Precisely you're mentioning RFC 2426. As RFC 6350 "obsoletes" 2426, I refer to 6350:

It would be great to have the possibility fo define a "LABEL" param for node "ADR", like in chapter 6.3.1 of RFC 6350 (https://tools.ietf.org/html/rfc6350#page-32):

The property can also include a "LABEL" parameter to present a delivery address label for the address. Its value is a plain-text string representing the formatted address. Newlines are encoded as \n, as they are for property values.

E.g.:

ADR;TYPE=home;LABEL=Boulevard 999\n10000 Berlin:.....

FYI Background: I have all my contacts stored in my Nextcloud instance. Using FOSS contacts app "Simple-Contacts" on Android (https://github.com/SimpleMobileTools/Simple-Contacts). This app does not use (to keep it simple :-)) detailed addresses, but a formatted address, storted in "street", plus the "LABEL=" parameter. Additionally, several of my adresses stored in Nextcloud have their base/origin in an LibreOffice Calc file, frequently updated and shared by email. To keep them in sync, I've wrote a perl script reading the Calc file (ODS), and create vcards out of them. For this step I need Text::vCard::Precisely.

Thanks, Michael

worthmine commented 4 years ago

It might be the problem of my writing the docs, but we can ALREADY do what you want to do with no updating. Because All you have to do is declaring to use V4 (the default is V3).

I've mentioned it in the source

and already pass the test

Please try below:

use Text::vCard::Precisely::V4;
my $vc = Text::vCard::Precisely::V4->new();

$vc->adr(
    {   street    => '123 Main Street',
        city      => 'Any Town',
        region    => 'CA',
        post_code => '91921-1234',
        country   => 'U.S.A.',
        label =>
            "Mr. John Q. Public, Esq.\nMail Drop: TNE QB\n123 Main Street\nAny Town, CA  91921-1234\nU.S.A."
    }
);

print $vc->as_string();

If there is anything you fail, tell me again because it is a bug.

worthmine commented 4 years ago

Oh, I found bug!

# when we run
use Text::vCard::Precisely;
my $vc = Text::vCard::Precisely->new(version => '4.0');
# there is no override for subroutines which must be overriddden.

So, if you declared like above, it was a bug and fixed already at 0.24

Anytime you confirm this, you can close this Issue.

michaelof commented 4 years ago

Yuki, thank you for your very fast and helpful answer!!

In fact I've tried with current 0.23 and the my $vc = Text::vCard::Precisely->new(version => '4.0'); invocation. Funny, so I've run into this small bug :)

Just checked, and it's working PERFECTLY fine for me with my $vc = Text::vCard::Precisely::V4->new(); in 0.23, thanks!

Another question, different topic, guess it's not worth opening a separate issue:

CATEGORIES, you are summarizing them as To specify additional information for your jobs E.g. NEXTCLOUD uses CATEGORIES for storing group information, for grouping contact as desired. "Value type: One or more text values separated by a COMMA character". No idea how to pass more than one value. Tried

$vc->categories("catA"); $vc->categories("catB"); -> CATEGORIES:catB

$vc->categories("catA, catB"); -> CATEGORIES:catA\, catB # incorrect backslash

my @catarr = ( "catA", "catB" ); $vc->categories(@catarr); -> CATEGORIES:catA

Did I make a mistake, or does your current implementation only allow a single value?

Regards, Michael

worthmine commented 4 years ago

Congrats! And thank you for another Issue. That may be an another miswriting.

Give me a few days

worthmine commented 4 years ago

As @michaelof said, CATEGORIES may have multiple content with separated by comma.(And so NICKNAME does). These were mentioned in RFC2426.

So I've fixed V3 and V4 in 0.27

michaelof commented 4 years ago

Thank you very much for extending your very nice piece of software! Just a final remark: I guess it should be RFC 6350, as 6350 obsoletes 2426 :-)

worthmine commented 4 years ago

Why do I stick to RFC 2426 is that the OS vendors Apple, Google and Microsoft DO NOT ratify with 6350.

For Example, Japanese Windows will open .vcf file as like as being encoding in cp932, not UTF-8 (Of course you know it was denied in 6350 ). It is telling about Windows 10, not 8 and elder. I remember well that I was disappointed by the FACT.

I don't know why they don't ratify, but I've been providing safe way not based on spec, but fact.

worthmine / Text-vCard-Precisely

Feature Request: RFC 6350: "LABEL" parameter for ADR #19