What's the purpose of being more restrictive than the base spec? I'd rather keep that flexibility.
-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 > _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
