1. Summary
Shepherd: Bert Greevenbosch
AD: Pete Resnick
The document defines "jCard", which is a JSON format for vCard [RFC6350]
data.
The main advantage of using a JSON-based format over the classic vCard
format is easier processing for JavaScript based widgets and libraries,
especially in the scope of web-based applications.
The jCard format is designed to be semantically equivalent to the vCard
format, and conversion between the formats can be done without loss.
Finally, the jCard format is designed to be easily used by a similar
JSON-based format for calendar data: jCal. The latter format is still
under development, but is expected to be finalized soon after
finalization of jCard.
The working group thinks that a Proposed Standard publication is
suitable. It is a normative document, and therefore Standards track.
The document defines a data format that will need to be interoperable
and is planned to be used by other IETF protocols.
2. Review and Consensus
Since the document's WG adoption on 25 March 2013, it has been widely
discussed on the mailing list. In addition, other working groups have
been consulted. The IETF working groups are SCIM, WEIRDS and CALSIFY. In
addition, we have contacted W3C public-contacts-cord and the
portablecontacts Google group. In-dept comments have been received from
WEIRDS and CALSIFY. WEIRDS has a jCal example in its
draft-ietf-json-response.
All technical issues raised on the mailing list have been resolved. The
topics have not been controversial, although several topics required
some rounds of discussion. Topics included the format for date and time,
handling of default values when converting between vCard and jCard,
structured values and grouping.
Section 6 of the draft mentions three implementations. These are
ICAL.js, Py Calendar and ez-vcard. The implementations have led to some
discussions on the list, resulting in clarifications in the text.
3. Intellectual Property
No IPR declarations have been made. An e-mail reminding the requirement
to disclose known IPR was sent on 22 May to the jcardcal mailing list.
Several people, among which the author of the draft, have confirmed that
they are not personally aware of any IPR related to the draft.
4. Other Points
Section 8 contains IANA considerations. The definition tables of the
GROUP parameter and the UNKNOWN data type are similar to the definition
tables of other parameters and data types in RFC 6350. A registration
e-mail with more verbose information as required by RFC 6350 sections
10.2.4 and 10.2.5 has been sent to vcarddav@ietf.org and iana@iana.org,
and is awaiting further processing.