Why I’m not working on vCard validators

The vCard 3.0 validator is ten years old. The standard has moved on, Python has moved on, and I’d like to think I’ve learned a thing or two as a developer. But I’m not working on any vCard validators, and probably won’t be for the foreseeable future.

Maybe I’m suffering from second-system syndrome, but I’ve tried to reboot the project at least three times now. The Python code isn’t very elegant, fast or well tested. I set up skeletons in Java version and Rust, both excellent languages. I tried defining an ANTLR grammar. But I’ve got nothing to show for any of that. The main problem is motivation: vCard 3, 4 and jCard are incredibly out of date, to the point where writing a parser is equal parts painful and boring.


And now, because the Internet needs more opinions (and standards): a human friendly address card format is possible. vCard/jCard is not it. When someone brave and tenacious enough to take this on comes around, I really hope they take at least the following into account:

  • Use a popular, existing serialization format. JSON won in this space. It’s not perfect, but it’s here to stay and it’s a good compromise between human and machine readable.
  • Don’t create another jCard. If you were developing the world’s first address card format, what would users and developers want to see?
  • Conversely, vCard did many things right. UTF-8, base64 and ISO dates are definitely good things.
  • All caps is hard to read. Don’t shout.
  • Don’t limit (or even recommend) a line length or line splitting scheme. Address cards shouldn’t be inlined into emails or documents any more than CSV files.
  • Dictionaries (as in associated key/value pairs) are useful. Use them.
  • Lists are useful. Use them.
  • Preferred name should probably be the only required name field.
  • Time zones are not UTC offsets. I do not live in time zone “+12:00”, because that offset changes twice per year. I live in time zone “Pacific/Auckland”. This can be the difference between being on time and wasting everybody’s time.
  • Allow linking to photos. Sure URLs are ephemeral, but so is basically everything in an address card.
  • Any property not in the standard should simply be ignored, as long as the entire document is still a valid instance of the serialization format.
  • Internationalization and localization are complex but important.

What will such a standard look like? Maybe something like this will be possible:

    "preferred name": "Jane Doe",
    "phone": {
        "cell": ["+99 9999-9999", "+11 0000 0000"],
        "home": "+99 9999-9999"
    "URL": {
        "blog": "https://…",
        "work": ["https://example.org/", "https://example.com/"]
    "photo": "https://…",
    "my custom property": "…",
    "time zone": "Pacific/Auckland"