14096 - LDIF import/export to deal with legacy data from/to 4.0x & 4.5 or later

Status: NEW

(MailNews Core :: Address Book, defect)

Description

[Katsuhiko Momoi]

This bug was split from Bug 13246 where we dealt with
importing Nova LDIF which we knew to be in UTF-8 (w/ no Base64).

For 5.0, we probably should use Base64 where needed also according
to the following standard-track document, which should reappear
as a regular RFC in the near future:

http://www.ietf.org/internet-drafts/draft-good-ldap-ldif-04.txt

Here are the cases we need to deal with in 5.0:

For importing, we should have dialog options to deal with the
following type of cases:

1. 4.0x LDIF files which are usally not in UTF-8
   but rather in one of the native charsets. This way we
   don't have to ask the user to manually change the extension from
   .ldif to .4ld(if). We can then either a) ask the user to specify
   the charset or b) assume that the charset is the same as the
   locale charset of the system. Which should we choose?
2. 4.5 and later LDIF files which are in UTF-8 but not using
   Base64 encoding as specified in the above document.
3. 5.0 and later LDIF files which will use UTF8+Base64 as needed. (This
   may be combined with #2 since decoding with or without Base64
   is probably easy.)


For exporting: We should have dialog options to deal with the
               following cases.

1. To 4.0x and other clients which can only deal with native charset
   data. (Either a) ask the user for the taget charset, or b) assume
   that it is the locale charset.

2. To 4.5 and later but within 4.x family.

   Export using UTF-8 but no Base64 encoding (unless 4.5 can decode
   this anyway. We need to check this in the Nova code.)

3. To 5.0 and later.

   Export using UTF-8 and Base64 as needed as described in
   the above RFC-candidate document.

Comment 1

[lchiang]

Should add this to http://bugzilla.mozilla.org/show_bug.cgi?id=10837?

Comment 2

[Phil Peterson]

Lisa, not sure what you're asking, but this bug is about text/ldif, and 10837 is
about 4.x binary DBs, so the work involved is pretty different.

Comment 3

[davidmc]

Yes, they're very different problems; the only similarity is that MDB is the same
destination for the imported content.  But the nature of the imported content is
entirely different, and there's not much code or design overlap, except in vague
theoretical terms.

Comment 4

[Katsuhiko Momoi]

The IETF draft was updated in 10/99. (Author: [e-mail])
The new version is:

http://search.ietf.org/internet-drafts/draft-good-ldap-ldif-05.txt

Comment 5

[selmer (gone)]

Mass moving to M16 to get these off the M15 radar.  Please let me know if this
is really an M15 stopper.

Comment 6

[selmer (gone)]

[LDAP] in summary

Comment 7

[selmer (gone)]

Not beta2 stopper.  Marking M20.

Comment 8

[scottputterman]

marking nsbeta1-

Comment 9

[Katsuhiko Momoi]

QA contact to ji -- when and if this gets worked on.

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

Are the issues mentioned in the section about importing ldifs still relevant, or
should the Summary for this bug be changed to only refer to data export?

Comment 11

[Katsuhiko Momoi]

As I stated when I first filed this request, the IETF draft 
document is now a standards track RFC 2849 -- see the URL field
above.
I recommend close examination of this document. 

I believe item 1 and item 2 mentioned for importing 
are still relevant if we care about legacy LLDIF files
created prior to Comm 4.5.
Item 3 is dependent on whether or not we do item 3
for exporting. 
Please examine the RFC above and evaluate its importance
and relevance.

Comment 12

[Peter Lairo]

suggest to addkeyword: nsCatFood because importing/exporting AB's is highly
relevant to users.

Many of us have/will have Mozilla at home *and* at work and will need to be able
to import and export our AB's (bug 72400). 

Even better would be the ability to *merge* AB's to keep the AB's syncronized
and to avoid duplicates (bug 72399).

Comment 13

[scottputterman]

reassigning to cavin

Comment 14

[R.K.Aa.]

Bug 116973: "implement LDIF export", was verified fixed on Feb. 2nd.
Remaining issues in bug 119360.

Is this bug (bug 14096) still relevant?

Comment 15

[Katsuhiko Momoi]

> Is this bug (bug 14096) still relevant?

That depends on:

1.  what was implemented by LDIF export function in the other bug.
   ** The remaining Bug 119360 does ont address the requests
      made here.
   ** A glance at the current LDIF export does not seem to
      address the issues in thisbug

and

2. how important it is to take care of legacy issues
3. if the current implementation follows RFC 2849.

Comment 16

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 17

[Joe Infla]

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

Comment 18

[Wayne Mery (:wsmwk)]

joshua, see anything related in your import ramblings?

Comment 19

[msh140.3]

Attachment: https://bugzilla.mozilla.org/show_bug.cgi?id=14096

Comment 20

[kiandresmith7]

[Tracking Requested - why for this release]:

Comment 21

[Wayne Mery (:wsmwk)]

This is not the place for your testing.
Please use https://landfill.bugzilla.org/ for your testing.