Hi Pawel and Maarten, Thanks for this, it's very helpful. I agree that on-the-wire payload size isn't much of a differentiator between the two models.
Nonetheless, I still feel that the array model has the edge over the object model, in that it's aligned with the way RDAP works elsewhere (e.g. entities), and the chat during the meeting seemed to agree with that. Therefore I will shortly be uploading a new version that incorporates Jasdip's feedback, and will then be asking the chairs to issue a WGLC. Cheers again, Gavin. > On 7 Nov 2025, at 21:39, Pawel Kowalik <[email protected]> > wrote: > > I made a small test on the performance of both approaches (yes, it's AI > generated code, I am not that fast), with inconclusive result (you may name > it a draw) so likely from this perspective I have to pull back my argument > that there is a major difference. > > On the usage side, I'm sure some people are and will be scripting RDAP with > curl and jq. > > This is how it would look like with object approach > > curl -s 'https://api.example.com/foo.example/map' | jq '.NS.TTL' > > This is the array variant > > curl -s 'https://api.example.com/foo.example/array' | jq '.[] | > select(.type[] == "NS") | .TTL' > > Both will work, one is a bit more complex than the other. The latter may > (theoretically) also deliver more than one result which might be surprising. > > From conversations I had it turns out, that operators have very distinct > (default) TTLs per record type, so in the end the benefits of array approach > may never appear. > Also, from the operator perspective it can be appealing to generate array > entries one by one and never "compress" them, because finding out which > records carry exactly the same data will be more code. > > Just few $0.01s. And no, I won't block this draft to proceed out of this > reason, but as I said I would like such decisions to be taken from the > perspective of running code and operational experience on both client and > server. > > [1] https://github.com/pawel-kow/RDAP_TTL_JSON_performance_test > > Kind Regards, > > Pawel > > On 07.11.25 10:50, Maarten Wullink wrote: >> Hi Gavin, >> >> after your presentation i got curious and i was looking into how compression >> affects both the array and object type of documents. >> i admit it was only a very quick look, but i found interestingly that the >> object type style response seems to be slightly smaller on the wire then the >> array type style response. >> even though there is duplicate info in the object style response. >> >> so maybe network load should not be used as argument when choosing a >> response style? >> although there is a tiny CPU cost for doing the compression/decompression. >> >> summary: >> >> network size: >> array style response: 220 bytes >> object style response: 216 bytes >> >> >> testing done using nginx and curl using command: >> curl -vv localhost:8080/ttl-object.json --silent -H "Accept-Encoding: >> gzip,deflate" --write-out "%{size_download}\n" --output /dev/null >> >> >> Best, >> >> Maarten >> >> >> >> —— array test file — >> >> { >> "objectClassName": "nameserver", >> "ldhName": "ns1.example.com", >> "ttl0_data": [ >> { >> "types": [ >> "A", >> "AAAA" >> ], >> "value": 86400, >> "remarks": [ >> { >> "description": [ >> "The .example registry does not permit TTL ", >> "values for nameservers to be changed." >> ] >> } >> ] >> } >> ] >> } >> >> >> — object test file — >> >> { >> "objectClassName": "nameserver", >> "ldhName": "ns1.example.com", >> "ttl0_data": { >> "A": { >> "value": 86400, >> "remarks": [ >> { >> "description": [ >> "The .example registry does not permit TTL ", >> "values for nameservers to be changed." >> ] >> } >> ] >> }, >> "AAAA": { >> "value": 86400, >> "remarks": [ >> { >> "description": [ >> "The .example registry does not permit TTL ", >> "values for nameservers to be changed." >> ] >> } >> ] >> } >> } >> } >> >> >> >> >> >>> Op 7 nov 2025, om 06:58 heeft [email protected] het volgende >>> geschreven: >>> >>> Internet-Draft draft-ietf-regext-rdap-ttl-extension-01.txt is now available. >>> It is a work item of the Registration Protocols Extensions (REGEXT) WG of >>> the >>> IETF. >>> >>> Title: RDAP Extension for DNS Time-To-Live (TTL Values) >>> Author: Gavin Brown >>> Name: draft-ietf-regext-rdap-ttl-extension-01.txt >>> Pages: 7 >>> Dates: 2025-11-07 >>> >>> Abstract: >>> >>> This document describes an extension to the Registration Data Access >>> Protocol ([RFC9083]) which allows the Time-To-Live (TTL) values for >>> relevant DNS record types to be included in RDAP responses. >>> >>> About this draft >>> >>> This note is to be removed before publishing as an RFC. >>> >>> The source for this draft, and an issue tracker, may can be found at >>> https://github.com/gbxyz/rdap-ttl-extension. >>> >>> The IETF datatracker status page for this Internet-Draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-ttl-extension/ >>> >>> There is also an HTMLized version available at: >>> https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-ttl-extension-01 >>> >>> A diff from the previous version is available at: >>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-ttl-extension-01 >>> >>> Internet-Drafts are also available by rsync at: >>> rsync.ietf.org::internet-drafts >>> >>> >>> _______________________________________________ >>> regext mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >> _______________________________________________ >> regext mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > _______________________________________________ > regext mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
