Omitted blank space in multi-line VCard 3 properties

[rfc2822]

When parsing the example from https://tools.ietf.org/html/rfc6350#section-6.2.3:

NOTE:This fax number is operational 0800 to 1715 
  EST\, Mon-Fri.

(two spaces in the second line)

ez-vcard/0.9.7 seems to return the value This fax number is operational 0800 to 1715EST, Mon-Fri. (note the missing space before EST).

Is this intentional? As far as I have seen, the first " " means "continue from previous line", while the second " " should be taken into account for the property value (but I'm not an expert at that, I just noticed that parsing the example didn't return what I expect).

See also the examples in https://tools.ietf.org/html/rfc6350#section-3.2

[mangstadt]

Sorry for the delayed reply. The behavior you cited is normal. Folded lines begin with one or more white space characters. So, if a line begins with 2 spaces, then both of those spaces are removed when the line is unfolded. This can result in the removal of spaces between words, depending on how the line is folded.

[rfc2822]

Hello, thanks for your reply.

https://tools.ietf.org/html/rfc6350#section-3.2 says:

A logical line MAY be continued on the next physical line anywhere between two characters by inserting a CRLF immediately followed by a single white space character (space (U+0020) or horizontal tab (U+0009)). The folded line MUST contain at least one character. Any sequence of CRLF followed immediately by a single white space character is ignored (removed) when processing the content type.

Where do I find the info about one or more space characters?

[mangstadt]

I'm sorry I closed the issue. All this time I thought folded lines could start with multiple whitespace characters. Thanks for pointing this out! I don't know how I missed this...

Based on some sample vCard files I have, it appears that some mail clients use multiple whitespace characters to fold base64-encoded data values (this may be how I got confused). ez-vcard will need to be aware of this and correct for it.

[rfc2822]

Thanks for having a look into this.

[mangstadt]

Fixed in 10c3111