Tom, Thanks for all your feedback. I'll be making the edits based on the feedback received and posting draft-ietf-regext-rdap-redacted-12 tomorrow or Thursday.
Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 5/22/23, 7:07 PM, "Tom Harrison" <t...@apnic.net <mailto:t...@apnic.net>> wrote: 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> > <mailto: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
