On Tue, Jul 11, 2023 at 8:44 AM Mario Loffredo <mario.loffr...@iit.cnr.it> wrote:
> > * In Sections 12.2.3.2 and 12.2.4.2, the individual entries are run > together into one big blob. Could we get blank lines between them, or > maybe put each in its own subsection if necessary? Or make it a table? > > [ML] I know that the layout is redundant and not compact at all but it's > the only one making the JSONPath expressions quite readable. > > I can move the fileds assuming always the same value (e.g. "Related > Resource Type", "Registrant Name" and "Registrant Information") at the > beginning so that each group of properties related to an entry in the IANA > registry gets shorter. > > Does it work for you ? > Looks like you could put each of the four registrations in its own subsection to nail this down. But what's weird is that if I view it here: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-reverse-search-22 ...it's all mashed together, but when I view it here: https://www.ietf.org/archive/id/draft-ietf-regext-rdap-reverse-search-22.html ...it looks fine. Let's just leave it for now (unless you like the subsections idea) and ask the RFC Editor to help with formatting. It may become an issue earlier if IANA finds it confusing. > * In Section 13, we have a "REQUIRED" followed by some non-specific advice > about what to implement. This doesn't seem like a good use of BCP 14 key > words. Can we say it some other way? > > [ML] Would it be better to use "SHOULD" instead of "are REQUIRED to" ? > I would change "are REQUIRED" to "need". The problem I have is that saying "you are REQUIRED to assure privacy" doesn't tell the implementer exactly what needs to happen to interoperate or assure privacy, so being able to specify what it will take to comply isn't possible. It's like the difference between saying "you MUST make sure your data are secured somehow" versus "you MUST use TLS 1.3"; it's easy to prove compliance with one of those, but not the other. > > * Section 3 should probably specify what should happen if the JSONpath > refers to an attribute/value that's not present in the object it's > referencing. > > [ML] The JSONPath expressions related to reverse search properties are > provided by servers and have been previously registered with IANA, hence > they have been checked by Designated Experts. It's very unlikely they are > wrong. Can't imagine how clients can operate when servers provide wrong > information. I mean, servers can return an error code when clients include > wrong or unsupported reverse search properties in thei requests, but > servers are always expected to provide correct data. > It just feels strange to presume you will always have valid input and never discuss error condition handling. I'm still learning about JSONpath (it's also in "AD Evaluation") so maybe this is a teachable moment for me, but it seems like there's a presumption that a query will always be run against a value that will resolve; is that the case here too? Maybe we should say that if so. -MSK
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
