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.
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.
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
