Hi Andy,Taking into account that this proposal is a result of considerations on rfc9537 I think this draft takes the issue too simplified or easy, just by removing the difficult part of the problem in rfc9537.
Actually it dictates allowed methods how redaction is done by the server, practically eliminating the possibilities foreseen in rfc9537 which lead to removal of properties, objects or array elements (mainly "Redaction by Removal" and one mode of "Redaction by Replacement Value"). If you'd remove these methods from rfc9537, you'd actually fix the issues with prePath as well because prePath would never occur.
The group consensus was however that these methods exist and are in use by the servers, so not taking them into account in rfc9537 would have too much of an implication on the servers. This would result in servers still doing the same thing (ergo removing properties, objects or array elements) and not having a way to signal it.
postPath does not pose such an issue, because even if more than one path is selected it is clear which elements of the response have been redacted any why. If an overlap happens the client can display both reasons fo the redaction.
A feature that your proposal adds is a possibility to mark exactly which part of partial redaction have been replaced. It didn't appear to me as a goal for rfc9537 to have information specific to that extend, especially in an unstructured data. The clients processing such response may still mark the whole field as redacted leaving the interpretation to the user. If this feature is deemed to be important it can be still added on top of rfc953, using a method you've proposed or any other suitable mean.
Kind Regards, Pawel On 17.06.24 15:12, Andrew Newton (andy) wrote:
Hi all,I spent some time thinking about how to make the redaction problem less complex by focusing on the places where redaction is most likely to to be found, in "personal data". Within RDAP, that appears to always be conveyed in JSON strings. Reducing the scope reduces the complexity, at least in my opinion.Included is an example with the ICANN redaction policies, which are the only published redaction policies that I know of. If others are published, please send me a link and I'll see about working up an example.Anyway, I am curious what people think. -andy -------- Forwarded Message --------Subject: New Version Notification for draft-newton-regext-rdap-simple-redaction-00.txtDate: Mon, 17 Jun 2024 05:51:39 -0700 From: internet-dra...@ietf.org To: Andy Newton <a...@hxr.us> A new version of Internet-Draft draft-newton-regext-rdap-simple-redaction-00.txt has been successfully submitted by Andy Newton and posted to the IETF repository. Name: draft-newton-regext-rdap-simple-redaction Revision: 00 Title: RDAP Simple Redaction Date: 2024-06-17 Group: Individual Submission Pages: 19URL: https://www.ietf.org/archive/id/draft-newton-regext-rdap-simple-redaction-00.txt Status: https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-redaction/ HTML: https://www.ietf.org/archive/id/draft-newton-regext-rdap-simple-redaction-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-simple-redactionAbstract: This document defines a simple redaction extension for the Registration Data Access Protocol (RDAP). The IETF Secretariat _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
