394856 - import problem of "objectclass:: (/Base64)<groupOfNames>

Status: UNCONFIRMED

(MailNews Core :: LDAP Integration, defect)

Description

[Ben]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: thunderbird version 2.0.0.6 (20070728)

I think think t will be a simple solvable problem for your developers...

Code of my bash-converting function...

function f_convert_latin1_to_base64 {
    _result="${1}"

    if [ -n ${#_result} ]; then
        #
        # write content to file
        #
        echo -e -n "${_result}" >  latin1.to.base64


        #
        # encode content
        #
        # step 1......... from "latin1" into "utf-8"
        # step 2......... from "utf-8"  into "/Base64"
        #
        # or in one step
        #
        # step 1......... from "latin1" into "/Based64"
        recode latin1../Base64 latin1.to.base64


        #
        # restore joined lines
        #
        set --
        _result=""
        while read line "${@}"
        do
            _result+="${line//\n%/}"
        done < latin1.to.base64


        #
        # clean space
        #
        [ -f "latin1.to.base64" ] && rm latin1.to.base64


        #
        # return result
        #
        echo -n "${_result}"
    else
        echo -n ""
    fi


    return
}


I used for a simple test the export-content of one special prepared "addressbook"
"application"->"thunderbird::addressbook" the simple solution with the function
above.

I can encode every modifyable content I extract by the example export from the
"thunderbird::addressbook" in /Base64.
With example given here for a phone number entry:

# 
# "telephoneNumber:: <work-phonenumber>"
#
   buffer="telephoneNumber:: "
rawbuffer=""
[-n "${element_list[${pos[10]}]}" ] && rawbuffer="${element_list[${pos[10]}]}"
echo "${buffer}$( f_convert_latin1_to_base64 ${rawbuffer} )"


To simpliy code for you, replace the "element_list[${pos[10]}]" with
a "phonenumber"

element_list[${pos[...]}] realizes for my import-process a flexible filter


I can encode every modifyable content, except the necessary one for creating
email-lists. Here I am forced to use:

echo "objectclass: groupOfNames"

If I use

echo "objectclass: $( f_convert_latin1_to_base64 "groupOfNames" )"

then the wanted email-address-list will not be imported/created.


I think there have someone forgotten to implement the "/Base64"-support,
if your addressbook-importfilter gets "objectclass:: ...".

Thanks for feedback,
Ben

Reproducible: Always

Steps to Reproduce:
1. see Details
2.
3.
Actual Results:  
work around is explained in Details

Expected Results:  
Repair of bug in future.

Merci beaucoup!

Comment 1

[Mark Banner (:standard8)]

Mark, do you think this is something we should support? Is it really in the spirit of RFC 2849?

Comment 2

[Mark Smith [:mcs]]

I am not sure I understand what the bug is here... is it that a line like this:

  objectclass::Z3JvdXBPZk5hbWVz

is not recognized as specifying the value groupOfNames for objectClass?  I would say that is a bug (I would also say it is unusual to encode strings as Base64 when they do not contain any special characters).

Comment 3

[Wayne Mery (:wsmwk)]

ben, do you agree with the question, and the analysis of comment 2?

Comment 4

[Ben]

Thanks a lot to all of you and for your feedback.

2007 is a realy long time ago, since I got to solve described problem with
import/export contact-data from and to Thunderbird.
The first and easiest way for me was solving my problem in bash.

What I can remember is, that special Characters like "äÄöÖüÜ" a.s.o
had made me some troubles during such a process, if I used it without the
transformation above. ASCII do not support these characters and the english
language has got no need in using "äÄöÖüÜ".

I made a quick look to my test-data, I saw that my described encoding was
always marked by an extra ":". "::" instead of a single ":"
So, it can really be, that in the line of phonenumber a single ":" marks
a non-encoded phonenumber, which, if the number would be right encoded,
has to be marked with "::"

I am sorry, that I can not give more help.
Problems I solved final in the past, would not be so often touched a second time.
;-D

@Mark Smith
You have right. There is no need for transformation, even it is necessary.

My quick patch do not check cases if necessary, or if not necessary
to use the transformation above. I did it for all, because it was the easiest
and quickest way. Once content importet into Thunderbird nobody will ask me
what encoding was taken for import. My customer was happy after process
run properly without any problems. ;-D

If think this thread can be closed, if the marks ":" for plain-text and "::" for encoded text were working right during import/export process.