Hi Andy,
Il 10/01/2023 16:38, Andrew Newton ha scritto:
What's the purpose of being more restrictive than the base spec? I'd
rather keep that flexibility.
Thanks for your suggestion. Yes, defintively it's much better to follow
the spec as is.
Best,
Mario
-andy
On Tue, Jan 10, 2023 at 4:39 AM Mario Loffredo
<mario.loffr...@iit.cnr.it> wrote:
Hi folks,
have discussed with Robert (the other JSContact co-author) about whether
to make uid optional in JSContact.
We have finally agreed that we need to keep it mandatory because, in
calext context, it's a fundamental requirement to identify the same
contact across different systems. In addition, the uid property is used
in other JSContact properties to represent associations between contacts
(i.e. the membership to a group and many other relationship types).
We have also agreed that, as Scott has pointed out, overriding that
constraint in rdap-jscontact would make the spec inconsistent and hard
to be implemented by libraries (including jscontact-tools itself).
Under these assumptions, the proposal I presented as Option 2 in my last
reply to James makes the uid value unlinked to the handle value.
The uid MUST be an URN in the UUID namespace and, as such, would be
inherently opaque.
To prevent from contacts correlation through the uid value, a possible
solution could consist in changing a bit the Option 2 by allowing other
UUID formats in addition to name-based (SHA-1) UUIDs, including randomly
generated (a.k.a v4) UUIDs.
A UUID randomly generated at every response would save the contact from
being correlated across the responses.
Depending on its redaction policy, an RDAP server would be free to
provide UUIDs according to a given version (see RFC4122 and, its
revision, rfc4122bis).
Please let me know if it could work and evaluate as well if it would
imply the definition of a new redaction method (e.g. randomValue) that
might be used to redact mandatory properties with a fixed format.
With regard to the representation of the street information, we have
decided to add text in the mapping document clarifying that the
StreetComponent "name" must be used when the street components cannot be
represented separately.
This would save us from defining an ad-hoc JSContact extension to
address the case of the street address stored as a single value.
Since something similar already happens when converting the RFC5733
"street" element into the pair of VCard ADR components <"street
address","extended address">, I wouldn't expect any particular objection
on this way to proceed.
Looking foward to your feedback.
Best,
Mario
Il 09/01/2023 18:26, Hollenbeck, Scott ha scritto:
-----Original Message-----
From: regext <regext-boun...@ietf.org> On Behalf Of Gould, James
Sent: Monday, January 9, 2023 12:08 PM
To: a...@hxr.us
Cc: mario.loffr...@iit.cnr.it; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] RDAP queries based on redacted properties
Caution: This email originated from outside the organization. Do not click
links
or open attachments unless you recognize the sender and know the content is
safe.
I'm getting a little confused, where the ability to redact a field like the
mandatory "uid" field in draft-ietf-calext-jscontact and indirectly in
draft-ietf-
regext-rdap-jscontact is needed for privacy reasons. It is up to server
policy
related to whether to include the "uid" field in the domain response, entity
query, and entity response, which should not be dictated by the protocol.
The
base specification or specifications need to be less strict on the
definition of a
field such as the "uid" field to support the use of those specifications
downstream. In this case, RDAP is the downstream protocol that needs to
support redaction of the "uid" field, since it's defined as being the same
as the
"handle" field of jCard. My recommendation is to make the "uid" a SHOULD or
MAY in draft-ietf-calext-jscontact that doesn't seem desired by CALEXT or
have
draft-ietf-regext-rdap-jscontact override it to make it optional in RDAP to
support the known redaction use case.
[SAH] If draft-ietf-calext-jscontact is a normative reference for
draft-ietf-regext-rdap-jscontact, and the "uid" property is mandatory in
draft-ietf-calext-jscontact, an override is going to be a problem. It'll make
things difficult for any library that implements JSContact because the specs
will be inconsistent. Has there been push-back from calext on the idea of
making the uid OPTIONAL?
Scott
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
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
--
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
