Thank you Jim Gould, and everyone for bringing this to closure. This WGLC is now closed.
In order to move this document forward the Chairs will need the document shepherd (Gustavo Ibarra) to indicate on the list if all issues have been addressed when v12 is published. The Chairs will also need Tom Harrison and Andy Newton to indicate on the list if their questions have been satisfactorily addressed. And, of course, the document shepherd will need to prepare the usual writeup. Thanks again to all! Antoin and Jim On 23 May 2023, at 7:47, Gould, James wrote: > 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 > [email protected] > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > > On 5/22/23, 7:07 PM, "Tom Harrison" <[email protected] <mailto:[email protected]>> > 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" <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
