On Mon, Sep 12, 2022, at 08:54, Antoin Verschuren wrote:
> Please review this document and indicate your support (a simple “+1” is
> sufficient) or concerns with the publication of this document by
> replying to this message on the list.
I should probably have said something earlier, sorry about this.
But I have a concern about §6 Implementation Considerations
as I think it glances over far too quickly on very important points.
I think it can be easy to expect reverse queries to generate "lots" of results,
but then all examples given ("restricting the
search functionality, limiting the rate of search requests according
to the user's authorization, truncating and paging the results, and
returning partial responses.") are not given details, which means there will
be left
to implementors and hence multiple incompatible solutions will emerge which
will make writing
a client more complex, for any case where it has to span multiple RDAP servers
(and then you are exactly in same territory as EPP extensions, too many of them
and too incompatible between them to easily write one client working with all
servers).
There is RFC 8977 "Registration Data Access Protocol (RDAP) Query Parameters
for Result
Sorting and Paging" but it is not even referenced
from this draft.
Same for RFC 8982 "Registration Data Access Protocol (RDAP) Partial Response",
shouldn't
be cited at least as a non-normative reference?
- "restricting the search functionality" does that mean by things related to
the protocol like constraints on `{searchable-resource-type}` or on
`{related-resource-type}` or on `<search-condition>` or by things external to
it, like rate-limit? How will a client discover that it got limited for any of
those reasons?
- "truncating and paging the results": maybe mention RFC 8977 and 8982
- "returning partial responses.": RFC 8982?
But how RFC 8982 would apply here since it is not necessarily the client asking
for limited
data in return but the server deciding to prune them in content or length?
Same question in fact for RFC 8977, that starts with client requesting specific
subsets and order.
I also dislike the mention of indexes here because this is specific terminology
of specific technologies and as such I don't believe an RFC describing a
protocol
should lay any assumption or give constraints on how implementers decide to
implement it.
--
Patrick Mevzek
p...@dotandco.com
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
