Re: [calsify] Working Group Last call for jscontact drafts

[Robert Stepanek <[e-mail]>]

Hi everyone,

this is go give you an idea where we stand with WGLC and how you can help getting the standards done.

*Where do we stand*
We received some feedback off-list. While we very much appreciate those people taking the time to review the documents, please also engage on the mailing list. Even if you fully agree with our proposals (does anyone ever?), stating so still is important!

Here are the things we already plan to change in the final draft versions based on the feedback we got:
 * The "localizations" property definition <https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-05.html#name-localizations> and examples <https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-vcard-04.html#name-language> caused some confusion: why would one choose either to patch just a String-typed field, versus a whole object? We agree that this needs more clarification.
 * The "contexts", "pref" and "label" properties <https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-05.html#name-common-properties> currently are defined for some, but not all JSContact object types. For example, an Organization object currently does not include these properties. But we came to learn of an implementation that uses the vCard PREF and TYPE parameters on ORG. We will update the definition of these properties so that they can be set in any JSContact object, other than Card.
*How you can help*
A thorough review of the documents is most important. Even in case you do not plan to support JSContact, its definitions are important also for
 * _vCard_: the vcard-jscontact-extensions <https://datatracker.ietf.org/doc/draft-ietf-calext-vcard-jscontact-extensions/> RFC draft introduces a bunch of new properties and parameters to vCard. These were introduced for JSContact but should be useful even without it.
 *  JSCalendar: some JSContact definitions should also apply for JSCalendar:
   * The versioning that we propose for JSContact (section 1.6 <https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-05.html#name-versioning>) is meant to also be useful for JSCalendar. If you do not agree with its definition now, please let us know!
   * The validation rules <https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-05.html#name-validating-jscontact-proper> of unknown properties should also apply for the future jscalendarbis draft.
   * The definitions <https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-vcard-04.html#name-new-vcard-properties-and-pa> of the vCard JSCONTACT-PROP property and JSPTR parameter should hint at the way we also might preserve JSCalendar JSON-data in iCalendar. Does that look good to you?
Thanks for your time,
Robert

On Fri, Nov 25, 2022, at 5:02 PM, Daniel Migault wrote:
> As mentioned during the meeting we are starting a WGLC for the following drafts. Please review by December 9 the documents and provide your feedbacks to the list. Note this is important we got some feedback.
>  * 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/