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 (Update: sorry, the subproject is dead) 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.

standards

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"
}