IETF Logo Mail Archive

Re: [calsify] JSContact in RDAP

Doug Royer <douglasroyer@gmail.com> Thu, 19 January 2023 22:22 UTC

Return-Path: <douglasroyer@gmail.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 546A0C14F720 for <calsify@ietfa.amsl.com>; Thu, 19 Jan 2023 14:22:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.094
X-Spam-Level:
X-Spam-Status: No, score=-1.094 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, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 jdHbub3ZYfS6 for <calsify@ietfa.amsl.com>; Thu, 19 Jan 2023 14:22:39 -0800 (PST)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 7DDADC14EAA3 for <calsify@ietf.org>; Thu, 19 Jan 2023 14:22:39 -0800 (PST)
Received: by mail-pl1-x636.google.com with SMTP id p24so3639690plw.11 for <calsify@ietf.org>; Thu, 19 Jan 2023 14:22:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:organization:references:to:content-language:subject :user-agent:mime-version:date:message-id:from:from:to:cc:subject :date:message-id:reply-to; bh=GOYjL1tgt4qtA8DD5qAF9GXYumz9Ocl0ntZgcsuNAc0=; b=FyRWNOt57ZSXav7I3Hp8pgMP3ErvSdxtEIbhNgtxKuNgTUAll5yqqfwMOR6xuU+hAR f1f2YcdlaQr6aX1CpOHiGj2tIaritogpfW2lasLAd9Nh871Aih3s36yzSK0j8s8XZ8Qc uTojQD+aONTVXTIYAoZAbcQEUeTHYDFJE/TZ0Ie1oFmgspGBPt2/63P6/xFGZ/RYA0OF KsP4qZ+jD0t/acBpnMiKJgUZjns7buJRVhW53qB802ckYfVO+BmnVuC8UJK8UaS6+W9l rqWxLHRMw/+Miihw76dAOFNJHZQKHnkwPMxgNnTbaDPxkRlStYv1ZYNzv713EnhZWvBN 2wUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:organization:references:to:content-language:subject :user-agent:mime-version:date:message-id:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=GOYjL1tgt4qtA8DD5qAF9GXYumz9Ocl0ntZgcsuNAc0=; b=QvXrAerbujwlfbiyOH0uEWXBE62rzy2tj5Zh9JUfdayK8hY1GKGuYf4I6clLAqXcjG FFPVl3rla4QOIlqOALaWbTrNM/cVq8UIzf+HSHVXXG0+CxUhKshGE+hJ7o2EDBHl9QHU Hyc80inRovAxHabCVxTavcDzbY1ngJsTTM34qNVYTsc8QRA3GkXofi/oKxB8qNvGnWVi 8xmQkGT/Hjs+jrtgygOcAZgINdloDMOvk1XwZupAz6rkqEblNOe3dcGdES02esyNRVpx 7biGOijy3p4LjsuRqLK3O0ymFT4dp0kERVM3Gu/zEHF8QeEBwWzLdraSdJOecqCU/5/g 8Oag==
X-Gm-Message-State: AFqh2krgA6EwBwCmTSRsKVznw18DR5rLvdYXWy++JUi+w0BRSuNqePbK xaVBbpb8UpDdA9Kt1vY/Vuta0MVrWHwJ+zHC5w==
X-Google-Smtp-Source: AMrXdXsEdIY8HSowh6KlXn9rbQ5YBccMNiie7SFiPCXEz3XUgg3MttYlPd9YmJePbpMALOWKBXFydQ==
X-Received: by 2002:a17:902:7b98:b0:18f:a447:2254 with SMTP id w24-20020a1709027b9800b0018fa4472254mr12239334pll.64.1674166957786; Thu, 19 Jan 2023 14:22:37 -0800 (PST)
Received: from [192.168.1.7] ([152.37.203.142]) by smtp.googlemail.com with ESMTPSA id jg20-20020a17090326d400b00194799b084esm11324477plb.10.2023.01.19.14.22.36 for <calsify@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Jan 2023 14:22:36 -0800 (PST)
From: Doug Royer <douglasroyer@gmail.com>
X-Google-Original-From: Doug Royer <DouglasRoyer@gmail.com>
Message-ID: <149b80cb-2681-2e25-e04a-a03eb0b606e6@gmail.com>
Date: Thu, 19 Jan 2023 14:22:34 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.6.0
Content-Language: en-US
To: calsify@ietf.org
References: <c0a301d7-92ac-3831-3db5-0f947fafc603@iit.cnr.it>
Organization: http://SoftwareAndServices.NET
In-Reply-To: <c0a301d7-92ac-3831-3db5-0f947fafc603@iit.cnr.it>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070503030404010107000201"
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/xB07pmPUpeGeWarT-bE5eG7ZjBE>
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: Thu, 19 Jan 2023 22:22:43 -0000

Is not the UID also used to cross references to other objects?
Removing it would break associations between objects, like 'members'?

It has been a while since I did a deep dive into all of this.

On 1/13/23 10:05, Mario Loffredo wrote:
>
> Hi folks,
>
> while discussing draft-ietf-regext-rdap-jscontact <https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/> at RegExt, we came across an issue related to the mandatory constraint on the uid property when JSContact is used in RDAP.
>
> To avoid correlation of contacts associated with domains across RDAP domain query responses, the uid property could be redacted by the RDAP server. The possible redaction methods are defined in another draft currently under discussion at RegExt, namely draft-ietf-regext-rdap-redacted <https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/>.
>
> The preferrable redaction method would be the uid removal but, unfortunately, it doesn't comply with the mandatory constraint on uid.
>
> I have proposed some alternatives to work around this issue (e.g. using randomly generated UUIDs at every response or setting the uid to an empty string since the free-text format is allowed). Nevertheless, I must agree that it would be better if the uid property was optional in RDAP.
>
> I strongly apologize if I didn't introduce the matter earlier but this is the time I'm finalizing rdap-jscontact for the WGLC and only now some RegExt members asked me as JSContact co-author for seeking a possible way to make uid optional in RDAP.
>
> For example, would it make sense to state in JSContact spec that the mandatory constraint on uid can be overriden when JSContact is used within other specifications?
>
> Best,
>
> Mario
>
>
> -- 
> Dott. Mario Loffredo
> Technological Unit “Digital Innovation”
> Institute of Informatics and Telematics (IIT)
> National Research Council (CNR)
> via G. Moruzzi 1, I-56124 PISA, Italy
> Phone: +39.0503153497
> Web:http://www.iit.cnr.it/mario.loffredo
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify


-- 
Doug Royer - ¯\_(ツ)_/¯ (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135

v2.23.0 | Report a Bug | By Email