Hi Pawel,
thnks for your quick reply.
Il 16/11/2022 17:06, Pawel Kowalik ha scritto:
Hi Mario,
My feedback below.
Am 15.11.22 um 19:58 schrieb Mario Loffredo:
Hi Pawel,
thanks a lot for your review.
Please find my comments inline.
Il 15/11/2022 17:28, Pawel Kowalik ha scritto:
Hi Mario,
I reviewed this draft and have 2 questions:
- Reverse search property - the draft defines a fixed list of 4
search properties. Do I understand it right that adding some other
reverse search properties, which are to be interoperable, would
require a new RFC? Wouldn't it be better to have an IANA registry
for the search properties? Actually JSON Values Registry for
"redacted name" proposed in draft-ietf-regext-rdap-redacted has
almost the same semantic meaning: giving labels to certain JSONPaths.
[ML] The document allows the definition of custom reverse search
properties that are related to response extensions.
A server that includes additional fields in its objects in accordance
with the extensibility provisions of section 6 of [RFC7480] MAY
support the use of those fields in search conditions, in the same way
as for the search conditions defined in this section.
The 4 properties listed in the document match the recommendation
presented in Section 6 and cover the relationships between the three
searchable resource types currently available and the only possible
related resource type (i.e. entity) for which a reverse search
property hasn't already been defined (see. nsLdhName and nsIp for
domain-nameserver relationship).
Hence, the definition of further interoperable reverse search
properties based on other relationships is deferred to other
documents introducing new resource types (either searchable or related).
That said, a specific registry could certainly provide a centralized
list of reverse search properties thus improving interoperability.
Each entry in the registry could contain the following fields:
- Searchable resource type
- Related resource type
- Property name
- RDAP property path
- Reference
Do you agree ?
[PK] Yes, I would support this.
[ML] Good.
Is there any other proposal from everyone else?
- Discovery - how should the client learn which reverse search
properties are supported? Even those 4 defined in the draft are a
SHOULD requirement, so do not have to be supported. I see this
particular issue was discussed on the mailing list
https://mailarchive.ietf.org/arch/msg/regext/dgdPRRnQbWNhL0VVa_dq7xM-a5M/
but there was no continuation/conclusion.
Have used "SHOULD" because RDAP operators may support some of them,
not all.
WIth regard to the discussion, guess the conclusion was subordinated
to the outcomes of the other discussion about the extension identifiers.
Surely, we could quickly resume the discussion on that point.
I would suggest two possible solution:
1) Simply extend the help response with the array of supported
reverse search properties . Each object of the array should include
as many members as the registry fields. The first free fields should
be required while "RDAP property path" and "reference" could be set
only for custom properties (i.e not included in the registry) .
2) Follow Tom's approach of having different metadata endpoints. In
this case, the first two fields would be omitted and only "property
name" would be required.
[PK] I will be more inclined to support the first option with the help
response. This was also the approach taken in the RDAP OpenID draft so
it would offer some consistency between RDAP responses.
[ML] It is my preferred option too.
Nevertheless, would like to wait for Tom's opinion since he first
suggested to provide metadata about the reverse search properties.
@Tom: Does option 1 work for you too?
Best,
Mario
Pawel
--
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
