We just published version 11 of the JSContact draft and related RFCs:
- https://datatracker.ietf.org/doc/draft-ietf-calext-jscontact/
- https://datatracker.ietf.org/doc/draft-ietf-calext-jscontact-vcard/
- https://datatracker.ietf.org/doc/draft-ietf-calext-vcard-jscontact-extensions/
These versions address the extensive IETF Last Call feedback. However, some of it requires further work and clarification. For details, please see below. How should we proceed? Most likely, we will take back the RFC to the working group and restart last call after these open items got decided on?
Some notable changes in the current version are:
- The registry policy for new submissions now is Specification Required for minor version changes, Standards Action for major version changes. The registry process and role of the Designated Expert is documented in section 4.3.
- The @type property now is optional and can be omitted in almost all cases. New section 1.3 defines this.
- The Address data type includes additional street component kinds for better support of international addresses. Their use is shown in additional address examples.
- The OnlineService data type now allows to define both a URI and username. The new vCard parameter USERNAME is defined.
- A couple of JSContact and vCard property names got shortened.
- A new conversion property vCardName allows to store which vCard property or parameter a JSContact object got converted from.
Open items include:
- How to update vCard to allow for same expressiveness in postal addresses as it is now supported in JSContact?
- How to support phonetics in both JSContact localization and vCard?
We will start discussion on these open items soon on the calsify mailing list.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
