> Le 16 janv. 2023 à 10:43, Pawel Kowalik <kowa...@denic.de> a écrit : > > Hi, > > My comment below. > > Am 11.01.23 um 19:03 schrieb Marc Blanchet: >> >>> Le 11 janv. 2023 à 12:43, Gould, James >>> <jgould=40verisign....@dmarc.ietf.org> a écrit : >>> >>> Mario, >>> >>> I'm assuming that JSContact will define an expected format for the "uid" >>> field that we must comply with in RDAP, which is not needed for RDAPs use >>> case. Use of redaction by empty value would not be compliant with the >>> potential format language. The difference between jCard and JSContact is >>> that jCard was already an RFC when RDAP was being created, where JSContact >>> is currently an Internet Draft. You are aware of the need to redact the >>> "uid" field for the RDAP use case, so why not make the "uid" optional in >>> JSContact to make it meet the broader use case of RDAP with some potential >>> caveats (e.g., the "uid" MUST be set when there is the need for >>> discovering, comparing, or synchronizing contact cards)? RDAP doesn't >>> have those needs, so the inclusion of the "uid" can be optional and used >>> where it makes sense, such as returning in an entity query response. The >>> "uid" could match the "handle" and be redacted in the domain query response. >> My 2 cents. an object shall have a mandatory unique identifier. I think we >> are going way too far by removing a unique (random) object identifier for >> the purpose of privacy. A UID/UUID does not provide any privacy related >> info. I’m aware of the cross references, but I just think we are going way >> too far. I would vote for keeping the UID as mandatory, since for an >> implementer perspective, I can keep this object and its UID, put it in a >> database and know when I have an updated version of that object because the >> UID is unique and mandatory. Without UID, all objects are different, and >> this is no fun to correlate: I would potentially have multiple copies of the >> same object without being able to flush them out, unless a do a full deep >> comparison, which does not make any sense. > > I think we would be going too far if the technical / protocol decision would > implicitly narrow down privacy policy options of the registry. > > If this is mandatory for the data structure to contain uid, that's fine. One > of the rules in this draft was not to break data formats by the redaction. > This can be achieved by replacing the real uid with a generated and > privacy-preserving one, as raised already in some of the proposals. It should > be properly signaled, same as for any other redaction taking place. The > client applications basically shall not rely on identifiers, which have been > redacted. > > It may be a valid point to expect RDAP server to always deliver the same > response to the same query, which would imply the same entity delivering the > same redacted uid in the same query context, instead of fully random uids. I > assume however that even that may be too much from privacy policy perspective > of some registries, therefore IMHO the specification shall allow for such > radical redaction and the client applications have to be able to deal with it.
Okay, but then, we are essentially disabling any kind of caching if the uid is always different and random at each query for the same object. That would have an impact on the servers, as clients will always query the servers, and the server operators won’t be able to use caching services to help manage trafic. Sad for an object that is so “cachable” as it otherwise does not change frequently. Marc. > > Kind Regards, > > Pawel > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
