Hi Tom,
thank you for your feedback.
Please find my comments below.
Il 22/11/2022 14:00, Tom Harrison ha scritto:
Hi Mario,
On Mon, Nov 21, 2022 at 04:40:28PM +0100, Mario Loffredo wrote:
With regard to the registration of the reverse search properties, I
have opted for adding entries in the RDAP JSON Values registry
rather than defining an ad-hoc registry.
That is because servers must include the reverse search properties
they support in a specific RDAP help response extension.
Therefore, some JSON values related to the pre-defined properties
must be included in that registry anyway.
I don't follow this part. The document as it stands requires that the
supported reverse search properties be included in the
reverse_search_properties member of the help response, but that of
itself doesn't mean those properties need to be registered in the
"RDAP JSON Values" registry. More relevantly, relying on the "RDAP
JSON Values" registry in this way means that a given field name can be
used for only one reverse search, because the only data in the
registry entry aside from the type is the field name. I think it
would make more sense to define a separate registry for the reverse
search properties, including the additional fields from the metadata,
and potentially the JSONPath to the field value as well (though
omitting the JSONPath may ease the transition from one underlying data
format to another, such as with jCard and JSContact).
[ML] Since a reverse search property could be custom, think that the
document can't require the registration of any supported reverse search
property in the RDAP JSON Values registry.
(To know the reasons supporting the need of custom properties please see
the subsequent comment)
A reverse search property basically depends only on the related resource
type. I mean, the searchable resource type is needed just to identify
the RDAP relationship which a reverse search feature is based upon.
Substantially, what we need to do is to register a conventional label
mapping an RDAP response field that is referred to in a reverse search
query.
Since the label is also used as a JSON value in the
"reverse_search_properties" member of the help response, IMO it could be
sufficient to use the JSON Values registry rather than defining a new one.
The content of "reverse_search_properties" member disambiguates the
meaning of that labels in the context of the reverse search queries a
server supports, e.g. an RDAP server could provide
"domains/reverse_search/entity?handle" rather than
"nameservers/reverse_search/entity?handle" or both of them.
That said, I admit that the description of the "handle" entry as
presented in the document is tailored on the "entity" as related
resource type so, if there is consensus on this way to go, I'll make it
more generic.
Maybe it could be better to have more generic descriptions in the other
entries as well.
At the same time, I have no particular objection to define an ad-hoc
registry if there is much consensus on it.
Would like to know other opinions so that we can come to a shared solution.
Separately, given that the bar for registering extensions is so low
(turnaround is 1-2 weeks, IME), it doesn't seem as though
"custom"-type reverse search properties are worth the additional
complexity. Omitting these would also avoid the risk of different
servers implementing support for the same search in inconsistent ways,
which may be an issue when transitioning to JSContact, for example.
[ML ] Custom properties can be used in test phase and, anyway, in the
interval between the beginning of their usage and the time they are
registered once they are assumed to be stable (or the RDAP server is
released in the live environment)
Basically, a custom reverse search property is a temporary unregistered
value for a registered extension.
I would let them be allowed but I wonder If it's worth clarifying that
a custom reverse search property SHOULD not collide with a registered
reverse search property.
With regard to the meaning of your last sentence, I need a
clarification. Are you meaning that inconsistencies come up because, for
example, the "email" reverse search property maps the same JSON value
but identified through two different JSONPaths in the RDAP response ?
Mario
-Tom
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dott. Mario Loffredo
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
