VCardRawWriter: Conditionally allow invalid groups.

[AltSysrq]

Something (possibly Busy Contacts) added the following properties to an
iCloud vcard, which iCloud happily accepts, and EZ-VCard actually
parses:

COM \NWWW.COLPATRIA.COM <HTTP://www.colpatria.com>\n
COM\NWWW.COLPATRIA.COM <HTTP://www.colpatria.com>\n\n\n\n

Since it would be kind of awkward for us to manually go through and
validate groups, instead just silently discard groups which aren't
valid. This is kind of unfortunate, but I wasn't sure how better to
avoid this completely failing.

@blendmaster @skazhy Open for suggestions

[blendmaster]

So ezvcard will read these groups in, but refuse to write them back out? I put in a6e1f87 already, maybe it just needs extending to the write-side.

[AltSysrq]

I put in a6e1f87 already, maybe it just needs extending to the write-side.

I think it needs extension to groups handling; I'll do that then.

[blendmaster]

Oh, upstream has dealt with this too https://github.com/mangstadt/ez-vcard/wiki/Changelog

Relaxed the logic that checks property names for validity before writing them to an output stream. Before, it would throw an exception if a property name contained any characters not allowed by the specifications. Now, it only throws an exception if the property name contains a character that breaks the syntax (such as newline sequences and colon characters). Spec-compliant character checks have been moved to the validation framework (see VCard.validate()).

[AltSysrq]

Now, it only throws an exception if the property name contains a character that breaks the syntax (such as newline sequences and colon characters)

This example has a newline character.

[AltSysrq]

Actually, if the writer doesn't violate the standard and escape newlines in group names, we probably need to stick with throwing them away rather than trying to write them back out. I feel like we're not losing much since clearly something's gone horribly wrong by that point anyway.

[blendmaster]

They also pulled in #1 and #2, which I actually think covers everything I patched in this repo. You could try vanilla upstream.

This example has a newline character.

Really? can you paste the vcard somewhere (this is a public repo)?

[AltSysrq]

can you paste the vcard somewhere

The relevant portion is in the description. (The vcard parser does turn that \N into a newline, which is what it ends up screaming about during reserialisation.)

[blendmaster]

Wow, icloud really does accept that wholesale. I suppose we could match their behavior and not unescape the newlines in group names, but I guess I'd be fine with blindly dropping them as well.

the spec only seems to mention \n,\N in one place:

The method for specifying CRLF character sequences in text
type values has been changed. The CRLF character sequence in
a text type value is specified with the backslash character
sequence "\n" or "\N".

https://www.ietf.org/rfc/rfc2426.txt but it does seem like icloud is in the wrong here.

[AltSysrq]

@blendmaster Revised to do this the same way as invalid properties.

[blendmaster]

lgtm.

[AltSysrq]

Actually, this won't really work as-is because it doesn't re-escape the groups when writing. It would probably be a better solution to not interpret the escapes on read instead.

[AltSysrq]

Closing in favour of #4