Hi Tom,
please find my comments below prefixed with ML3.
Il 27/11/2022 22:49, Tom Harrison ha scritto:
Hi Mario,
On Fri, Nov 25, 2022 at 02:18:35PM +0100, Mario Loffredo wrote:
Il 24/11/2022 13:46, Tom Harrison ha scritto:
This is the part I (still) don't follow, sorry. The fact that the
label is a JSON value in the "reverse_search_properties" member of
the help response does not mean that the label needs to be
registered in the "RDAP JSON Values" registry, as best I can tell.
[ML2] Per my understanding of the introduction of RFC8126, any
constant defined in a protocol should be registered.
Since the "reverse_search_properties" member includes some
pre-defined JSON values, they can be added to the "RDAP JSON Values"
registry.
Many protocols make use of points of extensibility that use
constants to identify various protocol parameters. To ensure
that the values in these fields do not have conflicting uses and
to promote interoperability, their allocations are often
coordinated by a central record keeper.
Thanks, this was the part I was missing.
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.
I don't see how the entry could be made more generic with respect
to the related resource type. Even the current descriptions are
arguably too broad, since they do not limit the searchable object
type to one of domains, nameservers, or entities (being the three
searchable object types mentioned in section 2) but could e.g. be
read as applying to IP networks and ASNs as well. A separate
registry would fix this problem.
[ML3] I don't have any objection to opt for a separate registry.
Provided that there is no concern on using a separate registry from
other WG members, I'll come up with a new proposal on the mailing list
shortly.
[ML2] I would simply remove the reference to the "entity" object
class as in the following:
OLD
When the related resource type in a reverse search query is
"entity", it signals that the RDAP server supports the reverse
search based on the "fn"property of an entity associated with the
selected searchable resource type
NEW
It signals that the RDAP server supports the reverse search based on
the "fn"property of the given resource type associated with the
given searchable resource type
As I wrote in my previous mail, the reverse search property maps a
property of the related resource type in a reverse search query. The
searchable resource type is just needed to specify which reverse
query an RDAP operator is willing to support but this information is
included in the "reverse_search_properties" help response extension.
This approach would minimize the number entries compared to those
required for a registry including all the variables in the reverse
search query model.
In fact, having defined four reverse search properties and based on
the fact that the object class entity is associated to any RFC9083
object class, the pre-defined entries of a possible "Reverse Search
Properties" registry should be the following:
(domains|nameservers|entities) - entity - handle
(domains|nameservers|entities) - entity - fn
(domains|nameservers|entities) - entity - email
(domains|nameservers|entities) - entity - role
domains - nameserver - handle
Applying reverse search to ips and autnums searchable resource types
without declaring additional properties would add no entry to "RDAP
JSON Values" registry instead of eight additional entries in the
"Reverse Search Properties" registry.
My main concern here is that the reverse search document defines
behaviour for searchable object types that contain an 'entities'
member which is a list of entity-type objects, with the further
requirement that the 'fn' and 'email' searches only work correctly for
entity-type objects containing vCards (i.e. they won't work for
entity-type objects containing JSContact records). Defining the
registry property generically runs the risk of server implementors
adding reverse search properties for other object types (searchable or
related), without properly defining the behaviour for those searches.
Using the existing registry is fine (IMHO) if the text limits the
search to the cases considered by this document. (That does mean that
it's not possible to register more than one reverse search for a given
name, but maybe that's not a serious problem in practice, given that
implementors can just choose another name if necessary.)
But there's no way to prevent collisions from happening, if custom
reverse search properties are supported. If server S1 uses a
custom reverse search property named P, and server S2 then
registers with IANA a property with the same name, then there will
be a collision between the two names. It won't necessarily be
possible for S2 to confirm that P hasn't previously been used.
[ML2] Even now there is no real way to prevent collisions since
extension identifiers and JSON values are normally used for long
before they are registered.
Currently, only when an extension is considered stable, the related
identifier is registered.
Think that preventing RDAP operators to provide temporary reverse
search properties is incompatible with registries'policy of
releasing features on test platforms for a limited period before
running them in the live environment.
I can see the argument here, but the document doesn't say e.g. "custom
properties may only be used temporarily, or for testing purposes", so
it doesn't prevent two servers from having two custom properties with
the same name and different behaviour, each of which is intended to be
used long-term (i.e. neither server intends to register the property,
for whatever reason). If support for custom properties is omitted
from the document, then a server wanting to support a new reverse
search property temporarily or for testing can still do that, but the
lack of in-protocol support for that makes it clear that it's not
meant to be a long-term solution.
[ML3] Would like to reach the largest consensus on this point too.
Therefore, my proposal is to rearrange the "reverse_search_properties"
extension by removing "type" and keeping "links" anyway.
The "links" member could be used to provide additional information about
unregistered properties.
Would it work for you?
Best,
Mario
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 ?
I don't think it would be open to a server to do this under the
current document, because the JSONPath to "email" is defined in the
document itself. An example scenario where inconsistency could occur:
- S1, S2, and S3 implement support for JSContact.
- S1 decides to add a custom reverse search property called "name",
for matching a JSContact "name" (per 2.2.1 of that document), by
looking at the "given" and "surname" name components for the
JSContact "name".
- S2 also adds a custom reverse search property called "name", but
instead matches against the JSContact "fullName".
- S3 also adds a custom reverse search property called "name", in the
same manner as S2, but if a jCard is retrieved, it falls back to
using the same logic as that for an "fn" reverse search per the
current document.
I still think that custom properties are useful for the reasons above.
On the other hand, their possible misuse should be ruled somehow.
Here in the following a possible statement limiting the scope of custom
properties:
"A custom reverse search property MUST NOT collide with a registered reverse
search property and MUST NOT match an RDAP property, or any of its variants,
matched by a registered reverse search property."
Being JSContact fullName a variant of jCard fn, both S2 and S3 can't define
"name" as a custom property.
I still don't see how the document can require that a custom reverse
search property not collide with registered reverse search properties
as to its name or the members that it refers to, because the person
registering a new reverse seach property is not guaranteed to be aware
of all existing custom reverse search properties. The fact that a
given field is a 'variant' of another may not be obvious to
implementors, either. If any new reverse search that isn't covered by
the existing document has to be defined in an extension, then these
problems go away.
-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
