Re: [calsify] JSContact in RDAP

Robert Stepanek <rsto@fastmailteam.com> Tue, 17 January 2023 16:46 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 EA8F6C1524D9 for <calsify@ietfa.amsl.com>; Tue, 17 Jan 2023 08:46:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 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_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="niskq5WM"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="iAGmd6/J"
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 nD1dDOsRGoqG for <calsify@ietfa.amsl.com>; Tue, 17 Jan 2023 08:46:35 -0800 (PST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (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 255EDC1524D7 for <calsify@ietf.org>; Tue, 17 Jan 2023 08:46:34 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id DAF63320029B for <calsify@ietf.org>; Tue, 17 Jan 2023 11:46:33 -0500 (EST)
Received: from imap43 ([10.202.2.93]) by compute3.internal (MEProxy); Tue, 17 Jan 2023 11:46:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=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=1673973993; x= 1674060393; bh=2nsNIiUPzv48nsPGNMVaP7ueHuwRfW8m/Rqd2ESwwwI=; b=n iskq5WMzqqxBcylilz4J3FNHIHJv7UwD8zC540Q8RgVjjYe5rdT5EroIu21ekXQA LBBgdGJMv/ncd2s1FgVHfWUHqColDW8371qs7t16xO385skjJCnepFekPLcab3nR EIOdhtdWufyXNHQg/DF0rJJWcQAPZCygT4cOsmkE4qRjitkhPwUwVEJ1iCYgCzgF bUkSDdujRF92e6OUMKDaxzrZL7W8LeLiQOEuo/YYwIQ5mSbtJQd0gPYGedVTVQpM 5DKYpNZpSKnrB6vxtB1UuKyDuqd30cBM26NLbFIr/uhHEFEVp8ofcVCOswVfndNF fIDaqqgVywbPe1BhmcwQA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=1673973993; x=1674060393; bh=2nsNIiUPzv48nsPGNMVaP7ueHuwR fW8m/Rqd2ESwwwI=; b=iAGmd6/JSjsHJa+APDUWGOmmwPNQ7zHe/W/vh9aT/djb JUZPpnIqhQ6Rqvgrx3I/SDx/mQBY6vHkxHbXiv4fwhQsQTcjA5FFJKjF7+9Hz9d/ qieasgPk87Pgbi3dVZV0CegPTYw1UZuqED9v4Hek4JMxjhBkNc8oLJdjXnF4/GbJ whHzV3Z7p/GeWP5nOpt1Im3sWelwyqB2nm9vUP7ZyEFw61g08N0/5QHY4P1OW7bW mNYSURWNaNr3wqNxL29fvH2t4u/X5maogpQgp4TBvYaO48l36Iwdj7FiYerhVG9d +EedXRiKeYeCkGLcfhy3GqBO2TX4dJ0xYDxldgpTgg==
X-ME-Sender: <xms:6dDGY-jlholM-wW5-hfmXnGVaZbd8WAL6KS1dGQRslaDkVNx6B4e3Q> <xme:6dDGY_Bv1CruJP7iOvBKIuL9KRipUo2rLcemkCH6fP1lL9l-fGBKky5VAjmPoHc3w ehggj8Et3pS4g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddtiedgleduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepheeguedvtd ekhfetgfeufefgvdeuteegfeefleehvddugeejjefhteeugfevveeinecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrg hilhhtvggrmhdrtghomh
X-ME-Proxy: <xmx:6dDGY2GhpWE0DcRyzH3k_-oOI0Nkj_IZvnHaLHvPSFKC1pU6diyx5g> <xmx:6dDGY3RI0opKU1f_unU_vNMrnKbXI_QDJ-cpTTfJcBvdivxTUM_Sqw> <xmx:6dDGY7zV1Kdp5l2HJHie1uk_ImA372f4ZjLVxaWgZw30zSUdoVuwCg> <xmx:6dDGY68lB2INEg2oPjY9Si_usToQ1Ke1OdAIvh1diPE9nHy7Kk5lcA>
Feedback-ID: ia5d944da:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 41E8D2D403FD; Tue, 17 Jan 2023 11:46:33 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-85-gd6d859e0cf-fm-20230116.001-gd6d859e0
Mime-Version: 1.0
Message-Id: <29f45ad9-8daa-42ca-bbcb-157b7c734f9e@app.fastmail.com>
In-Reply-To: <ed8cd750-88da-fa1e-a6ff-487590011d77@iit.cnr.it>
References: <c0a301d7-92ac-3831-3db5-0f947fafc603@iit.cnr.it> <6660d1f8-29f8-45e1-adfd-08ca960f7666@app.fastmail.com> <ed8cd750-88da-fa1e-a6ff-487590011d77@iit.cnr.it>
Date: Tue, 17 Jan 2023 17:46:12 +0100
From: Robert Stepanek <rsto@fastmailteam.com>
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary="27d0f501be9a4208810b5ebc5bc3a66d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/gLBQ9ILvc40jTwZ3gpKg8-OOvrw>
Subject: Re: [calsify] JSContact in RDAP
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, 17 Jan 2023 16:46:40 -0000

On Tue, Jan 17, 2023, at 3:31 PM, Mario Loffredo wrote:
> Il 17/01/2023 09:59, Robert Stepanek ha scritto:
>> 
>> On Fri, Jan 13, 2023, at 7:05 PM, Mario Loffredo wrote:
>> 
>> Is the only goal to not allow correlating JSContact objects by uid? If so, I do not understand why a random uuid4 per request does not resolve that issue. Or is it also important to signal to the recipient that the uid property value is redacted? In that case, how about setting the nil uuid (all bits set to zero)?
> Based on what is described in draft-ietf-regext-rdap-redacted, the RDAP server signals the client about the redacted response fields by including them in the "redacted" array.
> 

Thanks, that explains it better to me. In this case I think it is reasonable that the RDAP spec allows to omit mandatory properties, including "uid". The "redacted" array signals to the recipient that this is a partial JSContact object anyway. Only if the JSContact object is supposed to be complete, then omitting the "uid" would be invalid.

I say we keep "uid" mandatory in the JSContact spec, unless someone *now* tells about any other use case where this is not appropriate.