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 variantcurl -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]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
