Hi James,
On Fri, May 19, 2023 at 12:48:11PM +0000, Gould, James wrote:
> On Fri, May 05, 2023 at 10:36:18AM +1000, Tom Harrison wrote:
>> On Wed, May 03, 2023 at 07:50:07PM +0000, Gould, James wrote:
>>> In relation to the example JSONPath in the draft, they are based
>>> on the unredacted RDAP lookup response in Figure 11 and are
>>> snippets from the redacted RDAP lookup response in Figure 12. They
>>> are not intended to provide an example for a broader set of
>>> unredacted RDAP responses, such as having multiple entities with
>>> the same role.
>>
>> Right, but section 3.1 has:
>>
>> An example of redacting an RDAP object is removing the
>> administrative contact from the RDAP response and including the
>> following "redacted" member:
>>
>> "redacted": [
>> {
>> "name": {
>> "type": "Administrative Contact"
>> },
>> "prePath": "$.entities[?(@.roles[0]=='administrative')]",
>> "method": "removal"
>> }
>> ]
>>
>> i.e., it's presented as being of general application, and it's not
>> until much later in the document that the caveats around multiple
>> roles are noted (in section 5.2). The obvious fix is to note in the
>> text that the examples assume single-role entities, but even with that
>> approach there's no way for a client to know that a server will
>> include only single-role entities, and if the client doesn't know
>> that, then they are left with the (incorrect) inference from my
>> previous mail (that entities where the first role in the array is
>> administrative have been removed). Removing the prePath in this sort
>> of case addresses the problem.
>
> For background, the considerations associated with multiple roles
> were added to section 5.2, based on the multiple role discussion
> that happened on the mailing list. How about providing a note in
> Section 2 "Conventions Used in This Document" associated with the
> approach taken with the examples (e.g., based on unredacted RDAP
> lookup response in Figure 11 and using snippets from the redacted
> RDAP lookup response in Figure 12) and the use of single-role
> entities? The note could read:
>
> The examples are based on the unredacted RDAP lookup response in
> Figure 11 and use snippets from the redacted RDAP lookup response in
> Figure 12, which use single-role entities.
The problem with this (which I could have made clearer in my last
mail, sorry) is that the examples don't show how a client can
distinguish (in-band) a server that limits each entity to a single
role and a server that permits each entity to have multiple roles. If
it isn't communicated in-band, then clients are stuck with the
incorrect inference from the path. Some potential options:
- Embed this aspect of server policy in the "name"."description" text
for the relevant "redacted" entries.
- Declare in the document than any prePath with the form
"$.entities[?(@.roles[0]==...)]" means that the server will always
include at most one entry in the associated "roles" list. (Servers
using multiple-role entities have no reason to include a path like
this, as best as I can tell.)
- Add some sort of flag (e.g. to the "/help" response) indicating
that entities returned by this server will only ever contain one
role.
- The suggestion from the previous mail (i.e. remove the prePaths
that have this form).
>>> This JSONPath would not comply with draft-ietf-jsonpath-base. You
>>> can use the guidance provided by including multiple “redacted”
>>> member fields with JSONPath entries (“prePath” or “postPath” ) or
>>> decide not to use the JSONPath (“prePath” or “postPath” ) and signal
>>> it with a registered “name” child member, such as:
>>>
>>> "redacted": [
>>> {
>>> "name": {
>>> "type": "Administrative Contact"
>>> },
>>> "method": "removal"
>>> }
>>> ]
>>
>> Signalling via "name" exclusively is sensible, but if that's the
>> approach that has to be used for multiple-role entities, and it works
>> for single-role entities as well, and it would avoid the problem with
>> the ambiguous prePath, why not update the examples to use this
>> approach? Assuming that the document registers the associated types,
>> this would also increase implementation consistency, which will make
>> things easier on clients. (Even if the signalling is unregistered,
>> and relies on "description", it at least puts the client on notice
>> that if they want to understand what's happening more precisely,
>> they'll need to get that information out of band.)
>
> The examples do include the required "name" member, where the
> "prePath" member is included to provide a concrete example of use of
> the expression. The "name" member is required, and a note can be
> added that it can serve as the redaction signal. Would that help?
I'm not sure what "it can serve as the redaction signal" means here.
Assuming that this is about adding text that makes it clearer that the
"name" member alone is sufficient to indicate the field that's being
redacted, then I don't think that will help, because the problem with
ambiguous prePaths will still be present. (Putting aside the
possibility of embedding this aspect of server policy into the
"name"."description" text, per the earlier suggestion.)
> The JSON expression members "prePath", "postPath", and
> "replacementPath" are optional, where the examples are meant to
> demonstrate their usage. The intent of the extension is to provide
> the framework to support registration of the "redacted name" values
> in the JSON Values Registry and not to attempt to define a set of
> values that needs to consider server policy.
>
>>>> - Section 5.2 at point 4 has:
>>>>
>>>> When an entity has multiple roles, include "redacted" members for
>>>> each role using the role index. This will result in duplicate
>>>> "redacted" members, but will enable the client to treat redaction
>>>> consistently when there is a single role per entity or multiple
>>>> roles per entity.
>>>>
>>>> It's not clear why this advice is present, when compared with
>>>> e.g. having the redacted members be a mapping from the server's
>>>> policies. For example, if the policy is that administrative
>>>> contacts not be returned, then a single "redacted" entry with a
>>>> prePath like "$.entities[?(@.roles[*]=='administrative')]"
>>>> clearly conveys that message to the client, and the client will
>>>> understand that those entities will be removed regardless of any
>>>> additional roles that they might have. How do multiple redacted
>>>> members enable the client to treat redaction consistently?
>>>
>>> I believe for your case, it may be better to signal using the
>>> “name” field only, such as “Administrative Contact”. The JSONPath
>>> expression that you’re referencing is not valid, so it’s not an
>>> option.
>>
>> Using "name" makes sense, but it's still not clear to me why
>> including "redacted" members for each role would be useful in the
>> multiple-role case. Is this specifically about situations where
>> the server policy is such that e.g. both administrative and
>> registrant role entities are redacted?
>
> My experience is with single-role entities, so please let me know
> how you would like to see it. I imagine that if an entity had
> multiple roles and you had a per-role redaction policy that the
> result would be based on the most restrictive role. For example, if
> the policy is that you remove the "Administrative Contact" from the
> response and you only remove the "Technical Contact Name" for a
> "Technical Contact", that for a contact with is both
> "Administrative" and "Technical" roles, the server would follow the
> "Administrative Contact" rule and signal that the "Administrative
> Contact" was redacted. You could choose to also indicate that the
> "Technical Contact" was redacted as well, since it was redacted due
> to inclusion of a more-restrictive role. This could be handled by
> inclusion of a reason like "Due to Administrative Contact role" for
> the "Technical Contact" entry, which could be registered.
OK, I think I understand what is intended here now. I interpreted
point 4 as meaning that multiple redacted entries should be included
whenever an entity has multiple roles and part of the entity is being
redacted for some reason. What you have above sounds like a
higher-level statement about instances where content can be redacted
for multiple different reasons. Rather than limiting this to the
multiple-role case, I'd suggest removing point 4 and replacing it with
the following (basically an adaptation of your comment):
It is possible for there to be multiple bases for the redaction of
certain content. For example, if server policy is such that all
administrative-role entities are redacted and all technical-role
entities are redacted, then an entity having both the
administrative role and the technical role could be redacted for
two different reasons. In this situation, a server is required to
include at least one "redacted" entry, but should consider
including a separate "redacted" entry for each applicable basis
for redaction, so as to clearly document the server policies that
are relevant to redaction in each instance.
-Tom
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
