Dear Maintainer,
this bug report describes several related bugs, related to
a) whitespace (space, tab) in imported vCard files, and
b) vCard object separators (`BEGIN:VCARD`, `END:VCARD`).
------------------------------------------------------------------------
Bug 1: Leading whitespace in line continuation silently dropped
Example (note that vCard mandates CRLF as newline sequence):
---
BEGIN:VCARD
VERSION:3.0
N:Doe;Jane;;;
FN:Jane Doe
NOTE:an
example
END:VCARD
---
The NOTE value is parsed as `anexample` instead of `an example` (only
the first whitespace character should be dropped - see RFC 2426).
In particular, this means that a Roundcube export followed by a
Roundcube import may silently fail to recreate the original data.
------------------------------------------------------------------------
Note 2: Leading and trailing whitespace in a logical line is silently
dropped
Any number of space/tab characters at the start or end of a logical
line (or a component value, such as in `N`) is dropped.
This is not a bug, IMHO, given that Roundcube also strips surrounding
whitespace when entering data via its web UI.
I think it might be related, however.
------------------------------------------------------------------------
Note 3: Repeated `BEGIN:VCARD`: All ignored until last
If there are multiple `BEGIN:VCARD` lines before any `END:VCARD` line,
all lines (not only `BEGIN:VCARD` lines) until the last of those
`BEGIN:VCARD` lines are ignored.
I would say this is also not a bug, because such input is invalid. A
warning or error message would certainly be nice, though.
------------------------------------------------------------------------
Note 4: Repeated `END:VCARD` cause duplication
If a VCard object is terminated by more than one `END:VCARD` line, the
entry is imported as often as there are `END:VCARD` lines.
If on import, one does *not* choose to "[r]eplace the entire address
book", only one instance is imported, but with the note "Skipped (n-1)
existing entries: [...]".
Any physical lines after the first `END:VCARD` that are neither
`BEGIN:VCARD` nor `END:VCARD` are apparently ignored.
Again, not necessarily a bug, because any such input is of invalid
syntax (but a warning or error message would be nice).
------------------------------------------------------------------------
Bug 5: vCard object separators wrongly recognized in line continuations
If a physical line is of the form `[ \t]+(BEGIN|END):VCARD`, it is used
as line continuation, but also recognized as vcard object start/end
marker.
Example:
---
NOTE:example
END:VCARD
---
This is treated the same as:
---
NOTE:exampleEND:VCARD
END:VCARD
---
Note: For `BEGIN:VCARD`, the use as line continuation can only be
assumed, given that preceding lines are ignored (see Note 3).
While this bug may seem unlikely in practice, I actually witnessed it
with real data, likely due to past import/export errors.
------------------------------------------------------------------------
Bug 6: vCard object separators not parsed as logical lines
(6.1) Any logical line `BEGIN:VCARD` or `END:VCARD` that is broken into
multiple physical lines using `\r\n[ \t]\r\n` is not recognized as such.
(6.2) On the other hand, if a physical line `BEGIN:VCARD` or `END:VCARD`
is followed by a line continuation (i.e., a line starting with `[ \t]`),
this is (incorrectly) recognized as the corresponding vCard object
separator, and the line continuation is silently ignored.
Example for (6.1):
---
BEGIN:VCARD
VERSION:3.0
N:Doe;Jane;;;
FN:Jane Doe
EMAIL:jane.doe@example.net
END:
VCARD
---
The above example fails to import (and is instead attempted to be parsed
as CSV--without success).
I acknowledge that this bug hardly occurs in practice. I found it while
investigating the other bugs.
- Einhard Leichtfuß