Mario, This is the disadvantage of leveraging an existing set of contact drafts / RFCs to satisfy the needs for contacts and entities in RDAP, whether it's jCard / vCard or JSContact. The contact drafts / RFCs meet similar requirements but not the same requirements. The "uid" field of JSContact is a simple example of where it makes sense for the JSContact requirements to have a mandatory identifier that can be used to reference associations, but it doesn't make sense for RDAP where there is already an identifier represented by the "handle" jCard field and the contact ROID in EPP that needs to support redaction. This means that it can't be made mandatory for RDAP. If JSContact defines a new required identifier in the form of a UUID then the provisioning system needs to generate a new identifier just for displaying it in RDAP via JSContact or the RDAP server needs to create a useless random identifier with every response. .
You and Robert as JSContact co-authors need to consider the broader use of the draft for defining a required field. Why not make the JSContact draft more flexible to the broader set of uses and provide guidance for the known or the primary use case? I believe the JSContact "uid" field needs to be made optional (SHOULD would suffice) to cover both the primary use case of JSContact and the RDAP use case of JSContact. If that can't be done, then JSContact may be the wrong JSON draft to use for RDAP contacts and entities. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 1/10/23, 4:39 AM, "regext on behalf of Mario Loffredo" <regext-boun...@ietf.org on behalf of 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://secure-web.cisco.com/1cW2bwBl1PqzlMj4vTY6NPM8O3TZCXC29EvSNIDFCybWQ-NtuvoucubH4xMDsonvDLKz6O3xsoAuUY6nISvmqiBJYbIzbp1sJ5VjNOlB_LDfC3srT477prJilklA33IJpdAADl9mW_dB-yM33bG0mW_GAJtwEhEl0xnaKo5zx0mWAtw2X9P99sNzUyaE3TCllLSfw2J4Ra4f5-KFdN3cr8YzlbjSiFTJ0s8Ta3EJtuJxJQVdIc87iSlRKWKv-unUPkqGN7JCpjGn2mcBZOlbIGU5T6kboOr4pRegSGwnbK_M/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext -- 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://secure-web.cisco.com/1d9psFegQEtnqWWaW6UV2nyIORXVHRL2oQP6D4eDukQfk7jT9gVHOD9P2mTd6qcWQSAlBrJpXJMSKERpyqOqWbQvefNEpR9OfkPJ8sp0HgtyzwFiTuzSAey_Q68yID_ndl49iKdnIP7bFLDh_XtOBt9DqBbfbmn18s8qb4gIhmKYhFymAJ5rfcSe2Ul9Q38U9v09SZBVhYmGikEELBkCRqHt-frSOZ5Bua9gR2y_QWrAFLK5HrBUKeanJioUGGqS7g9nswK9tOBZKKTLfSjuvLbQsENJmWIc-QNWBkyq7ahw/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/1cW2bwBl1PqzlMj4vTY6NPM8O3TZCXC29EvSNIDFCybWQ-NtuvoucubH4xMDsonvDLKz6O3xsoAuUY6nISvmqiBJYbIzbp1sJ5VjNOlB_LDfC3srT477prJilklA33IJpdAADl9mW_dB-yM33bG0mW_GAJtwEhEl0xnaKo5zx0mWAtw2X9P99sNzUyaE3TCllLSfw2J4Ra4f5-KFdN3cr8YzlbjSiFTJ0s8Ta3EJtuJxJQVdIc87iSlRKWKv-unUPkqGN7JCpjGn2mcBZOlbIGU5T6kboOr4pRegSGwnbK_M/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
