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

Robert Stepanek <rsto@fastmailteam.com> Tue, 10 January 2023 10:02 UTC

Return-Path: <rsto@fastmailteam.com>
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CA5C1526E5 for <calsify@ietfa.amsl.com>; Tue, 10 Jan 2023 02:02:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level:
X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b="Js0U4qik"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="T8bJUvUG"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXSSAFDVkacL for <calsify@ietfa.amsl.com>; Tue, 10 Jan 2023 02:02:14 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90690C15258A for <calsify@ietf.org>; Tue, 10 Jan 2023 02:02:14 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 738F05C0078; Tue, 10 Jan 2023 05:02:13 -0500 (EST)
Received: from imap43 ([10.202.2.93]) by compute3.internal (MEProxy); Tue, 10 Jan 2023 05:02:13 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1673344933; x= 1673431333; bh=RFVTUnTMv3r9AOC5CE6z79SU5cj31GzAtllLwFAq6D0=; b=J s0U4qik06b0NqXcUIqBV8BMaGlooBzGEPD9Ay1KD7R4Jc88YLt5yQB1Xj0EpENoo z8wMf7PR9bCpWks76tLmgVQFj6hDdqla7epFxArSK0f+SkZM+MoVX0HSAfD5A+h2 1F74a3gQdsPu4AynqsnYsixH73UrvNQBfVIykF1TYXzBApeUWdba3YysbsLEsSBd IQahl5binyu40HUuegPTCJgRsb0+5vqULxhXysGQEFP2FOHbs++neoORBNFGd5dY YjyVZuIDTk2pq+NipJHtV45+5d7vFtgF67SiVSl5i1Nk3HsbfhKr122QlWJUkvr2 NTrQx/9ul8Chdx61pjmbw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1673344933; x=1673431333; bh=RFVTUnTMv3r9AOC5CE6z79SU5cj3 1GzAtllLwFAq6D0=; b=T8bJUvUGHoO9ptzBgOKVTZsYPGyKKGrDBuUkbYQYL+fI wmLj00iIo49MQYkQ6H+Z+5qkDyqcGlbwZVeS309QrRMp2ydVfeuhqTyPFXW0xPL1 YRc5JVEpphvBnxB8mI3CwLNjSDBp31mQ0BUTCuRr0TKOzxEfk0tdCMShSsGavOfy zjUwWqUK/t5Sv4Rj5AqGfpW8VOlC5PjcpM7MO1GZBE3S63QLNG59a9Ju3he/W4Rw DYHRCwWm2tTmII7L8rgV7LkBfQj52V9Lp69aAFoA+xRgMop2hJiQHNI29jbaIMjI i0YIf175IA3xH5ulTLJoN6JEIf4XuLe3/XjynUd3Ew==
X-ME-Sender: <xms:pTe9Y-Qb5Do4zsOTLMmQ6hUvi0hwQUBLXa5qpqXjTSYRYque3UEz1A> <xme:pTe9YzzUVLrkbaUl8URQuaOyycDdVzhJUv1vcUq-hKxvHXk9cCZVp5MjV5YfT7q37 hAM2F14QyW9og>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrkeekgddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvfevufgtsegrtd erreerredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepfefhleeuve fhveetvdegiedugfektddvgefgvdekfedtgeekfeeiffejvdffveffnecuffhomhgrihhn pegvgigrmhhplhgvrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheprhhsthhosehfrghsthhmrghilhhtvggrmhdrtghomh
X-ME-Proxy: <xmx:pTe9Y72dfDOs3xwOIuErPMzZiprnCvvy3JpVCmOU7ZDInR-GrH5oHQ> <xmx:pTe9Y6Bj5nZHqMg7gzd_Ds50U9pI26mSzFzQdywkNFbcZCtRgPUwnw> <xmx:pTe9Y3jvXXFOfg7gTYOshRZaa6if8606XGjs0Sw0r61RGt2vHhohyA> <xmx:pTe9Y5fSMBU0ecjNLAtee2Lfy94LIq1KabHV2BCYQmXLGPFk0Fao6g>
Feedback-ID: ia5d944da:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 386DC2D40074; Tue, 10 Jan 2023 05:02:13 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1191-g085608b2ee-fm-20221214.002-g085608b2
Mime-Version: 1.0
Message-Id: <44833205-f654-4320-93c8-cbeb13a748ed@app.fastmail.com>
In-Reply-To: <CADZyTkksfg8i-B1UNjSENnOSBrF1HRNaMMQYvfSBekmZ__-=-Q@mail.gmail.com>
References: <CADZyTkn_08H3zaG6PHwYOrN3sJZP_+_HUEF2ynWhsVBtg1bM4g@mail.gmail.com> <23d97a2d-0927-a046-83cf-bf2a3f300d4a@audriga.com> <77ba2bd4-98c4-421d-a237-848a048cf50b@app.fastmail.com> <36c0a914-25a9-4c06-97bd-a17e0251514b@app.fastmail.com> <CADZyTknzYwn9XLY-CKerK99W0m1Chna6L2ynd5JGWRE1EqfASA@mail.gmail.com> <c6532221-e93d-41b5-8781-ffdb5abe0d91@app.fastmail.com> <CADZyTknD1aXS8jjMu0EEVp_1drF9edF2+0B402tT30EYzeBrkw@mail.gmail.com> <a3e8ff46-ed4a-45b1-8614-5f9bf70ef511@app.fastmail.com> <CADZyTkksfg8i-B1UNjSENnOSBrF1HRNaMMQYvfSBekmZ__-=-Q@mail.gmail.com>
Date: Tue, 10 Jan 2023 11:01:52 +0100
From: Robert Stepanek <rsto@fastmailteam.com>
To: Daniel Migault <mglt.ietf@gmail.com>
Cc: calsify@ietf.org
Content-Type: multipart/alternative; boundary="f5acc05aa2614dabaf6efc7750a389fb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/iLwTo7lLZz6qL0NJFu-_500QQMg>
Subject: Re: [calsify] Working Group Last call for jscontact drafts
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Calendaring and Scheduling Standards Simplification <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jan 2023 10:02:19 -0000

Hi Daniel,

thanks again for the document review. Please see my replies below.

On Wed, Jan 4, 2023, at 11:46 PM, Daniel Migault wrote:
> 1.  Introduction
> 
>    This document defines a data model for contact card data normally
>    used in address book or directory applications and services.  It aims
>    to be an alternative to the vCard data format [RFC6350] and to
>    provide a JSON-based standard representation of contact card data.
> 
> <mglt>
> Maybe I am not enough familiar with the terminology, but I am expecting from thes eline the vCard format to be expressed in JSON which is already done by jCard.
> I believe that JSCard i sprimarily a new (or updated) data model used by vCard and the fact it is expressed as JSON seems sort of secondary.
> If I am correct, I am wondering what indicates JSCard is not simply a translation to JSON.
> </mglt>

Thanks, I simply removed the "provide a JSON-based standard representation of contact card data" part.

> 
>    The key design considerations for this data model are as follows:
> 
>    *  Most of the initial set of attributes should be taken from the
>       vCard data format [RFC6350] and extensions ([RFC6473], [RFC6474],
>       [RFC6715], [RFC6869], [RFC8605]).  The specification should add
>       new attributes or value types, or not support existing ones, where
>       appropriate.  Conversion between the data formats need not fully
>       preserve semantic meaning.
> 
> <mglt>
> I found the formulation a bit strange, especially the sentence:
> """
>  The specification should add
>       new attributes or value types, or not support existing ones, where
>       appropriate.
> """
> I am just checking I understand it correctly.
>  "not supporting ones" confused me and raised my attention as it could sound - at least to me - as SHOULD NOT support existing ones, which I do not think was the purpose. I think the specification should take most of the existing attributes. Since this is "most" it means some attributes have been left over and these are not supported. I do think this is implicit. In addition the spec adds new attributes.
> Am I correct ?
> 
> I let you decide whether the text can be clearer or not.
> </mglt>
> [...]

I now made more clear that JSContact may choose to not define equivalent properties for vCard attributes, if the vCard ones are considered to be obsolete or otherwise inappropriate.

> 
> 
> 1.3.  Type Signatures
> ...
>    *  A[] - An array of values of type A.
> 
> <mglt>
> Maybe we should have a JSON array to remain coherent with the other definition.
> </mglt>
>    *  A|B - The value is either of type A or of type B.

Done

> 1.5.3.  The pref property
> 
>    Type: UnsignedInt
> 
>    This property allows to define a preference order for contact
>    information.  For example, a card holder may have two email addresses
>    and prefer to be contacted with one of them.
> ...
> 
> <mglt>
> It seems to be more a ranking than a preference no ? I understand the higher the preference is the least it is preferred. If that is correct, I am wondering if that is common practice or if we think that could be more coherent.
> </mglt>

We chose "pref" as this matches the name of the equivalent "PREF" property in vCard.

> 
> 
> 2.2.2.  name
> [...]
> 
> <mglt>
> If I get it right the names components are ordered as the "one entering them" wishes them to be printed. This order may vary, so rank can clarifies this.
> 
> sortAs indicates how to handle these names components for sorting. However, I suspect that sorting may also depend on the culture and for example a list of participants in country A or country B will be sorted differently.
> I am wondering if that is correct or if I am missing something.
> 
> </mglt>

Correct, rank is more culture-specific and tells how same-typed name components rank within a name. sortAs defines how to sort by name component among multiple addressbook entries. As it is likely that an addressbook contains entries from multiple cultures, the sortAs property defines a generic sort. If an application wants to support multiple sorts depending on the culture of the viewer, they need to derive that by themselves.

> 
> 
> 2.3.3.  phones
> [...]
> <mglt>
> I understand "voice" is "phone" i.e a non mobile phone;-)
> </mglt>

We chose to use the exact same enumeration values like vCard. They more describe the features of a phone, e.g. any smartphone would contain the features "voice", "text", "cell", "video". Admittedly, I don't think most will bother to set all these features for a personal or business contacts, but the option is here. Maybe "cell" is a misnomer in the current time and "mobile" would be more appropriate?

> 
> 2.6.2.  directories
> [...]
>       ...
>        "directories": {
>          ...
>           "dir1": {
>             "@type": "DirectoryResource",
>             "type": "entry",
>             "uri": "http://directory.example.com/address books/jdoe/Jean%20Dupont.vcf"
>           },
>          "dir2": {
>            "@type": "DirectoryResource",
>            "type": "directory",
>            "uri": "ldap://ldap.tech.example/o=Example%20Tech,ou=Engineering",
>            "pref": 1
>          },
>       ...
>       },
>       ...
> 
> <mglt>
> There is a space in address book. I am wondering if that is not a nit.
> </mglt>

Thanks, I fixed that when I fixed the long-line errors that idnits found.

>              
> 4.2.6.  Initial Contents for the "JSContact Properties" Registry
> 
>    The following table lists the initial common usage entries of the
>    "JSContact Properties" registry.  The Since Version for all
>    properties is 1.0.  The Until Version for all properties is not set.
>    All RFC section references are for this document.  The change
>    controller for all these properties is IETF.
> 
> <mglt>
> The table is a bit too large.
> </mglt>

Do you want us to split the table? I might come up with a way to do that, but any split would be kind of arbitrary.

Regards,
Robert