Hi James,
On Mon, May 22, 2023 at 09:08:53PM +0000, Gould, James wrote:
> On 5/22/23, 8:12 AM, "Tom Harrison" <t...@apnic.net <mailto:t...@apnic.net>>
> wrote:
>> On Fri, May 19, 2023 at 12:48:11PM +0000, Gould, James wrote:
>>> 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).
>
> Based on a separate private thread with Mario, who provided the
> example expressions, it looks like the
> "$.entities[?(@.roles[0]==...)]" will match all entities with the
> role defined at position 0 of the roles array, so it doesn't need to
> be done one-by-one. A more flexible approach is to use the function
> extension, such as the non-standard indexOf function extension
> supported by jsonpath.com. The expression
> $.entities[?(@.roles.indexOf('technical')!=-1)] does match all
> entities with the "technical" role defined anywhere within the roles
> array. Jsonpath-base defines a different syntax for function
> extensions, so it could be supported by a server using something
> like $.entities[?indexOf(@.roles,'technical')!=-1]. The exact JSON
> expression to use will be up to server policy and out-of-scope for
> draft-ietf-regext-rdap-redacted. I can add clarity Section 2
> "Conventions Used in This Document" that the examples are based on
> the unredacted RDAP lookup response in Figure 11 and using snippets
> from the redacted RDAP lookup response in Figure 12. Figure 11 and
> Figure 12 can include a multi-role entity example if that helps or
> specify that the examples only cover a single-role entities. The
> prePaths are optional and are used in the examples to demonstrate
> the use of the expressions.
Specifying that the exact paths to use are out of scope and that the
examples are limited to single-role entities sounds fine to me,
thanks.
>>>> 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 term "signal" may be the wrong word, but the intention is to
> signal or indicate to the client that the "name" member has been
> redacted without the use of the path members ("prePath", "postPath",
> and "postPath"). The registration of the "redacted name" and
> "redacted reason" values are up to server policy and will be
> registered outside of the draft. I referenced the updated RDAP
> Profile that intends to register a set of "redacted name" values
> useful for the Domain Name Registries (DNRs). Let me know whether
> there is any wording that would help clarify the intention for the
> "name" member.
No, I think the existing text for the "redacted" member makes it clear
that it may contain only a "name" field, so I don't think any extra
change is needed here. Declaring the exact paths to use as being out
of scope should be sufficient to address this point as well.
-Tom
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
