Hi Murray,
thanks for your reply.
Please find my responses inline.
Il 25/07/2023 22:49, Murray S. Kucherawy ha scritto:
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.
[ML] Hope I made it more readable. Let's how it will be rendered. I
checked the layout in TXT, HTML and PDF and looks good to me.
* 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.
[ML] Agreed.
* 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.
[ML] Probably I didn't make myself clear or I still don't catch your
remark. The JSONPath expressions are provided by servers to help clients
in linking the available reverse search properties to the reponse
fields. Client can only use the reverse search properties in their
queries. The invalid use of both reverse search poperties and predicates
by clients results in servers returning an error as defined in Section 7:
*
*
*Servers MUST return an HTTP 501 (Not Implemented) **[RFC9110
<https://author-tools.ietf.org/api/export/be29d181-e21a-48ce-afdb-d5731c79c81c/draft-ietf-regext-rdap-reverse-search-23.html#RFC9110>]**response
to inform clients of unsupported reverse searches.*
*Based on their policy, servers MAY restrict how predicates are used to
make a valid search condition, by returning a 400 (Bad Request) response
when a problematic request is received.*
Obviously, it can happen that a server returns an either wrong or
unmatched JSONPath expression in the reverse_search_properties_mapping
member. In this case, think there are two options for the client:
1) The JSONPath expression is wrong but the related reverse search
property works (e.g. the propertyPath value for the "email" reverse
search property is "$.entities[*].vcardArray[1][?(@[0]=='email')][*2*]"
instead of "$.entities[*].vcardArray[1][?(@[0]=='email')][*3*]"). The
server will return a valid response. If a client will discover the
mistake in JSONPath expression, the server will be informed about it in
an out-of-band communication.
2) The JSONPath expression is supposedly correct but the related reverse
search property doesn't match a response field (e.g. the response field
is redacted). In this case, the servers shouldn't have put the reverse
search property in the reverse_search_properties_mapping array and the
client is supposed to receive an error as defined in Section 7
IMO, the document already covers those cases. Hence, no further change
is needed about this matter.
Do you agree ?
Best,
Mario
-MSK
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
