Hi Mario,
Sure, this would not change anything in context of Marc's concerns. If
uid would be optional/missing, still no option to do cache management on
client side without deep compare. Maybe this is in the end the only
reliable option for the client and we have to live with that in the
world of redacted data.
Kind Regards,
Pawel
Am 17.01.23 um 08:12 schrieb Mario Loffredo:
Hi Marc, Pawel and others,
as you may have known, I have asked CalExt for defining in JSContact
spec possible conditions where uid can be optional, for example the
use of JSContact in another protocol.
Let's wait for a response and then we'll be able to make a definitive
proposal about this matter.
Meantime, thanks everyone who has joined the discussion thus far.
Best,
Mario
Il 16/01/2023 23:33, Marc Blanchet ha scritto:
Le 16 janv. 2023 à 16:18, Pawel Kowalik <kowa...@denic.de> a écrit :
Hi Marc,
Comment below
Am 16.01.23 um 16:49 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.
[PK] I think the statement is not fully true. All http-based
strategies for caching will remain available, as long as the server
operator would not exclude caching on purpose by setting appropriate
http headers. The server operator would have to balance out the
privacy policy vs. the strategies of uid redaction and the
implications on the server performance. I think it is a fair deal if
this decisions are left out to the server operator rather than
arbitrarily deciding it on the protocol level.
If the object is in a CDN (with id=1), then the client make the
request and then either get the CDN cached object (which we don’t
want per definition of a new id every time) or the CDN go get another
version from the server because cached data has expired and therefore
the server is queried. To properly serve an object whose internal id
change every time, one must set the expire to always expire (i.e.
no-cache), which means cache are not useful.
Marc.
One consideration we may think of, is whether there is (enough)
value for the server to inform the client (by the mean of specific
new redaction methods) whether the redacted uid is random each time,
or it's random but stable for a given entity in the same context, or
it's redacted with a static value and always the same for all
entities. It may serve a benefit for the clients and their caching /
object management strategies, but adds certain complexity to the
protocol.
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
