Re: [calsify] Robert Wilton's No Objection on draft-ietf-calext-jscontact-09: (with COMMENT)

[Robert Stepanek <[e-mail]>]

Hi Robert,

thanks for your review. We have addressed both of your points in the upcoming RFC draft version. Please see details below:

On Wed, Apr 12, 2023, at 11:36 AM, Robert Wilton via Datatracker wrote:
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for this document.
> 
> Given time constraints this week.  Sorry, but due to holiday & PTO, I've only
> been any to review this as a fairly cursory level.
> 
> At a high level, the biggest question that I have is why an implementor would
> choose to use this instead of using one of the established and presumably
> widely deployed encodings of the vCard format?  As such, I think that this
> document may benefit from a slightly longer
> introduction/explanation/justification as to why an implementor may choose to
> use this over a vCard format (i.e., what problem is being solved), and possibly
> an appendix (or separate document) highlighting the main differences between
> this format and the vCard (or jCard) formats.  Perhaps this is what the
> introduction text is intended to already cover, but if so, that didn't come
> across clearly.

We now added a section to the Introduction that highlights this. Copied here verbatim:

1.1.  <https://app.fastmail.com/mail/JSContact/compose/M5b556dd73ccf7bfdcdeee945?u=e4d9409a#section-1.1>Motivation and Relation to vCard, jCard and xCard <https://app.fastmail.com/mail/JSContact/compose/M5b556dd73ccf7bfdcdeee945?u=e4d9409a#name-motivation-and-relation-to->

The vCard data format [RFC6350 <https://app.fastmail.com/mail/JSContact/compose/M5b556dd73ccf7bfdcdeee945?u=e4d9409a#RFC6350>] is an interchange format for contacts data between addressbook service providers and vendors. However, this format has gone through multiple specifications iterations with only a subset of its deprecated version 3 <https://app.fastmail.com/mail/JSContact/compose/M5b556dd73ccf7bfdcdeee945?u=e4d9409a#RFC2426> [RFC2426 <https://app.fastmail.com/mail/JSContact/compose/M5b556dd73ccf7bfdcdeee945?u=e4d9409a#RFC2426>] being widely in use. As a consequence, products and services internally use a richer contact data model than they expose when serialising that information to vCard. In addition, service providers use a proprietary JSON representation of contact data in their APIs.

JSContact provides a standard JSON-based data model and representation of contact data as an alternative to proprietary formats.

While writing this document, several features missing in vCard were brought to the attention of the authors, such as social media contacts, gender pronouns and others. This highlights how vCard is not perceived as an evolving format and consequently hasn't been updated since close to ten years. JSContact addresses these unmet demands and defines new vCard properties and parameters to allow interchanging these in both formats.

The xCard [RFC6351 <https://app.fastmail.com/mail/JSContact/compose/M5b556dd73ccf7bfdcdeee945?u=e4d9409a#RFC6351>] and jCard [RFC7095 <https://app.fastmail.com/mail/JSContact/compose/M5b556dd73ccf7bfdcdeee945?u=e4d9409a#RFC7095>] specifications define alternative representations for vCard data, in XML and JSON format respectively. Both explicitly aim to not change the underlying data model. Accordingly, they are regarded as equal to vCard in the context of this document.


> 
> One minor nit, in section 1.7, where it discusses versioning, it may be helpful
> to specify that if a new major version is published then the minor version is
> also reset back to 0.

We now emphasize this in the IANA considerations.

Regards,
Robert