vCard: Knowns, Unknowns, and Decisions

This document separates what the specifications say, what this project observed, what is only conventional, and what had to be decided where the format is silent.

Documented

Observed

Conventional

Unknown or unspecified

Decisions this project made

Question Decision Why
A card with no FN return it with a warning, and derive a display name from N a viewer can still show the person; refusing hides a readable card
A card with no N return it with a warning 4.0 requires only FN
An unknown VERSION read it as 4.0-shaped and warn the line grammar is shared; the alternative is refusing a readable file
A malformed line skip it and warn one bad line must not hide the rest of the card
A charset outside UTF-8, US-ASCII, and ISO-8859-1 keep the octets as written and warn a wrong transcoding is worse than a visible replacement character
A remote PHOTO URI report it, do not fetch it reading a card must not contact a third party
An inline photo with no MEDIATYPE sniff the PNG and JPEG signatures, otherwise keep the bytes and warn the bytes are the reliable statement
A javascript: URL report it, never link it the card is untrusted input and the SVG is a document
Two FN values keep both, show the first, warn the file is wrong; the reader still has a useful value
Text outside a card warn and ignore it a concatenated export may carry a stray line
A NUL byte in the file refuse the file as not a vCard a text format with a NUL is binary damage, not a card
A quoted-printable soft break with no leading whitespace join the next line some producers write it; the alternative is to lose the rest of the value
A five-component ADR whose fifth part looks like a postal code read the fifth part as the postal code some 2.1 producers omit the trailing empty components

Security notes