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
- [calsify] Working Group Last call for jscontact d… Daniel Migault
- Re: [calsify] Working Group Last call for jsconta… Robert Stepanek
- Re: [calsify] Working Group Last call for jsconta… Ken Murchison
- Re: [calsify] Working Group Last call for jsconta… Neil Jenkins
- Re: [calsify] Working Group Last call for jsconta… Robert Stepanek
- Re: [calsify] Working Group Last call for jsconta… Joris Baum
- Re: [calsify] Working Group Last call for jsconta… Robert Stepanek
- Re: [calsify] Working Group Last call for jsconta… Robert Stepanek
- Re: [calsify] Working Group Last call for jsconta… Daniel Migault
- Re: [calsify] Working Group Last call for jsconta… Robert Stepanek
- Re: [calsify] Working Group Last call for jsconta… Daniel Migault
- Re: [calsify] Working Group Last call for jsconta… Joris Baum
- Re: [calsify] Working Group Last call for jsconta… Robert Stepanek
- Re: [calsify] Working Group Last call for jsconta… Daniel Migault
- Re: [calsify] Working Group Last call for jsconta… Daniel Migault
- Re: [calsify] Working Group Last call for jsconta… Robert Stepanek
- Re: [calsify] Working Group Last call for jsconta… Mario Loffredo
- Re: [calsify] Working Group Last call for jsconta… Daniel Migault
- Re: [calsify] Working Group Last call for jsconta… Robert Stepanek
- Re: [calsify] Working Group Last call for jsconta… Daniel Migault