Voici la version 2 du format de représentation d'entités (personnes ou organisations) JSContact (). En fait, ce numéro de version est trompeur, il n'y a qu'un seul changement, le membre uid qui était obligatoire devient facultatif. Mais ce petit changement, qui casse la compatibilité, oblige à changer de numéro de version.

Dans la section 2.1.9 du , l'uid (User IDentifier) était obligatoire. Alors que le vieux format vCard () le disait facultatif, ce qui rendait difficile toute traduction automatique de vCard vers JSContact. En outre, s'il était cool d'avoir la garantie d'un identificateur unique pour chaque carte de visite au format JSContact, cela ne convenait pas dans tous les cas. Ainsi, RDAP () n'utilise pas du tout cette propriété uid.

Donc, seul changement entre les versions 1 et 2, l'attribut uid devient optionnel. On passe de : uid: String (mandatory) à : *uid: String (optional).* Mais c'est suffisant pour obliger à changer le numéro de version de JSContact (, section 1.9).

Par exemple, cet object JSContact (qui n'a pas d'uid) est désormais légal : { "@type": "Card", "version": "2.0", "name": {"components": [{"kind": "given","value": "Jean"}, {"kind": "surname","value": "Durand"}]}, "emails": { "email": { "address": "jean.durand@example.com" } } } (Avec la version 1, il aurait fallu quelque chose comme "uid": "a73c940e-b1d3-4f3c-aa50-c9749352c253" après la version.)